R720 DHCP client bug

[david_fuchs]

I have a R720 running Unleashed, which gets its IP address from a Mikrotik router via DHCP, with a lease time of 1hr. The DHCP client implementation has a weird issue, where the DHCP lease is released before it is up, but the address continues being used. This is what I see in the router's logs:

Dec/30/2020 10:18:41 LAN assigned 10.1.10.250 to 24:79:2A:XX:XX:XX

Dec/30/2020 10:03:23 LAN deassigned 10.1.10.250 from 24:79:2A:XX:XX:XX

Dec/30/2020 09:18:36 LAN assigned 10.1.10.250 to 24:79:2A:XX:XX:XX

Dec/30/2020 09:03:08 LAN deassigned 10.1.10.250 from 24:79:2A:XX:XX:XX

etc, etc - with this exact pattern repeating every hour.

I suspect the 720 is attempting to refresh the lease after 45 minutes, but instead ends up simply terminating it. I have an R710 and R510 also, which do not exhibit this behavior. (In fact no other device on my network is behaving like this, which leads me to believe this is a Unleashed issue, rather than a Mikrotik one.)

For the most part the bug is benign (the R720 continues to use the DHCP assigned IP after terminating the lease), but I do occasionally experience spurious system reboots which I believe are the result of address collisions resulting from the use of an IP address after the lease has been terminated.

Making the lease for all the unleashed APs static seems to be a usable workaround, but a buggy DHCP client in a networking product that can lead to address collisions is something Ruckus should fix...

Unleashed version 200.9.10.4.212.

EDIT: Unlike I originally suspected this will not lead to address collisions. The reboots are due to something else. 

[david_fuchs · Accepted solution]

Yeah, Ruckus' DHCP client implementation is buggy. Or at least, strange. 

For whatever reason, the master AP - and only the master - sends a bunch of DHCPDISCOVER messages when it already has an active lease. The DHCP server dutifully responds with offers, which the AP ignores. Mikrotik's DHCP server interprets this as the client no longer being bound (it still respects the original lease time though, so my initial assumption that this could lead to address collisions was wrong).

Why does it broadcast DHCPDISCOVERs when it is already bound? 

[david_fuchs]

After wasting waaay too much time with this, my conclusion is that Unleashed does not like long-ish DHCP lease times. 

Playing around with the lease times, I found that short (10min) lease times cause no problems. With a 2hr lease time, the master AP actually let the lease expire and kept using the expired IP for ~30 minutes before finally sending another DHCP request. 

Pretty shoddy for a $1200 "enterprise grade" networking product. 

[david_fuchs · Accepted solution]

Sigh. The reboots, after all, do appear to be caused by Ruckus' faulty DHCP implementation, as a result of "heartbeats lost" events.

I see "heartbeats lost" events pretty much exactly the same time every hour, and, sure enough, they correspond exactly to when the master APs lease expire. 

Similar issues have already been reported here and here in the past. 

I have $10 gadgets that can do DHCP correctly. As already stated - a faulty DHCP implementation is shoddy for an "enterprise grade" networking appliance, and the fact that there are 2 year old reports of this same issue and Ruckus can't be bothered to fix the bug is beyond disappointing.