NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
IP Address DIsplay/Attached Device Display 870 Series
Just chiming in here with just one of many issues I have been having with my Orbi 870/871 devices. I am set up in AP mode (we wont get into the issues with this) and, looking at the attached device...
Do these devices appear correctly on the RBRs web page?
If this is from the RBS web page, there has been some odd behaviors around what the RBS report. I would agree, should be reporting correctly if all devices and names and MAC addresses are aligned.
Phones and pads, make sure you disable MAC address randomizer on them...
jeffrymaynard wrote:
From just a single satellite. More devices on others show similar. 1st 2 are and iPhone and iWatch. .30 is a Nest Thermostat, The next one if a Bose Soundtouch, and the last is an Amazon Firestick. It's not just iPhones.
They do not show up on the main RBR devices connected page. Example, the SoundTouch would be .111 and called Little Bose and it is missing. So are others.
Please describe how this 870 system is connected.
It comes as a surprise to many users that Netgear designed the Orbi system for the router to "see" satellites only when they are connected to the router with WiFi or wired to the router LAN ports.
People with sophisticated systems often find it convenient to connect both the router and the satellites directly to the primary network appliance (firewall, router, etc.) or to a switch that is connected to it. Thus, the satellite are "sort of" connected to the router through the router WAN port. There are numerous conversations on the forum demonstrating how this does not work and renders the router information display inaccurate.
Ok, I have read some of those other posts and I call B.S. on it. One should NOT have to connect the satellites to the main RBR in order for the control channels to function properly. There simply is no valid justification for having to do this in my humble opinion. If you cannot transmit that traffic via standard protocols it should not be used. The entire intent for AP mode is so that you can spread the satellites away from the RBR and so that you do not have to use the system as your main router. Simply stated, the Orbi is not a 'router' of choice for many users. Sure, it's a great product for some families with no technical knowledge, but some of us have jobs, or other reasons, that we need to be able to control our home networks with a little more granularity. The fact that Netgear has chosen to lock down the devices they way they have is a bad decision overall, but the fact that it is locked down and does not do simple things like allow you to utilize a feature like hard medium (Ethernet) for back-haul over s standard network is even worse.
Please do not misunderstand me here, I am not trying to bad mouth the product. Based on what I have seen, the customer support is good, the product is robust and I am going to continue working with Netgear and the community to help make things better; but blaming people with 'sophisticated' networks for the behavior of the products is not going to fly.
Blaming people networks, cabling, etc. is a dull move and should be avoided. In fact, I ran across a number of posts doing just that and, truth be told, it left a really bad taste with me. Most networks at peoples homes are fairly simple and running simple Ethernet switches should not be an impediment to a product working. When a product is advertised as having the ability to run in AP mode eliminating the need for it to participate in routing, it should do just that. When is also advertises that you can tun the back-haul over Ethernet, that should also work. That does not mean run it in AP mode only from the ports on the RBR.
Onto the statement on documentation and other discussions. Just because someone 'discusses' the problem does not mean it's not a problem. Just because someone says 'that's how it works' does not mean it's not a problem. A problem is always a problem until it is actually fixed. If it were not a problem there might be 1 or 2 comments and discussions about it. It's a lot more of an issue that that! Because multiple people have 'discussed' it tells one that it is a problem and continues to be a problem. When we just push folks off when they bring it up again and again, we do a disservice to the product and it's users by allowing it to drop into oblivion and never really get solved. This causes user frustration and anxiety and make the brand and product unworthy; which no one really wants.
Sorry for the long thread and vent, but I felt I needed to speak up for all of us out here who do not want to hear that it's documented to not work. We want to help to make it work that way we believe it should.
jeffrymaynard wrote:
Ok, I have read some of those other posts and I call B.S. on it. One should NOT have to connect the satellites to the main RBR in order for the control channels to function properly. There simply is no valid justification for having to do this in my humble opinion.
Software engineers make a lot of choices when designing products. Many mesh WiFi systems are designed where every unit is identical. Any of them can be the "root" connected to the internet. Netgear designed their mesh with different firmware on the single 'router' and the multiple satellites. The original product had no 'wired' backhaul capability. That was one of the first features customers asked for.
So, I agree 100%. The product should have been designed to support wired satellites which appear on the WAN interface rather than the LAN interface. This design decision has frustrated a number of sophisticated users and consumed a lot of forum time.
Not having forum participation from the software engineering group means the people most likely to understand and be able to articulate the design are not present. We customers are left to speculate.
How many devices do you have connected in total?
How many of these sound devices do you have?
What is the Mfr and model# of the host router the RBR is connected too in AP mode?
How is AP mode configured on the RBR? Dynamic or Static configuration? I use Static with mine.
What Firmware version is currently loaded?
NS is Bin
The network contains roughly 90 devices, most being wired to the network. The Internet is connected to my pfSense firewall/router and there are multiple l2/3 managed switches. There is a core L3 switch (Yuanley YS100-0008MS) straight off of the pfSense box and from there I hand off to other L2/3 switches (Yuanley YS100-0008MS) for ethernet services. The RBR is attached to one of these YS100-0008MS switches. I did have a coupe of the satellites connected via Ethernet to other switches but had to disconnect because the Ethernet back-haul is not stable and results in devices dropping off the network or having connectivity issues. Now, before someone says it must be the switches or cables, I can assure you that this is NOT the case. The network itself is extremely stable. In fact, before the Orbi installation I had Linksys products (2017 products) running in AP mode for multiple years, connected to the exact same ports and never had an issue, until the Linksys hardware started to fail. Most of my cabling is Cat6e or better and the devices are 2.5/10G devices.
The Orbi's are running the latest code V10.5.18.3_2.2.37 on all nodes. The RBR and all satellites get a fixed IP address from the DHCP server.
I am going to assume the next question is how are the switches configured. All switches, including the Core, are in a flat VLAN and no actual routing is taking place. It's a simple L2 network except I can see traffic, the interfaces, and enable QOS if I choose; I have not chosen to do so. The entire network is dumped into one single VLAN for simplicity.
DNS is Bind running on my pfSense box and DHCP is DHCP server running on that device.
Are any of the RBS connected to these switches or are the RBS wirelessly synce to the RBR?
There is no CAT6E cabling, There is either CAT6 UTP or CAT6A STP.
One reason for bad RBS ethernet backhaul is Orbi and Managed switches do not work well with Managed switches. Tends to be IGMP and Green Ethernet protocols that cause this. I was able to make Orbi work with managed switches with a VLAN Tag configuration, however this works for router mode. There is a Orbi FW problem while in AP mode that causes the Guest Network to not work while RBS are ethernet connected to these manages switches and all points to Orbi FW having the issue. Something that is solved by using a non managed switch. I haven't been able to find a work around for managed switches with Orbi in AP mode to get Guest Network working correctly. Seems to be more in FW that would have to be solved here.
Possible how you have your switches configured may be inducing problems. I would remove ALL switches from the mix and test with the Orbi system alone with the RBS and see if your devices appear correctly on the RBRs web page first. Then check RBS. Help rule out the system, then introduce maybe one managed switch to connect to the RBR and your devices and re-check devices at the RBR. Leave the RBS wireless connected for now.
You should try a Non Managed switch and see if this help your RBS being ethernet connected. Mine are wireless however have been wondering when I should get them ethernet connected. I may do that today to help check this.
