Multicast WLAN issues, chromecast and spotify

  • 0
  • 2
  • Question
  • Updated 3 years ago
  • Answered
  • (Edited)
I have connectivity issues with multicast when I try to use chromecast and spotify. I have enabled multicast replication and configured per guide:
https://gtacknowledge.extremenetworks.com/articles/Solution/Chromecast-is-not-connecting-or-streaming-on-wireless/

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.
Photo of Esa Kuusisto

Esa Kuusisto

  • 310 Points 250 badge 2x thumb

Posted 3 years ago

  • 0
  • 2
Photo of Hartmut Sachse

Hartmut Sachse

  • 2,598 Points 2k badge 2x thumb
Hello Esa,

have checked this post  https://community.extremenetworks.com/extreme/topics/chromecast-not-streaming-over-wireless 

if its helpful for you?

Bulk aps are not compareable to enterprise aps, the default multicast handling is very different.

Best regrads
Hartmut
Photo of Esa Kuusisto

Esa Kuusisto

  • 310 Points 250 badge 2x thumb
Hi

Yes, I have checked that post.

I have been wondering this issue for a while. If the traffic goes between wireless and wired using Identifi AP things work just fine.
Photo of Andre Faupl

Andre Faupl

  • 94 Points 75 badge 2x thumb

Hello Esa,

 

Do you have Wireless Replication also activated at the multicast configuration?

 

Like the help box it seems to be exactly your problem:

"Wireless replication" controls whether multicasts from wireless clients will be forwarded back to other wireless clients. Disabling wireless replication can save wireless bandwidth but some protocols (such as SpectraTalk's "Push to Talk" feature) won't work when wireless replication is disabled. When multicast bridging/forwarding is enabled while wireless replication is disabled multicasts to the address will only be forwarded from the wired network to wireless stations and from wireless stations to the wired network, not directly between wireless stations.

 

Regards,

Andre

Photo of Esa Kuusisto

Esa Kuusisto

  • 310 Points 250 badge 2x thumb
Hi

Multicast bridging checked. IP 0.0.0.0/0, Group All multicast, Wireless Replication checked.
Photo of Ronald Dvorak

Ronald Dvorak, Embassador

  • 48,924 Points 20k badge 2x thumb
Could you please post a screenshot of the role that is used for this wireless client.
Photo of Joseph Burnsworth

Joseph Burnsworth

  • 2,328 Points 2k badge 2x thumb
Are the wireless devices on different subnets or on the same?
Photo of Esa Kuusisto

Esa Kuusisto

  • 310 Points 250 badge 2x thumb
Yes, I can provide screenshots. It is not all default as I have tried to debug why it does not work.

All devices are in same subnet.

Photo of Joseph Burnsworth

Joseph Burnsworth

  • 2,328 Points 2k badge 2x thumb
Can we see the Policy Rules? Also,is Multicast enabled on the physical interface of the controller?
Photo of Esa Kuusisto

Esa Kuusisto

  • 310 Points 250 badge 2x thumb
Yes you can. Controller is in totally different network over Internet and traffic is bridged@ap.
Photo of Joseph Burnsworth

Joseph Burnsworth

  • 2,328 Points 2k badge 2x thumb
I have ran into where the last rule you have has hung it up. I have my rules set as

dest none
none src
Photo of Ronald Dvorak

Ronald Dvorak, Embassador

  • 48,924 Points 20k badge 2x thumb
I don't think that you'd need this 2 rules.
There is no deny rule so everything will be allowed ....you'd delete them.

BTW, you wrote "Chromecast ... cannot communicate with android phone" - does it work with IOS ?
Photo of Esa Kuusisto

Esa Kuusisto

  • 310 Points 250 badge 2x thumb
Ok. Removed the rules. Those were only for debugging.

I have not. Will try with IOS.
Photo of Esa Kuusisto

Esa Kuusisto

  • 310 Points 250 badge 2x thumb
No change with IOS. I can setup chromecast device and connect it to my wireless network. I can not find it after initial setup.
Photo of Esa Kuusisto

Esa Kuusisto

  • 310 Points 250 badge 2x thumb
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.
Photo of Esa Kuusisto

Esa Kuusisto

  • 310 Points 250 badge 2x thumb
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.
Photo of Bill Handler

Bill Handler

  • 1,314 Points 1k badge 2x thumb

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 role

80 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

Photo of Esa Kuusisto

Esa Kuusisto

  • 310 Points 250 badge 2x thumb
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.
Photo of Esa Kuusisto

Esa Kuusisto

  • 310 Points 250 badge 2x thumb
Little bit more tcpdumping. I used pineapple ap as a alternate AP. All works great with it. From wireshark I can see that only ipv4 is used and all connections work fine.Something with ipv6. I keep looking and post when I find something.

For reasons unknown to me even with new VNS and multicast allowed in topology Apple device tries mDNS (ipv6) to find the chromecast. When I use pineapple ap which do not support ipv6 all happens in ipv4 and apple device finds the chromecast. All ipv6 options are disabled and ipv6 is disabled at the router.

Or could the problem be more inside AP? I looked a into to a AP /flash/home/config/current.cfg. From there I found something interesting:

Under radio x vns 1 I found vlan configuration where traffic is forwarded.
cset vapDynamicEgressVlanList 0:2 40970 4
cset vapDefaultContainVlan 0:2 40970

and under topology settings. What ever I change in controller does not change anything in this settings.
# cset topology2Vlan key:vlanId tagged/untagged tunnel/bridge
cset topology2Vlan key 4 vlanId 40970 untagged bridge
cset topoMcastFilter key 4 add rule 1 allow 224.0.0.5/32 wirelessRep disable
cset topoMcastFilter key 4 add rule 2 allow 224.0.1.1/32 wirelessRep disable
cset topoMcastFilter key 4 add rule 3 allow 224.0.0.1/32 wirelessRep disable
cset topoMcastFilter key 4 add rule 4 allow 239.255.255.253/32 wirelessRep disable
cset topoMcastFilter key 4 add rule 5 deny 0.0.0.0/0 wirelessRep disable
(Edited)
Photo of Esa Kuusisto

Esa Kuusisto

  • 310 Points 250 badge 2x thumb
This now fixed. Problem was that I was using site. After deleting the site and assinging wlan services individually to APs chromecast started to work.

Using wireshark now I can see mDNS searched using ipv4 and ipv6 and also I see devices using ipv4 SSDP to search chromecast.

Thank you for the help. You know who you are!

Gtack article should be updated.