Has anyone had any success configuring a chromecast device?
What model access points are you using?
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.
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
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.
I have similar issue and couldn't find fix yet. I have first gen. of Chromecast.
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
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".
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".
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.
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.
Did ya'll do Bonjour Forwarding on the MX?
You have to do that on the MX and the AP's config > Access section.
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.
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.
@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.
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)
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.
Yes.. Under wireless account control changed Client IP assignment to bridge mode. Started working.
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.
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!
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.
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.
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.
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!!
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!