Configuring chromecast on SSID?

fcsdjc
Comes here often

Configuring chromecast on SSID?

Has anyone had any success configuring a chromecast device?

34 REPLIES 34
PhilipDAth
Kind of a big deal
Kind of a big deal

Yes. I didn't have to do anything special. It just worked.

What model access points are you using?

MilesMeraki
Head in the Cloud

We've had a few issues with Chromecasts on our SSID; What firmware version are you running? I've updated to 25.6 and now things to appear to be working fine.  However, I'm assuming it could be related  to the known bug "investigation causes 2.4GHz radios to become unresponsive" as per the firmware release notes. 

Eliot F | Simplifying IT with Cloud Solutions
Found this helpful? Give me some Kudos! (click on the little up-arrow below)

I am running 24.8.

We still seem to have ongoing issues now on 25.6. We are running MR32's - Probably time to engage support however I'm assuming it's related to the 2.4ghz Radio issue reported in the caveats 

Eliot F | Simplifying IT with Cloud Solutions
Found this helpful? Give me some Kudos! (click on the little up-arrow below)

We've had similar problems, regardless of whether the Chromecast is generation 1 or 2 (have not tried the Ultra).

 

It's a bit hit or miss which is making it weird.  ~140 classrooms are now outfitted with Chromecasts.  Our high density schools have MR53's, while our lower density schools have MR33's.  The schools with MR53's report no issues with the Chromecasts, however we are increasingly (last 1 month or so) getting reports that the Chromecasts attached to MR33's are unable to cast properly.  They will display the screen cast, but then when you go to play dynamic content like LucidPress, youtube, WeVideo etc, nothing happens.  Rebooting the AP does not make a difference, though we did find that hard wiring the Chromecasts to a VLAN within the same layer 3 segment resolves the problem.  I do not suspect it is related to the AP being overwhelmed, nothing indicates that and we get similar results even if I go to the school when no one else is in it.

 

So the problem seems specific to the AP model #, not the Chromecast generation.

MijanurRahman
Getting noticed

I have similar issue and couldn't find fix yet. I have first gen. of Chromecast.

One tip I can give is don't use a domain of ".local" in your DHCP scope. If you are using Meraki you might now have a domain defined at all, but using ".local" makes it unreliable (".local" is a reserved domain for when there are no DNS servers).
pjc
A model citizen

Hi Philip, can you elaborate a bit on the issues you have seen using .local domain ?  Does it cause a problem with the AP or clients or both ?  Not heard or can find anything, so would be interested in your findings - Thanks

PhilipDAth
Kind of a big deal
Kind of a big deal

RFC6767 reserves ".local" for multicast devices (jump to number 3, "Multicast DNS Names").

https://tools.ietf.org/html/rfc6762

 

Chromecast uses this to register itself on your local domain.  When a device wants to find a chromecast it sends a multicast DNS query looking for chromecasts in the domain ".local".

https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-mobility/119017-config-chromec...

 

If you use ".local" for unicast services (AKA "normal" IP address), and you have a DNS server defined then you screw this mechanism up,  Now the queries will get sent to your defined DNS server, which will know nothing about the multicast DNS service, and fail.

 

 

So the moral of the story is never used reserved DNS domains on your network, especially ".local".

JPena
Meraki Employee
Meraki Employee

Also make sure that your SSID is not isolating clients.
Jose Pena
Network Support Engineer @ Cisco Meraki .:|:.:|:.
ASJ2018
Conversationalist

Hi 

I found a solution for this you need to change the DHCP leasing from in the SSID Settings from NAT DHCP to NAT Bridge Mode DHCP it works, we spend the whole day resolving this but got to the bottom of it.

 

The chrome cast does not like going on the internet via NAT DHCP.

 

A


@JPena wrote:
Also make sure that your SSID is not isolating clients.

 

GT
Here to help

Thank you this worked very well


@ASJ2018 wrote:

Hi 

I found a solution for this you need to change the DHCP leasing from in the SSID Settings from NAT DHCP to NAT Bridge Mode DHCP it works, we spend the whole day resolving this but got to the bottom of it.

 

The chrome cast does not like going on the internet via NAT DHCP.

 

A


@JPenawrote:
Also make sure that your SSID is not isolating clients.

 


 

CharlesIsWorkin
Building a reputation

Did ya'll do Bonjour Forwarding on the MX?

https://documentation.meraki.com/MX/Other_Topics/Configuring_Bonjour_forwarding_for_the_MX_Security_...

 

You have to do that on the MX and the AP's config > Access section.

ASJ2018
Conversationalist

Hi 

I found a solution for this you need to change the DHCP leasing from in the SSID Settings from NAT DHCP to NAT Bridge Mode DHCP it works, we spend the whole day resolving this but got to the bottom of it.

 

The chrome cast does not like going on the internet via NAT DHCP.

 

A

Correct.  This is because NAT DHCP networks inherently enable client isolation.

 

 

ASJ2018
Conversationalist

Hi 
I found a solution for this you need to change the DHCP leasing from in the SSID Settings from NAT DHCP to NAT Bridge Mode DHCP it works, we spend the whole day resolving this but got to the bottom of it.
 
The chrome cast does not like going on the internet via NAT DHCP.
 
A

I have chromecast capable wired AV equipment on a VLAN that is also used by wired workstations and securely attached wireless devices. I do not use bridge mode. An unsought benefit is that once the wireless device has connected to the AV device and the correct stream is playing, the phone can be turned off and the stream continues to play.

 

The SSID is in Layer 3 roaming mode.

 

From a security point of view, it is preferable to keep AV hardware on a different VLAN to corporate networks. One can either get clever with CIDR super/sub netting or make creative use of DMZ-style configurations.

 

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel

Layer 3 roaming mode does use bridging unless you roam to a different AP...


@PhilipDAth wrote:
Layer 3 roaming mode does use bridging unless you roam to a different AP...

I understand that, ;-()

 

However, I am led to believe that the Meraki way suggests that Bridge mode be used for typically static devices, whilst Layer 3 roaming be used for mobile devices. There is a certain logic in this. My rule of thumb is to wire anything that doesn't move, so largely unlikely to use the former option. Habitually I reserve a portion of the available IP addresses for any given (V)LAN for those devices that require a fixed IP address, but can't remember when I last had to make use of this. All my AV kit is wired and gets an IP address from a DHCP server.

 

 

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel

I've found that a lot of "smart" devices do simply not work reliably using layer 3 and concentrator.

Bridge mode however works perfectly, but activating the concentrator only allows reliable discovery and control of devices on the same AP as the management device.

 

Even hardwired devices become either noticably slower and more clunky or simply do not reliably work.

 

My guess is that most of these devices are a little bit too "clever" for their own good in trying to do transparent discovery and management.

 

Someone smarter than me can probably expand on this.

The problem with most smart devices is that many of them are truly dumb as far as communicating is concerned. Mostly because they have been designed by snowflakes for snowflakes. WiFi chipsets usually selected on the grounds of price alone, no awareness of security, or worse they flagrantly lie about the need for security and the risks involved.

 

Keep this K-R-*-P on a network of its own.  (Everybody's favorite radio station)

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel

Yes this is the correct solution.  You can see why here:  - in NAT mode clients cannot communicate with each other:

 

Note I just set up a separate SSID for the clients that require this to avoid compromising rest of network.

 

  • NAT mode: Use Meraki DHCP
    Clients receive IP addresses in an isolated 10.0.0.0/8 network. Clients cannot communicate with each other, but they may communicate with devices on the wired LAN if the SSID firewall settings permit.
  •  Bridge mode: Make clients part of the LAN
    Meraki devices operate transparently (no NAT or DHCP). Clients receive DHCP leases from the LAN or use static IPs. Use this for shared printers, file sharing, and wireless cameras.
Asif
New here

Yes.. Under wireless account control changed Client IP assignment to bridge mode. Started working.

GaryShainberg
Building a reputation

All,

 

I have just had a similar issues with a large client of mine and having switched from UBNT to Meraki their Chromecasts stopped working, after spending some time today trying to resolve this and also going through this great thread, I just wanted to add my thoughts on the resolution. 

 

We discovered two issues that both stop the Chromecast working, Layer 3 roaming and band-steering, if either of these are on, the CC will not work, so yes, it appears the solution is to create a seperate SSID and make sure these are not enabled and "hay presto" it all works.

CTO & Solutioneer
CMNA, CMNO, ECMS2
SNSA, SNSP
~~If you found this post helpful, please give it kudos. If my answer solved your problem, click "accept as solution" so that others can benefit from it.~~
KevinGoke
Conversationalist

SSID needs to be set into Bridge mode vs. NAT mode. Do this by accessing the "Wireless-AccessPoints"  and locating "Address and traffic." Select "Bridge mode: Make clients part of the LAN."
 
Then, allow the Local LAN access in the SSID. Do this by accessing the "Wireless-Firewall & Traffic Shaping." Then, locate "Layer 3 firewall rules" and "Allow Any Protocol to access the Local LAN on Any Port. 

Hello Everyone! I have a particular case: I´m having troubles to cast from a windows 10 desktop to chromecast, but I´m able to do it from a cell phone.. I´ve doing a lot of testing bun nothing works, here are the specs of the network:

 

- Separate SSID

- Bridge mode

- Band Steering disabled

- Multicast to Unicast conv disabled (also tried enabled)

- MR45

- Rls 27.5.1

- 802.11ax disabled (also tried enabled)

 

I don´t think it´s a windows issue, because I´m replacing a fortinet wireless network, and with that it works perfectly. I´m doing a PoV, so, you would guess what the customer is telling me.. 😞

 

thank you in advance for your comments!

GT
Here to help

Hi, it sounds like you have the right setting.

Now I have found lowering the bitrate down to 6 on that SSID on the "Access Control" has worked wonders on Chromecast deployment.

I really can't explain why sadly, it is just something I tripped over. Hope this little tip helps.

 

Something else, is the Win10 and Chromecast on the same SSID? this helps, but if bridge mode is on, it should work even if on different SSID's.  Are they on the same VLANs?  

 

Setting I have used

- Separate SSID yes and dis-similar SSID have worked.

- Bridge mode yes 

- Band Steering disabled no (I leave it on an drop the bit rate to 6Mpbs)

- Multicast to Unicast conv disabled (also tried enabled) ( I leave it on Multicast haven't tried this)

- MR45 (MR42,MR32,MR56) never tried it with a MR45 

- Rls 27.5.1 yes 

- 802.11ax disabled (also tried enabled) (I leave it on but, have tried this) 

 

they can be frustrating. 

 

 

PhilipDAth
Kind of a big deal
Kind of a big deal

Is the site using a domain of "local"?

  Hello Philip! thank you for your comment, now you mention it I recall the previous message you post about it, and I asked the customer, yes they are using a "GRUPO-LOMAS.LOCAL" domain.. you think that could be the cause? if so, what is your opinion that I can cast from a cellphone? I think it should have the same problem, but is not..

 

In that case, if I change the DNS onthe win10 computer to 8.8.8.8 just for test, that should work, right?

 

  I´m not so familiar with domains, and I guess the solution could be stop using the .local domain, how easy is to do that? just change the name and that is all? how could the customer network be affected with that change?

 

Thank you so much for your comments!

 

Mauricio.

PhilipDAth
Kind of a big deal
Kind of a big deal

Mobile phones ignore the domain parameter given out by DHCP (at least to the best of my knowledge).  So they are not affected.

 

Changing your DNS server is not likely to resolve it.  Giving your machine a static IP address with no DNS suffix, or with a different DNS suffix (like .internal) may sort it.

You need to avoid getting the DNS suffix from the DHCP server.

 Philip thank you so much for the information!! I´ll test it tomorrow and let you know the results.

msosa
Getting noticed

Hello Everyone! I went to the customer and now it is working, I thank all the comments you gave me, there was nothing involved with the problem we had. the fix procedure we found was:

 

- disable all firewall and antivirus software from the windows computer.

- disable/enable the wireless adapter

- Connect to the network, try to cast, it works.

- enable firewall/antivirus software

- the cast still working

- we also reboot the computer, and the cast still working.

 

The parameters of the configuration at Meraki are:

- Separate SSID yes and dis-similar SSID have worked.
- Bridge mode yes
- Band Steering enabled 
- Multicast to Unicast conv disabled 
- MR45 
- Rls 27.5.1 
- 802.11ax enable

 

   thank you all!! 

msosa
Getting noticed

Thank you GT, yes both are at the samen SSID and same VLAN.

 

Tomorrow I´ll go to the premises to do some test, I´ll do the lowering bitrate to see if it works and let you know.. thank you!

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels