NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
971 with 10GB Gateway slow LAN Ports
971 / 2 970s and Xfinity X10 gateway. My new Xfinity plan and XB10 Gateway gives me 2Gb/2Gb up/down, but... I cannot take advantage of the 10GB ports on the XB10 or all the ORBI Wired ports (Router and Sats) get slow on download to around 300Mbs - upload is fine up to 2Gb. So, while I have 2Gb/2Gb up/down from Xfinity, I can only get that with WIFI devices. Wired devices are terrible. If I use the 1Gb ports on the XB10, all is fine but of course tops out at 1Gb/1Gb. If I put a 2.5Gb switch between the Orbi and Gateway, that helps somewhat with wired devices topping out around 600-700gb. Don't know why that helps, but I don't view that as a long-term solution - it's just weird. Is this a general issue with 10GB gateways and Orbi? The AI bots lead me to think it might be. Or is there some setting on the Orbi that will get this working correctly? Any insights appreciated. The Orbi is in Router mode and the Gateway in Bridge mode. I tried AP mode, but it didn't help the Orbi Ports. It could however be a workaround solution as all the XB10 ports worked fine if I use the Orbi only as WIFI and don't use any of the Lan ports, but I don't love that setup.mDNS/Bonjour issue on RBE971 running firmware V12.1.11.15_5.4.12
Similar mDNS/Bonjour issue on RBE971 running firmware V12.1.11.15_5.4.12 I'm experiencing what appears to be a very similar issue on my Orbi RBE971, despite running the newer firmware V12.1.11.15_5.4.12. Two Elgato Key Lights intermittently disappear from Bonjour discovery on my Mac Studio, even though both remain connected to Wi-Fi and accessible through their direct HTTP control interfaces. I've performed extensive troubleshooting and have the following findings: Both lights respond successfully to ping and direct HTTP requests, even when they disappear from Elgato Control Center. Bonjour discovery from the Mac intermittently finds only one light, or sometimes neither. An iPhone using a DNS-SD discovery app can successfully discover both lights. When the Mac connects to my separate 2.4 GHz IoT SSID, both lights become discoverable immediately. When switching back to the main SSID on either 5 GHz or 6 GHz, one of the lights consistently disappears from discovery. Packet captures using tcpdump confirm that the Mac sends mDNS multicast queries, but no mDNS responses from the missing light are received during the failure. The other light responds normally. Restarting the Elgato software, refreshing macOS's mDNSResponder, and power-cycling the affected light did not resolve the problem. Rebooting the Orbi router immediately restored both lights, including when the Mac was connected to the main network on 6 GHz. This behavior suggests a potential issue with multicast/mDNS handling between wireless clients. I recognize that my packet captures don't conclusively establish where the traffic is being lost. Given the similarities to the original report, I'm wondering whether this could be related to the same underlying issue, despite the newer firmware. Could a NETGEAR moderator or engineer please investigate or escalate this to the firmware team? In particular, I'd appreciate clarification on whether Wi-Fi-to-Wi-Fi multicast forwarding is a known issue in this firmware and whether a permanent fix is available. I'm happy to provide additional diagnostics or packet captures privately if needed. Thank you!It is a 10 Mbit/s half-duplex issue
It is a 10 Mbit/s half-duplex issue; I had the same problem with the tado internet bridge. The only way I could get it to work was to use a network switch instead of connecting directly to the RBE971, which also started having problems again, so I ended up upgrading to the tado X, which uses Wi-Fi instead.Orbi 970 Protection Engine blocks ChatGPT file uploads
After updating my Orbi 970 firmware, file uploads to ChatGPT Temporary Chat fail when connected over Wi-Fi. The same uploads succeed immediately over cellular data. Disabling the Orbi Protection Engine completely resolves the problem. This is reproducible and strongly suggests that the Protection Engine is incorrectly blocking legitimate HTTPS upload traffic. Please escalate this to the firmware engineering team for investigation and correction.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.Orbi RBE971: Selective website and DNS failures improved after disabling Protection Engine
Orbi RBE971: Selective website and DNS failures improved after disabling Protection Engine Sharing this in case it saves someone else the time I spent chasing it. Over the last few days, some websites loaded normally, others were very slow, and some would not load at all. This affected three laptops and multiple mobile devices. I reworked my home network, but the problem continued. Ninjapatches.com was a consistent example. Turning off Wi-Fi on my phone allowed it to work over cellular. Connecting my laptop to a VPN also made it work while using the same home Wi-Fi. My setup: Orbi RBE971 in Router mode Firmware: V12.1.11.15_5.4.12 Protection Engine: 2.2.214.4/1.0.0.2049 Brightspeed Fiber through a Calix GP1100X ONT DNS configured as 1.1.1.1 and 8.8.8.8 A Cloudflare test showed 660 Mbps down, 475 Mbps up, and 0% packet loss. The useful clue came from DNS testing: lookups for Ninja Patches timed out through the Orbi and through direct queries to both Cloudflare and Google. A curl test also stopped at “Resolving timed out.” I went to: Advanced → Security → Protection Engine I unchecked Enable Protection Engine and clicked Apply. With the VPN still off, this previously failing command then succeeded: nslookup ninjapatches.com 1.1.1.1 It returned 23.227.38.32, and browsing appeared to improve. I’m treating this as a temporary troubleshooting workaround because it disables a security feature. I have not confirmed a permanent fix, retested every affected device, or completed a repeated on/off comparison. Has anyone else experienced this with the RBE971 and these versions? Can NETGEAR confirm the expected Protection Engine version and whether there is a supported update or refresh procedure? I’d like to have the feature enabled without the DNS failures. Hopefully these details help someone facing the same frustrating combination of good speed-test results and websites that refuse to load.
