Potential Workaround For mDNS Bug/Non-Implimentation

Here is a bit more details on what is required on the application side.

You need to broadcast to the same subnet. So if your device was on 192.168.1.10 you need to broadcast to 192.168.1.255

For those of you wanting to develop an IOS or Mac application, I have provided a few more details below.

First you need to get  CocoaAsyncSocket from Github - https://github.com/robbiehanson/CocoaAsyncSocket

You will find the UDPEchoClient example, this will show you how to send a UDP packet and receive a response. You will need to make sure you add this [udpSocket enableBroadcast:YES error:nil]; in the setupSocket method to make sure you can send broadcast UDP. This is added immediately after you create the udpSocket.

All else in the example will be the same except for adding some includes and changing udpSocket method to the following:-

#include <sys/socket.h>
#include <netdb.h>
#include <arpa/inet.h>

----

- (void)udpSocket:(GCDAsyncUdpSocket *)sock didReceiveData:(NSData *)data
                                               fromAddress:(NSData *)address
                                         withFilterContext:(id)filterContext
{
    NSString *msg = (NSString *)data;

	if (msg)
	{
        // Uncomment to see the entire structure of address, we extract the 2nd value below to get ip address
        //[self logMessage:FORMAT(@"RECV: DATA: %@", address)];

        //Get the bytes from the data and cast it to the correct struct
        struct sockaddr_in *addr = (struct sockaddr_in *)[address bytes];
        //inet_ntoa converts from the binary format to a C string
        NSString *ipAddress = [NSString stringWithCString:inet_ntoa(addr->sin_addr) encoding:NSASCIIStringEncoding];
        
		[self logMessage:FORMAT(@"RECV: STRING: %@", ipAddress)];
	}
	else
	{
		NSString *host = nil;
		uint16_t port = 0;
		[GCDAsyncUdpSocket getHost:&host port:&port fromAddress:address];
		
		[self logInfo:FORMAT(@"RECV: Unknown message from: %@:%hu", host, port)];
	}
}

Glenn.

Hi Glenn --

I completely understand the frustration you've expressed on the previous mDNS thread.

Personally I agree with Valkyrie-MT that TI should remove the current mDNS related nonsense from their firmware and remove all mDNS related claims from their publicity material. It would be nice if they then went on and either fully supported mDNS at the driver level or at least provided useful support functionality for it for those who wanted to provide an implementation at the user level.

It seems now that you are now trying to implement a simplified version of mDNS or to be more precise DNS-SD (as you're doing discovery rather than plain lookup).

First thing I would say is that a kitten dies every time you use broadcast rather than multicast :)

And second I'd say why invent your own protocol when DNS-SD already exists with a clearly defined behavior, multicast address etc?

DNS-SD is one of those things that looks horribly complicated if you look at the specs and documentation but is actually really simple if you actually look at what's happening on the network when someone queries for a service, e.g. on Linux look at the packet that goes out when you query for all services:

$ avahi-browse -at

If you're lucky you'll see something on your network that implements the _device-info._tcp service. This is the obvious thing you'd want  to implement for the CC3000.

If you do then you can do:

$ avahi-browse -rt _device-info._tcp

Which will print out something like:

+ eth0 IPv4 mymacbookair _device-info._tcp local
= eth0 IPv4 mymacbookair _device-info._tcp local
hostname = [mymacbookair.local]
address = [192.168.1.201]
port = [0]
txt = ["model=Mac"]

It's the txt bit that's interesting - in here you could indicate that the thing responding in your case is a CC3000.

So if you do this you can see the query packet sent out by avahi and the response packet from at least one other device on your network (if multiple things reply just look at one of the reply packets).

If you're using wireshark to monitor for packets it should be relatively easy to work out the encoding of both the query and response. So then you code up something for the CC3000 that looks out for that query and then produces a response - the only hard bit about the response is the DNS label compression used (this means if a piece of text, e.g. "mymacbookair" appears multiple times in a response a pointer scheme is used to avoid repeating the full text after the first occurrence) - but this compression is optional - don't bother implementing it.

I'd suggest looking at the implementation that Valkyrie-MT did in C# that's available at http://cc3000.codeplex.com/ - it will probably give you some serious help in how to do things (ignore all the NetBIOS stuff).

But to be honest Glenn - I think once you've resolved this issue you'll find another. I hope your end product is aimed at hobbyists who'll put up with a lot and not at the general consumer market as I really don't think the CC3000 is ready for this market (and in fact I'm skeptical it ever will be). I think it's super for hardware hobbyists, e.g. users of the Spark Core, but not for the consumer market :(

/George

Hi George,

I really appreciate your input, you are right about the right way to do this. I am just flat out doing a bunch of things, trying to get this product ready for mass production. So coding a solution to spec, isn't high up on my agenda.

In my case, the mobile apps are closely linked to the device, so there isn't a great need to have this work with all the utilities out there. I just need my apps to find the device, so they can send UDP packets to it. If I have time before production, I will look into implementing DNS-SD proper....and perhaps a miracle will happen by then and TI decides to provide a solution. At least now, I can get this product out to interested parties and perhaps do some limited beta testing. 

My product is aimed at the consumer market, everything needs to work seamlessly! If you are interested, you can see a demo of some of the music synchronisation features here - http://vimeo.com/user20707777/review/81621493/d283c189e8 or if that doesn't work, try youtube here - http://www.youtube.com/watch?v=z3TzdUjfSEM (It does a bunch of other stuff, all depending on the app).

Even though I am killing kittens on mass with my broadcast solution (hey, I am dog person anyway). Do you see anything particularly wrong with my solution? Other than I have created my own protocol, when others exist.

Glenn.

p.s. I do worry about the CC3000, in that it looks like TI have lost interest in it, and are not focusing any resources on it. I have never come across such an effort to deny obvious flaws in a product in my 20+ year career and I worked at Microsoft as a support engineer during the Windows 95 and XP days! 

Hi Glenn,

I'm sorry I didn't chime in earlier on the mDNS thread, but I've also had to resort to a homebrew discovery solution similar to yours. The client broadcasts a particular discovery command over a certain UDP port and the CC3000 (which is anyway listening for commands) picks it up and returns a status packet containing the firmware version and MAC address.

I haven't quite thought through what would happen if some random other devices are listening on that port and decide to respond with data the client does not expect.

Hopefully our unorthodox techniques don't get us into trouble!

-Vishal

Hi Vishal,

Great minds think alike!

I have thought about that very issue, and the way I will deal with it, is by having data in the response which I can use to verify that this response is from my device.

So in my solution, I obtain the IP address from the source of the packet, I then extract the data contained in the UDP packet which I can use for various purposes, including verification (and in your case firmware version and MAC address)

I am thinking our solution has its benefits. As I can use this method to query multiple devices for information, they can all return the information, which you can parse and present. So for example, you could quickly obtain information on which of the devices needs a firmware upgrade.

And yes, an apology is due for not chiming in earlier! But at least it is good to know someone else is doing what I am doing to solve the lack of discovery support in the CC3000, so all is forgiven.

Glenn.

Hi Glenn,

That makes a lot of sense. I guess I would have to add some identifying token to the response, since the fields in my current response are totally numeric and 8 bytes from anyone could be interpreted that way.

Definitely agree with those benefits! I love running the discovery command and having the immediate satisfaction of seeing CC3000 devices that are alive on the network. You can't help but wonder why mDNS fails so hard, or why a simple driver feature couldn't address anything that was too much overhead for the CC3000 itself.

Yup, sorry again. Still working off the holiday lethargy.

Vishal

Hi Vishal,

I had some technical questions about your implementation.

1) Which broadcast IP addresses are you using? I have used 0.0.0.0 on the CC3000 and x.x.x.255 to broadcast the packet.

2) I have noticed that the  sendto method does not always function. In fact it has about a 30% drop rate. I am wondering if you have also experienced this issue? I get around it by responding with multiple packets (see code above).

Glenn.

Hi Glenn --

You and Vishal have discussed pretty much everything I would have addressed in a response.

While I'm not super keen on an ad hoc solution I think that the way you are doing things sounds fine.

I would point out that DNS-SD does exactly support what you are trying to do.

I.e. send out a query and have multiple devices respond with information including things like their current firmware version.

For an ad hoc solution on an address and port that may potentially also be being used by unrelated applications I'd probably include a predefined UUID as the first 16 bytes in any request or response and then ignore any packets that did not start with it.

I think TI started releasing sample CC3000 modules in late 2011 and it seems to be only in the last 6 months or so that people have really started taking up on it. So maybe TI kind of wrote it off too early and hence the relatively undersupported feel one gets these days.

Things like the mDNS issue don't worry me too much - as one can solve them in one's own code - it's things like the sendto issue you report that really worry me. I've seen lots of odd little one off or occassional issues with the CC3000 and it's these that really damage my confidence in the product for the consumer market.

When I look at the issues covered in each new firmware update I don't get the impression that this is a product that has settled in, the bugs being fixed still often look really serious rather than being obscure like fixes or nice little new features.

On a more fundamental side I'm not so about the whole Smart Config idea. It looks cool when it works. When it doesn't work though there's little possibility to diagnose the issue in a consumer setup due to the one way communication between the configuring application and the device.

In the long term I think BLE may win out for this kind of thing. It probably sounds like overkill to add BLE for the one off task of configuring a device with an SSID and network password. However BLE is fairly cheap and will get cheaper and I think the ability of the device to actively communicate information back to the configuring app is a massive win, e.g. being able to say things like "I can't see any networks" or "I can see these X networks - but not the one were interested in".

One can cobble something like this together yourself already. And Intel have announced a tiny form factor device called Edison with both wifi and BLE - I'll be interested to see how they price it.

But that's for the future - at the moment many devices don't have BLE, and Android has only fairly recently included support for it.

Back to the here and now - I looked at your Vimeo video. Looks cool! I wish you the best of luck with it - hope it works out really well for you :)

/George

Hi George,

I do hope this is a case a delayed start, and once the sales numbers come in for the last quarter, TI begins to put an effort back into the CC3000.

I agree with you about BLE, I actually looked at this at the beginning of my research, but it is as you say a while to go before it has the penetration to rely on it completely. My product is mainly targeted at the IOS ecosystem, so perhaps I could have got away with it from a technical perspective (though there is a large percentage of earlier IOS devices in use). But in the end, it is hard enough getting retailers to carry a new consumer product, and not providing at least some level of Android support just makes this job harder.

Actually I just had a thought, I know why the CC3000 hasn't been receiving the effort it deserves. It's because a new version is on its way with smartconfig and BLE, and we will hear the announcement soon ;-) (TI's WiLink 8 already has this, but you need the host OS (Linux or Android) to do the grunt work).

Thanks for the pointer to the Edison, I'll be checking this out.

And yes, I am a little nervous about all this, I've invested a lot in my product.....it was smartconfig that sold me, as it solved the biggest issue that faces headless devices for the consumer market. Most devices like mine are completely inaccessible to your regular consumer due to the difficulty in configuring them for wifi. 

I can say I have tested smartconfig on a number of routers and hotspots now, including all the major brands and they have all worked with smart config. One was having issues, but when I looked at the router, it had something like 50 machines in it memory, and this was a basic consumer router, once I cleaned out this list, everything worked fine. So I am not too concerned about whether smartconfig will work.....but you never really know till you have it in the consumers hands!

Glenn.

Hi Glenn,

1.  I'm using 0.0.0.0 on the CC3000 as well, but when broadcasting the Python library I'm using allows me to use a special address called "<broadcast>". I'm not sure what this resolves to.

2. I haven't noticed any packet loss issues so far, but the host driver is prone to getting stuck and blocking indefinitely waiting for the CC3000 to interrupt during recvfrom's. Generally the devices respond perfectly when they are alive and don't when they're hanging (which thankfully is rare), but I haven't noticed any reliability issues in between. Could your drop rate be due to antenna/RF performance or are you using the dev boards?

I'm not even doing the select() before recvfrom() (I used the nonblocking socket flag) and so far things seem to be ok. For what it's worth, I've had the most issues with TCP sockets causing blocking and lockups to the point where I had to switch over to a UDP socket.

-Vishal

Hi Vishal,

1) I have just remembered that the broadcast address is calculated using a bitwise OR on the IP with the inverted netmask. So here are a few examples:-

IP: 192.168.1.10  Subnet: 255.255.0.0 -> Broadcast: 192.168.255.255

IP: 192.168.0.10  Subnet 255.255.255.128 -> Broadcast: 192.168.0.127

Here is a calculator - http://www.subnet-calculator.com/

It is great you have a function for this in Python, I need to find one for IOS and Java, otherwise this will be a pain to code.

EDIT: I did need to code this my self for IOS, details and code found here - http://stackoverflow.com/questions/21077133/calculating-the-broadcast-address-in-objective-c

2) You might want to run a network sniffer to check the packet loss issue if not already done so. Though I guess if you are always getting a response back this will let you know if there are any dropped packed. I am currently using dev boards. I will check to see if placing router next to all equipment improves the situation. 

Regarding the recvfrom, I haven't noticed this issue, but I have noticed a hang every now and then, it last for about a second. I can tell this, as the RGB LEDs that my device controls through music synchronisation, stay on the same color even though music is playing. It does recover and continue, and this is a rare occurrence that could be caused by network traffic or the router, also it could be due to other features used in my code like the sending out of the DMX packet to the lights. I do use a select() before the recvfrom(). Not sure why you would not, I am receiving 30 packets a second on the CC3000 using this method without a problem. How hard are you stressing recvfrom()? 

Could this issue be a device disconnect from the AP? Do you just reboot your device to resolve the problem? I have noticed that the CC3000 device does disconnect from the AP sometimes, I can tell this is the issue as the router does not show it is connected. Perhaps the problem is due to me not having reconnect code in my solution yet, but still it seems strange that it would disconnect in the first place. 

Glenn.

Hi Glenn,

1. I tried skimming the Python source code looking for what address <broadcast> computes to or is bound to, and as far as I can tell, it's 255.255.255.255. Maybe this is too promiscuous? :P Here's the code if it helps:

hg.python.org/cpython/file/90cd87f64632/Modules/socketmodule.c

2. I did monitor the network traffic back when I was still trying to use TCP for streaming data, which turned out to be a huge mistake. I ended up not using select() because at least back with that version of the CC3000 firmware, there was some random latency it introduced with a maximum value of something I couldn't tolerate. I also remember the docs saying that 5ms was the value but that didn't really look right. Someone on the forums suggested just setting the socket to be nonblocking and that turned out to be the fastest way to get data or fail fast trying.

Since wifi isn't an essential component for our product to function, I haven't stress tested it for a while, and certainly not since the last firmware update. When I get back to this I'll let you know if I'm running into any more random hangups. I had chalked it up to the nefarious missed interrupt problem, but who knows. It could be a disconnect, too.

Thanks,

Vishal

Hi Vishal,

Most hardware and software drops 255.255.255.255, so you would want to make sure it is not using that as your broadcast address, I haven't had a look at the code, but I'd suspect that it isn't using that for broadcasting.

When I tried using 255.255.255.255 initially, I would not get a response from my device. Not sure if it was the router which filtered it out or if the CC3000 did not respond to it.

Glenn.

Hi Glenn,

I'm verrry curious about this:

Actually I just had a thought, I know why the CC3000 hasn't been receiving the effort it deserves. It's because a new version is on its way with smartconfig and BLE, and we will hear the announcement soon ;-)

Where did you hear about this?

-Vishal

I am just being sarcastic. 

I have not heard anything regarding this. Perhaps this is more wishful thinking than sarcasm.

Glenn.

Hi Glenn et all,

just want you to point to this posting "by Tomer Kariv on Nov 03 2013 01:55 AM":

http://e2e.ti.com/support/low_power_rf/f/851/t/292709.aspx?pi267162=3

(in the middle of page 3, just before my long posting)

"I appreciate your detailed answer, and we are already working on part of the things you mentioned for our next generation solutions. This includes better documentation, much more examples, ease of porting, etc.."

and

"As stated at the beginning, we are working already to improve our next generation solution, and will do our best to accommodate your comments."

but never got an answer, by requesting more details in next message...

(just a new software release? a new chip/module?)

How about this posting:

http://e2e.ti.com/support/low_power_rf/f/851/p/285351/995753.aspx#995753

or this

http://e2e.ti.com/support/low_power_rf/f/307/p/295681/1031582.aspx#1031582

or this

http://e2e.ti.com/support/low_power_rf/f/851/p/281567/982043.aspx#982043

But never saw a release date so far or if it is coming at all or if it was just an internal test and will never be released...

Best regards,

Martin

Ah, I thought that might be tongue-in-cheek but I knew there had to be a reason "CC3100" was one of Google's autocomplete results :P Thanks for those links, Martin. It's too bad for us the investment in documentation and support seem to be directed to the "next-gen" solution.

Hi Martin,

Thanks for that, very enlightening! So TI is busy working on the CC3100. Which may address some of the feature requirements we have been requesting.

My device would benefit greatly with an Ad-Hoc AP capability. And perhaps my wishful thinking may be based in some fact, disregarding my BLE comments.

I do hope this is real and not a case of vaporware, I think some official response may be in order. As to mention this new device so many time in the support forums and then not inform if things have changed, certainly makes it vaporware.

Back to the CC3000, we have also been promised a firmware update in a few weeks, this was over a month ago - http://e2e.ti.com/support/low_power_rf/f/851/p/290584/1067580.aspx#1067580 

Would be good to get an update to this, and also some indication as to what issues are being resolved. Is there amy online bug tracking system like the one available for TI-RTOS and the Tiva C?

Glenn

Hi Vishal,

I 'm having issues with my broadcast packet solution to the the broken mDNS. The issue is discussed in this thread - http://e2e.ti.com/support/low_power_rf/f/851/t/312391.aspx

I would like to compare notes on how you implemented your solution. Perhaps I've done things differently and if not, then your code is likely exposed to the same issue discussed in the thread. It can take a while to manifest.

Anyway, get back to me so we can make sure our solution doesn't have problems. 

I am new to the cc3000.  I am evaluating it for one of my projects.  Like some of the other posters, non-working mDNS is a show stopper for me, so I am particularly interested in your post.  

I was reading in the specification that the cc3000 supports multicast.  If this is so, could a "hand rolled" mDNS solution send to the standard mDNS multicast IP address (224.0.0.251) rather than the broadcast address, also how does your implementation work of it does not listen on the mDNS port (5353)?

Also a quick query on the posted code.  It seems to only have 75 lines.  Is that the end, or do you have to download the source, I could not find a download button, and there seems to be be no way of adding an attachment on this forum.

Is there anything preventing me from writing standard-compliant mDNS code that listens on port 5353 and sends to IP 224.0.0.251?

I have a hand rolled mDNS code that I currently use on the PC, its about 1000 lines of C code.  I could post it if anyone is interested.

Thanks for you efforts to solve this issue.

Hi John,

Yes you could develop your own mDNS code, I opted for a simple broadcast solution as it only required the code you see above. I listen on port 0.0.0.0 for broadcast packets on a particular port, if one comes in, I parse the data to make sure it is from my app and if it is, I then send out a reponse packet. The udp server on my app then picks up this packet, and uses the source ip address to let my app know what my devices ip address is.

So nothing is stopping you from developing a proper mDNS solution, and I am sure if you were willing to open source the code many would be very appreciative and possibly give you a hand.

Hi John --

There is nothing preventing you from writing standard-compliant mDNS code that listens on port 5353 and sends to IP 224.0.0.251. You obviously tie up one of your limited number of sockets and you have to manage supporting handling mDNS queries etc. while also handling the "real" logic of your application.

I think coding up your own working mDNS solution (and making it available to the world so that everyone doesn't have to keep on reinventing the wheel) is certainly a reasonable way to go.

You can definitely do it in substantially less than a 1000 lines of C if you limit the supported functionality. E.g. just support mDNS A record lookup and reverse lookup - and do this using a largely canned response (with just the logic necessary to vary the hostname). And then build some DNS-SD support on top of that - again with little more than the logic necessary to announce and query the _device-info._tcp pseudo service.

Valkyrie-MT has already done something like this (in fact more sophisticated than what I describe) in C# for the Netduino - http://cc3000.codeplex.com/

Using an approach where most of your response message is canned (rather than constructed from scratch by logic that really understands and builds arbitrary mDNS messages) and skipping the complexity of DNS compression (which is completely optional and not a required part of a supporting DNS/mDNS) means you can do this in a very small amount of code, i.e. suitable for a memory limited MCU.

Take a look at the Adafruit A record querying support here for some possible pointers:

https://github.com/adafruit/CC3000_MDNS

I think one can do a lot better than this - personally I don't like that it uses malloc, which I think is completely unnecessary - and one could add proper DNS-SD, i.e. service discovery with only a little extra effort, i.e. the ability to browse for CC3000 devices (and retrieve basic information about them, e.g. current firmware version).

Good luck - it really is a shame that TI don't just throw out their half-baked mDNS logic and just do things properly even if they do this at the driver level rather than in the firmware.

/George

Hi Glenn,

It sounds like we are doing exactly the same thing. I also listen on 0.0.0.0:50007 for commands sent by controlling device. When a certain "discover" command is received, the firmware replies to the sender with a payload full of identification data. On occasion, a command or response seems to slip by but I've just chalked it up to UDP being UDP. A bigger problem is what you've highlighted in the other thread - we still occasionally get hangups in hci_event_handler() that I haven't been able to track back to any source yet.

This mostly happens when we have a second, TCP socket open and active, in which case it's usually the connect() or recv() that hangs, but occasionally it does hang in recvfrom() as well. Definitely smells of a race condition somewhere.

My assumption is that I won't be able to iron out hangs entirely, so I added a timeout inside hci_event_handler() that will force the module to reset if it's been busy-waiting for more than a second. An ugly fix, but still better than forcing your problems on the end user.

Let me know if you need more details, and thanks for reaching out.

Vishal