Rachio 3e here.
It seems that the Rachio is doing something unique when it comes to DHCP negotiation. My wireless controller sees the rachio, it’s connected to a 2.4ghz SSID. My router sees the DHCP requests and offers a valid IP. Then, the rachio self assigns.
If i use a different WAP on the same VLAN it works fine.
WAP - TP-Link eap225
Router - OPNSense latest version.
Any ideas on what the EAP might be doing to block negotiations?
Thanks
RouteThis code is F2UZBHDT.
I assume that you are seeing DHCPDISCOVER messages from Rachio, to which the router is replying with DHCPOFFER, but that is not ‘heard’ and Rachio sends the Discover repeatedly.
Unfortunately, Rachio sends DHCPDISCOVER with the Broadcast flag set, which means that your OPNSense is sending DHCPOFFER as a layer 2 broadcast, which I suspect is being blocked by the TP-Link. Some APs block LAN-to-WLAN broadcast, as it’s usually not needed and consumes a lot of airtime. Possibly, if you have SSID Isolation on, turning it off may help. Or, there might be newer firmware available for the AP that gives you explicit control of how broadcasts are handled.
You can confirm or refute this hypothesis by capturing traffic on a PC connected by Wi-Fi to the SSID in question. If you see the Discover packets from Rachio but don’t see Offer from the AP, then this is your issue.
I think you nailed it. Let me dig into the WAP configs and see what’s up.
Update:
After a bit of digging, i couldn’t find anything that really caught my eye. I decided to see if disabling “airtime fairness” would have an impact and sure enough, it did.
Now my Rachio, along with another device that seemed to be in the same situation, are good to go.
Thanks!
I’m speechless. I was in the same situation a while back and forgot that I’ve disabled that setting “airtime fairness” in addition to doing a ton of other things trying to determine why the DHCP packets were dropped. I attributed the solution to rebooting my managed switch, which I now realize was not it at all. It seems to be a common issue with TpLink APs, but until now we were not sure what was causing an issue. I wish TpLink made it clearer that “fairness” was effecting the broadcast traffic (in hindsight, it makes sense as broadcast is the slowest kind of traffic there is).
@franz, please look into omitting broadcast flag from your DHCP requests, or at least allow us to set a static IP. I’m glad we now have a solution, but it’s frustrating that Rachio controllers are affected more than a ton of other devices on the same wifi / network.
Something else that was happening while i was troubleshooting this is pretty dissapointing. While the controller had a self assigned IP, the app and website both showed the controller as being online (green wifi icon). The only way i knew it was not communicating was when i tried to manually run zones. The method for determining if a controller is online or not needs to be revised.
In my case, Rachio would get an IP from DHCP the first time it would connect, I think the core problem is that once it knew the IP and Mac of the DHCP server, it continued using broadcast messages for lease renewal.
Ill see if the firmware team has any ideas around this!
Thank you - the ultimate fix will be for the DHCP requests to confirm in format to how pretty much every other wireless device operates i.e. to stop using the BROADCAST flag as Gene points out.