NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
DHCP not working properly, log filling with DHCP assignments
So I have noticed that after rebooting, sometimes DHCP doesn't work properly. No devices that use DHCP, whether they have a DHCP reservation or not, get DHCP assigned IP addresses. Whenever this problem is occurring, my log fills up with DHCP entries, for the same devices, over and over and over. All of the devices that appear are only the ones that need DHCP.
Rebooting an extra time or two usually resolves it. But of course that's not terribly friendly to the devices that have static IP's (as many as I can possibly set to static) that are working just fine.
Tonight I tried something different - I went to Advanced, Setup, LAN, and turned off DHCP, clicked Apply, then waited, then turned DHCP back on, clicked apply. My devices started getting their correct IP's - those with reservations (including both my satellites!) got their reserved IP's, and devices with no reservations got addresses from the standard range. And my log stopped getting filled up with DHCP entries. So at least there's a much less disruptive workaround to this problem.
So apparently, after some reboots, DHCP gets messed up. I'm guessing that turning off DHCP then turning it back on again is effectively "restarting" the DHCP service, which obviously happens with a full reboot as well, but this seems to be far less disruptive to the rest of the devices on my network that don't need DHCP.
Here's my firmware info - I'm running the latest:
| Model Name | Device Name | Current Version | Status | |
| Router | RBR50 | RBR50 | V2.2.1.210 | No new firmware version available. |
| Satellite | RBS50 | Sat2 | V2.2.1.210 | No new firmware version available. |
| Satellite | RBS50 | Sat1 | V2.2.1.210 | No new firmware version available. |
I also captured traffic using Wireshark both before and after restarting DHCP. The main difference I noticed was that while it was not working, most of the entries that did not originate from the router were almost all DHCP Discover packets. Only an occassional DHCP Request. After restarting DHCP, there were many more DHCP Requests. When looking at the packets that originated from the router, before the restart there were very few DHCP Ack packets. After the restart there were many more DHCP Ack packets.
So, I don't know a lot about the internal details of DHCP, but I'm guessing it works something likes this:
Client DHCP Server
DHCP Discover--------->
<-----------------DHCP Offer
DHCP Request--------->
<-----------------DHCP Ack
To me, it seems that the problem lies in the DHCP Offer packet sent in response to the DHCP Discover packet from the client. The client, for whatever reason, either doesn't get the DHCP Offer packet, or can't read it properly.
I did notice that a few devices did send DHCP Requests while DHCP was not working for most devices, and there was a DHCP Ack sent back. So this may not affect all devices. The one device that I saw worked was my Samsung Family Hub refrigerator, which I believe runs Tizen. Apple iPhones cannot get DHCP IP addresses when this is not working.
I'd prefer not to upload my capture logs here, as there is obviously very detailed information about the devices on my network. But I'd be happy to examine anything in more detail.
I think I'm providing some good info here, feel free to ask more questions!
22 Replies
I wonder if by cycling the DHCP option off then on, you are actually reinitializing some system variables/processes that became incorrectly set. If so, this would be a good indication for system engineers to relook at that section of code logic.
What is the Mfr and model# of the ethernet switch if one is in the configuration.
What devices, wired and wireless do you have all connected to the system?
How are the satellite(s) connected?
Has a full factory reset been performed after you updated to v210?
What happens if you change the default IP address pool to 192.168.1.100 to .200?
RIP version enabled?
I would file a support ticket here:
https://www.netgear.com/mynetgear/registration/login.aspx
DougB628 wrote:
So I have noticed that after rebooting, sometimes DHCP doesn't work properly. No devices that use DHCP, whether they have a DHCP reservation or not, get DHCP assigned IP addresses. Whenever this problem is occurring, my log fills up with DHCP entries, for the same devices, over and over and over. All of the devices that appear are only the ones that need DHCP.
Rebooting an extra time or two usually resolves it. But of course that's not terribly friendly to the devices that have static IP's (as many as I can possibly set to static) that are working just fine.
Tonight I tried something different - I went to Advanced, Setup, LAN, and turned off DHCP, clicked Apply, then waited, then turned DHCP back on, clicked apply. My devices started getting their correct IP's - those with reservations (including both my satellites!) got their reserved IP's, and devices with no reservations got addresses from the standard range. And my log stopped getting filled up with DHCP entries. So at least there's a much less disruptive workaround to this problem.
So apparently, after some reboots, DHCP gets messed up. I'm guessing that turning off DHCP then turning it back on again is effectively "restarting" the DHCP service, which obviously happens with a full reboot as well, but this seems to be far less disruptive to the rest of the devices on my network that don't need DHCP.
Here's my firmware info - I'm running the latest:
Model Name Device Name Current Version Status Router RBR50 RBR50 V2.2.1.210 No new firmware version available. Satellite RBS50 Sat2 V2.2.1.210 No new firmware version available. Satellite RBS50 Sat1 V2.2.1.210 No new firmware version available. I also captured traffic using Wireshark both before and after restarting DHCP. The main difference I noticed was that while it was not working, most of the entries that did not originate from the router were almost all DHCP Discover packets. Only an occassional DHCP Request. After restarting DHCP, there were many more DHCP Requests. When looking at the packets that originated from the router, before the restart there were very few DHCP Ack packets. After the restart there were many more DHCP Ack packets.
So, I don't know a lot about the internal details of DHCP, but I'm guessing it works something likes this:
Client DHCP Server
DHCP Discover--------->
<-----------------DHCP Offer
DHCP Request--------->
<-----------------DHCP Ack
To me, it seems that the problem lies in the DHCP Offer packet sent in response to the DHCP Discover packet from the client. The client, for whatever reason, either doesn't get the DHCP Offer packet, or can't read it properly.
I did notice that a few devices did send DHCP Requests while DHCP was not working for most devices, and there was a DHCP Ack sent back. So this may not affect all devices. The one device that I saw worked was my Samsung Family Hub refrigerator, which I believe runs Tizen. Apple iPhones cannot get DHCP IP addresses when this is not working.
I'd prefer not to upload my capture logs here, as there is obviously very detailed information about the devices on my network. But I'd be happy to examine anything in more detail.
I think I'm providing some good info here, feel free to ask more questions!
There are multiple switches in my network - how does that pertain to a problem related to DHCP? I have both wired and wireless devices that do not get DHCP addresses when this is not working correctly.
I have 40+ devices on my network - are you asking me to list all of them?
Satellites are connected via wireless backhaul.
My RBR50 and first RBS50 were purchased together as a kit. The second RBS50 was purchased several weeks later. A full factory reset has never been performed on any of them, and I know that all of them did an automatic upgrade to v210 after their first boot up. I can try to set some time soon to do that - it will need to be coordinated with the family, as they tend to get pretty irritated when the internet is not available.
Changing the default IP address pool for .100 to .200 is not a viable option - I have an addressing scheme in use that has many static IPs in that range.
RIP Version is disabled. I see options for RIP_1, RIP_2B, RIP_2M. Should I try one of those?
A follow up from my earlier discovery - the process of turning off DHCP, applying change, and turning it back on, applying change is not a guaranteed fix. It is as reliable as the reboots, but it is still better than rebooting. Last night I had to turn DHCP off/on a few times before it stablized.
I setup a Raspberry Pi last night with DNSMasq, and I am *very* close to just using that for my DHCP to solve this and the fact that the Orbi won't let me set a subnet mask of 255.255.252.0. Plus I'll get the benefit of DNS caching. I have a couple more Raspberry Pi's around from some set top box experiments, so I'll even be able to have redundancy of having two or three of them. Seems that it shouldn't be necessary to have to do that with a mesh wifi system that I have now spent well over $500 on...
There are user posts about some switches not working well with Orbi. So reason for asking. Please let us know Mfr and model please.
A reset should be performed on the entire system after a FW update. I've seen issues with autoupdate or even a manual FW update not working well untill a factory reset and setup from scratch as been performed. Works after that.
When you say "Static IP in that range" do you mean IP address reservations set ON the router or Static IP set ON devices. Static IPs are set ON devices OUTSIDE of the routers default IP address pool. IP address reservations are set WITHIN the routers default IP address pool. Just want to be clear on this.
You can try one of the RIP versions however for most home configurations, its not needed. However you can try and see. Disable it if you don't see any changes.
If you have a RPi for DHCP and DNS, why not configure the Orbi for AP mode. Would make things much easier.
Over all, DHCP works well, I use a custom DCHP range for mine. I haven't seen issues like this. Non Managed switches only.
DougB628 wrote:
...........
To me, it seems that the problem lies in the DHCP Offer packet sent in response to the DHCP Discover packet from the client. The client, for whatever reason, either doesn't get the DHCP Offer packet, or can't read it properly.
..........
DougB628 Thanks for doing a thourough troubleshooting anf for the good analysis.
I'd look at this differently. I think that the fact that Orbi does not reply to the DHCP Discover packets makes me think that those packets were really sent to another element in the network. Does the ISP modem/router provide any routing functionality? Do you have any other network elements (like extenders, repeaters, ...) that can supply DHCP functionality that can cause such an issue?
My cable modem is an Arris Surfboard. I purchased it myself from Amazon, it was not provided by my ISP. It definitely has no DHCP functionality. No other devices on the network that can provide DHCP, at least not that is enabled. The other indication that it is the Orbi's problem is that it resolves itself after resetting DHCP a few times. Sometimes only one reset (turn off DHCP, apply, turn on DHCP, apply) is needed, other times it's two, three, or four times. Once it stablizes, it's 100% good for quite a while. I'm still learning what changes I make can trigger at least partial resets of things, and there are definitely things that appear to reset DHCP (I see my phone lose its wifi in these cases), and then it's a crap shoot as to whether it will come back stable or not. So I've definitely learned to leave everything alone if its working. I need to build trust back up from my wife - at this point she thinks either that I just want to play with it, and don't give a damn how it affects everyone, or that I truly have no clue what I'm doing. I know the first one is not right... jury is still out on the second...
What is the Mfr and model# of the ethernet switches are you using in the configuration?
DougB628 wrote:
My cable modem is an Arris Surfboard. I purchased it myself from Amazon, it was not provided by my ISP. It definitely has no DHCP functionality. No other devices on the network that can provide DHCP, at least not that is enabled. The other indication that it is the Orbi's problem is that it resolves itself after resetting DHCP a few times. Sometimes only one reset (turn off DHCP, apply, turn on DHCP, apply) is needed, other times it's two, three, or four times. Once it stablizes, it's 100% good for quite a while. I'm still learning what changes I make can trigger at least partial resets of things, and there are definitely things that appear to reset DHCP (I see my phone lose its wifi in these cases), and then it's a crap shoot as to whether it will come back stable or not. So I've definitely learned to leave everything alone if its working. I need to build trust back up from my wife - at this point she thinks either that I just want to play with it, and don't give a damn how it affects everyone, or that I truly have no clue what I'm doing. I know the first one is not right... jury is still out on the second...
Oh - one more thing - the Orbi is definitely replying - I see tons of DHCP Offer lines in the Wireshark log coming from the Orbi. It's the clients that are not sending the DHCP Request after that that is not happening when this is not working. When it is working, I see the following sequence for each device:
Device Orbi
DHCP Discover------>
<-----------DHCP Offer
DHCP Request------>
<------------DHCP Ack
When it is not working, The client sends the DHCP Discover, the Orbi sends the DHCP Offer, but most of my devices are not sending the DHCP Request after that. So it breaks down at that point.
