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)
Update:
I did a reset on one RBS leveraging the reset button.
When the RBS was back and stable I checked the time it got its IP lease from the ISP DCHP server: 11:54
I started a ping monitoring from a Mac against (1) the RBS freshly reseted, and to which the Mac is directly connected via WiFi, (2) as well as against the ISP router IP address (default gateway).
Around 12:53 , then 13:55 pings response time started increase drastically or to fail for about 10 to 15 seconds (see below pings against the RBS). Hourly recurrence seems to shift a little over time.
I had no TV live stream lags as the TV box had moved to the other RBS while I was resetting the closest RBS.
Note: prior the reset, the hourly glitch was happening around every hh:15, consistent with the time of the latest DHCP lease request by the RBS, which confirms the correlation between DHCP process and connectivity glitches.
I have now moved to static IP DHCP lease to see if it makes any difference.
Ping logs:
13:55:05.468496 64 bytes from 192.168.1.20: icmp_seq=1198 ttl=64 time=4.205 ms
13:55:06.729311 64 bytes from 192.168.1.20: icmp_seq=1199 ttl=64 time=262.760 ms
13:55:07.478149 64 bytes from 192.168.1.20: icmp_seq=1200 ttl=64 time=7.598 ms
13:55:09.184341 64 bytes from 192.168.1.20: icmp_seq=1201 ttl=64 time=708.671 ms
13:55:09.819179 64 bytes from 192.168.1.20: icmp_seq=1202 ttl=64 time=339.760 ms
13:55:11.095636 64 bytes from 192.168.1.20: icmp_seq=1203 ttl=64 time=613.844 ms
13:55:12.356424 64 bytes from 192.168.1.20: icmp_seq=1204 ttl=64 time=873.268 ms
13:55:13.491090 Request timeout for icmp_seq 1205
13:55:14.497993 Request timeout for icmp_seq 1206
13:55:15.500303 Request timeout for icmp_seq 1207
13:55:16.164752 64 bytes from 192.168.1.20: icmp_seq=1208 ttl=64 time=664.488 ms
13:55:17.435749 64 bytes from 192.168.1.20: icmp_seq=1209 ttl=64 time=930.677 ms
13:55:18.511620 Request timeout for icmp_seq 1210
13:55:18.517089 64 bytes from 192.168.1.20: icmp_seq=1211 ttl=64 time=6.054 ms
13:55:19.561629 64 bytes from 192.168.1.20: icmp_seq=1212 ttl=64 time=46.008 ms
13:55:20.531264 64 bytes from 192.168.1.20: icmp_seq=1213 ttl=64 time=7.168 ms
13:55:21.526985 64 bytes from 192.168.1.20: icmp_seq=1214 ttl=64 time=3.992 ms
Ok. Something to open a support ticket with NG about. This would need to be looked at by support and engineering.
I don't have a support contract and my free support just expired.
I'm sure I'm not the only one using AP mode to have such glitches as it is reproducible, happening on both RBE370 and 371 , so maybe one day NG will identify and fix the issue.
Thanks for your support
Would you trigger the debug logs on the RBR and RBS. Please include the WAN/LAN check box before setting off the logging. Please let the logging run on each unit for about 5 minutes then save off. Please post to a cloud share and PM me the link. Will pass this to NG.
Very kind of you.
I managed to find how to access to the RBR and RBS debug log pages, so I should be able to provide you with the RBR and RBS logs. I'llfirst update the RBR FW so all are sharing the same FW and register to a cloud share, any preference?
Ok.
So FW on the RBS was different from what has been on the RBR?
FW on the RBR and RBS need to be the same at all times to be sure we are getting good or consistance accurate results.
No preference.
I have now updated the FW in the RBR so all kits are at the latest level.
I generated debug logs for each kits so 10 seconds period glitch is included.
I have added a README file as well as a Wireshark capture file of Wifi management traffic where we can see beacon frames transmission glitch for channel 11, used by the Orbi 2.4 GHz band, during the 10 seconds window.
Here is the link to the files: https://transfert.free.fr/gKcHIVA
An the password: nEtgearLogs260226
Ok, passing this to NG.