• State
  • Locked Locked
  • Replies 10 replies
  • Subscribers 42 subscribers
  • Views 1272 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC3000 MDNS Advertisement quits broadcasting

chad ely
Intellectual 480 points

HI,

I have been working with the CC3000 and like many others I have been bothered by the inconsistencies in the mdns to simply advertise as it should.  I understand all the other issues folks are having and would like to keep them out of this discussion since there are numerous threads on the other issues recently.  

I would like to try to troubleshoot the simple fact that calling mdns advertise does not continue to work even though the CC3000 returns a satisfactory response each time even if the advertisement was not actually broadcast.  

Some things I have noticed and info:

1. When sniffing with Wireshark I notice the source port is incrementing by one every time and starts at different values and gets hung up on different values.  When looking at all other packets from other vendors with mdns the source port is always the same as the destination port - 5353.  TI - why is this not hard coded to 5353.  This could easily be the problem if every time mdns broadcasts it opens a new port to do so.

2. The point where the CC3000 quits sending mdns packets varies but for me seems to be around 7-8 minutes when calling mdns every 6 secs.  Sometimes it will start sending again and sometimes it does not.

3. I am not using "CC3000" as my mdns name and I hope TI is not in there testing as I feel most are not using the default string.  My name is one word no spaces 15 characters including numbers.

4. I have had this issue for the last few updates so it was not just introduced in  1.11.1 which I am running along with 1.11.0.

5. Maybe by coincidence or maybe not, sometimes when other devices on my network do their mdns routines the CC3000 will quit broadcasting.

6. When the CC3000 stops broadcasting I tried to stop and restart the mdns, so to speak, by calling mdns advertise with it disabled and I get the same response back but the next call to mdns returns with a different code, it goes from 0xc6 to 0xd9.  I am not able to get mdns to broadcast again until I reboot the CC3000 and it appears that I may have to restart the CC3000  after my 5 minute mdns timeout to be able to broadcast again in the future, which would obviously suck.

Any information anyone else has that they can contribute to this would be greatly appreciated.  And for those who keep thinking they are doing something wrong and the issue is not in the CC3000, think of it like this, if you can call mdns advertise once and it works it should work everytime there after also correct?  If nothing on my device changes from call to call to the function then I should get the same result which is a packet not returning zero and a packet sent to my router which I can see sniffing my network.  

Nothing the router does should impact other wifi devices seeing this packet either, but maybe there is something there I am missing.

Also if anyone other than TI can get their CC3000 to consistently broadcast I would like to here from you also, even if to say it does work all the time for you.  At present TI cannot reproduce this issue even though it seems to affect a large number of people, so any info would help.

Thanks to all who try to help,

Chad

  • 0
    Genius 4895 points

    Hi Chad,

    I am not from TI and even my mDNS usage/knowledge is limited. But would it be possible for you to create traces? I think the most useful traces for TI would be debug pin traces of both debug pins of CC3000. You can do these with USB <-> serial converters which use a voltage level of 1.8V. Sometimes logic analyzers do understand the voltage level and can record the debug pins and afterwards exports the capture of each pin to a separate file.

    Even SPI traces, wireshark traces, source code of your calls could help.

    > "At present TI cannot reproduce this issue"

    Unfortunately I read this too often in a lot of discussion here in CC3000 forum instead of seeing real progress (even small steps) reported from TI. If the errors cannot be reproduced at TI, then there must be a different way to catch the errors like more detailed debug output, which can be enabled in case of error on developer/customer side. Or a new debug call to dump important content of RAM, to see in what state the CC3000 is, what the CC3000 has received/sent the last time, state of important state machines, ...

    Best regards,

    Martin

  • 0 in reply to Marie Maurer
    TI__Mastermind 27095 points

    Hi Chad,

    We do understand that few have seen this issue. And we have been working to get this recreated at our end for some time now, to provide a proper resolution for this issue. But it seems to be an issue with difference in test environment. While we are trying to get more out of it, it would be appreciated if you can provide us logs from the debug pins along with the air traces, to add to Martin's inputs above.

    Our test setup is something like below:

    1. With SP1.24 and Host driver 1.11, we keep broadcasting mDNS packets for a considerable amount of time.

    2. mDNS packets are advertised once in 10-15 seconds. i.e, a call to mdnsAdvertiser API is made once in 10-15 seconds.

    3. Remote device, which is a smart phone, runs a Bonjour browser application. mDNS packets are received on the phone. And also the air traces show the mDNS packets.

    Thanks & Regards,

    Raghavendra

  • 0 in reply to Raghavendra Shenoy
    Intellectual 480 points

    Hi,

    I do not have access to my debug pins but can modify the pcb to achieve this, but I do not have a 1.8v converter.  I do have a 3.3v but I am sure this will destroy the CC3000, so I will see about getting the hardware required.  Will you please provide the part # for the one TI uses for in house testing so I can be absolutely sure it will work.  

    You say: "once in 10-15 seconds", I assume you mean once every 10-15secs?  Why the variation?  I have never seen a variable timer in programming before.  I set mine off every six seconds using a timer.

    I can provide Wireshark traces showing my results but I would also like to see TI provide us with the same.  It seems that there are some people who are not at all convinced TI is actually looking at this and this would go a long way to show exactly how you are implementing and as proof that it does work on your end.

    I have some more questions on your setup:

    1. What name are you broadcasting? CC3000? Try something else and lets see what the results are.

    2. Do you ever use mdns disable? What is the meaning of it and should a name be provided?  I get errors either way, see previous post.

    3. Can you try to reproduce my circumstances and set a timer for 5 secs and run for at least and hour using at least a 10 - 20 character name using letters and numbers and see what you get?  I will also extend my timing out to 15 sec and see if that matters in my setup at all.

    4. I need an answer on why the source port is incrementing -- THIS IS MAJOR! (see example below)

    Here is my capture of 3 packets that demonstrate the source number changing according to Wireshark at least:

    I have done some more testing today and will continue to collect data and I will update this again by the end of the day, but it appears it may be associated to how often you call mdns advertise.  I have changed my timing from every 6 secs to every 16 secs and it now seems to be working all the time, although I only have about 1/2 hour of testing in so far.  I am going to try some different times and see if there seems to be a cutoff on how quickly we can call the function and actually get it to broadcast.

    I will include my traces later.

    Thanks,

    Chad

  • 0 in reply to chad ely
    Genius 4895 points

    Hi Chad,

    I am not from TI, but I can help on the debug pin topic:

    On

    http://processors.wiki.ti.com/index.php/CC3000_Radio_Tool

    the following USB <-> seriell converter with voltage 1.8V is suggested: TTL-232RG-VREG1V8-WE (it is from FTDI, around 20 Euro). See bottom of this page for color and signals, but be careful, left and right side have different order!

    The both debug pins are both outputs (from CC3000 point of view). So if you want to trace both at the same time, you need 2 such cable. Some more details can be found here:

    http://processors.wiki.ti.com/index.php/CC3000_Logger

    and notes on bottom of this page.

    Best regards,

    Martin

  • 0 in reply to Marie Maurer
    TI__Mastermind 27095 points

    Hi Chad,

    Thanks for the details. The interval 10-15 mins. is not the specific timer value. It is just to say that certain tests were conducted with a 10 second interval and some tests were tried with a 15 second interval.

    I have attached the air capture of testing done at our end, which was run for about an hour. Rename the file to .pcapng. 5504.mDNS1.log

     Regarding the name, yes it was tested with a longer name. The log that I have attached has the name "home_assistant" in it.

    Regarding test with smaller time, I remember testing with no interval and flooding the network. Not much success here.

    The port number increase should be fine I think. As it follows UDP and source port should not be of much significance. It is just a port on which a reply is expected in required cases.

    When you face this issue, what symptoms do you see? Are you able to create socket and work with it?

    Thanks & Regards,

    Raghavendra

  • 0 in reply to Raghavendra Shenoy
    Intellectual 670 points

    Raghavendra,

    Could you share with us more details about your test setup? In particular:

    - what is the smart phone (brand, model and fw ver). If you use multiple types, please provide the list.

    -the same info for the Wi-Fi host (AP, router, etc.).

    BTW, one can google many posts about broken multicast reception in certain Android devices. i.g. 

    http://codeisland.org/2012/udp-multicast-on-android/

    And there are some routers with known multicast problems.

    So if it works on your test bench do not necessarily means it will work ewerywhere. Even with the assumption the multicast implementation in CC3000 is perfect.

    ---

    regards,

        Igor

  • 0 in reply to Igor Uspensky
    Intellectual 670 points

    Raghavendra,

    In addition,

    Because of that reason, I think it'll be a good idea TI to provide simple test application (something like http://cafbit.com/entry/testing_multicast_support_on_android ) so the user can easy verify compatibility of his/her Android device with CC3000.

    ---

    regards,

        Igor

  • 0 in reply to Raghavendra Shenoy
    Intellectual 480 points

    Hi,

    I have done more testing and have come across some very interesting results.  I have now tested on two different routers under different circumstances and using different timings.  I does not appear that how often you broadcast makes no difference(tested 4-16 sec intervals) I came up with the following results no matter the timing:

    1: Netgear wgr614v10 - no devices connected except the CC3000 and the computer for sniffing.  
    Results - Broadcasting mdns packets matched TI's testing in that I was able to broadcast steady for 2.5 hours before I finished testing with no noticeable errors or issues.  

    2. Netgear wndr3700v2 - My normal home router with many devices connected including 3 devices that actively use mdns in a full implementation.  I was not able to broadcast for more than 8 minutes before it would stop. I could not find anything that even sent a packet to the CC3000 so it appears it stopped on its own.  I then noticed that more often than not, when the CC3000 quit broadcasting that a device was broadcasting its services and discovering other devices on the network.  I then began to remove one of the 3 devices at a time(1 netgear readynas, 1 dlink nas, 1 4th gen ipod).  With each device I removed I was able to broadcast for longer periods of time until I was able to broadcast continuously with no noticeable errors or issues.  I then powered my netgear nas back on and broadcasting ceased.

    This seems to point to some issue with other devices broadcasting mdns in at least some situations.  I was able to restore broadcasting using 3 different methods:

    1. Refreshing the router attached devices via the routers web portal.

    2. By forcing a connection to my open TCP socket. And to answer Raghavendra, my tcp socket is created already and waiting for my app to connect once it hears the mdns broadcast.  Even though the broadcasts cease the socket is accessible and seems to jump start the mdns again.

    3. By rebooting the CC3000.

    My devices that also do mdns are not overly chatty and seem to only talk every few minutes, which still may be a lot for mdns.  I cannot find any communication back to the CC3000 period.  I assumed I would see something that would tick it off, but if it is I am not seeing it at this point. 

     The way my device broadcasts is for 5 minutes at a time after smart config and for another 5 minutes after the button is pressed.  I broadcast from 6- 16 secs, most testing was done with 12 secs as this seems to be a decent target time to not absolutely flood the network but also not make the user wait too long for the process to complete.

    So I was hoping TI could provide some more testing with other devices on their network, specifically devices that use mdns on a regular basis.  NAS's seem to be a big one and apple devices.  I was also wondering what the longest time 1.11.1 was tested for broadcasting.  If it was only an hour or two this is not sufficient in any testing situation and should persist for at least 24 hours but I would prefer 72.  This gives sufficient time for buffer overruns and underruns to show up, although they may show up sooner. During my testing days I had many wireless devices that had problems show up a day or two later under certain circumstances.

    Also, Raghavendra, thanks for the details on your testing, but I still think the port is changing unnecessarily. It may not be an issue, just seems a bit odd if there is not a reason for it, but changing it to 5353 permanently may be a good idea.

    Thanks, 

    Chad

  • 0 in reply to chad ely
    Intellectual 480 points

    DEAR TI,

    WE SEEM TO HAVE A BUFFER PROBLEM!!!!

    THERE ARE SO MANY POSTS LATELY THAT HAVE ENCOUNTERED THE INTERNAL BUFFER ON THE CC3000 RUNNING OUT FOR NO APPARENT REASON.  IT IS PRETTY CLEAR YOUR DEVICE HAS A SERIOUS PROBLEM.  YOU NEED TO START TAKING US SERIOUSLY AND START SOME MAJOR TESTING OF THIS DEVICE.  

    I HAVE SPENT THE LAST 4 DAYS TRACING THE MDNS QUITS BROADCASTING ISSUE AND IT MOST DEFINITELY IS THE INTERNAL BUFFER FILLING UP.  SOMETIMES IT CLEARS ITSELF OVER TIME SOMETIMES IT NEVER RECOVERS AND IT MUST BE RESET.  

    I AM NOT SURE WHAT WE HAVE TO DO TO GET THIS RESOLVED BUT YOUR ANSWER SEEMS TO BE THE SAME, SEND US THE DEBUG LOGS.  WELL GUESS WHAT MOST OF US DIDN'T ROUTE THEM OUT DUE TO ANY NUMBER OF ISSUES.  IF YOU HAD FOLLOWED THE REST OF THE INDUSTRY AND PROVIDED A NORMAL PACKAGE LAYOUT, YOU KNOW WHERE THE CONNECTIONS ARE ON THE SIDES AND IT CAN BE SOLDERED LIKE NORMAL, LIKE EVERY OTHER WIRELESS RADIO MODULE I HAVE EVER SEEN, THEN WE COULD SIMPLY DO THIS FOR YOU BUT WE CANT AND WE ARE ALL REALLY PISSED OFF.  

    I PERSONALLY HAVE SPENT SIX MONTHS TRYING TO DEVELOP A PRODUCT THAT SEEMS DOOMED!  IT COULD HAVE BEEN SO MUCH DIFFERENT.  YOU COULD HAVE PROVIDED US WITH OP CODE TABLES AND ERROR CODE TABLES AND IT WOULD HAVE BEEN SO MUCH EASIER.  WE ASKED SO MANY TIMES FOR THEM WITH NO REAL ANSWER AS TO WHY YOU CANNOT PROVIDE THEM. WHY CANT YOU?????????????????  CAN SOMEONE PLEASE ANSWER THIS???? WE WILL SIGN AN NDA IF WE HAVE TO! I HAVE HAD TO DO THIS BEFORE TO GET SUCH INFO BUT AT LEAST THEY SAW THE NEED TO GIVE IT TO THEIR DEVELOPERS.  

    I REALLY DON'T KNOW WHERE TO GO FROM HERE, MAYBE I SHOULD JUST GO BACK TO USING GAINSPAN AND PAY THEM $1000 TO USE THEIR PRODUCT, AT LEAST IT WAS RELIABLE.  THIS CHIP WAS SUPPOSED TO BE AWESOME AND IT SO HAS THE CAPABILITY TO DO SO, BUT YOU MUST FIGURE IT OUT.  I HAVE SEEN MANY PEOPLE GET FRUSTRATED ON THIS FORUM DUE TO LACK OF SUPPORT FROM TI.  THIS IS YOU SUPPORT PORTAL AND YOU MUST LEARN TO SUPPORT IT BETTER.  YOU MUST LEARN TO MAKE YOUR DEVICES MORE DEVELOPER FRIENDLY, YOU MUST LEARN TO WORK WITH THE PEOPLE WHO ARE WILLING TO PUT THE TIME IN TO MAKE YOUR PRODUCT BETTER AND THUS MAKE YOU MORE MONEY.  

    AND LET ME BE CLEAR THE LAST POINT IS THE MOST IMPORTANT, WE ARE TRYING TO HELP YOU, LET US HELP YOU, MAKE IT EASIER.  I DID NOT SPEND THE LAST 6 MONTHS DEVELOPING TO LET SUCH A SIMPLE ISSUE STOP ME.  YOU ARE A VERY LARGE COMPANY, ARE YOU WILLING TO ACTUALLY DEVOTE SOME RESOURCES TO GETTING THIS TO WORK?  I AM WILLING TO HOST AN ENGINEER IN MY LAB TO FIGURE THIS OUT ONCE AND FOR ALL AND I AM SURE A LOT OF OTHER PEOPLE ARE.  

    WHAT EVER IT TAKES, THAT IS MY ATTITUDE, THAT IS THE AMERICAN ATTITUDE, IS THAT TI'S ATTITUDE?  IF SO LETS START THINKING OUT OF THE "PLEASE GIVE A DEBUG LOG" BOX AND LETS GET THIS DONE!

    CHAD

  • 0 in reply to chad ely
    Prodigy 50 points

    I share in the frustration with this situation.  I pretty much have everything working with the CC3K except mDNS advertise.  Thinking that the latest patch (1.12/1.26) might fix the situation, I set up a test with two CC3K's advertising every 20 seconds.  The same difficulty still exists as one can see from the log below. 

    Each packet contains the CC3K's ip and MAC addresses (C0A8010A0025CA021217 & C0A8010808002857448C, respectively) in hex format.  The one ending in 17 lasted about 5 minutes before quitting.  My experience has been that the CC3K's sporadically start and stop with no particular rhyme or reason.  I've tried just about everything (including 10 packet bursts), but to no avail.  I've even tried setting up my own mDNS, but the CC3K's UDP does not want to designate port 5353 as a destination port in its header.

    Wireshark confirms the findings of my port 5353 listener.   I remain frustrated that the CC3K appears to be 99% there and now appears to be dead-in-the-water.

    2014/03/09-01:49:32 C8C0A8010A0025CA021217   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:49:36 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:49:52 C8C0A8010A0025CA021217   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:49:56 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:50:13 C8C0A8010A0025CA021217   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:50:16 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:50:33 C8C0A8010A0025CA021217   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:50:36 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:50:53 C8C0A8010A0025CA021217   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:50:56 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:51:13 C8C0A8010A0025CA021217   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:51:16 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:51:33 C8C0A8010A0025CA021217   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:51:37 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:51:53 C8C0A8010A0025CA021217   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:51:57 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:52:13 C8C0A8010A0025CA021217   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:52:17 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:52:33 C8C0A8010A0025CA021217   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:52:37 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:52:53 C8C0A8010A0025CA021217   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:52:57 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:53:13 C8C0A8010A0025CA021217   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:53:17 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:53:34 C8C0A8010A0025CA021217   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:53:37 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:53:54 C8C0A8010A0025CA021217   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:53:58 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:54:14 C8C0A8010A0025CA021217   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:54:18 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:54:34 C8C0A8010A0025CA021217   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:54:38 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:54:58 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:55:18 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:55:38 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:55:58 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:56:18 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:56:39 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:56:59 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:57:19 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:57:39 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:57:59 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:58:19 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:58:39 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:59:00 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:59:20 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-01:59:40 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-02:00:00 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-02:00:20 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-02:00:40 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-02:01:00 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-02:01:21 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-02:01:41 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-02:02:01 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-02:02:21 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-02:02:36 C8C0A8010A0025CA021217   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-02:02:41 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-02:02:56 C8C0A8010A0025CA021217   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-02:03:01 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-02:03:16 C8C0A8010A0025CA021217   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-02:03:21 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-02:03:37 C8C0A8010A0025CA021217   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-02:03:42 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-02:03:57 C8C0A8010A0025CA021217   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-02:04:02 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-02:04:17 C8C0A8010A0025CA021217   dev=CC3000 vendor=Texas-Instruments
    2014/03/09-02:04:22 C8C0A8010808002857448C   dev=CC3000 vendor=Texas-Instruments