mDNS ad problem

Hi Igor,

You are experiencing what many of us have been experiencing.

If you want to see the history of this discussion go here - http://e2e.ti.com/support/low_power_rf/f/851/t/290584.aspx

If you would like to see a potential workaround to the issue, check this discussion out - http://e2e.ti.com/support/low_power_rf/f/851/t/313896.aspx

Glenn.

Hi Glenn,

You're quite right. Actually there are many issues with mdns:

1. The device does not respond to mDNS queries automatically. This problem is already discussed within the community and TI did clarified that they have no intention to improve the firmware in that regard.

2. The device name is hardcoded to "target". This problem is also already discussed and TI did promised to address it in the next firmware release. 

3. During the Smart Config procedure execution, the TI-provided application (at least for Android) does not detect mDNS advertisement message from the device so the procedure finishes only on the timeout expiration. I presume this problem is specific to my particular case as I have found no discussions on that issue. So it seems the problem is caused by corrupted message sent by the device.

4. The CC3000 host driver provides API  mdnsAdvertiser()  that allows applications to trigger mDNS ad message transmission. According to the manual, it returns zero on success. In my case it returns a non-zero value and the transmitted message is not recognized by listeners (even by that from TI). Something is definitely going wrong.

Hi Igor,

Some more information.

3) I get the exact same issue with IOS, and yes it has been discussed, here is one such post - http://e2e.ti.com/support/low_power_rf/f/851/p/312881/1091031.aspx#1091031

The suggestion from Alon from TI support is to call mdnsAdvertiser multiple times in case UDP packets are getting lost. I have tried this, and it still fails to stop the SmartConfig process. I am continuing testing to ensure there is nothing else on my end. But it would seem that is not the case since a few people have reported this now.

4) This has also been reported by others.

Most of these issues do not matter once you implement your own solution as many of us are now doing. The SmartConfig issue on the other hand, is going to be a problem. I guess we could try and code around that issue also, but I haven't looked into it close enough to see whether it is possible from the IOS end. It may also require using another 1 of the 4 available sockets on the CC3000 to do this.

Glenn.

Hi Glenn,

Thanks for the pointing. Unfortunately the chain does not cover a follow-up investigation. Anyway the conclusion is that the cause of the problem is still not clear. So the chances are it's not related to the CC3000 device itself. As such the root cause need to be found before proceeding with a workaround.

With that purpose, I'd manually parsed the captured raw message (see the original post) and found no problems. There is no packet missing or corruption. The message seems syntactically correct and semantically meaningful (see the attached file). I'm not a mDNS guru, please correct me if it's wrong.

Imo, the implication is no matter how  the message is generated (by the TI's firmware or by the user's app), the result will most likely be the same. It would not work here. It seems here is a factor external to CC3000 that prevents the things from working. And the factor may be different in each particular network setup.

By the way I read the George Hawkins' blog where he explain how the smart config works. Excellent post! Devil knows what did prevented TI from sticking with that method to provide the device with the sender's IP address so the device can send "stop smart config" message directly to the sender. It's really a pity that TI opted to use the mDns mechanism instead.

The mDNS is not designed for unsolicited response messages. So it's no surprise sometimes it does not work. As such, all users (even those not interested in device discovery at all) actually will have to implement a full-blown mDNS responder in their code with the sole purpose to finish the SmartConfig procedure gracefully. Looks odd.

---

regards,

    Igor

4034.mdns_dump.pdf

Hi Igor,

I am all for root cause analysis when the knowledge obtained will be used to resolve the issue within the time frame required. If that is not the case, it is just annoying knowledge and it may have been better to spend the time and energy on a workaround.

Working on your premise, that it is not the CC3000 that is causing the issue, I have begun to dig into the App side of the equation, which in my case is Objective C code for my IOS devices.

It looks relatively simple to workaround this issue and provide a custom solution to stop the smartconfig process. Smartconfig comes with the stopTransmitting method, so all one needs is a way to trigger this method. I propose a UDP listener that is set to a specific port, this is then the port that the CC3000 needs to send a broadcast packet out to once it finishes joining the network. This packet could be picked up by the client app and used to both stop smartconfig and also to configure the app with the correct IP address. This solution, just like the mDNS query workaround would be more simple than developing a full blown mDNS implementation.

Sorry, I didn't look at the packet trace, as I really do not know mDNS packets well enough to comment. I have noticed that my preferred network sniffer (Microsoft Network Monitor) does parse the packet differently at different times, which indicates the packet is not consistent.

Glenn.

Hi Igor,

I wonder if you can actually capture what you are sending with some sort of mdns application, a few java ones exist if you google them.  I see you are using home_assistant as your name, but are you putting that into the app as the string to look for?  

I just dont see where you are going wrong, but I can say 0xc5 is expected for the size of your name, mine returns 0xc6 and you use one character less.  So it seems like the CC3000 liked the packet but whatever you are using is not for some reason.  Maybe try without the underscore?  Here is some info about my packet to look at:

Using the smart config app:(notice the Device Name must match what is in you packet)

My packet according to Wireshark:

My packet being seen by DNSSD for Chrome:

Hope this helps,

Chad

Hi Chad,

In first, thanks a lot for confirming that mdnsAdvertiser() does not return zero on success. It turns out the comment in the header

//@return On success, zero is returned, return SOC_ERROR if socket was not 
//! opened successfully, or if an error occurred.

is just wrong and misleading. Seems it was blindly copy-pasted from somewhere.

As for the device name, my screenshot does correspond to the name as it is in the TI-provided source. Of course I did tried different names to make sure changing the name does not make a difference. Also I did tried to increase the string length argument for mdnsAdvertiser to count the null terminator. Just wasted my time.

Concerning the problem, I suspect something is wrong with my Android device (Samsung GT-P6810) running the SmartConfig app. I did tried two of them with the same result. But I did notice other applications using multicast are unable to work properly on that devices (Bonjour browser, PeerDeviceNet, etc.). Will try different device.

---

regards,

    Igor