Discovery problem in iOS applications

[GoogleCodeExporter]

There is a problem with Cromecast discovery in Apple iOS apps(except in the 
Chromecast and Youtube app). The problem is in Cisco WLC WiFi-network setup 
(with mdns). Casting/discovery from all Android apps and the Google Cast 
extension in Chrome on all supported plattforms work as expected.

What steps will reproduce the problem?
1. Using a Cisco WLC environment set up in accordance to their setup guide:
http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/7-6/chromecas
tDG76/ChromecastDG76.html
2. Running AireOS version 8.0.121 on the WLC
3. Use an Apple iOS app with Chromecast support (except Chromecast and Youtube 
app, thoose apps work)

What is the expected output? What do you see instead?
The iOS apps with Chromecast support should discover and show the Chromecast 
devices. Instead no Chromecast devices is discovered.

What version of the product are you using? On what operating system?
Latest version of different Apple iOS(9.2) applications with Chromecast support.
For example SVT Play 4.1.1

Please provide any additional information below.
Using this setup it makes no differens if the iOS devices is in the same 
SSID/VLAN as the Chromecast unit or not. For all the other devices both 
scenarios work as expected. 

Original issue reported on code.google.com by matt...@nonetwork.se on 18 Dec 2015 at 10:35

[GoogleCodeExporter]

It seems unlikely to be an issue with Cast SDK since the Chromecast set up app 
discovers the device. Please make sure your set up is correct and contact Cisco 
support for any environment specific issues that could cause this behavior. 

Moreover, the doc you've linked suggest that after initial discovery - "The 
subsequent connections are TCP based unicast packets, which are explained in 
detail at: http://www.dial-multiscreen.org/dial-protocol-specification" (at 
very bottom) which could be a good place to look. 

Closing for now. Yet, feel free to respond to this ticket with specific repro 
steps including Chromecast device version/firmware info and receiver logs, if 
after troubleshooting the WiFi environment this seems like an issue with Cast 
SDK.

Original comment by na...@google.com on 22 Dec 2015 at 9:43

• Changed state: NotSDK

[GoogleCodeExporter]

Hi, geting hold of an IOS device and making some more tests and debugging on my 
own I would like to make some corrections of my previous statements.

It it stil true that there is only problems with casting from Apple IOS apps.
Even Youtube app is affected, only chromecast app discovers the chromecast 
units.(mdns queries looks normal from that app)
It does work in this network setup if sender and receiver is in same network 
segment, but not in different segments(ie when relying on the mdns 
functionality).

This makes me wonder if the implementation of the (mdns) discovery is different 
in the Chromecast app and the SDK. Thinking it might be something wrong with 
the mdns discovery whould explain why it stil works in the same networksegment 
since you then can fall back to the older DIAL discovery mechanism(if I'm not 
misstaken). Doing some mdns debugging in my WLC (Wireless LAN Controller) shows 
indeed what I think looks like a problem.
--
*Bonjour_Msg_Task: Jan 13 09:06:37.558: [PA] 34:ab:37:09:XX:YY Parsing 4 
bonjour Questions
Bonjour_Msg_Task: Jan 13 09:06:37.558: [PA] 34:ab:37:09:XX:YY Query Service 
Name: Polarfront.local., RR-Type:  INVALID RR TYPE !! , Class: 8001
*Bonjour_Msg_Task: Jan 13 09:06:37.558: [PA] processBonjourPacket : 1175  
CLIENT MAC =  34:AB:37:09:XX:YY  UNSUPPORTED QUERY Service Name: 
ChromecastX.local. , Type: 1C, Class: 8001
*Bonjour_Msg_Task: Jan 13 09:06:37.558: [PA] 34:ab:37:09:47:ad UNSUPPORTED 
Query Service Name: ChromecastX.local., Type: 1C, Class: 8001 
---

Expected questions would look like:
---
Bonjour_Msg_Task: Jan 13 09:15:24.948: [PA] 5c:e0:c5:26:XX:YY Parsing 1 bonjour 
Questions
*Bonjour_Msg_Task: Jan 13 09:15:24.948: [PA] 5c:e0:c5:26:XX:YY Query Service 
Name: _googlecast._tcp.local., RR-Type:  TYPE_DOMAIN_NAME_PTR , Class: 1
*Bonjour_Msg_Task: Jan 13 09:15:24.948: [PA] processBonjourPacket : 1016 
qNameStr : _googlecast._tcp.local., bonjServiceNameStr : 
_googlecast._tcp.local., bonjSpNameStr : _googlecast._tcp.local.
---

I have got further debug data(that is more extensive than I would like to 
anonymize) that I would rather not disclose in public.

Best regards

Original comment by matt...@nonetwork.se on 13 Jan 2016 at 10:04