Rachio Gen 3 frequently offline / DHCP failure

Hi.

I have emailed the support box twice about this but not received any reply whatsoever. Posting here for visibility. The issue persists and now when the device waters while offline it doesn’t show properly in the calendar (although it does appear in history).

I’m having issues with my Rachio Gen3 sporadically not picking up an IP address from the DHCP server. This manifests as the controller going offline for extended periods of time. Sometimes the only way to bring it back is to power cycle it and maybe the WiFi AP as well.

Very similar to the problem experienced by this user:

DHCP Logs from Router:
17:52:04.236812 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 58:d5:0a:bd:27:b0, length 300
17:52:05.238235 IP 192.168.99.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
17:52:52.425803 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 58:d5:0a:bd:27:b0, length 300
17:52:52.426611 IP 192.168.99.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
17:52:57.425302 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 58:d5:0a:bd:27:b0, length 300
17:52:57.426086 IP 192.168.99.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
17:53:05.425515 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 58:d5:0a:bd:27:b0, length 300
17:53:05.426320 IP 192.168.99.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
17:53:19.027327 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 58:d5:0a:bd:27:b0, length 300
17:53:19.028084 IP 192.168.99.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
17:53:23.021558 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 58:d5:0a:bd:27:b0, length 300
17:53:23.022348 IP 192.168.99.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
17:53:32.027259 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 58:d5:0a:bd:27:b0, length 300
17:53:32.027983 IP 192.168.99.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
17:54:21.015560 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 58:d5:0a:bd:27:b0, length 300
17:54:21.016414 IP 192.168.99.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
17:55:26.008931 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 58:d5:0a:bd:27:b0, length 300
17:55:27.010392 IP 192.168.99.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
17:56:10.162058 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 58:d5:0a:bd:27:b0, length 300
17:56:10.162816 IP 192.168.99.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
17:56:15.155670 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 58:d5:0a:bd:27:b0, length 300
17:56:15.156381 IP 192.168.99.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
17:56:23.154885 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 58:d5:0a:bd:27:b0, length 300
17:56:23.155615 IP 192.168.99.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
17:56:36.317638 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 58:d5:0a:bd:27:b0, length 300
17:56:36.318363 IP 192.168.99.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
17:56:40.314144 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 58:d5:0a:bd:27:b0, length 300
17:56:40.314956 IP 192.168.99.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
17:56:49.314132 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 58:d5:0a:bd:27:b0, length 300
17:56:49.315043 IP 192.168.99.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
17:57:05.311458 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 58:d5:0a:bd:27:b0, length 300
17:57:05.312279 IP 192.168.99.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
17:57:37.312160 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 58:d5:0a:bd:27:b0, length 300
17:57:37.312941 IP 192.168.99.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
17:58:41.301388 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 58:d5:0a:bd:27:b0, length 300
17:58:42.302848 IP 192.168.99.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
17:59:26.905857 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 58:d5:0a:bd:27:b0, length 300
17:59:26.906590 IP 192.168.99.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
17:59:26.909426 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 58:d5:0a:bd:27:b0, length 300
17:59:26.910153 IP 192.168.99.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
*No further requests after this point. Controller came back online but had been offline on/off sporadically for several days.

You can see that in the period of a very short space of time the device requested a DHCP address multiple times, and the router sent responses.

Also attached -

  1. Screenshots of WiFi AP page showing that the Rachio is connected to the AP, but is not accepting an IP and therefore taking a 169.254.x.x IP address. This also shows that the signal strength is -69dB, which is plenty strong enough for a reliable connection. The controller is close to a garage door opener device which does not have any of the same connectivity issues.

  2. Screenshot from router showing the DHCP address leased to the device (should it decide to accept it); and

  3. Another screenshot from the AP a short while later this morning, when the device finally accepted the IP and came back online.

Any advice you can offer would be appreciated. Let me know if you’d like me to run any tests on my end or grant you access to logs etc.

I see you are using a TPlink AP, are you running it off of a managed switch by any chance?
Also, I find it useful to explicitly allow traffic to / from broadcast address 255.255.255.255 with firewall rules.

Thank you for replying.

The AP is plugged directly into the router which is a UBNT device so depending on how you think of it you might call a managed switch?

I do not suspect any firewall issues because I can see the DHCP packets coming in and leaving the router, and because literally no other device behaves this way.

Is there a debugging log we can pull to see what the Rachio sees on its end?

Do you have IoT SSID on a different / dedicated VLAN?

Yes, I do. The tagging is done by the AP and the router has two DHCP servers running, one for each VLAN. The Rachio service itself would not have knowledge of any other network or even that it is on a ‘special’ VLAN.

Unfortunately I’ve never used edgerouter myself (as I prefer pfsense), seems there are some issues with switch0 (default) interface and other vlans, see if this video helps:

TLDR: looks like this is a known issue (# 10 here), whereas you’ll need to configure your default vlan from switch0 to switch0.1 in order to use additional vlan tags.

I believe that this problem is caused by Rachio using the BROADCAST flag in its DHCPDISCOVER (and DHCPREQUEST) packets. This requests the DHCP server to send the reply as a broadcast packet. It would normally be used by older devices that are incapable of receiving unicast packets before the protocol stack has been set up. IMO, it’s very unlikely that Rachio is one of them; if they simply turned the bit off (in new firmware releases) the problem would be permanently fixed. However, if their hardware really does have this limitation, we need to do something at the customer end. See


or see https://tools.ietf.org/html/rfc2131 for the gory details.

Broadcast packets are expensive on Wi-Fi for several reasons. Among others, they must be sent from all APs on the LAN, as well as at a low speed. There is some useful detail here:

Some APs ‘handle’ the issue with a ‘block LAN to WLAN broadcast’ option, which is on by default. If that’s your case (the controller eventually hears the reply from a more distant AP), turning this off should fix your problem.

I’m not familiar with EdgeOS, but mapping the Rachio to a static IP may cause it to issue an indefinite or much longer lease time, which may mitigate or eliminate the trouble.

If neither of the above are applicable, and assuming that you have far fewer devices than the subnet allows for, i.e. you have no need to reuse LAN addresses, consider setting the DHCP lease time to e.g. 90 days (and overriding any shorter time that the device requests). I’d expect this to greatly reduce connectivity loss, unless the requests you are seeing are a result of having lost association / authentication at the Wi-Fi level, rather than the lease having run out.

1 Like

Interesting, I was always wondering why Rachio was effected whereas others seemingly were not. Broadcast flag may explain it.

Another thought: If you have two or more APs on the same channel or on overlapping channels, it’s possible that they transmit the broadcast packet simultaneously and interfere with each other. There is no acknowledgement for broadcast, so they won’t know to retransmit.