• Resolved

Firmware bugs in mDNS on latest cc3000 firmware


I just started using the mDNS command and I noticed a few issues right away.  First off, I am using the latest firmware 1.11.  I have a lot of experience with mDNS, having written my own implementation previously.  So here are my issues:  

1. Local name is hardcoded to "target.local" instead of what the user specified.  So, for instance, I named my cc3000 "helloworld" with the HCI_CMND_MDNS_ADVERTISE command, but the mDNS response sets that name to "target.local".  So, instead of having a name that resolves to "helloworld.local", it resolves to target.local.  So, now it responds to ping at target.local:  

And here is the problem shown in wireshark:  

Also, here is another user asking for a change to TTL, but if you look, his wireshark information also reports "target.local"  : http://e2e.ti.com/support/low_power_rf/f/851/t/262801.aspx

Because of this all cc3000 devices on the local network will have the same conflicting name "target.local" -- very bad.  And because of this, local mDNS name resolution is quite broken.  

2. The mDNS "query response" is supposed to be sent in response to a query from another device on the local network.  So when there is an mDNS Query for the name helloworld (or whatever), the cc3000 is supposed to be listening and immediately send the "query response", but it seems that it is not listening to the multicast mdns port.  It should be continuously listening for queries and respond (when mdns is enabled of course).  In the above wireshark trace, it appears to work, but that is only because I am actually calling HCI_CMND_MDNS_ADVERTISE every 10 seconds.  This means that responses can take as much as 10 seconds just for name resolution, which is very bad.  The mDNS advertiser, when enabled, MUST respond to queries.  The cc3000 must continuously listen for the queries when mDNS is enabled.  

My recommendation would be to add a new value to the "mdnsEnabled" variable so that 0 = disabled, 1 = enabled, 2 = enabled and listening.  That way, it is not a breaking change.  

3.  I don't know if this is a wireshark parse issue or a bug in the mDNS packet, but the first letter in the service record is missing.  

4. Finally, this is more of a suggestion than anything else.  LLMNR is nearly identical to mDNS, but that is what all Windows Vista, 7, 8 versions all use by default.  The cc3000 could EASILY respond to both messages, the responses are nearly Identical for the local name (A Record).  Windows is still the most widely used OS in the world and it REALLY should work out of the box.  The cc3000 should implement LLMNR.  


  • I'm sad that this has gotten no response from TI - they're usually pretty good at at least acknowledging clearly competent technical questions.

    I was going to ask a nearly identical question - having found much the same things myself.

    For me the big issues are:

    • it announces an A record for itself using the name "target.local" rather than the name you gave the device.
    • it doesn't respond to mDNS queries.
    • it occasionally seems to fail to send an mDNS message when you use HCI_CMND_MDNS_ADVERTISE.

    Like Valkyrie-MT I've been recording the traffic on the mDNS multicast group. Rather than wireshark I actually wrote a tiny Java application to do this and used dnsjava to parse and display the messages so that I had complete control over things.

    Valkyrie-MT reports that he saw the first letter truncated from the service name in wireshark - I suspect this may be a wireshark issue as I did not see anything similar.

    Not responding to mDNS queries is a serious issue - are developers expected to handle this themselves? I.e. TI is giving them the choice of:

    1. using up resources to explicitly listen for queries and calling HCI_CMND_MDNS_ADVERTISE in response (or hand craft responses to simple hostname or reverse IP queries that aren't covered by HCI_CMND_MDNS_ADVERTISE), or
    2. saving on resources but not playing nice in the mDNS world.

    If that's the case can someone from TI please confirm it?

    Even if that's so I still think it's a bug that the CC3000 calls itself "target.local" in the A record, and it's definitely a bug that it sometimes fails to produce any mDNS message at all when calling HCI_CMND_MDNS_ADVERTISE.

    The CC3000 must use CSMA/CA so collisions shouldn't be the explanation for these missing messages, although maybe CSMA/CA isn't used when sending such small one off UDP packets? Even then my network is very lightly loaded so even given the potential for collisions I wouldn't expect to see this issue as often as I do.

    If the CC3000 announces itself via DNS-SD/mDNS then I really think it should handle queries too as part of its firmware and should respond properly to _device_info queries, and given that it advertises an A record I think it should also respond properly to basic hostname and reverse IP queries.

    At the moment the one off announcement (resulting from a call to HCI_CMND_MDNS_ADVERTISE) soon expires from the caches of any other clients on the network (and never appears in the caches of clients that didn't happen to be active at the time the HCI_CMND_MDNS_ADVERTISE call was made). And the "target.local" name is just bizarre.

  • In reply to George Hawkins:

    Hi George,

    Yes I can confirm that the CC3000 does not reply to mDNS queries. Also SRV, TXT and PTR types are user defined. The A type is not. There's only so much functionaility that can fit into the chip, so we have to pick and choose what to implement.


      ***  Please click the Verify Answer button on a post if it answers your question.   ***

  • In reply to made4engineering:

    Thanks for confirming that Aaron, but I am quite confident that we knew that the CC3000 does not reply to mDNS queries.  The problem here is that the mDNS spec requires that it does respond along with a variety of other requirements.  Including (RFC6762 - http://tools.ietf.org/html/rfc6762):

    • A Multicast DNS responder MUST NOT send announcements in the absence of information that its network connectivity may have changed in some relevant way.  In particular, a Multicast DNS responder MUST NOT send regular periodic announcements as a matter of course.
    • Whenever a Multicast DNS responder receives any Multicast DNS response (solicited or otherwise) containing a conflicting resource record, the conflict MUST be resolved as described in Section 9,    "Conflict Resolution".

    So a few points here. 

    1. By making all devices have the same "target.local" name, you are in violation of the specifications for mDNS.  You cannot hardcode the name. 
    2. A string substitution (which you are already doing for the service answer) will not increase the size of the firmware on the chip.  You already have a variable for the name, just reuse it in the A Record answer.  It's an absolutely trivial change. 
    3. By not properly supporting local name resolution you are preventing perhaps the biggest use case, which is to have multiple devices in the home with a cc3000 chip to connect them.  If they are all named target.local, you would never be able to host a webserver that is independently addressable with a distinct name. 
    4. By advertising this name, you are actually creating a name conflict without having implemented the required name conflict resolution handler.   

    A canned Multicast UDP packet, sent only on command, is NOT a valid mDNS (ZeroConf) implementation.  IMHO, you don't have to implement the entire RFC, but allowing the developer to set the name at least gives us a chance to avoid a name conflict. 

    If you need help understanding how to implement this, I am happy to help.  I have written a TCP/IP stack myself (mip.codeplex.com) with 3 tiers of local name resolution -- mDNS, LLMNR, and NetBIOS over TCP.  Embedded devices NEED proper name resolution. 

    Also, I recommend looking at the O'Reilly book "Zero Configuration Networking", see page 44. 

    Please try harder on this.  It's important for you and it's important for us. 

  • In reply to Valkyrie-MT:

    I agree with Valkyrie-MT on nearly everything he says - however I'm not going to be quite so insistent in how I look at this.

    I'm prepared to accept that the CC3000 only has so much room to implement functionality.

    My impression is that one could implement full mDNS functionality in the driver code (or user level code) rather than the CC3000 firmware.

    Doing so outside the firmware would force the user to make an explicit choice as to how important mDNS functionality is.

    For many users it may not be important enough that they are prepared to tie up some of the fairly scarce resources of the CC3000 in doing so, e.g. at the very least one of its limited number of sockets.

    However I do think that even if only a little bit of mDNS functionality is provided in firmware that functionality should at least make sense.

    I don't think the current choice to hardcode "target.local" in the A record while using the actual name of the device in the other records makes any sense.

    If you are going to include only a little bit of mDNS functionality in the firmware I think it would have made more sense to provide more basic functionality to help user's provide driver or user space support for full mDNS support, if they wanted it, rather than this unsatisfactory canned mDNS _device_info announcement (unsatisfactory for all the reasons outlined by Valkyrie-MT).

    If you're not going to enhance the mDNS functionality please at least fix the "target.local" issue which is just out and out odd.

    E.g. see this dig style dump of the DNS-SD announcement the CC3000 sends out. I've set the name of the CC3000 to "MyDeviceName" and this value appears in the PTR, TXT and in the name part of SRV records but bizarrely is not used in the A record or the rdata portion of the SRV record:

    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 0
    ;; flags: qr aa ; qd: 0 an: 5 au: 0 ad: 0

    ;; ANSWERS:
    _device-info._udp.local.              4500 IN    PTR MyDeviceName._device-info._udp.local.
    _services._dns-sd._udp.local.         4500 IN    PTR _device-info._udp.local.
    MyDeviceName._device-info._udp.local. 4500 IN/cf TXT "dev=CC3000" "vendor=Texas-Instruments"
    MyDeviceName._device-info._udp.local. 4500 IN/cf SRV 0 0 1234 target.local.
    target.local.                         4500 IN/cf A

  • In reply to George Hawkins:

    Hi guys,

    I understand your concerns, and I've asked our dev department to look into maybe changing the A record.



      ***  Please click the Verify Answer button on a post if it answers your question.   ***

  • In reply to made4engineering:

    Hi Aaron,

    I would like to second that request, and also add my own difficulties using the mDNS watch program to discover the CC3000. It doesn't appear in the "Device Info" group at all, and I've confirmed with a Wireshark trace similar to what Valkyrie-MT posted that my advertisements are being sent.



  • In reply to Vishal Talwar:

    Thanks Aaron --

    I think fixing up the A record is a good first step. I appreciate you taking it up with the dev department.

    I think this is an easy fix - and can probably be quickly incorporated.

    I think adding query support, relative to this, is a bit more complex but still very simple.

    So it would be great if the dev team considered adding proper query support.

    Perhaps as an optional part of the driver logic - something that could be compiled out to free up resources for end users that don't want to accept the added cost of properly support mDNS.

    Now Vishal's issue - I think what you're seeing is also down to lack of query support.

    On Mac OS X you can query services (including the pseudo service _device_info) like so:

    $ dns-sd -B _device-info._udp

    If the Mac was active when the CC3000 connected to the network it will cache the mDNS records that the CC3000 announces.

    These records are marked with a TTL of 4500 seconds.

    The above dns-sd command will try to actively query for devices that advertise the _device-info._udp but will also return cached records, so for 75 minutes after the CC3000 announces itself this data will be returned by dns-sd.

    But if your tool (mDNS watch) relies only on active queries, which is a completely reasonable thing to do, and doesn't cache records then the CC3000 will never show up as, as discussed here in previous messages, it does not respond to queries.

    If I use avahi-browse, the Linux equivalent of dns-sd, then it never returns the CC3000 _device-info._udp information - so like your tool I presume it is relying on active querying and doesn't use cached data.

    Note: even the Mac will sometimes throw out records before the TTL period expires - e.g. if you put it to sleep, it will empty it's cache on waking.

    Valkyrie-MT - you seem to be a mDNS/DNS-SD expert, I don't have the O'Reilly book you mention above, and information about _device-info on the web seems to be scarce. What exactly does the "._udp" portion mean?

    _device-info is a pseudo service, i.e. there isn't actually anything that can be accessed, via UDP or TCP, so maybe it's irrelevant whether one uses "._udp" or "._tcp"? However any examples of _device-info I've found on the web always use "_device-info._tcp". The CC3000 seems to be the only thing advertising this service as "_device-info._udp" - is this of any significance?

  • In reply to George Hawkins:


    Regarding your questions:


    1. You're correct. We will modify  "target.local" to reflect the name as provided in the API. This will be done on our next release (V1.11.2 – no target date yet).
    2. "query response"  will not be implemented in this device. The user can implement this at host level though.
    3. Despite the similarity, we will not implement LLMNR in this device - This can be implemented from host level though.
    4. The CC3000 device shouldn't drop mDNS packets due to loaded network. This packet is treated as any other packet in the system. If packets are dropped from time to time, then it's a bug, and we should debug this issue.
    5. Just to clarify, we don't support the Bonjour protocol, but only a very narrow subset to advertise device information.



  • In reply to Tomer Kariv53:


    Thanks for the response and the commitment to fix target.local.  Obviously, we are familiar with the constraints of embedded devices.  However, local name resolution is critical to having a functional consumer product, particularly, when the device does not have a user interface (something that becomes possible with SmartConfig).  

    In order to get local name resolution with a decent coverage of client devices, implementing both LLMNR and Bonjour (both are types of mDNS), would cover around 90% of client devices, but Bonjour alone, covers little more than Apple devices and the very newest Androids.  If I have to implement the listening for Bonjour and LLMNR, that would use 2 of the 4 sockets, and responding to LLMNR would require another without the built-in support.  Then listening on port 80 for a web server would require the 4th.  Then you are out of sockets with which to reply to web requests.  Also, service discovery is not really practical if you are not listening for the client probes.  

    I am open to alternatives (like 2 more sockets), but my vision is to use the cc3000 in consumer products where the user runs SmartConfig to join the network, then can go to any web browser on the local network and access the device's web page with a name, like http://lights.local or http://sprinklers.local.  Without local name resolution, you have to use an IP address (which could change periodically - DHCP), but how would a consumer ever even know what ip address was assigned?  Local name resolution is essential to the Internet of Things use-case.  It allows for a simple SmartConfig, then followed by just navigating to a name in your browser.

    I hope you'll consider the huge impact this will have on the product if you fully implement local name resolution on the cc3000.  

  • In reply to Tomer Kariv53:

    Hi Tomer,

    Thank you for the clear-cut responses. I, for one, do feel like I have been misled a bit by the marketing on this count:


    "The CC3000 module now also supports service discovery applications on phones, tablets and PCs using Bonjour® zero-configuration networking technology, making it easier for consumers to quickly identify and manage networked devices."

    Additionally, the wiki page for CC3000 mDNS functionality states that for iOS, the applications "Discovery" and "mDNS Watch" can be used. I couldn't find the former, and the latter probably doesn't work for the reasons George surmised about the improper query behavior (though the screenshots indicate it does/did work under some conditions).

    That said, I am happy with a limited version of mDNS now that I know the facts, but I think the technical documentation (if not the marketing stuff) should be much clearer about how to properly use this mechanism for discovery. I know nothing about mDNS and didn't plan on getting intimate with it, since I thought the CC3000 would basically handle that on the device side, and there would be plenty of libraries to be use on the application side. It seems like I'll have to start getting familiar withit or come up with my own discovery mechanism. At the very least, a sample application would be a wonderful resource if the dev team has a chance to come up with one.