Fixing Litter-Robot 3 Connect network issues

The Litter-Robot 3 Connect is a rather well-designed self-cleaning cat litter box. I’d used a previous version about a decade ago, and am pleasantly surprised at how well the current incarnation works.

One of the main selling points of the LR3 is that it can be controlled via an Android app. There are a lot of complaints about the LR3 frequently dropping off the network, requiring a powercycle to reconnect.

I have a TP-Link TL-WR940N that has been flashed with OpenWRT, so I’m in a position to troubleshoot this problem. I turned hostapd debug up all the way, and started poking around.

I have identified three issues that cause the LR3 to stop working.

First, the LR3 can’t handle 802.11n. The wireless access point must be configured for legacy (802.11b/g) mode only. That fixes the “immediate disconnect” issue.

Second, Wireless Multimedia Mode (aka “WMM”, aka “WME”) must be disabled. WMM has a sub-feature called “Power Save Certification” (“APSD”), which (according to a Netgear techpub):

“… uses mechanisms from 802.11e and legacy 802.11,to save power (for battery powered equipment) and fine-tune power consumption.

“This feature of WMM to save power might cause disconnects under certain
conditions.”

That solves the “disconnect after thirty seconds” issue .

The third one is the most important: if the wireless access point hasn’t seen any packets from a client for awhile, it will send an empty data frame to the client to see if it is still there. By default, this packet is sent five minutes (300 seconds) after the last client packet was seen.

If the client doesn’t respond, the access point will deauthenticate the client. It is up to the client to re-authenticate.

The LR3 doesn’t respond to that empty data frame. The access point decides that it’s not there anymore, and administratively deauthenticates it. The LR3 firmware apparently doesn’t ever try to reauthenticate, and thus needs to be powercycled to get it back on the network.

The hostapd logs (edited for clarity) look like this:

13:57:25 x.x.x.x hostapd: wlan0: AP-STA-DISCONNECTED {LR3_MAC}
13:57:25 x.x.x.x hostapd: wlan0: STA {LR3_MAC} IEEE 802.11: authenticated
13:57:25 x.x.x.x hostapd: wlan0: STA {LR3_MAC} IEEE 802.11: associated (aid 1)
13:57:25 x.x.x.x hostapd: wlan0: AP-STA-CONNECTED {LR3_MAC}
13:57:25 x.x.x.x hostapd: wlan0: STA {LR3_MAC} WPA: pairwise key handshake completed (RSN)
13:58:36 x.x.x.x hostapd: wlan0: AP-STA-DISCONNECTED {LR3_MAC}
13:58:36 x.x.x.x hostapd: wlan0: STA {LR3_MAC} IEEE 802.11: authenticated
13:58:36 x.x.x.x hostapd: wlan0: STA {LR3_MAC} IEEE 802.11: associated (aid 1)
13:58:36 x.x.x.x hostapd: wlan0: AP-STA-CONNECTED {LR3_MAC}
13:58:36 x.x.x.x hostapd: wlan0: STA {LR3_MAC} WPA: pairwise key handshake completed (RSN)
14:04:22 x.x.x.x hostapd: wlan0: AP-STA-DISCONNECTED {LR3_MAC}
14:04:22 x.x.x.x hostapd: wlan0: STA {LR3_MAC} IEEE 802.11: disassociated due to inactivity
14:04:23 x.x.x.x hostapd: wlan0: STA {LR3_MAC} IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)

And there it is. A tad over five minutes after the LR3 authenticates/associates, the access point kicks it off the network because the LR3 ignored the empty-frame query.

(Side note: the LR3’s association/authentication logic appears to be very broken. When it first connects, it will connect/authenticate/disconnect/reauthenticate at randomly-chosen one/three/five/fifteen minute intervals for awhile … then it will go silent for long periods of time, then start the dance again)

Increasing the timeout from 300 seconds to 3600 seconds (i.e., one hour) solved the problem here. The LR3 will perform the connect/authenticate/disconnect/reauthenticate dance at least once an hour, so the maximum inactivity timer won’t be exceeded.

In OpenWRT, set “max_inactivity” to ‘3600’ in /etc/config/wireless. Regular wireless access points should have a similar setting buried somewhere in the “Advanced” tab.

I’ve passed along these findings to Whisker Support. They thanked me for the information, and say that they will be advising customers with connection issues to tweak the wireless access point with the above settings.

Sadly, there won’t be a firmware patch for the LR3. From the conversation with support:

Whisker: Our engineering team wanted to thank you as well. They said that we have completely overhauled ESP32 Firmware for future models. In the meantime, we will be recommending customers to disable WMN for LR3 units.

Me: I’m glad to hear that the team has rewritten the ESP32 firmware. Are there plans to make it available for the LR3, or will it be only for future models?

Whisker: It will only be for future models.

… so LR3 owners that need stable network connectivity will need to configure their access point as outlined above.

The LR3 controller is an ESP32, and there is an apparently stalled replacement firmware project. The next time I have the LR3 open for cleaning, I might pull the controller board and see if I can pull the firmware from the ESP32. Reverse-engineering can be fun.

About Chris Kobayashi

I'm a security systems engineer, specializing in UNIX, network, and physical security. I'm in Tokyo, and I'm mostly retired now. I'm well-versed in both electrical and software engineering, with a particular interest in old computers and game consoles. You can contact me here.
This entry was posted in Uncategorized. Bookmark the permalink.

1 Response to Fixing Litter-Robot 3 Connect network issues

  1. Jason says:

    Really appreciate you doing all the research and posting this. Just purchased the LR3 and every few days it kept disconnecting. Installed DD-WRT on the router and updated the settings as posted. Two weeks now and the darn thing has stayed connected – no more power cycling! Thanks!

Leave a Reply

Your email address will not be published. Required fields are marked *