NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Casting and Airplay from Phones to NVidia ShieldTV not working.
Before switching to the Orbi 370, I was able to cast or AirPlay from phones to the NVidia ShieldTV. Now, I am not even seeing the ShieldTV as an option when trying to cast. I verified that the Shie...
Very curious where the device isolation "feature" is documented - for both the Guest and the IoT network. I remember when Netgear introduced the Guest network isolation on the now one decade old Orbi RBR50/RBS50 - also mostly without documenting it.
I agree the behavior isn't properly stated anywhere (and in the case of current Orbi systems can't be modified). It should be written down, and I also think users should have control over the isolation for both IoT and Guest.
AFAICT the main purpose of the IoT network is to allow WiFi 5 and older devices to connect to the network w/o loss of any WiFi 7 features. So it's really a legacy network.
AFAICT the main purpose of the IoT network is to allow WiFi 5 and older devices to connect to the network w/o loss of any WiFi 7 features.
The original driver was the absence of a control to disable e.g. the 5 GHz WiFi from a generally configured wireless profile. The initial reason for it's introduction was to overcome stupid IoT "discovery" Apps complaining that e.g. a mobile or a tablet is connected successfully to the WiFi network - instead being associated -only- to a 2.4 GHz band - depsite of the fact that the SSID does represent the very same network 8-)
So it's really a legacy network.
Not at all my friend!
Less for the legacy reasons we talked in the community many times before. Much more with the intro of WiFi 7, where higher requirements mandate for deploying WPA3-SAE for 6 GHz networks, where a lot of existing IoT devices still work on WPA2-PSK, or their documentations request configuring the wireless router to operate on WPA3-compatibility-mode - technically allowing both WPA2-PSK and WPA3-SAE on the same network. As such, it includes multiple AKM values, unicast encryption ciphers in the Robust Security Network (RSN) Information Element (RSNI). IEEE introduced something called RSN Override with the 3.4 WPA3 specs if wally brain is right. Netgear misleadingly names this WPA3 Personal Mixed.
Still today, the WPA3-compatibility mode remains cumbersome with many real-world implementations.
On top of that come 802.11w Protected Management Frames which are mandatory for with WPA3-SAE, with WPA3 mandatory for 6 GHz, and optional for 5 GHz and 2.4 GHz - but again required with WPA3.
I don't know what compromises Netgear has implemented on the Tri-Band Orbi systems in these aspects when it comes to configuration granularity. I -guess- PMF will be set by default with WPA3-SAE active, WPA3-SAE mandatory anyway, that would be the most logical and correct way from the standardisation prospective way at least.
So what has to happen with non-WPA3- and PMF-capable devices? Correct: Move them to the IoT network! That much about IoT network being legacy.
with the intro of WiFi 7, where higher requirements mandate for deploying WPA3-SAE for 6 GHz networks, where a lot of existing IoT devices still work on WPA2-PSK
That's what I meant by legacy network. And choosing a specific band is part of that (since single SSID has become ubiquitous). It allows these older devices to connect even though they don't support WiFi 7 features and requirements.
I wasn't intending to discuss the history, just giving my opinion on the purpose Netgear's "IoT network" serves today.
Well, Netgear documentation team (is there is something the like ...) has enough food they need to add some more pages to the non-existing Orbi Guest and IoT Network documentation. Should take not more than a few days to release a current, up2date documentation for these newish Orbi consumer stuff. I'm happy to review in case...