cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1276
Views
0
Helpful
9
Replies

iPad guest users cannot see YouTube videos but Android devices can

Hi all,

I am in the process of moving a guest SSID from a local Wireless LAN Controller to it being anchored for security reasons to another WLC in the DMZ. I have created a test SSID which is anchored in the DMZ and have found that everything is working perfectly except for YouTube videos. While those guest users that are connected on Android devices can watch YouTube videos just fine, those connecting via iPads or iPhones are unable to watch these videos. Any ideas?

Thank you in advance for your help.

rgrds,

inayat

1 Accepted Solution

Accepted Solutions

Hi ,

Multicast is not supported between anchor and foriegn guest configuration.

Since Multicast is not supported over an anchored WLAN, client protocol such
as bonjour will no function and if the youtube APP from apple requires bonjour (multicast)
then it will not work.



View solution in original post

9 Replies 9

WLCs are 4400 series and running v7.0.230.0 code.

The odd thing is that internet radio streaming works just fine on the iPads and they can watch stuff like Bloomberg TV. They just can't seem to watch YouTube videos.

George Stefanick
VIP Alumni
VIP Alumni

I have a large guest network and have installed a number of guest anchors while consulting and never had this issue on any of my installs.

Since it seems to be device specific. The one item that jumps out at me, based on your post is TCP packet size. Are you limiting packet fragmentaion at all ? Perhaps, the iPad is sending larger frames and your network is having issues fragmenting them while the droid is sending smaller frames ? I had a real world experince with this at a customer site. HPs worked great, but MACs would break when they went to certain sites or did videos.

You could snff the traffic and compaire the frame size between the devices.

"Satisfaction does not come from knowing the solution, it comes from knowing why." - Rosalind Franklin
___________________________________________________________

Hi George,

Thank you for your reply.

I did two packet captures: once with a working Android device and once with a failing iPad. There did not seem to be any difference in packet sizes when trying to download a YouTube video (both seemed to be around 1368 bytes per packet). The packet capture with the failing iPad showed a number of TCP resets and attempts to connect to 224.0.0.251 MDNS) - that seemed to be the only difference with the packet capture from the working Android device.

What I did notice when looking at the existing local WLC (from where the iPads can successfully connect to YouTube - remember that they are failing when they are tunnelled to a test SSID in the DMZ) the local WLC contained a Layer 3 MGID for 224.0.0.251 with a number of users in that group which were iPad users. When I looked at the anchor WLC in the DMZ it did not have this MGID listed - or any other Layer 3 MGID for that matter.

Your comments and ideas please!

rgrds,

inayat

An additional strange observation:

I noticed that when I connected both an Android and an iPad to an SSID which terminates at a local WLC where Youtube works fine with both Android and iPads - only the iPad MAC address was listed in the L3 MGID as belonging to 224.0.0.251. The Android device was not listed!

So, there appears to be some kind of dependency with iPads/iPhones on L3 MGIDs in order to receive YouTube videos. Is anyone able to shed light on this matter and if a workaround/fix is possible to get the SSID fully working at an anchor controller? Thank you.

Just to recap: I want to test my tentative thesis that iPads/iPhones cannot receive YouTube videos if they are connecting to an SSID which is anchored to another Wireless LAN Controller eg in the DMZ. Could someone out there please try this on their own guest SSID if it is anchored in the DMZ and see if they are able to see YouTube videos on their iPads/iPhones via the official YouTube app. Thank you.

Just want to mention that 224.0.0.251 is multicast address used by Apple devices for Bonjour service. So it is normal that it is listed forIPAD, not Android.

Sent from Cisco Technical Support iPad App

Hi zhenningx,

Yes, I saw that. My real question is whether the Apple devices (iPad and iPhone) have a dependency on multicast when trying to stream YouTube videos because if they do then it seems to me based on the tests I have do so far that they will not be able to watch YouTube videos if they are connecting via an SSID that is tunnelled to an anchor controller (whereas those with Android devices can).

Is anyone out there able to confirm whether this is the case or not by doing a quick test ie trying to watch a YouTube video via the YouTube app on an iPad/iPhone when connecting to a guest SSID that is terminated at an anchor controller? I have tried it and it does not seem to work and I want to see if it is due to a misconfiguration on my part or whether it is a limitation of the Anchor WLC design. I know that Cisco say that multicast traffic is not supported over a guest tunnel. Thank you.

Hi ,

Multicast is not supported between anchor and foriegn guest configuration.

Since Multicast is not supported over an anchored WLAN, client protocol such
as bonjour will no function and if the youtube APP from apple requires bonjour (multicast)
then it will not work.



Hi fbarboza,

Yes, I think you may well be right in suggesting that the Apple YouTube app on the iPad/iPhone appears to rely on multicast and that is perhaps why clients cannot watch YouTube videos when connecting to an SSID which is terminated at an anchor controller.

It is a bit frustrating though because the YouTube app works just fine on Android devices even if connecting to an SSID terminating at an anchor WLC so it looks like the Android app is not reliant on multicast traffic.

rgrds,

inayat

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: