NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
WiFi Drops Every Hour
Hello - Same issue for me here. My setup is made of one RBE371 and 2xRBE370, firmware V12.1.3.11_5.1.12, acquired end of October 2025. Initially I thought the issue was coming from my ISP Live TV st...
Hello - Sorry for the delay responding, I was busy trying to get more evidences about the issue. I think I finally found something interesting.
First I miss to indicate that my RBR is configured as an Access Point, connected to my ISP router via a Cat7 cable.
The RBR is acquiring its IP address from the ISP router via DHCP.
I found in the Orbi logs that there were events recorded every 6 hours showing internet connection being established (I missed to save the exact message). I identified that the time the events were recorded were the same the RBR was renewing its IP address (my ISP provider lease time is 12 hours)
These events' time were also the same I could witness serious TV live stream freeze or pings failing against the RBR IP or the ISP router.Smaller freezes were also happening every hour between two DHCP lease renew requests, e.g. renew request at 1:34 implies about 3 seconds TV stream freeze, shorter freezes could be seen at 2:34, 3:34, 4:34, etc... up to the next renew request and so on.
I then concluded that the DHCP IP address renew request of the RBR was intrusive, as well as smaller events occurring hourly between each DHCP renew.
I decided to set a fixed IP address in the RBR and so far I haven't had any TV live stream freeze.
Note 1: that all traffic with buffering (music, internet radio, video) was not noticeably impacted versus Live TV which in the case of my provider is multicast
Note 2: I initially thought about Wifi drops but I'm now convinced that it is related to the RBR leaving and entering back in the network at each IP DHCP renew plus other hourly events that i cannot understand but that could be related as they are happening each hour between two renews.
Hope it helps.
I'll have a look at the new firmware if available for my region too (I'm located in France)
Hello - Sorry for the delay responding, I was busy trying to get more evidences about the issue. I think I finally found something interesting.
First I miss to indicate that my RBR is configured as an Access Point, connected to my ISP router via a Cat7 cable.
The RBR is acquiring its IP address from the ISP router via DHCP.
I found in the Orbi logs that there were events recorded every 6 hours showing internet connection being established (I missed to save the exact message). I identified that the time the events were recorded were the same the RBR was renewing its IP address (my ISP provider lease time is 12 hours)
These events' time were also the same I could witness serious TV live stream freeze or pings failing against the RBR IP or the ISP router.
Smaller freezes were also happening every hour between two DHCP lease renew requests, e.g. renew request at 1:34 implies about 3 seconds TV stream freeze, shorter freezes could be seen at 2:34, 3:34, 4:34, etc... up to the next renew request and so on.
I then concluded that the DHCP IP address renew request of the RBR was intrusive, as well as smaller events occurring hourly between each DHCP renew.
I decided to set a fixed IP address in the RBR and so far I haven't had any TV live stream freeze.
Note 1: that all traffic with buffering (music, internet radio, video) was not noticeably impacted versus Live TV which in the case of my provider is multicast
Note 2: I initially thought about Wifi drops but I'm now convinced that it is related to the RBR leaving and entering back in the network at each IP DHCP renew plus other hourly events that i cannot understand but that could be related as they are happening each hour between two renews.
Hope it helps.
I'll have a look at the new firmware if available for my region too (I'm located in France)
Ok so yes if the RBR is in AP mode, recommend using static IP address configuration on the RBR to help avoid Dynamic DHCP IP address expiration and renewing at the ISP router level.
Please review this for Orbi AP Mode and using Static IP address configurations:
Static IP Address Configuration for AP Mode | NETGEAR Communities
If you want to update the FW on your system, please review this:
Procedure to Manually Firmware Update Orbi and Nighthawk Mesh systems. | NETGEAR Communities
If you feel that your change in configuration was solved, please mark your post as a solution so others will know.
Be sure to save off a back up configuration to file for safe keeping. Saves time if a reset is needed.
https://kb.netgear.com/000062080/How-do-I-back-up-the-configuration-settings-on-my-Orbi-WiFi-System
Enjoy. 📡
Thanks. post marked as a solution.
That said, first time I'm seeing a so intrusive DHCP IP renew, as well as unexpected hourly disruptions between to renews, something Netgear should have a look at.If the ISP is renewing this every 12 hours, "RBR was renewing its IP address (my ISP provider lease time is 12 hours)" then the RBR is only following up and having to re-handshade the connect when this happens if the ISP triggers this. You'll need to ask the ISP about this as that would be the source of the interuption.
I understand the RBR/RBS are doing what they have to do to renew their DHCP lease, like all my other network devices, and my ISP DHCP server is responding accordingly from what I can see in the logs, i.e IP addresses renewal upon requests at 50% of the lease time.
What I'm not convinced is correct is that the RBR/RBS IP becomes hardly reachable or unreachable like if there was a rebind during a renew where there is no need for, and what I don't even consider as normal, is that RBR/RBS interfaces stop responding similarly every hour between two DHCP lease renews.
Moving to a fixed IP address in the RBR seems to have solved the issue on the RBR side, but there are still the same issues with the RBS where static IP cannot be configured (as far as I know).
Below sample is a ping from my computer against the RBS IP address. My computer is connected to this RBS so traffic path must be minimum.
The next DHCP lease renew for this RBS is expected around 21:18. What you can see here are ping response time increasing, even stop responding, from 16:18:48 or 18:18:50 for a few seconds, enough to perturb live TV stream in my case, and I'm seeing this every single hour around the 48th minute.I'll run other diagnostics suggested by a member of this forum to identify if the failure to respond happens at the physical layer or at the network level.
16:18:43.745808 64 bytes from 192.168.2.20: icmp_seq=362 ttl=64 time=13.798 ms
16:18:44.741423 64 bytes from 192.168.2.20: icmp_seq=363 ttl=64 time=8.446 ms
16:18:45.749583 64 bytes from 192.168.2.20: icmp_seq=364 ttl=64 time=11.206 ms
16:18:46.746323 64 bytes from 192.168.2.20: icmp_seq=365 ttl=64 time=5.514 ms
16:18:47.756257 64 bytes from 192.168.2.20: icmp_seq=366 ttl=64 time=9.959 ms
16:18:48.933017 64 bytes from 192.168.2.20: icmp_seq=367 ttl=64 time=181.030 ms
16:18:50.202832 64 bytes from 192.168.2.20: icmp_seq=368 ttl=64 time=446.549 ms
16:18:50.763489 64 bytes from 192.168.2.20: icmp_seq=369 ttl=64 time=5.519 ms
16:18:51.856326 64 bytes from 192.168.2.20: icmp_seq=370 ttl=64 time=94.300 ms
16:18:53.108371 64 bytes from 192.168.2.20: icmp_seq=371 ttl=64 time=342.816 ms
16:18:54.400599 64 bytes from 192.168.2.20: icmp_seq=372 ttl=64 time=632.555 ms
16:18:54.781684 64 bytes from 192.168.2.20: icmp_seq=373 ttl=64 time=9.407 ms
16:18:56.064135 64 bytes from 192.168.2.20: icmp_seq=374 ttl=64 time=283.827 ms
16:18:57.105736 64 bytes from 192.168.2.20: icmp_seq=375 ttl=64 time=324.073 ms
16:18:58.377383 64 bytes from 192.168.2.20: icmp_seq=376 ttl=64 time=592.260 ms
16:18:58.797595 64 bytes from 192.168.2.20: icmp_seq=377 ttl=64 time=9.353 ms
16:19:00.063109 64 bytes from 192.168.2.20: icmp_seq=378 ttl=64 time=272.638 ms
16:19:01.334999 64 bytes from 192.168.2.20: icmp_seq=379 ttl=64 time=539.419 ms
16:19:01.977813 64 bytes from 192.168.2.20: icmp_seq=380 ttl=64 time=177.867 ms
16:19:02.813827 64 bytes from 192.168.2.20: icmp_seq=381 ttl=64 time=12.431 ms
16:19:03.818633 64 bytes from 192.168.2.20: icmp_seq=382 ttl=64 time=12.207 ms
16:19:04.816403 64 bytes from 192.168.2.20: icmp_seq=383 ttl=64 time=4.164 ms
18:18:43.989252 64 bytes from 192.168.2.20: icmp_seq=20 ttl=64 time=9.555 ms
18:18:44.992896 64 bytes from 192.168.2.20: icmp_seq=21 ttl=64 time=7.987 ms
18:18:45.999857 64 bytes from 192.168.2.20: icmp_seq=22 ttl=64 time=9.638 ms
18:18:47.008615 64 bytes from 192.168.2.20: icmp_seq=23 ttl=64 time=13.837 ms
18:18:48.007240 64 bytes from 192.168.2.20: icmp_seq=24 ttl=64 time=8.204 ms
18:18:50.005870 Request timeout for icmp_seq 25
18:18:51.008532 Request timeout for icmp_seq 26
18:18:51.014271 64 bytes from 192.168.2.20: icmp_seq=27 ttl=64 time=6.204 ms
18:18:53.018538 Request timeout for icmp_seq 28
18:18:54.020248 Request timeout for icmp_seq 29
18:18:54.793913 64 bytes from 192.168.2.20: icmp_seq=30 ttl=64 time=773.702 ms
18:18:55.438786 64 bytes from 192.168.2.20: icmp_seq=31 ttl=64 time=413.781 ms
18:18:57.028666 Request timeout for icmp_seq 32
18:18:57.342750 64 bytes from 192.168.2.20: icmp_seq=32 ttl=64 time=1312.382 ms
18:18:57.353260 64 bytes from 192.168.2.20: icmp_seq=33 ttl=64 time=324.858 ms
18:18:58.600689 64 bytes from 192.168.2.20: icmp_seq=34 ttl=64 time=570.909 ms
18:18:59.377093 64 bytes from 192.168.2.20: icmp_seq=35 ttl=64 time=344.978 ms
18:19:00.297671 64 bytes from 192.168.2.20: icmp_seq=36 ttl=64 time=260.345 ms
18:19:01.579148 64 bytes from 192.168.2.20: icmp_seq=37 ttl=64 time=540.701 ms
18:19:02.199146 64 bytes from 192.168.2.20: icmp_seq=38 ttl=64 time=156.553 ms
18:19:03.066263 64 bytes from 192.168.2.20: icmp_seq=39 ttl=64 time=21.495 ms