NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
RBE970/RBE971 Routing Issues
I have an Orbi RBE970/RBE971 mesh environment that was set to auto-upgrade, but I noticed it was still running 9.12.4.16 even though the firmware update page said that upgrades were available. I used the online upgrade to the offered 12.1.10.12. After the upgrade, I am seeing some LAN to LAN network connections appear to the server on the connection (HTTP, SSH, etc.) to come from the internet interface. This prevented connections due to firewall rules on my servers that only allow connections from my internal LAN network IP range. Oddly, some connections between internal hosts do not exhibit this behavior. Additionally, connections from internal hosts to my internet facing IP address are no longer forwarded to the configured port forward host. And again, this is inconsistent depending on what host I initiate the connection from. I manually updated to 12.1.11.15, but that did not change any behavior. The Protection Engine was enabled, but I disabled it and rebooted all devices, and there was no change. The only pattern that I can find is that the different and unexpected/undesired behavior is to/from virtual machines on a VMware ESXi server. But it's not for all services. To make this real, I have an internal subnet of 172.x.x.0/24. Let's call that network $A. Here are my hosts and ip addresses: Orbi router: $A.254 MacBook1 Ethernet directly connected to Orbi router: $A.8 MacBook1 Wireless: $A.9 MacBook2 Wireless: $A.111 Linux Server in VMware: $A.1 Windows 11 in VMware: $A.138 Internet network interface: $B Linux iptables firewall only allows connections from $A.0/24 and a handful of trusted internet hosts. Port forwarding is configured on the Orbi router for several services including SSH, HTTP, HTTPS, etc. to $A.1. ssh from MacBook1 and MacBook2 to $A.1 fails because the Linux server ($A.1) sees it as coming from $B. ssh from MacBook1 to MacBook2 works just fine. ssh from Windows 11 to Linux server (both in VMware environment) works fine. HTTP connections from MacBook1 and MacBook2 to $B (which is port forwarded to $A.1) work just fine. HTTP connections from $A.1 to $B (which is port forwarded back to $A.1) timeout. This is not a firewall issue. As soon as I open SSH in the Linux firewall to allow connections from $B, all works. netstat and who confirm the connection is coming from $B even though the client connections started on same subnet. I pulled the debug logs from the router, but I can't see anything that looks out of place in the routing or interface definitions. I may not know exactly what to look for. I thought I would downgrade to see if the problem went away, but it seems you can't go back to 9.x from 12.x. Any thoughts on how best to diagnose this further would be more than welcome.RBE971 / 12.1.10.12 NA: 224.0.0.0/24 multicast dropped on Wi-Fi, mDNS discovery broken
I've spent the better part of a week chasing this and I believe it's a firmware problem rather than anything at my end. Laying out what I found in case it's useful, and because there's a very similar report on another model. The setup Orbi 970 — RBE971 router, two RBE970 satellites, V12.1.10.12_5.3.16 (NA region), router mode behind a Verizon Fios ONT. Single subnet, roughly 63 clients. One satellite on wired backhaul, one wireless. What's happening Wi-Fi clients receive no inbound multicast addressed to 224.0.0.251. Wired clients on the same network receive it continuously. That takes out every Bonjour-based service — printers, scanners, AirPrint — for anything on wireless. It surfaced as a printer that stopped appearing in Add Printer on two different Macs, but it's a good deal broader than printing. The capture that settled it MacBook, two metres from the router, -34 dBm on 5GHz: sudo tcpdump -i en0 -n 'port 5353 and dst 224.0.0.251 and not src 10.0.0.16' Sixty seconds of that: zero packets captured, out of 31463 received by the filter, none dropped by the kernel. The identical filter on a wired Mac mini — same LAN, same minute — scrolls continuously. The client looks correct to me. netstat -gn lists the mDNS group against en0 with link-layer address 01:00:5e:00:00:fb, so both the IP membership and the hardware multicast filter are in place. It transmits multicast fine too — the same capture shows it sending PTR queries for the printing service types with the QM flag set, meaning reply by multicast. The query leaves. The reply never comes back. What I've already ruled out Signal and placement — -34 dBm at two metres. The client — two entirely independent Macs, one personal and one a managed corporate machine, behave identically. AWDL — disabled with ifconfig awdl0 down, no change. The printer — advertises all its service types correctly, verified by browsing from the wired Mac. Disable IGMP Proxying (ADVANCED / Setup / WAN Setup) — tested in both states, no difference. The mesh — 63 hours of ping logging to the router and both satellites gives roughly 0.01 percent loss, median 2–3 ms, and not one sample above 50 ms from the wired client. This is not a coverage or stability problem. One thing that misled me for a while: an iPhone on the same SSID works perfectly. I took that as evidence multicast was fine on wireless. It isn't — Apple's mobile stack sends QU queries requesting unicast replies, so an iPhone never needs to receive multicast at all. Why I think this is a defect That address is in the Local Network Control Block. RFC 4541 section 2.1.2 states that traffic to 224.0.0.0/24 must be forwarded on all ports regardless of IGMP snooping state. It isn't supposed to be filterable. And before anyone suggests IGMP settings on the ONT: that address is link-local, TTL 1, and never touches the WAN, so nothing upstream can affect it. I mention it only because that's what support suggested in the thread below, where it wasn't applicable either. A near-identical report on another model Thread ID 2478846 on this board — "Orbi 37x and Local Network Control Block (224.0.0/24) multicast", June 2026. RBE371 with two RBE370s, so 770 series rather than mine. Same filtering problem, same address block, and that poster independently describes "a difference between RBS/RBR ethernet port traffic management and wireless management." In his case the mDNS group still gets through and other groups don't; mine looks like a worse version, with the mDNS group itself gone. Two model families showing the same class of problem points to something shared in the firmware rather than a model-specific fault. That thread is still unresolved and escalation was requested. Three questions Is this a known defect, and is there a tracking item I can be attached to? The 12.1.11.10 release notes say it fixed "an IGMP snooping issue that caused satellite connectivity failures, and multi-device connectivity problems." Is that this? I can find no NA-region build newer than 12.1.10.12 — if that's the fix, is an NA release planned that contains it? Failing that, is there anything supported I can change on 12.1.10.12 to restore forwarding of this address block to wireless clients? Happy to provide full captures or run anything else that would help.6 G to Satellite is slow
I ran a speedtest of my Orbi97 in the interface and it is showing 66mbps download speed. My laptop has a 6G connection to a satellite with a strong signal, and while it normally gets pretty good speed, it will often drop to like 5mpbs download (upload is about 10 which is what my provider gives me). There aren't that many devices demanding the bandwidth. Other devices are using 2.4g and 5 g., but mostly 2.4 Any ideas on why this might happen and what settings I might use to prevent this slowdown?Looking for answers
I have the 973 with 12.1.11.15. Orbi router connected to AT&T Gateway in passthrough and gateway radios turned off, Orbi in Router mode. Router on main floor. One satellite on main floor on the other side of house with wired connection. Never any issues with this one. Second satellite upstairs with the following connections. From wall outlet to Asus 2.5 unmanaged switch. From switch to Satellite, from switch to URC MRX 5, and from switch to LG C3 TV. Connected to Router from wall outlet behind router on main floor. In the Orbi web interface it will show connection as 1000m for 2 to 3 days and then drop to 100m. Will go back to 1000m if unplugged at router and plugged back in or a power recycle. The MRX-5 is for a URC remote. I am aware that both the MRX-5 and LG C3 are 10/100 max. Why will it show 1000m for 2 to 3 days and drop to 100? This will happen also if I unplug the Satellite and have it in wireless backhaul. My question is if I leave the satellite in wired backhaul and the web interface shows a drop to 100m is this effecting the speed of the wired backhaul?Orbi 770 Satellites Randomly Disable All Radios and Drop Clients
I’m posting this to document a serious defect in the Orbi 770 series and to express growing frustration after months of dealing with it. I have an Orbi 770 system (RBE770 satellites, firmware V10.5.20.3). One or both satellites will randomly stop broadcasting on all bands (2.4 / 5 / 6 GHz) while continuing to report a perfectly healthy status everywhere Netgear tells you to look. From the router UI: Satellites show “Good” Backhaul (wired or wireless — tested both) remains connected No warnings, alerts, or errors From the Orbi mobile app: Satellites show online and healthy No indication of any issue From the satellite’s own web UI (when you log in directly): The page proudly states “Your WiFi Orbi Satellite connection is up and running” However, ALL radios (2.4 / 5 / 6 GHz) are disabled This is incredibly misleading. Yes, the satellite is powered on — but it is not functioning as a WiFi access point. The management interface claims everything is fine while the radios are effectively dead. The only way to discover this is by: Noticing degraded WiFi performance, and Manually logging into the satellite’s local web UI to confirm the radios are disabled There is no notification, no alert, and no exposed log entry that explains why this happens. Impact When this occurs: Clients drop or cling to distant APs Overall network performance degrades The mesh effectively collapses silently The only workaround is rebooting the affected satellite(s). This restores service temporarily, but the issue reoccurs — often once or twice per week. For a system in this price range, that is unacceptable. Why “Interference” Is Not a Valid Answer Even if this were RF-related (which I doubt), the platform provides no visibility and no control: No RSSI / dBm metrics No interference indicators No spectrum analysis No transmit power control No actionable RF diagnostics If satellites were “too close” (they aren’t, they're more than 40 feet away from each other), I still have no way to tune or mitigate overlap. The system simply disables itself and leaves the user guessing. Additional Context Firmware updates have not resolved this Hardware has been RMA’d with no improvement Wired vs wireless backhaul makes no difference My neighbor’s Orbi 970 series exhibits the same behavior All bands fail simultaneously, pointing to a firmware or radio state failure, not roaming behavior Conclusion This appears to be a fundamental firmware defect where the radio subsystem fails while every management interface (router UI, satellite UI, mobile app) continues to report “healthy” and “up and running.” For a premium mesh product, silently disabling radios with no alert, no diagnostics, and no explanation is unacceptable. If Netgear is aware of this issue, it needs to be acknowledged. If logs exist, they need to be exposed. If engineering is investigating, customers deserve transparency. Right now, this product behaves like an expensive beta.Intermittent loss of Internet access plus IOT issues
I am using the Orbi as Access Point only, have 3 satellites, Larger size 2 storey home, all sats are connected hardwire Cat6 to the 971. Initially worked well, but about 6 months ago I started to develop intermittent loss of connection to the internet. My router is a Mikrotik and am on FTTP. I have the Orbi setup for auto download of FW and running the latest on all units. The 971 has a 50cm Cat6 cable to the router/dhcp. I run 2 SSID's from this setup, one having both 2.4 plus 5/6 and the other locked to 2.4 for my IOT devices but the "IOT" connected deices cannot get any internet access at all when connected to it, the devices connected will get an IP address allocated but will not get access. I do have lots of IOT Devices in the house. I had the same issues with the AC unit not having access to the cloud, connecting either via the main SSID or the IOT SSID and after lots of trial and error I finally installed a different brand of AP again locked to 2.4g and hard wired to the router and that works perfectly has not dropped at all. This has me stumped, I've tried rebooting the 971 as well as all Sats and as many of the IOT devices I can but does not make any difference. Any suggestions would be appreciated.
