5.7.0.3 problem-- AirPlay mirroring non-functional on same access point

[tschaps]

Anyone planning to use Apple TV's (small Roku-type devices, for those who don't know) to mirror the screens of iPads, iPhones, and laptops, the latest update breaks this functionality if the two devices are connected to the same radio of the same AP.

I have spent a lot of time testing this while preparing to rollout out Apple TVs on MSM765zl/MSM430/MSM460 (60+ APs) school network to work with teacher iPads to mirror the screen and stream video. This uses a protocol called AirPlay, and it worked great up until the update, and no settings have changed.

Now what appears to happen is that the iPad can find the Apple TV (which means that Bonjour discovery packets are getting passed between wireless clients properly), and then you can tap to mirror the screen, but on the display or projected image, nothing happens, and it eventually times out. I have also tried this on a Mountain Lion-equipped MacBook with the same results. 

If I walk down the hallway, as soon as my iPad associates to a new AP, the mirroring will work as expected (and it's nothing specific to this AP, have tried this by moving equipment over the building, works the same everywhere). Then, if I walk back to near the Apple TV, as soon as the iPad jumps to the same AP, the screen mirroring freezes, then times out and disconnects. 

I don't believe this is multicast filtering related, as the Bonjour discovery would not work as well as it does. It appears the port(s) which are needed to start the mirroring session are now blocked between wireless clients on the same radio (and the APs are set to allow ALL traffic on the VSC in question). But it has something to do with traffic between clients on the same radio, not AP--- an iPad or iPhone 4 on Radio 2 (2.4 Ghz) *can stream fine* via AirPlay to an Apple TV connected to Radio 1 (5 Ghz) on the same AP. 

Though we are planning to hard-wire the Apple TVs with ethernet as much as possible to minimize bandwidth, we need this to work as it used to for those cases that no ethernet is available. It makes me also wonder what other traffic has been blocked in the latest update that might come back to haunt later. 

If anyone has the ability to test this on your system, or particularly if you have not updated to 5.7.0.3 but plan to and have an Apple TV to test this, you'll want to check it again after the update. You need to use the controller web interface to make sure your devices are connected to the same APs for accurate testing results. Any comments/ideas/relevant experience are welcome. 

I do plan to open a case, but I hardly have time right now to type this (while eating lunch), much less fart around with HP support on the phone. 

Thanks 

[tschaps]

To update on what I did to troubleshoot this, I reverted one of my MSM430's to autonomous mode (still at 5.7.0.3, obviously) and recreated the configuration, and I verified that Airplay mirroring also does not work on an AP in autonomous mode. Then I reverted the firmware in just that AP to 5.5.3.0-01 and recreated the configuration again, and I confirmed that Airplay worked fine on that version. I am not able to find the version 5.7.0.2 I had installed on the system previous to 5.7.0.3, and I think I deleted it, thinking I'd never need it again. However, I know from much testing and usage by many people here over the past 3-4 months that Airplay had no problems whatsoever until I upgraded the wireless controller (and, therefore, AP's) from 5.7.0.2 to 5.7.0.3.

Still hoping someone out there can verify this. I think I have enough data points to open a case, maybe if I have time this week-- 

[SHawkins]

Anecdotally,  I think one of my clients has the same problem with 5.7.0.3.

We haven't taken the steps you did, which were absolutely great troubleshooting steps, but they saw basically the same thing.

Please, absolutely get a case open with HP.  This needs to be looked at deeper, as it would help a lot of us.

[SHawkins]

A thought on a possible workaround - please try it if you're willing and let me know the results

Under AP configuration, turn off igmp proxy.
Ideally also configure your switches with igmP turned on, on every vlan on every switch in your network, with at least one device with igmp on also having an ip in each vlan so it can query the multicast group.

I'd bet $1 this might fix it

[SHawkins]

P.S. I am assuming you're *not* tunneling your traffic back to the controller.

[tschaps]

---

@SHawkins wrote:
...Under AP configuration, turn off igmp proxy.
Ideally also configure your switches with igmP turned on, on every vlan on every switch in your network, with at least one device with igmp on also having an ip in each vlan so it can query the multicast group.

I appreciate the try, but no cigar. First off, as far as I can tell, AP's in autonomous mode do not have the "IGMP Proxy" setting, and this issue happens just the same whether the AP is in controlled mode or autonomous. "IGMP Snooping" is an option on both, I tried turning if off in autonomous mode, no change. I did go to the controller IGMP Proxy setting (actually found on mine under "Team: (name)" -> Network) and confirmed it is actually off, since our vendor set this up without using the Internet interface and we don't tunnel traffic to the controller, there's no upstream or downstream traffic to be proxied. 

In any case, the only sure thing which makes Airplay mirroring work is downgrading the firmware to 5.5.3. Instantly on reboot, it all works again as inspected. Upgrade again to 5.7.0.3, Airplay no work. 

Another reason I am sure that the controller settings are not relevant is that this is really an issue of traffic on a single radio (within an IP which may have multiple radios). I have two networks on my test AP, "Airplaytest2.4" and "Airplaytest5G" on the same subnet. Airplay mirroring between two devices, one of them on each radio of the test IP, works just fine, as expected. Only when the Apple TV and other device (be it an iPad, iPhone 4S or Mac running Mountain Lion) are on the *SAME* SSID on the *SAME* radio does the failure to communicate occur.  And as before, multicast traffic seems to be fine, the devices can see the Apple TV via Bonjour, but unicast traffic between them is blocked, so they can't connect. If I disallow traffic between all clients on the VSC, then they can't even see the Apple TV via Bonjour, so this is not the same as using that setting.

As for the switch setting, this traffic does not make it back to the switch, the traffic between clients on the same radio should go right back out wirelessly and not even hit the wired network. However, IP IGMP is enabled n all switches and relevant subnets, as we have a lot of Apple equipment which uses Bonjour to find network resources.

Any more ideas? :)

Thanks

[tomlinsonk48867]

I am experiencing the same issue. 

[ISoliman]

mmm When you mentioned that this traffic is not working between clients in the same SSID I thought about the option under the VSC that allows and denies traffic between the clients, please check this setting, I remember reading that they changed the behavior in 5.7 so it is worth checking but I don't remember where I read that :D

[tschaps]

---

@ISoliman wrote:

When you mentioned that this traffic is not working between clients in the same SSID I thought about the option under the VSC that allows and denies traffic between the clients, please check this setting, I remember reading that they changed the behavior in 5.7 so it is worth checking but I don't remember where I read that :D

---

Thanks-- but it has been checked and double-checked. I have tried both settings on the controller and also on an AP in autonomous mode. There is a difference, though, actually, I think I wrote in one of these posts, but maybe not: using 5.7.0.3, if clients on the same radio *ARE* allowed to communicate, multicast traffic between them works, but they cannot ping each other. If no communication is allowed, then truly, there is no ping and no multicast traffic, and we do not use that setting anywhere except on our guest network.

[AnilGuptaAtHP · Accepted solution]

Try changing the VSC QoS settings to VSC-based Normal for now, and that should work. A bug has been logged on this, will be fixed.