Re: RBK853 With Ethernet Backhaul Satellites Drop Out
H Furry
Just thought i would post an update. Had a busy day today.
Disconnected all LAN switches on my network and added the two satellites in wireless mode. Because of the positioning of the RBS's they have configured in a daisy chain model.
The ONLY two wired connections are directly with the RBR. One is my work laptop (could not let the dodgy wireless impact my work) and the other was the HUE hub as it needs to be an Ethernet connection.
The wireless devices show good connectivity when you review either the RBR or the RBS portal screens (the occasional Out of Sync message but not too often). Both connecting at 5ghz.
Every few hours or so, the RBS devices would drop, when i jumped on the portal I would see the connectivity type changing from 5ghz to Wired, even though the is NO wired connection going into either of the RBS devices. After a little while they would settle back to 5Ghz and things would settle down again.
I am in the process of getting the devices replaced, however, I just thought I would post this in case it rung a bell on any other issues you have seen in the past.
I ran further tests over the last few days, with a variety of combinations of satelites (one and both) and wireless and Ethernet backhaul and CAT6 cables and locations and so on and so on and so on ad infinitum.
I also spent some time on a call to Netgear, and as nice as the guy was, his attempts for me to roll back the firmware failed (it kept auto upgrading) and also his configuration changes made no difference. The issues kept happening and my satellites continue to drop.
So, today... a nice shiny new box arrived with 3 new RBR / RBS boxes.
I quickly set it up, using the same locations cables as before, BUT IMPORTANTLY, I did NOT perform the upgrade. The boxes remain at V3.2.16.22_1.4.9. I have been running through the entire day and have had no dropping issues like before. Just a single day is longer than i have ever achieved befrore.
So... i now have the ultimate quandary!!! Do I assume my previous fault was a hardware one, and upgrade my system to 4.6.3.16 and run the risk of my 3 shiny boxes becoming as useless as the three I had previously. Or do I leave it as it is.
Deep down, i kinda know the answer, leaving it is not really an option as I dont want to be stuck with a Product that I cant upgrade.... but given all the bad feedback of 4.6.3.16 on the forums I am 99% certain that the moment I upgrade, my issues will be back.
What's your thoughts? Given your experience of the forums?
Re: RBK853 With Ethernet Backhaul Satellites Drop Out
I've asked for some more info.
New FW should help resolve these issues we've been seeing this last year.
I haven't loaded it yet but with this last v11, mine and others has been working WAY better than before. So I can only presume NG has taken the complaints to heart and fixing things.
I tried my new hardware, as described previously. And at version 3 it was working OK. My plan yesterday was to reconnect all my old hardware and upgrade to v4.6.7.5. Then see if the issue persisted. However, when i woke up my new hardware had auto updated to the latest official version 4.6.3.16. Therefore, i thought i might as well upgrade the new hardware to the 4.6.7.5.
I followed all the appropriate instructions and the upgrade went well. For the entire day my network was performing perfectly. No issues encountered at all, all devices were operating as expected. I left an amazon radio playing all day (as this would aways stop when the satellites lost connectivity) and it played all day no issues. In this instance, i had two satellites connected over ethernet backhaul.
Then, late at night, my daughter calls from upstairs and sure enough, the same issue was happening again. Devices dropping from satellites. I immediately checked the portals and sure enough, wired connections to the satellites were showing as 5ghz for brief moments and on the satellites themselves, the message:
Your WIFI Orbi Satellite connection is up and running.
had changed to:
Move your Orbi Satellite closer to your Orbi network to improve connection.
Exactly the same situation as the previous hardware experienced and software experienced.
We now have to accept that this has something to do with either a) the firmware or b) something in my house causing the issue. Although in this setup with the new hardware I had all my network back in play, Ethernet LAN connected etc... I think we can be confident this is not the issue as I have seen the problems when all of this has been disconnected.
It is worth pointing out that whilst we experience the issues, ALL Ethernet LAN connected devices (connected to either the satellites via switches or the main router via switches) continue to run perfectly. In addition, ALL devices connected wirelessly directly to the router continue to operate normally.
So, i thought i would look at the log and I see a rediculous number of MAC address IP Allocation throught the night. is this normal, I have showns an example below but this continues through the night when everyone is asleep an you can see the same devices getting addresses allocated even within the same minute:
[DHCP IP: (192.168.1.11)] to MAC address FA:C9:33:8C:35:76, Sunday, Jan 09,2022 06:51:39 [Admin login] from source 192.168.1.16, Sunday, Jan 09,2022 06:50:05 [DHCP IP: (192.168.1.16)] to MAC address E4:A7:A0:4C:A6:F8, Sunday, Jan 09,2022 06:48:31 [DHCP IP: (192.168.1.11)] to MAC address FA:C9:33:8C:35:76, Sunday, Jan 09,2022 06:47:52 [Admin login] from source 192.168.1.37, Sunday, Jan 09,2022 06:47:42 [DHCP IP: (192.168.1.25)] to MAC address 8E:B1:09:E4:B7:DB, Sunday, Jan 09,2022 06:47:13 [DHCP IP: (192.168.1.11)] to MAC address FA:C9:33:8C:35:76, Sunday, Jan 09,2022 06:47:12 [DHCP IP: (192.168.1.10)] to MAC address 8C:CE:4E:EB:F3:E3, Sunday, Jan 09,2022 06:47:10 [DHCP IP: (192.168.1.16)] to MAC address E4:A7:A0:4C:A6:F8, Sunday, Jan 09,2022 06:46:53 [DHCP IP: (192.168.1.16)] to MAC address E4:A7:A0:4C:A6:F8, Sunday, Jan 09,2022 06:46:27 [DHCP IP: (192.168.1.16)] to MAC address E4:A7:A0:4C:A6:F8, Sunday, Jan 09,2022 06:46:12 [DHCP IP: (192.168.1.28)] to MAC address 6C:CD:D6:E9:90:6E, Sunday, Jan 09,2022 06:46:04 [DHCP IP: (192.168.1.13)] to MAC address A8:03:2A:D9:16:68, Sunday, Jan 09,2022 06:46:04 [DHCP IP: (192.168.1.37)] to MAC address 3A:A8:7E:E7:FE:CE, Sunday, Jan 09,2022 06:46:00 [DHCP IP: (192.168.1.36)] to MAC address 6C:CD:D6:E9:90:42, Sunday, Jan 09,2022 06:45:51 [DHCP IP: (192.168.1.28)] to MAC address 6C:CD:D6:E9:90:6E, Sunday, Jan 09,2022 06:45:49 [DHCP IP: (192.168.1.36)] to MAC address 6C:CD:D6:E9:90:42, Sunday, Jan 09,2022 06:45:45 [DHCP IP: (192.168.1.28)] to MAC address 6C:CD:D6:E9:90:6E, Sunday, Jan 09,2022 06:45:45 [DHCP IP: (192.168.1.10)] to MAC address 8C:CE:4E:EB:F3:E3, Sunday, Jan 09,2022 06:45:42 [DHCP IP: (192.168.1.28)] to MAC address 6C:CD:D6:E9:90:6E, Sunday, Jan 09,2022 06:45:42 [DHCP IP: (192.168.1.36)] to MAC address 6C:CD:D6:E9:90:42, Sunday, Jan 09,2022 06:45:41 [DHCP IP: (192.168.1.28)] to MAC address 6C:CD:D6:E9:90:6E, Sunday, Jan 09,2022 06:45:40 [DHCP IP: (192.168.1.36)] to MAC address 6C:CD:D6:E9:90:42, Sunday, Jan 09,2022 06:45:39 [DHCP IP: (192.168.1.28)] to MAC address 6C:CD:D6:E9:90:6E, Sunday, Jan 09,2022 06:45:38 [DHCP IP: (192.168.1.36)] to MAC address 6C:CD:D6:E9:90:42, Sunday, Jan 09,2022 06:45:36 [DHCP IP: (192.168.1.28)] to MAC address 6C:CD:D6:E9:90:6E, Sunday, Jan 09,2022 06:45:35 [DHCP IP: (192.168.1.16)] to MAC address E4:A7:A0:4C:A6:F8, Sunday, Jan 09,2022 06:45:34 [DHCP IP: (192.168.1.36)] to MAC address 6C:CD:D6:E9:90:42, Sunday, Jan 09,2022 06:45:34 [DHCP IP: (192.168.1.28)] to MAC address 6C:CD:D6:E9:90:6E, Sunday, Jan 09,2022 06:45:33 [DHCP IP: (192.168.1.36)] to MAC address 6C:CD:D6:E9:90:42, Sunday, Jan 09,2022 06:45:33 [DHCP IP: (192.168.1.28)] to MAC address 6C:CD:D6:E9:90:6E, Sunday, Jan 09,2022 06:45:32 [DHCP IP: (192.168.1.10)] to MAC address 8C:CE:4E:EB:F3:E3, Sunday, Jan 09,2022 06:45:09 [DHCP IP: (192.168.1.11)] to MAC address FA:C9:33:8C:35:76, Sunday, Jan 09,2022 06:44:08 [DHCP IP: (192.168.1.64)] to MAC address AC:9B:0A:B4:1C:1D, Sunday, Jan 09,2022 06:42:47 [DHCP IP: (192.168.1.11)] to MAC address FA:C9:33:8C:35:76, Sunday, Jan 09,2022 06:42:07 [DHCP IP: (192.168.1.62)] to MAC address 56:26:0A:B7:42:66, Sunday, Jan 09,2022 06:39:29 [DHCP IP: (192.168.1.11)] to MAC address FA:C9:33:8C:35:76, Sunday, Jan 09,2022 06:38:39 [DHCP IP: (192.168.1.62)] to MAC address 56:26:0A:B7:42:66, Sunday, Jan 09,2022 06:38:38 [DHCP IP: (192.168.1.11)] to MAC address FA:C9:33:8C:35:76, Sunday, Jan 09,2022 06:38:06 [DHCP IP: (192.168.1.11)] to MAC address FA:C9:33:8C:35:76, Sunday, Jan 09,2022 06:36:06 [DHCP IP: (192.168.1.62)] to MAC address 56:26:0A:B7:42:66, Sunday, Jan 09,2022 06:35:36 [DHCP IP: (192.168.1.64)] to MAC address AC:9B:0A:B4:1C:1D, Sunday, Jan 09,2022 06:33:53 [DHCP IP: (192.168.1.11)] to MAC address FA:C9:33:8C:35:76, Sunday, Jan 09,2022 06:32:55 [DHCP IP: (192.168.1.25)] to MAC address 8E:B1:09:E4:B7:DB, Sunday, Jan 09,2022 06:31:44 [DHCP IP: (192.168.1.54)] to MAC address 34:3E:A4:88:FA:FB, Sunday, Jan 09,2022 06:29:01 [DHCP IP: (192.168.1.11)] to MAC address FA:C9:33:8C:35:76, Sunday, Jan 09,2022 06:26:51 [Admin login] from source 192.168.1.16, Sunday, Jan 09,2022 06:25:06 [DHCP IP: (192.168.1.16)] to MAC address E4:A7:A0:4C:A6:F8, Sunday, Jan 09,2022 06:24:25 [DHCP IP: (192.168.1.17)] to MAC address C6:CB:FC:41:63:F1, Sunday, Jan 09,2022 06:24:14 [DHCP IP: (192.168.1.37)] to MAC address 3A:A8:7E:E7:FE:CE, Sunday, Jan 09,2022 06:24:03 [DHCP IP: (192.168.1.37)] to MAC address 3A:A8:7E:E7:FE:CE, Sunday, Jan 09,2022 06:22:43 [DHCP IP: (192.168.1.62)] to MAC address 56:26:0A:B7:42:66, Sunday, Jan 09,2022 06:22:42 [DHCP IP: (192.168.1.11)] to MAC address FA:C9:33:8C:35:76, Sunday, Jan 09,2022 06:22:30 [DHCP IP: (192.168.1.17)] to MAC address C6:CB:FC:41:63:F1, Sunday, Jan 09,2022 06:22:09 [DHCP IP: (192.168.1.25)] to MAC address 8E:B1:09:E4:B7:DB, Sunday, Jan 09,2022 06:20:49 [DHCP IP: (192.168.1.17)] to MAC address C6:CB:FC:41:63:F1, Sunday, Jan 09,2022 06:20:26 [DHCP IP: (192.168.1.31)] to MAC address 74:E2:0C:B6:06:24, Sunday, Jan 09,2022 06:20:26 [DHCP IP: (192.168.1.36)] to MAC address 6C:CD:D6:E9:90:42, Sunday, Jan 09,2022 06:20:24 [DHCP IP: (192.168.1.13)] to MAC address A8:03:2A:D9:16:68, Sunday, Jan 09,2022 06:20:22 [DHCP IP: (192.168.1.28)] to MAC address 6C:CD:D6:E9:90:6E, Sunday, Jan 09,2022 06:20:18 [DHCP IP: (192.168.1.17)] to MAC address C6:CB:FC:41:63:F1, Sunday, Jan 09,2022 06:20:12 [DHCP IP: (192.168.1.28)] to MAC address 6C:CD:D6:E9:90:6E, Sunday, Jan 09,2022 06:20:11 [DHCP IP: (192.168.1.36)] to MAC address 6C:CD:D6:E9:90:42, Sunday, Jan 09,2022 06:20:10 [DHCP IP: (192.168.1.28)] to MAC address 6C:CD:D6:E9:90:6E, Sunday, Jan 09,2022 06:20:06 [DHCP IP: (192.168.1.36)] to MAC address 6C:CD:D6:E9:90:42, Sunday, Jan 09,2022 06:20:06 [DHCP IP: (192.168.1.4)] to MAC address 68:C6:3A:C0:2B:D3, Sunday, Jan 09,2022 06:20:05 [DHCP IP: (192.168.1.36)] to MAC address 6C:CD:D6:E9:90:42, Sunday, Jan 09,2022 06:20:02 [DHCP IP: (192.168.1.28)] to MAC address 6C:CD:D6:E9:90:6E, Sunday, Jan 09,2022 06:20:01 [DHCP IP: (192.168.1.36)] to MAC address 6C:CD:D6:E9:90:42, Sunday, Jan 09,2022 06:20:00 [DHCP IP: (192.168.1.28)] to MAC address 6C:CD:D6:E9:90:6E, Sunday, Jan 09,2022 06:19:59 [DHCP IP: (192.168.1.10)] to MAC address 8C:CE:4E:EB:F3:E3, Sunday, Jan 09,2022 06:19:59 [DHCP IP: (192.168.1.36)] to MAC address 6C:CD:D6:E9:90:42, Sunday, Jan 09,2022 06:19:58 [DHCP IP: (192.168.1.28)] to MAC address 6C:CD:D6:E9:90:6E, Sunday, Jan 09,2022 06:19:56 [DHCP IP: (192.168.1.36)] to MAC address 6C:CD:D6:E9:90:42, Sunday, Jan 09,2022 06:19:55 [DHCP IP: (192.168.1.28)] to MAC address 6C:CD:D6:E9:90:6E, Sunday, Jan 09,2022 06:19:53 [DHCP IP: (192.168.1.36)] to MAC address 6C:CD:D6:E9:90:42, Sunday, Jan 09,2022 06:19:52 [DHCP IP: (192.168.1.28)] to MAC address 6C:CD:D6:E9:90:6E, Sunday, Jan 09,2022 06:19:52 [DHCP IP: (192.168.1.4)] to MAC address 68:C6:3A:C0:2B:D3, Sunday, Jan 09,2022 06:19:51 [DHCP IP: (192.168.1.8)] to MAC address E6:57:51:C6:66:20, Sunday, Jan 09,2022 06:19:30
I honestly cant think of anything else to try. I feel this must be something to do with my environment. But I am at a total loss of what to try next. I do have another solution arriving today (and ASUS MESH system) and will quickly set that up and see if the same problems exist. That will determine 100% that this is my house and not the netgear setup.
Anyway, another long message. Welcome your thoughts.
Re: RBK853 With Ethernet Backhaul Satellites Drop Out
If this is happening with two systems, either this is a FW issue or something at your location is causing this. I'm thinking something at your location...
Can you provide us a diagram of how the Orbi system is configured and connected? Please include the ISP modem and any and all LAN switches. Please put in a list of devices thats connected at the RBR and RBS.
Yes, i am inclined to agree. However, the only thing I will say is that through all this testing I have disconnected pretty much every device i have in my house and still seen the issue. The only consistent thing is the ISP Modem.
Anyway, to answer your questions. I have attached a picture of the network diagram I have running. There are various switches (all netgear). I should also point out I have seen this issue consistently without ANY LAN connected.
The ISP modem is not in the diagram but it is directed via Ethernet (CAT6) directly to the Main Orbi Router. All other cabling around the house is either CAT5e or CAT6, however, in the case of the connections directly from the Router to the two satellites, these are CAT6 cables which I have replaced during this test phase and experienced the same issues.
Distances are:
RBS to Sat1 - about 20 foot in this current set up, but I have moved this to well outside of 30ft in tests. The reason it is a little closer is that this is in my house extension so the distance has to take into account a double brick exterior wall of the main house.
RBS to Sat2 - about 40 foot from the Sat 1 and therefore probably about 50ft from the router. This device is in the garden office and without this device i get VERY weak signal from the main house, if any at all.
In my tests I have had JUST RBR and SAT2 connected and seen the issue occur. And this was with two separate ethernet cables being tested.
The diagram shows all the physically connected diagrams and it is worth pointing out that there are approximately 8 other SONOS devices that are on the network (i.e. have an address) but route traffic over the SonosNet network through the Arc connected to the Lounge SAT Switch. WIreless I would add the following:
3 x apple watches
11 x apple ipads / iphones
5 x wifi sockets
2 x wifi bulbs
7 x Amazon Echo devices
1 x Samsung Phone
1 x Ring Alarm Hub
1 x Roomba Hoover
1 x Blinds Hub
1 x Office Heater
2 x Reolink Cameras
I think that pretty much covers everything, however, as mentioned, during tests i have turned off / disconnected all of these devices and seen the issues.
Re: RBK853 With Ethernet Backhaul Satellites Drop Out
Possible indication of the RBS changing from ethernet to wireless and all the devices having to get reconnected thus causing this DHCP list. Not sure though.
What are the brand and model# of all the switches you have connected?
So with everything powered OFF and disconnected from the Orbi system accept for 1 wired PC, the RBS wireless work then after they are ethernet connected they work for a while then fall back to wireless and stop working. This with with nothing connected to the RBS when ethernet connected? And no LAN Switches in the mix.
How long does it take from what you can tell from when the RBS are ethernet connected and up and running to when they revert back to wireless?
Something you can do if you would, while everthing is disconnected and turned OFF accept for 1 wired PC. With the RBS wirelessly connected, enable debug logging on both RBS and RBR. IPAddress/debug.htm
Once you get all the orbi units enabled for logging. Give a couple of minutes then connect the RBS via ethernet one at a time and let them get connected and come to ready. When you notice the RBS revert back to wireless, select the Save DEBUG log button on each unit and save the .zip file captured by the web browser. Lets see if we can get these to NG for review and see whats happening.
Re: RBK853 With Ethernet Backhaul Satellites Drop Out
Ok... its only right to wrap up these forum chat groups in case people follow in the future.
In the end, I decided to bail on the Netgear RBK853 and I returned both sets back to Amazon whilst I was still able to do so without issue.
I have since purhcased an ASUS ZenWifi XT8 mesh system and since installation 6 days ago I have had no issues at all (touching wood as I type).. The devices are in the same locations as my RBK853, using the same cabling etc... and the performance has been far superior with no drop of network and including speed checks from my mobiles which report my maximum internet speed of just over 500mb, whereas with the NG kit the speed was 200-350.
Clearly people have had issues with the v4 release of the NG firmware for the RBK853 and clearly NG are working hard to try and fix things. Another apparent thing to me here (given that many people report good success in their home setups with the new beta patches) is that there are many factors that go into whether you will hit issues or not with kit you purchase. Environmental factors must be particularly pertinent to RBK853 given the variety of issues reported and the scale of success through to failure we see in the forums.
I am not promoting the use of any solution over another, but given my set up and house (distances between devices, cabling) etc... clearly the ASUS solution is a better fit and whatever defects there are in the NG code found my property to be right in the "sweetspot" for the factors that would trigger problems. I hope those sticking with NG have great success in the future.
One final point. I want to thank all those that responded in this forum and also call out @FURRYe38 in particular for his patience and seemingly neverending desire to want to help people out with their netgear products. When I first purchased my RBK53 3-4 years ago it was your support that got it running as I wanted. Unfortunately we did not quite get there with the RBK853, but regardless, I thank you for your time and advice.
Re: RBK853 With Ethernet Backhaul Satellites Drop Out
@ElCapo... I just wanted to say that this has been a riveting discussion (yes: nerds, unite). I recently purchased the RBK852 (one satellite) as the price was enough to make me "try it before I buy it". I had serious set up issues initially (using the app) as I didn't want to set up the satellite during initial setup. It kept hanging and not connecting repeatedly. After resetting more than a few times, I finally give in. I plugged in the Satellite and added it during the initial setup and voila, everything "magically" worked.
But this ethernet backhaul issue is my biggest worry. I just bought a new 6000+ sf home. In my previous home, I had an ASUS AiMesh system working with a hodgepodge mix of very-old to kind-of-new devices (RT-AC68U[refurb], RT-AC88U, and a RP-AC1900 extender). All nodes were connected via ethernet directly to the router (I even ran the cables and terminated them myself). I must say that the AiMesh system was flawless for me. We had on average 36-41 devices running/streaming/conferencing/gaming/etc. All devices switched between each node effortlessly and I was *mostly* satisfied. We did have some capacity issues because, you know, AC1900. That and my only other problem was the AC88U router where it suffered from the dead 5GHz radio bug. Most other users with this issue had a dead 2.4GHz radio problem, but I was unfortunate to find out about my 5GHz issue nearly a year after my return window had closed. But the extender handled all of the 5GHz traffic like a champ, so I just disabled the 5GHz radio on the router itself and left well enough alone.
Anyway, back to NetGear. My RBR/RBS system was setup over wireless like I said earlier and I haven't had any major issues, but my house isn't running at a "full capacity" of clients yet as we are still moving in. Preemptively, I wanted to create some more bandwidth, so I decided to change my wireless backhaul to ethernet. Again, my concern has always been the ethernet backhaul. The documentation mentions NOTHING about it which was my first concern. Also, as I only switched a day ago, I haven't had any time to really benchmark it or stress test it. However, I did notice last night my phone kept cutting out (using wifi calling). This was strange because I'd been using wifi calling exclusively since moving in and setting up the RBR/RBS and didn't have this issue until last night. Not sure if it's related and, again, no major testing of the system yet. But, nevertheless, I still have concerns...
I read on another post in this forum recently, that the 2nd 5GHz band is always reserved for backhaul. So even with an ethernet backhaul, that band will never be available for client devices. Is this true? @FURRYe38 , do you know this to be true? Well, if so, that is a deal-breaker for me. As I mentioned earlier, I really have a large space to cover (including outside areas). I have some avid gamers and streamers to support. I need all of the bandwidth I can get. So if the third band of a Tri-Band system is unusable by clients, then I cannot justify the expensive price tag of this system. I will have to go back to ASUS as well.
Please let me know your experience/thoughts on this. I only have about a week left in my return window as well. And before I shell out another $300 for a second satellite, I need to be confident.
