Reporting back after some days of testing firmware 4.6.7.13 with my RBR850+RBS850 with Ethernet backhaul, running in AP mode with 1Gbit/sync fiber over Fritz!Box Modem. Generally I can say the switching to pink every 24h is history, the whole network is way more stable now.
Nonetheless, I’m facing random complete WiFi dropouts, causing the entire network to be inaccessible for some minutes, even wired devices. Sometimes only restarting the Satellite is helping. If the satellite is off, everything is perfectly stable, so I have to assume it’s the combo of AP and satellite that make the WiFi break down.
20/40Ghz coexistence is off, but that didn’t solve much. The logs are absolutely useless and don’t contain anything.
I would need help to get this fixed 😞 My Setup: ISP: Deutsche Glasfaser, Fiber (1GBit/s Sync), Router: Fritz!Box 5530RE, RBR850 + RBS850 (RBK853) in AP mode, Cat7 Ethernet Backhaul
@Zweiklang wrote: Reporting back after some days of testing firmware 4.6.7.13 with my RBR850+RBS850 with Ethernet backhaul, running in AP mode with 1Gbit/sync fiber over Fritz!Box Modem. I presume the RBR and RBS were powered OFF for 1 minute then back ON after v.13 was applied or maybe was factory reset?
Generally I can say the switching to pink every 24h is history, the whole network is way more stable now. 👍
Nonetheless, I’m facing random complete WiFi dropouts, causing the entire network to be inaccessible for some minutes, even wired devices. Sometimes only restarting the Satellite is helping. If the satellite is off, everything is perfectly stable, so I have to assume it’s the combo of AP and satellite that make the WiFi break down. What is the distance between the router and 📡 satellite(s)? Is the RBS directly connected to the back of the RBR or is there a wall jack or LAN switch in between them? Does this still happen if the RBS is wirelessly connected instead of wired?
20/40Ghz coexistence is off, but that didn’t solve much. The logs are absolutely useless and don’t contain anything. What channels are you using? Auto?
I would need help to get this fixed 😞 My Setup: ISP: Deutsche Glasfaser, Fiber (1GBit/s Sync), Router: Fritz!Box 5530RE, RBR850 + RBS850 (RBK853) in AP mode, Cat7 Ethernet Backhaul
I did a full factory reset after installing the firmware update.
The Backhaul is wired directly, no switch or wall socket in between. Distance between the two devices is approx 10m, separated by a concrete floor and a few doors. Running the satellite on wireless Backhaul shows only a “poor” connection to the AP, that’s why I have refrained from that. Connected devices had a hard time to stay connected to the network.
Host Router WiFi is disabled, yes. Also tried leaving it on, makes no difference.
As for the wireless Backhaul causing the same issues, I would have to try again as that was before the update.
The LAN cable is running external, in a separate cable channel.
Will check reducing the transmit power to 50% and see if this would repeat then. Maybe the top floor wouldn’t be properly covered anymore, though. The second satellite might not get enough wireless Backhaul signal to make that up.
Ok, something to try, swap RBS with each other to see if the problem with the one RBS follows or remains at this one ethernet connected location.
Turn off the ethernet connected RBS and attempt to run the wireless RBS to see if same problem appears here. You may need to move this RBS a bit closer to the RBR since concrete is involved here.
Tried now for a few days, seems to be difficult to diagnose, since the network drops don't happen in a measurable frequency. Wireless test has the same results, still network drops. I had to move the Satellite closer to get enough backhaul connection as you mentioned, but even with "good" wireless backhaul, the drops happened.
To state this clearly again:
It's not individual devices dropping out, it's the entire WiFi is dropping out. It shows as available, but no devices can connect anymore until I reboot the satellite (and only the satellite, no matter which of the 2 of the RBK853 I am connecting, so doesn't seem to be a hardware failure of any of the satellites).
I forgot maybe one crucial info: This applies to both the guest and the main network. Switching the guest network off entirely doesn't improve anything though.
The logs dont't help, they worry me even more (anonmyzed mac addresses and log sent address).The mentioned IP addresses are running in the guest network and drop out wayyyy too frequently imho (no people moving around), this is just an excerpt, the list is way longer and is dating back into the previous day:
[email sent to: xxx] Friday, Mar 25,2022 09:44:08
[DHCP IP: (192.168.2.4)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 09:43:38
[DHCP IP: (192.168.2.6)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 09:42:16
[DHCP IP: (192.168.2.2)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 09:39:48
[DHCP IP: (192.168.2.7)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 09:36:10
[DHCP IP: (192.168.2.4)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 09:28:44
[DHCP IP: (192.168.2.5)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 09:27:51
[DHCP IP: (192.168.2.6)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 09:24:58
[DHCP IP: (192.168.2.7)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 09:19:35
[DHCP IP: (192.168.2.6)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 09:04:44
[DHCP IP: (192.168.2.7)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 09:04:34
[DHCP IP: (192.168.2.4)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 09:04:04
[DHCP IP: (192.168.2.5)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 09:02:51
[DHCP IP: (192.168.2.6)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 08:50:05
[DHCP IP: (192.168.2.4)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 08:48:34
[DHCP IP: (192.168.2.5)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 08:48:16
[DHCP IP: (192.168.2.7)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 08:39:59
[DHCP IP: (192.168.2.8)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 08:35:47
[DHCP IP: (192.168.2.8)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 08:35:22
[DHCP IP: (192.168.2.6)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 08:35:03
[DHCP IP: (192.168.2.5)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 08:33:35
[DHCP IP: (192.168.2.4)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 08:33:34
[DHCP IP: (192.168.2.8)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 08:30:07
[DHCP IP: (192.168.2.8)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 08:29:51
[DHCP IP: (192.168.2.7)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 08:26:10
[DHCP IP: (192.168.2.6)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 08:20:22
[DHCP IP: (192.168.2.5)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 08:18:55
[DHCP IP: (192.168.2.4)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 08:18:53
[DHCP IP: (192.168.2.8)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 08:17:35
[DHCP IP: (192.168.2.8)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 08:14:46
[DHCP IP: (192.168.2.8)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 08:12:31
[DHCP IP: (192.168.2.8)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 08:12:15
[DHCP IP: (192.168.2.8)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 08:09:14
[DHCP IP: (192.168.2.8)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 08:06:56
[DHCP IP: (192.168.2.6)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 08:05:38
[DHCP IP: (192.168.2.8)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 08:05:31
[DHCP IP: (192.168.2.7)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 08:05:10
[DHCP IP: (192.168.2.5)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 08:04:15
[DHCP IP: (192.168.2.4)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 08:02:15
[DHCP IP: (192.168.2.7)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 08:00:12
[DHCP IP: (192.168.2.8)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 07:56:49
[DHCP IP: (192.168.2.8)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 07:56:20
[DHCP IP: (192.168.2.8)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 07:53:16
[DHCP IP: (192.168.2.6)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 07:50:54
[DHCP IP: (192.168.2.5)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 07:49:36
[DHCP IP: (192.168.2.7)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 07:44:33
[DHCP IP: (192.168.2.4)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 07:43:59
[DHCP IP: (192.168.2.8)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 07:41:06
[DHCP IP: (192.168.2.6)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 07:35:50
[DHCP IP: (192.168.2.5)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 07:34:57
[DHCP IP: (192.168.2.8)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 07:30:00
[DHCP IP: (192.168.2.4)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 07:29:28
[DHCP IP: (192.168.2.7)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 07:24:37
[DHCP IP: (192.168.2.6)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 07:21:10
[DHCP IP: (192.168.2.5)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 07:20:24
[DHCP IP: (192.168.2.8)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 07:14:19
[DHCP IP: (192.168.2.4)] to MAC address xx:xx:xx:xx:xx:xx, Friday, Mar 25,2022 07:11:30
....
Yes, independent of the satellite, the problem still persists. Feels like a software issue to me, like a memory leak/overflow caused by my network setup.
Doesn’t look weird to me. This is right after boot up and one of the disconnects. About the same picture 1h before it shut down. Just about 80Mb more memory usage.
Unfortunately no, no other router at hand. Any chance I can aggregate the COU/RAM stats anywhere somewhat easily? Otherwise it’s more spot checks that might miss any spikes.
With that huge number of DHCP requests that is showing in the router log, I'm wondering if it is not overflowing memory somewhere and causing memory corruption - thereby causing the reboot. It's more of a concern that things are dropping off/reconnecting like they are, but I haven't had a chance to digest the logs yet.
I see you have a mailed copy of the router logs. Is this a scheduled mail or did you go to the router logs and click on SEND. If you manually sent - the logs won't clear, but if a scheduled send, it should clear the logs, although I have found that occasionally it does not.
I've found in the past that if you have a scheduled E-Mail of the logs - IF the logs fill up before the scheduled send - it will mail the log and clear.
Looking at the logs briefly, it almost looks like these devices are bouncing between satellites although difficult to tell for sure. I've seen that in the past.
Wondering was this need on prior versions of FW? v.5 or v.16?
@Zweiklang wrote: Unfortunately no, no other router at hand. Any chance I can aggregate the COU/RAM stats anywhere somewhat easily? Otherwise it’s more spot checks that might miss any spikes.
Hey, thanks for catching up! No positive development on this, unfortunately. I had temporarily swapped systems with a friend's Unifi 6 LR to check whether it's my house's infrastructure. It's not, the Unifi is working just fine.
I am still testing and in touch with support r/n. Will report on progress.
