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...
Sorry, had missed your message! No, I don't have that.
Timtech wrote:Any chance you have a MyQ garage door opener? I moved mine to the guest network and dhcp is working well ever since.
For everyone suffering from this issue: my network has been working flawlessly and I have been able to reboot effortlessly over 10 times when testing. Doesn't skip a beat anymore. I submitted this to NetGear:
RBR850 + 2 RBS850. I have ~100 devices. Upon reboot multiple devices won't get an IP. Only way to get it reliably to work is to turn of all devices in the house, reboot the Orbi, wait ~5 minutes and then slowly turning things on. I solved the issue by running ISC DHCP on a Linux machine in my network and turning it off on the Orbi.
Suspicion is that DHCP in Orbi is not thread safe, and upon reboot it cannot handle the simultaneous DHCP requests, **even with all devices being named**.
Firmware version V7.2.6.31_5.0.24
Hope this helps my fellow Orbi users that suffer from this issue. I have literally spent over 100 hours to narrow it down to this, thinking it was related to network interference, experimenting with router/AP placement etc. They probably just forgot to make the IP assigmnent method thread safe and things have clearly not been tested with large amounts of devices.
Had you seen this behavior on FW v.21 as well?
Since v.31 has been out, though were seeing more issues with 750 series and some on the 960 series, not really confident that v.31 is a stable FW as v.21 is.
rdouma wrote:Hope this helps my fellow Orbi users that suffer from this issue. I have literally spent over 100 hours to narrow it down to this, thinking it was related to network interference, experimenting with router/AP placement etc. They probably just forgot to make the IP assigmnent method thread safe and things have clearly not been tested with large amounts of devices.
At approximately 100 devices you are definitely at the published limit for the number of concurrent devices listed for the 8 series and probably the user with the highest number of connected devices I've seen on the forum.
Great research and testing - hopefully someone at NG is taking this in and verifying/resolving.
FURRYe38 wrote:Had you seen this behavior on FW v.21 as well?
Since v.31 has been out, though were seeing more issues with 750 series and some on the 960 series, not really confident that v.31 is a stable FW as v.21 is.I didn't know there was an update, I will try. To be honest I'm quite weary by now of upgrading firmware as it was the latest upgrade that introduced me to a world of pain... while I was outside of the country my house went dark. 😬 But I have the previous firmware version here and a backup; I should be good with that. Just have to find some motivation. Sort of enjoying the situation where I'm not losing sleep trying to fix my network 😂
At approximately 100 devices you are definitely at the published limit for the number of concurrent devices listed for the 8 series and probably the user with the highest number of connected devices I've seen on the forum.
Great research and testing - hopefully someone at NG is taking this in and verifying/resolving.
Thanks for the feedback, appreciate it.
As for the limit to concurrent devices... I wasn't aware there was a maximum other than the number imposed by a class C network. I could imagine there could be a performance issue if these would all be high throughput devices, but the majority are IoT things (light bulbs & smart plugs) that have almost no traffic. But I do concede I'm not your average user. Just would never expect (what I assessed to be) a high-end consumer router to cause me a problem on something as basic as DHCP assignments.
By now I'm actually happy with my setup and I consider it even better, as I can now assign a named device a specific IP and just restart the DHCP server instead of having to reboot the entire router for it to work. I don't think I'll be using the Orbi's DHCP anymore for that reason alone.
v.21 is a downgrade. FYI, v.21 was beta tested and lots of users helped out on that BEFORE it was released so after testing, it had mostly a good release and good user experiences. We didn't get a chance to beta test v.31 so I've been seeing posts over past month in regards to users not having great experiences with it. So been recommending for users having problems on v.31, go back to v.21. 🙄
Completely understand Sir. If it's working, run it and relax man. 😉
Yeah... I'm a big fan of "if it ain't broke, don't fix it" 🙂
Ya, that too. 👍
rdouma wrote:
Thanks for the feedback, appreciate it.
As for the limit to concurrent devices... I wasn't aware there was a maximum other than the number imposed by a class C network. I could imagine there could be a performance issue if these would all be high throughput devices, but the majority are IoT things (light bulbs & smart plugs) that have almost no traffic. But I do concede I'm not your average user. Just would never expect (what I assessed to be) a high-end consumer router to cause me a problem on something as basic as DHCP assignments.
By now I'm actually happy with my setup and I consider it even better, as I can now assign a named device a specific IP and just restart the DHCP server instead of having to reboot the entire router for it to work. I don't think I'll be using the Orbi's DHCP anymore for that reason alone.
I wonder if this issue/limitation is part of the OpenWrt Chaos Calmer 15.05.1 code base that the router firmware is built upon or part of the Netgear personalization that sits on top of it.
Either way, it definitely is something that SHOULD work correctly!
FURRYe38 wrote:Had you seen this behavior on FW v.21 as well?
Since v.31 has been out, though were seeing more issues with 750 series and some on the 960 series, not really confident that v.31 is a stable FW as v.21 is.As you may have seen I have reported this problem more than once on different firmware versions.
v21 is the highest version I have seen it on, didn't go to v31.
raven_au wrote:
FURRYe38 wrote:Had you seen this behavior on FW v.21 as well?
Since v.31 has been out, though were seeing more issues with 750 series and some on the 960 series, not really confident that v.31 is a stable FW as v.21 is.As you may have seen I have reported this problem more than once on different firmware versions.
v21 is the highest version I have seen it on, didn't go to v31.
And here we are, years later and the DHCP problem remains on models prior to the WiFi 7 routers.
Yes, that';s right, the RBE973 kit appears to have a working DHCP server, all it took was a move away from Broadcom to Qualcomm, a different sdk, so it's unlikely Netgear actually fixed anything themselves.
And another bug that has been reported and continued to go unfixed for years is the Orbi app seems unable to see iOS and iPadOS devices that have Armor installed always reporting them as not having Armor. The status of these devices gets recorded on armor.netgear.com AFAICS but the Oribi app can't see it. This can (and does) make the security score meaningless which, IMO, is useful. It's a shame that a feature that, IMHO, is quite good has remained buggy for so long as to make people that would appreciate it not want to use it.
While I'm at it I have to say that the TP-Link be85 works much better than this router. The hardware these two devices use is very similar and yet Netgear managed to mess up the WiFi, it's less stable and it's slower. I am persevering though because I believe the security on the Orbi is actually fairly good although still plagued with bugs too.
