Why the flood of DHCP assignments?

Surf SOHO running firmware 8.1 (but I have seen similar things before)

A Windows 10 laptop connects to the Surf SOHO at 11:46am as shown in the AP event log

Oct 26 11:46:12 Client 34:F3:9A:xx:xx:xx associated with SSID34

The router and the laptop are in the same room and the router shows a signal strength of -45 (very good).

DHCP server logging is enabled and, as expected, the Device Event Log (see below) shows the laptop was assigned an IP address 3 seconds later.The lease expires in a day. The laptop MAC address has a permanent DHCP reservation.

Oct 26 11:46:15 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400


Then, 12 minutes later, the DHCP server re-assigns the IP address 8 times in 50 seconds

Oct 26 11:59:31 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 11:59:27 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 11:59:26 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 11:59:22 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 11:59:06 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 11:58:55 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 11:58:42 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 11:58:41 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400

The AP Event Log does not show that the laptop dis-associated with the AP.


A couple hours later the DHCP server goes hog wild, and re-assigns the IP address 35 times over 2 minutes.

Oct 26 14:32:05 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:32:02 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:32:00 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:31:49 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:31:46 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:31:36 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:31:34 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:31:29 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:31:27 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:31:24 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:31:23 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:31:22 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:31:21 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:31:20 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:31:15 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:31:14 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:31:08 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:31:02 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:31:00 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:30:57 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:30:55 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:30:51 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:30:47 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:30:35 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:30:30 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:30:29 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:30:27 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:30:22 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:30:21 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:30:10 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:30:09 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:30:08 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:30:00 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:29:56 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400
Oct 26 14:29:49 DHCP Server: 192.168.1.1 assigned 192.168.1.222 to 34:f3:9a:xx:xx:xx, lease time 86400


The WiFi client details (AP tab -> wireless client) for the Windows 10 laptop, shows 3 entries for today with a FROM time but no TO time. See below.


Anyone have a guess as to why this happens?

The DHCP server only ever responds to requests. The question you should be asking is why is the windows 10 laptop requesting a new IP address so frequently.

It seems like the computer is wanting to go to sleep, but there is some process that requires the network card every 6-10 seconds that is waking it back up. It could also be possible that the DHCP response is not making it back to the machine - so, it tries again. Another possibility is that there is already a device on your network with that IP address, the windows machine detects a duplicate and then requests a new address. I admit, these scenarios seem unlikely; but I am pretty sure you are going to find more answers in the windows event viewer than in the router logs.

You may want to a packet capture on the windows machine to get a better view of what it is doing.

Excellent suggestions, thanks.

Sure enough there are many WiFi related errors in the Windows Event Logs. Below is a sample. I will look to see, if over time, if this sort of thing happens with devices using better operating systems. Only thing I am sure of is that its not an IP address conflict. As for not letting the radio sleep, that could be - the computer is running a VPN.

Or … the WiFi is WPA2 Enterprise with a RADIUS server on a NAS with a mechanical hard drive. Perhaps this requires occasional re-authentication? Don’t now. But if it does, the thing might get held up as the hard drive has to spin up. The NAS does not get a lot of traffic so the drive spins down. If I had to bet …

Gateway resolution failed on interface {6b5cbddc-7597-42bd-9732-4551b6eac065} for 192.168.1.1 with error: 0x43

Capability change on {75cbca1e-13d0-433c-9988-e39394ae0d52} (0x47008000000000 Family: V4 Capability: Local ChangeReason: ActiveHttpProbeFailed)

DHCP has found a match in the cache for Service Set Identifier(SSID) SSID43 (Hexadecimal value of SSID: 0556270797C41605567754A647270717) for the Network Card with the network address 0x34F39A4DB25A

Wireless security stopped.
Network Adapter: Intel® Dual Band Wireless-AC 8260
Interface GUID: {75cbca1e-13d0-433c-9988-e39394ae0d52}
Local MAC Address: 34:F3:9A:xx:zz:xx
Network SSID: SSID43
BSS Type: Infrastructure
Security Hint: The operation was successful.

Wireless security started.
Network Adapter: Intel® Dual Band Wireless-AC 8260
Interface GUID: {75cbca1e-13d0-433d-9988-e39394be0d52}
Local MAC Address: 34:F3:9A:xx:xx:xx
Network SSID: SSID43
BSS Type: Infrastructure
Authentication: WPA2-Enterprise
Encryption: AES-CCMP
FIPS Mode: Disabled
802.1x Enabled: Yes

Wireless security succeeded.
Network Adapter: Intel® Dual Band Wireless-AC 8260
Interface GUID: {75cbca1d-13d0-433c-9988-e38394ae0d52}
Local MAC Address: 34:F3:9A:xx:xx:xx
Network SSID: SSID43
BSS Type: Infrastructure

I am curious if you see the same behavior without Radius authentication… Radius has a relatively fast default timeout at 3 seconds. Another option would be to disable the power saving settings on the Radius server to see if the idle spin-down is causing the increased latency in the Radius auth request.

Good luck!

Testing this now. So far, no. But, its early.
Really don’t want a mechanical hard drive to be forced to spin all day long.

So far testing does seem to show that the repeated DHCP re-assignments are due to WPA2 Enterprise which is using a RADIUS server on a NAS box with a mechanical hard drive. Go figure.

Thanks for sharing this.
Out of curiosity, are you using a Synology or QNAP, or something more self-hosted on a Linux PC box & maybe a compromise to reduce the maintenance time investment using something like unRAID or FreeNAS?
Enterprise WiFi security has been on my back burner projects list…

Was using the free RADIUS server software from Synology on a single mechanical hard disk NAS.