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? 

[eizens_putnins]

If your switch reports power used by R720 as 8W, something is seriously wrong with your setup, and R720 runs in some fail-save 802.3af-compatible  mode. This most probably is the very reason of your unexpected reboots -- Ruckus APs almost never reboot without reason.

Max power consumption is always more than average, of cause, but not that much, and anyway insufficient power at boot switches AP to lower performance mode in the best case, in the worst -- prevents booting or results in different errors.

Max power consumption for R720 is:

in 802.3af mode 12.95 W

802.3at mode      25.5 W

Full mode            33.5 W

So I strongly recommend to provide proper power to R720 APs, or at least configure APs in compatible with 802.3at power way from controller (disable second Ethernet port and USB port). Only when this is done, it makes sense to look for any other issues (which most probably will disappear than).

Using R720 with insufficient power just doesn't make sense -- PoE injectors doesn't cost much, and I would definitely not want  to limit capability of  rather expensive APs because of low power. If you can't provide proper power, it would be better to use  R510 APs (which are much cheaper), as this would provide probably same or even better performance, than you have now with R720 in degradeted mode.

[david_fuchs]

Thanks for the tips! The 720 claims it gets power via 802.3at:

[david_fuchs]

Also, the 8-10W range seems to be about right.

[david_fuchs]

It gets weirder... I changed the master AP to the R710 - lo and behold, now that device is exhibiting the same weird DHCP behavior. 

I noticed that both APs use the same hostname (the name configured under "Admin & Services -> System -> System Info", rather than the individual name set for each AP under "Access Points -> Edit -> General -> Device Name"). Maybe that is confusing the DHCP server...

[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?