NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.

Forum Discussion

EnjoyLife73's avatar
EnjoyLife73
Follower
Apr 19, 2026

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 ShieldTV and the iPhone (and other phones) are on the Guest network when trying to cast to it.

7 Replies

  • schumaku's avatar
    schumaku
    Guru - Experienced User

     

     

    StephenB wrote:

    The IoT network would also work.

    FURRYe38 wrote:

    Try connecting these devices to the main WLAN to see if they work for casting. 

     

    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. 

     

    Since then, the IoT network was added - with the very vague, decode-able for hardcore IT and network people only :

     

    ===

    IoT network: The Internet of things (IoT) network is enabled by default so that you can connect WiFi-enabled smart devices that can range from light bulbs to appliances. If you do not need the IoT network, you can disable it. You can select the radio bands for the IoT network and change the WiFi network name (SSID), security option, and password, all of which are unique to the IoT network.

     

    Guest network: The optional guest network is disabled by default, but you can enable it so that guests and visitors can connect to your WiFi without compromising the security of your other WiFi networks. You can change the WiFi network name (SSID), security option, and password for the guest network, all of which are unique to the guest network.

    ===

     

    To compare, here what the fine Netgear UM for the WEB7xx Access Points says:

     

    ===

    Enable or disable client isolation for a WiFi network

     

    By default, client isolation is disabled for a WiFi network (SSID or VAP), allowing communication between WiFi clients that are associated with the same or different WiFi networks on the AP. For additional security, you can enable client isolation so that clients that are associated with the same or different WiFi networks cannot communicate with each other, except for communication over the Internet, which remains possible.

    ===

     

    How difficult can it be, to bring a comprehensive section on both the IoT and Guest network to the  (admitted consumer class Orbi) documentation please?

     

    In contrast, the Orbi User Manual does contain almost 100 times (wasting the same number of pages):

     

    ===

    Change the  xxxx

     

    To change xxxx 

     1. Launch a web browser from a computer or mobile device that is connected to your Orbi network.

    2. Enter orbilogin.com (Windows and Android devices) or orbilogin.local (Apple MacOS and iOS devices).  A login window displays.

    3. Enter the Orbi admin user name and password. The user name is admin. The password is the one that you specified when you set up your Orbi. The user name and password are case-sensitive. The BASIC Homepagedisplays.

    4. Select ADVANCED>Advanced> xxxx

    ===

     

    Hope some moderator like KevinLiT​ and fellow community members like StephenB​ and FURRYe38​ manage to push this documentation deficiency and disproportion.

     

     

     

    • StephenB's avatar
      StephenB
      Guru - Experienced User
      schumaku wrote:

      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.

      • schumaku's avatar
        schumaku
        Guru - Experienced User
        StephenB wrote:

        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-)  

         

        StephenB wrote:

        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.

         

         

  • FURRYe38's avatar
    FURRYe38
    Guru - Experienced User

    Try connecting these devices to the main WLAN to see if they work for casting. 

    Guest Network has isolation features so may not work when connected to the Guest Network. 

    • StephenB's avatar
      StephenB
      Guru - Experienced User
      FURRYe38 wrote:

      Try connecting these devices to the main WLAN to see if they work for casting. 

      The IoT network would also work.

       

      Casting definitely won't work on Guest since the router prevents devices on guest from connecting to each other.