cancel
Showing results for 
Search instead for 
Did you mean: 

Multicast WLAN issues, chromecast and spotify

Multicast WLAN issues, chromecast and spotify

Esa_Kuusisto
New Contributor III

I have connectivity issues with multicast when I try to use chromecast and spotify. I have enabled multicast replication and configured per guide:
https://extremeportal.force.com/ExtrArticleDetail?an=000074801

Chromecast problem is with that cannot communicate it with android phone.
Spotify problem is that cannot control spotify at amplifier from laptop. Something to do with multicast.

My test setup is one 3805i AP and V2110 controler at other location. So traffic is bridged@AP. Version 09.21.02.0014. Traffic goes inside one AP. No problems if traffic goes between wired and wireless.

No problems if I use some bulk home AP. I have not filtered any traffic. All traffic should pass. Multicast bridging enabled with 0.0.0.0/0. Issue did exist also with couple older software releases.

Any clues where to check? This should be possible as this works with bulk no name AP, but not with identifi.

1 ACCEPTED SOLUTION

nevajbeach
New Contributor

Hello Extreme Networks Community,

It sounds like you're experiencing issues with multicast traffic on your WLAN setup, particularly affecting Chromecast and Spotify. The Chromecast problem appears to be related to communication with your Android phone, while the Spotify issue involves controlling the amplifier from your laptop. Given your setup, with a 3805i AP and a V2110 controller bridging traffic at the AP, it seems the multicast traffic isn't being handled effectively when contained within a single AP, although it works fine between wired and wireless connections. To resolve these issues, you might want to explore more robust network configurations or firmware updates. Additionally, for a smoother Spotify experience, consider using the Spotify Unlimited Skips APK, which can offer enhanced functionality and control over your music playback.

Good Luck!!

View solution in original post

21 REPLIES 21

Esa_Kuusisto
New Contributor III
Hi

I tried using your suggestion. No change. I tried using Win 7 laptop but no go. I have default permit as a default rule.

Direct connections work but these devices want to make automatic discovery to find each other and make things work. For some reason that discovery does not work and I have no idea what to next.

Bill_Handler
Contributor II
If you are interested in additional testing, below is what we discovered with a customer when was using ChromeCast and a default deny role. We were able to troubleshoot the problem and come up with the below filters which worked for us. Of course, your mileage may vary; we were working with laptops, not Android/iOS devices...

Chromecast - Ports to open for a Deny role80 TCP HTTP - AirPlay

443 TCP HTTPS - AirPlay

554 UDP/TCP RTSP - AirPlay

1900 UDP SSDP - Bonjour

3689 TCP DAAP - AirPlay

5000 TCP - Mirroring

5297 TCP - Bonjour

5298 TCP/UDP - Bonjour

5350 UDP NAT Port Mapping Protocol Bonjour

5351 UDP NAT Port Mapping Protocol Bonjour

49159 UDP MDNS (Windows) - AirPlay / Bonjour

49163 UDP MDNS (Windows) - AirPlay / Bonjour



tcp > port - 5000 (seen with music)

tcp > port - 7001 (seen with video)

tcp > port - 7000 (seen with picture/file)

tcp > port - 7100 (seen with display-mirroring)

udp > port - 7010 (seen with display-mirroring)

udp > port - 7011 (seen with display-mirroring)

tcp > port - 3689 (iTunes music sharing)

tcp > port - 49152-65535 (dynamic ports)

udp > port - 49152-65535 (dynamic ports)

tcp > port - 123 (so appletv can get time)

udp> port - 123 (so appletv can get time)

8008-8009 - TCP transmission between Chromecast and casting device

Thanks,

Bill

Esa_Kuusisto
New Contributor III
Finally had some time to do some debugging.

Using wireshark I can see mDNS traffic coming from wif-interface. I can see going out from eth0 interface of the AP. If I put one device to 2.4Ghz and other to 5GHz I can see mDNS coming in from other but not going out from other channel.

I added second 3805i AP to configuration. If I connect my iPhone to AP 1. and Chromecast to AP 2. Using wireshark I can see mDNS coming from AP1 wif interface. Going out on eth0. Same time using wireshark on AP 2 I can see mDNS coming in from eth0 interface. I cannot see mDNS going out on wif interface of the AP 2.

Same behavior even I disable multicast replication and multicast bridging. Traffic looks like this:
fe80::81d:5929:13b:4926 ff02::fb MDNS 202 Standard query 0x0000 PTR _googlecast._tcp.local, "QM" question
fe80::81d:5929:13b:4926 ff02::fb MDNS 211 Standard query 0x0000 PTR _raop._tcp.local, "QM" question PTR _airplay._tcp.local, "QM" question

My conclusion is that identifi AP cannot replicate ipv6 multicast or even pass it thru if it comes from eth0 (wired interface). Even upgraded to v10 software. No change.

Esa_Kuusisto
New Contributor III
Looks like that mDNS (multicast) traffic using IPv6 is the source of the problem. I can see that traffic when connecting wireshark to AP and capturing traffic. That is traffic type what I can see.

Esa_Kuusisto
New Contributor III
No change with IOS. I can setup chromecast device and connect it to my wireless network. I can not find it after initial setup.
GTM-P2G8KFN