Once you press "Start" in a TI Smart Config setup application the application will repeatedly broadcast the SSID etc. until the relevant CC3000 device has successfully connected to the network.
How does application detect that the CC3000 has successfully connected?
mDNS and DNS-SD
First some information about the technologies involved.DNS is the service that allows us to use names like www.google.com rather than addresses like 173.194.40.48.
For normal DNS someone has to explicitly configure the mapping from a name to an address in advance.
A variation on DNS called multicast DNS (mDNS - see also RFC 6762) allows a device that has connected to a network using e.g. DHCP to advertise a name for itself, i.e. provide its own mapping for the address it has been given, without the need for someone to have preconfigured this.
This is commonly seen on home networks, e.g. your printer, NAS or media server may well have assigned themselves easy to use names.
Usually they add themselves to the domain "local".
E.g. if you have something like a WD TV Live media player you can access its web interface without needing to know its IP address using the URL:
http://wdtvlive.local/
The mapping from wdtvlive.local to an IP address was created using mDNS.
To a large degree mDNS works just like normal DNS and you can use standard tools like nslookup and dig to retrieve mDNS records just like you can for normal DNS records.
E.g. to retrieve the A records for www.google.com one would do:
$ dig www.google.com
To retrieve the A record for a device like the WD TV Live media player mentioned above one just needs to specify the relevant name server and port as part of the command:
$ dig @224.0.0.251 -p5353 wdtvlive.local
As far as dig is concerned 224.0.0.251:5353 is a normal name server. However 224.0.0.251 is in fact a multicast group address and all the devices, like the WD TV Live media player, that are interested in providing name mappings for themselves listen to this group and respond to requests that relate to them.
E.g. if 192.168.1.126 is the address for wdtvlive.local and I do a reverse IP lookup like so:
$ dig @224.0.0.251 -p5353 -x 192.168.1.126
Then the device with the address 192.168.1.126 will see the request sent to the multicast group and reply giving its name.
DNS (and mDNS) involve far more record types than just the A records that map names to addresses.
The various other record types make it possible to build additional services on top of DNS.
DNS Service Discover (DNS-SD - see also RFC 6763) does just that - and provides a mechanism to discover services via DNS.
Service providers can advertise that they provide a given service, e.g. a file server can advertise that it provides SMB services (SMB is the standard Windows file sharing protocol). And clients can discover all the devices that provide a given service that they are interested in, e.g. your laptop can discover all devices that provide file sharing related services.
mDNS, DNS-SD and the CC3000
When a CC3000 enabled device successfully joins a network it typically advertises this fact using DNS-SD.Note: this is not handled automatically by the CC3000 firmware, the firmware provides support for publishing the mDNS message but this must be triggered explicitly either by the driver code running on the device controlling the CC3000 or invoked from user level code outside the driver.
The Smart Config setup application looks out for the relevant DNS-SD messages and stops broadcasting once it sees one that contains the name of the device, e.g. "CC3000" that it is interested in.
Before we go further I should mention the library of Java tools that I've developed that can be used when working with CC3000 enabled devices. It can be cloned from GitHub like so:
$ git clone https://github.com/george-hawkins/betaengine
If you don't have git you can download the repository as a zip file here:
https://github.com/george-hawkins/betaengine
For build instructions see the included README.md file.
One of the tools allows you to monitor all mDNS traffic. Run it like so:
$ java -classpath 'bin:lib/*' net.betaengine.mdns.MDNSListener
If you leave it running for for a few minutes and you have more than one or two devices on your local network then you may be surprised at how much traffic you see as devices query each other and advertise their services.
If you leave this tool running and the use one of the Smart Config setup applications to get a CC3000 enabled device connected to your network then you should see the mDNS listener tool output a message like this when the CC3000 enabled device successfully connects to the network:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 0 ;; flags: qr aa ; qd: 0 an: 5 au: 0 ad: 0 ;; QUESTIONS: ;; 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 192.168.1.120By default CC3000 enabled devices use the name "CC3000" for themselves, I've explicitly changed it here to "MyDeviceName" so that you can see where the name appears in the resulting mDNS records.
Note: "/cf" above indicates that the cache flush bit is set - see RFC 6762 section 10.2.
Unfortunately at the moment the CC3000 DNS-SD/mDNS support is highly unsatisfactory.
It should use its name, e.g. "MyDeviceName" in the above example, in the A record but instead uses the hardcoded name "target.local".
At the moment one can do:
$ ping target.local
Rather than being able, as one would expect, to do:
$ ping MyDeviceName.local
According to TI this will be fixed in their next release - V1.11.2.
The CC3000 does not support mDNS querying - this is fundamental and means the CC3000 cannot make any real claim to support DNS-SD/mDNS.
The CC3000 will publish an mDNS message like the above if explicitly told to do so, but it will not respond to queries for DNS-SD/mDNS related information. So the standard dig examples shown above cannot be used to map the name of a CC3000 enabled device to an address or do a reverse lookup on the address of such a device as the CC3000 will simply ignore the queries generated by dig.
This means nothing can actively discover a CC3000 enabled device.
Generally a client, e.g. your laptop, does not need to have been on when a device such as a file server joined the network. However only clients that were on when the CC3000 joined the network and announced its presence will be in a position to cache the relevant messages. The records shown above are all marked with a time-to-live (TTL) of 4500 seconds, i.e. 75 minutes, so even clients that cache those records will expire them once this amount of time has elapsed.
These issues with the CC3000 DNS-SD/mDNS support are discussed in detail on the TI CC3000 related forum here:
http://e2e.ti.com/support/low_power_rf/f/851/t/290584.aspx
The mDNS message up above advertises the fact that the CC3000 enabled device supports the DNS-SD _device-info service. This is a pseudo service, i.e. one cannot connect to the device and receive any real _device-info related service, it's sole purpose is to provide details about the device. In this case the details are:
"dev=CC3000" "vendor=Texas-Instruments"
However despite being a pseudo service TI seem to be providing records for it as if it were a real service. This issue and whether it should be using the service name "_device-info._tcp" rather than "_device-info._udp" are discussed on the Apple Bonjour developer mailing list here:
http://lists.apple.com/archives/bonjour-dev/2013/Oct/msg00000.html
TI does provide some (not terribly useful) information on the CC3000 and DNS-SD/mDNS here:
http://processors.wiki.ti.com/index.php/CC3000_mDNS
Note: that while a subset of the records shown in the mDNS message above are advertising the DNS-SD service _device-info TI rarely seem to distinguish between mDNS and DNS-SD and mainly just seem to use the term mDNS as if it covered everything.
To find the logic relating to the DNS-SD/mDNS announcement in the driver code for your device just search for the HCI opcode HCI_CMND_MDNS_ADVERTISE. It's worth looking at this and following through the sequence of calls involved in order to see just how basic the mDNS support really is.
An oddity of how TI constructs the mDNS message is that under Mac OS X you can browse for the cached "_device-info._udp" records using dns-sd like so:
$ dns-sd -L CC3000 _device-info._udp Lookup CC3000._device-info._udp.local DATE: ---Mon 16 Sep 2013--- 15:14:22.579 ...STARTING... 15:14:22.580 CC3000._device-info._udp.local. can be reached at target.local.:1234 (interface 4) dev=CC3000 vendor=Texas-Instruments"This shouldn't work as _device-info isn't a real service and should not have an associated SRV record, this is discussed in the Apple Bonjour developer mailing list message mentioned above and in more detail here:
http://lists.apple.com/archives/bonjour-dev/2011/Jul/msg00016.html
DNS-SD/mDNS support in a Smart Config setup application
mDNS is on the whole very simple and there's no requirement for special libraries etc. in order to send or receive mDNS messages.A Smart Config setup application needs to create a multicast socket which it binds to port 5353, and then needs to join the multicast group 224.0.0.251.
When the CC3000 enabled device successfully connects to the network it sends a UDP datagram packet to this group address and port, i.e. to 224.0.0.251:5353. This packet contains a message like the one shown above, i.e. one that consists of a number of mDNS answer records, the first of which contains the device's name in its RDATA section.
The TI Smart Config application for Java ignores everything except for the device name, however it's important that the message be a fully valid mDNS message so as not to confuse other parties listening to the mDNS multicast group.
Note: the TI Smart Config application for Java does not specify a codepage when reconstructing the device name so it may experience issues when run on platforms with an unusual default charset. It also depends on the current order of the answer records in the mDNS message (it ignores all but the first record) even though the ordering of the records shouldn't be important.
Look at the source for my mDNS listener and responder tools to see how to listen for mDNS messages and how to construct a message in an almost identical fashion to the CC3000.
Emulating the CC3000 DNS-SD announcement
In the set of tools mentioned above I've provided a tool that emulates the announcement issued by a CC3000 enabled device on joining a network. You can run it like so:$ java -classpath bin net.betaengine.smartconfig.device.Responder <device-name>If you don't provide a device-name it will default to "CC3000".
If you run a Smart Config setup application and then run my responder tool, using the same device name with both of them, you will see that the Smart Config setup application will immediately stop broadcasting the SSID etc. once the responder tool is run.
If you look at the source for the class net.betaengine.smartconfig.device.Responder you will see a detailed breakdown of the mDNS message that is sent.
Setup failure
A CC3000 enabled device can obviously only announce its presence on a network if everything goes well - if any of the details, e.g. password, are incorrect then it will be unable to connect and the Smart Config application will simply timeout waiting for the relevant mDNS message. When this happens the application will have no way of knowing what the underlying issue was (maybe the device wasn't even plugged in).Failure of CC3000 to send mDNS message
Currently I only have one CC3000 and my particular example regularly fails to send the mDNS message that the Smart Config setup application depends on seeing in order to know when to stop sending the SSID etc. So even though the device consistently connects to my network successfully this is often not picked up by my Smart Config setup application.
If I run my listener tool covered above I can see that indeed no mDNS message shows up from the CC3000 in these problem cases.
And if I run my responder tool I can see that the messages it generates never go missing and that the Smart Config setup application is always fooled into stopping.
This strongly suggests to me that this is an issue with the CC3000 and not with the network or the Smart Config setup application.
0 comments:
New comments are not allowed.