NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Public Service Announcement - DHCP requests still an issue
You may notice this if you have Apple devices in your home....if you check the logs, you will see a LOT of DHCP request entries in there for Apple products!
Some have said it's due in part because Apple products by default have a setting to use a "Private IP address", which changes the advertised MAC address to reduce tracking across networks. However, this is not true - both in testing, and in theory. The private MAC address only changes when the device is power cycled, or the network is "forgotten" and reconnected - both of which are likely very infrequent for most devices.
In my case, maybe 5 devices have about 55-60 DHCP requests in a week - about 8 a day. But one iPad had 225 DHCP requests in the last week! That's 32 a DAY.
Luckily this seems to have no impact on network performance, which is why Netgear is not addressing it. You can also create a static IP address outside the router's address pool range for an offending device, if you are concerned. Maybe other network vendors have the same issue, I don't know.
9 Replies
SLK-Purdue might chime in on this as well. He did some checking into this as well.
We have brought this to NG attention.
Very interesting! It sure did look like DHCP protocol was being used for something out of the norm. In my router logs, DHCP messages are easily 95% or more of the messages - my original motivation to get of the unnecessary ones so I could really see what was happening with leases, see other messages more easily, etc.
donawalt wrote:
Luckily this seems to have no impact on network performance, which is why Netgear is not addressing it. You can also create a static IP address outside the router's address pool range for an offending device, if you are concerned.
Netgear cannot "address" a device repeatedly making DHCP requests. A device sends a DHCP request and the DHCP server responds. What would we have Netgear do? Not respond and let the device drop off the network?
A static IP address set on the device would stop the behavior, but using the LAN setup process to define an IP outside of the DHCP pool does not change the fact that the device does not follow the DHCP protocol and wait until the lease is half expired before asking to renew it. The device will still use DHCP to get that assigned IP.
I think you are making assumptions as to what is going on here, which of course may or may not be true. Having been in software development for over 40 years and being bitten by surprising bugs, and developing many test harnesses to validate code, I think of several reason besides your suggestion that could be the cause - none of this of course will we know what's the truth without access to the specific data going between device and router:
1 - a FW bug could be causing the lease information sent to the device to be incorrect;
2- DHCP requests could be rejected improperly (this seems plausible too because I have seen in the logs the DHCP requests often times come in a flurry, many requests within minutes;
3- bug/issue could be breaking the integrity of the DHCP request message, causing retries/reissues;
There could be device side bugs too - thinking it has to get another DHCP every time the device wakes up, or switches between router/satellite, malformed DHCP request messages, etc. etc. - many many possibilities
That said, wouldn't it be nice, especially since many of us were in the beta test group, for Netgear to actually investigate the issue and reply what they found - even if it's a problem on the device side. Then we would know and possibly know how to get around it. But we know that won't happen.
Good points. A bit strange that only Apple products appear to be affected, which might skew the investigation more toward the device than the DHCP server. But you are entirely correct. Examining the actual DHCP packets is the only methodology that would uncover much.
Investigating network issues with WiFi devices is so much more cumbersome than wired devices. It is almost trivial to mirror a switch port to a PC and use Wireshark to capture every DHCP packet that goes across the network (while ignoring everything else). WiFi clients are more of a hassle.
It is also frustrating that using the Debug feature to capture LAN/WAN traffic is not useful because of the limited space available to store the capture. My ancient RBR50 (version 1) has an option to store the debug log to the USB port (which newer Orbi models do not have.) I plugged a 32GB USB stick into the router and the LAN/WAN capture was capped at the most recent 2GB. (My goal was to "record everything" for several days and then look through it. Not happening!)
