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? 

[dave_raines_86z]

Are these Apple devices on OS 14.2 or higher with private IP enables on the SSID whereas it spoofs a fake mac address?

[david_fuchs]

No, these aren't some random devices connected to the AP - it's the AP itself that is misbehaving.

[eizens_putnins]

This sounds impossible -- normally router always assigns same IP to same MAC, if this device is up, never assigns to same device different address, and also it  never assigns that previously used IP address to any different device, as far as AP was not off-line for a long period of time. I have many installations, where Ruckus AP get IP from Mikrotik routers, but not exactly same configuration -- R720 in unleashed configuration, we mostly use only vSZ managed different models.

        Anyway, as a first step I would propose to upgrade Mikrotik router to newest firmware, as what you describe doesn't look an AP issue -- router should never assign IP to any device, if such IP is reachable on network. It should be marked as bad IP and not used instead. Upgrade is done by couple of clicks - in menu System/packages click on "download and upgrade".

      I have seen issues with DHCP on some networks, when ARP proxy feature was enabled on WLAN, as DHCP server understood that as assigned address, so check if this option is checked and try disable it.

Fact that different model APs doesn't show same issue may be related with fact that R720 consumes much more power and uses 2.5Gbps-capable port.

       Next-- how is your AP powered? Reboots and any other issues are very possible if there is not enough power for AP -- if you use 802.3at ports, you need to disable second Ethernet port and USB port. I would recommend to use at least 50W PoE injector.

     Another thing to check is Ethernet port speed and connection quality. R720 supports 2.5GBps port speed, and with low quality cable connection, or low quality PoE injector,  you may easy get issues. For example, using non-gigabit PoE injector guarantees AP reboots with Kernel panic messages in the log...

Hope it helps,

[david_fuchs]

Thanks! 

The occasional reboots I'm experiencing are very annoying, but may have nothing to do with the DHCP issue I reported.

Regardless of the reboot issue, the fact that the R720 releases its IP address but then keeps using it anyway is definitely not a correct implementation of DHCP, and Ruckus needs to fix it. I am reasonably sure that this is a Ruckus issue, and not a Mikrotik one, as no other device on my network - including 2 other Ruckus APs - behave this way. I agree that it's unlikely that the DHCP server will re-assign the IP to a different device in the short window where the AP is using it illegitimately (unless something really funky is happening, like some other device impersonating that same MAC - unlikely), but still - it's broken.

My access points are connected to a POE switch, via 2.5G 802.3at (for the 720). Load is reported as somewhere in the 8-10W range, well within the PoE+ specs and well below the 300W budget of the switch. The mikrotik router is up-to-date. The AP's reboot reason is "last disconnected reason [Heartbeat Loss]" - again, any connection to the DHCP issue was just wild speculation on my part.