NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Orbi RBR850 unstable/DHCP assignment issues after reboot
Post concerns a RBR850 and 2 RBS850 satellites, all running firmware version V7.2.6.31_5.0.24. Summary: I have to turn off all WiFi devices near the router in order to get a successful reboot whe...
rdouma wrote:TL/DR: I suspect the latest firmware update made the router unstable and it seems to have trouble assigning DHCP addresses if wifi-devices are turned on before it finalizes its booting sequence. Assigning them IP-addresses via named devices doesn't seem to help; the devices need to be OFF. Not doing so makes the entire house fail in DHCP-assignments.
I don't think so, I have had this same problem for a long time.
I was excited to read that, for you, not making any DHCP reservations resolved the problem.
I reinstated my 850's to see if that would work and to my surprise removing all my DHCP reservations did allow the system to reboot and continue issuing addresses, unfortunately, after less than 24 hours one of my satellites started showing magenta light which I took to mean it could not renew its IP address and sure enough my Android phone could not renew its address either.
A couple of things to note:
1) This is on V7.2.6.21_5.0.20 and I have seen it on earlier firmware versions.
2) Some time after I first saw this I tried my RBK50 kit and saw the same problem leading me to think it is related to some sort of a race in the DHCP server when the number of devices is large, possibly more than about 50 but more than 80 is when I really started having a problem.
3) Following a factory reset the system, which generally works to get the system going again, will sometimes reboot successfully a couple of times before the same problem occurs again.
I have no idea why this happens but once it starts it doesn't seem to stop, and I have no reliable work around, the only thing I can do is disable the router DHCP server and use my NAS for DHCP instead.
This has been a problem for years and Netgear not paying any attention to the forums is just not good enough, but then they give only three months support on new purchases, so ...
Ian
I was excited to read that, for you, not making any DHCP reservations resolved the problem.
Eh... where did I say that? I surely didn't intend to say that; one of the steps I used to get back to a workable solution was the opposite of that: I basically have all known devices in my house as a named device now.
Some time after I first saw this I tried my RBK50 kit and saw the same problem leading me to think it is related to some sort of a race in the DHCP server when the number of devices is large, possibly more than about 50 but more than 80 is when I really started having a problem.
Very well possible it's related to the amount of devices. I have a bunch of them and a large amount was added over the last months when installing Wiz light bulbs.
This has been a problem for years and Netgear not paying any attention to the forums is just not good enough, but then they give only three months support on new purchases, so ...
Yeah, with you on that one. I would expect that you would never want to restrict users to be able to easily submit bug reports but no. Luckily there's this forum and some power users here that seem to know their way around this but in my opinion NetGear should be welcoming bug reports instead of trying to make it hard to submit one.
rdouma wrote:I was excited to read that, for you, not making any DHCP reservations resolved the problem.
Eh... where did I say that? I surely didn't intend to say that; one of the steps I used to get back to a workable solution was the opposite of that: I basically have all known devices in my house as a named device now.
Umm ... reading your post again I think I misunderstood, sorry.
Nevertheless, the dhcp server is probably single threaded and applications like this usually spawn a sub-process for each request to increase throughput. So doing that means they need to record information about the address assignments in a file somewhere because sub-processes are themselves isolated from one another. If there are multiple concurrent requests (a lot of devices wanting to register at once) and the locking of that file isn't right or isn't even done then you can easily get corruption in the file.
I've seen that before in Linux, for years we had a lot of trouble with /etc/mtab (mounted mounts list), in spite of quite a sophisticated locking algorithm it frequently got corrupted during heavy mount activity. It wasn't until /etc/mtab was made a symbolic to the proc file system mount table it was resolved (the proc file system mount tables are files generated on the fly from kernel data structure, they are not written to).
So, it is easily possible the dhcp server is broken, of course the problem is that Netgear hasn't done anything about it or aren't competent enough to fix it if they have tried. The problem is no secret either, there have been a number of reports of it over the years.
For my part I have never been in a position to log a call with support because of the support policy and even if I was within the twelve weeks period at some time I'm not at all sure I would be willing to subject myself to the pain and suffering of what logging a support call involves.
Ian
Sorry for my late response. I agree it looks suspiciously like a the DHCP server not being thread safe. I'm going to experiment with running a docker with a DHCP server and see how a network restart behaves with that.
Any chance you have a MyQ garage door opener? I moved mine to the guest network and dhcp is working well ever since.
