CC3000 Hangs using udp sockets, also MDNS does not seem to work at all. FW1.13.00

I can't find it either, perhaps TI Employee can help?

I cannot download it from the US either, though it seems like a few people were able to download it at some point.

Did it get pulled because of issues with UDP mentioned in another thread?

http://e2e.ti.com/support/wireless_connectivity/f/851/t/342177.aspx

I am seeing the exact same thing.  The first boot of the cc3000 after flashing seems to work.  But, after I power cycle and start up the cc3000 again, it locks.  Right after binding of my second UDP socket, the entire cc3000 locks up.  Firmware v1.13. 

Here are my SPI command logs, where you can see the 1001 to open the socket and response, then the 1009 to set socket options with response, then the bind command tries twice with no response, then times out. 

05/20/2014 00:56:08 Sending (1001) - 01001100000101100C02000000020000001100000000
05/20/2014 00:56:08 New Response Received (1001) - 040110050001000000
Added new Response to Queue for opcode: 1001/1001
Sent 323 bytes on Socket 0
05/20/2014 00:56:08 Sending (1009) - 01001D00000109101801000000FFFFFFFF00000000080000000400000000
05/20/2014 00:56:08 New Response Received (1009) - 040910050000000000
Added new Response to Queue for opcode: 1009/1009
Socket ID is 1
Binding socket 1 to port 27921
05/20/2014 00:56:08 Sending (1002) - 01001900000102101401000000080000000800000002006D110000000000
05/20/2014 00:56:13 Sending (1002) - 01001900000102101401000000080000000800000002006D110000000000
A first chance exception of type 'System.Exception' occurred in Networking.WifiAdapter.dll
Additional information: Failed to bind socket port 27921

-Valkyrie-MT

Update: I also noticed that before the sockets tried to open, on the connection, I don't seem to have valid DNS Server or Gateway coming from the cc3000.  It could be that there is a problem happening earlier than the Socket Bind. Here is what I am getting from the HCI_NETAPP_IPCONFIG (0x2005) command: 

Firmware 1.13 output:

Handling Response for OpCode: 2005, Payload: 0405203D006401A8C000000000000000000000000000000000ACE3562800084D616A6F724E65740000000000000000000000000000000000000000000000000000
...
Woot! We are now connected to Wifi!
Network Name: MajorNet
IP address: 192.168.1.100
Gateway: 0.0.0.0
DNS Server: 0.0.0.0
Opening UDP Socket
...

So, I flashed back the old firmware and NETAPP_IPCONFIG worked again and gave me this response:

Firmware 1.12 Output:

05/20/2014 01:32:55 Sending (2005) - 01000500000105200000
05/20/2014 01:32:55 New Response Received (2005) - 0405203D006401A8C000FFFFFFFE01A8C0FE01A8 ...
Added new Response to Queue for opcode: 2005/2005
Handling Response for OpCode: 2005, Payload: 0405203D006401A8C000FFFFFFFE01A8C0FE01A8C0FE01A8C0ACE3562800084D616A6F724E65740000000000000000000000000000000000000000000000000000
...
Woot! We are now connected to Wifi!
Network Name: MajorNet
IP address: 192.168.1.100
Gateway: 192.168.1.254
DNS Server: 192.168.1.254
Opening UDP Socket

As you can see by comparing the two payloads, the new firmware is not getting the gateway and dns server addresses.  Note all the zeros in the

Update 3: Now when I flash the old firmware it also hangs on the UDP Bind.  Also, I have seen it get a Gateway and DNS Server value, but still fail to bind, so I am completely at a loss.  The only thing I can think of is that maybe the smartconfig information that is persistent needs to be cleared and rewritten.  That info does persist between flashes. 

Hi TI and everyone

After upgrading to the new 1.13 firmware we're seeing alot of devices no longer responding to pings. We use pings to first determine if the device is available before trying to connect to it (connect timeout is so long).

A WiFi reset fixes this problem for a while, sometimes  for a long time (hours), sometimes just a short period (minutes). We have yet found the reason for this but it seems network dependant. On one of our networks all devices works fine for hours(possably longer, havent left them on longer than 6-7 hours) on another they choke quite quick.

If I ignore the fact that they don't respond to the ping it's most of the time possible to connect anyway.

FYI: The devices also sends a UDP broadcast every 3 seconds and connects to a cloud server every 5 minutes (or more often if something interresting happens).

 I saw another person writting about problems with UDP, could it be the same bug?

Kind regards

Jimmy

Today the PatchProgrammer 1.13 download was there and I downloaded it successfully. Have not flashed it yet.

It looks like they released some type of beta and contacted a few people to test it. Then they pulled it.

These are of course my own wild speculations about what is happening. But given the constant silence form TI, wild speculations is all you're gonna to get! :)

I cannot find the download for PatchProgrammer 1.13. The downloads page only shows 1.12.

Not approved for export yet ? (I am in Austria).

Raghavendra,

Thanks for the reply to my questions.

I also found a work around, but it really isn't feasible, but it does get it working for me.  If you go to your wifi router settings and refresh the attached devices it should force the router to update its arp table and upd and mdns then work.

As for the workarounds you suggested:

1. What is considerable delay?  In my function I wait for the response and get it and then I try to receive the buffer(opcode 4100), which means I wait to send another one until the CC3000 is done sending the first and it never returns and stays locked up.  I just cant seem to get this to work with your fix.

2. Is this going to work as a reliable workaround with 'gethostbyname' also having documented issues? 

I guess I am just wondering if 1.13 should be pulled, fixed and released as 1.13.1 to save everyone the time of trying to workaround issues TI is going to fix anyway.  From my point of view, and I realize others may have much different views, the other issues were easier to work around than the new issues introduced by 1.13.  Seems like TI is really close to getting it all fixed and I would rather see the time spent fixing it, rather than even one more minute spent on workarounds.  Just my two cents, good luck.

Thanks for your help,

Chad 

Thanks Raghavendra!  I have made the recommended changes and it appears to be working...  I have resumed my testing.  We'll see how long I can run!  I am using a 1 second delay after the first send_to. 

Hi Raghavendra

Regarding the Ping im not talking about the CC3000 pinging some IP but a PC pinging the CC3000!

So the workaround does not apply in this case!

This issue has only been seen on the new firmware.

Regards

Jimmy

Hi Chad,

Thanks for the feedback. We will check on what can be done here.

Below are the answers to your questions:

1) The Considerable delay could be a 1 second delay. I think the current wait time was not sufficient for this particular case.

2) The gethostbyname should work in this case for mDns. The other known issues should not create an issue here.

Hi Jimmy,

The ping works fine for me when pinged from a remote device. I have tested it with SP1.28. For example, I start a TCP server and the CC3000 is waiting for an incoming connection. At this point, I start ping from a phone, and the ping completes successfully. I have also pinged from a PC and I have tried on different networks(APs) as well.

Thanks & Regards,
Raghavendra

My cc3000 is responding to ping with the v1.13 firmware.  In fact, the response time is the fastest I have ever seen from a cc3000, under 5ms.  Jimmy, you could look at wireshark to confirm that the ping request is going out and that the address is correct.  I'll keep checking periodically to see if I can reproduce this. 

Hmmm. This is very currious. I'm now having problems with the units that previously had 1.13/SP1.28 in them but then were downgraded again to 1.12 /SP1.26. The response to ping either work or don't after starting up  and connecting to the wifi,(it varies from time to time, haven't been able to see a pattern yet. But iIf I then issue a wifi reset it seems it starts to work as it should after reconnecting. If I'm just registered with with smartconfig or changed wifi net, I send 20 mdns broadcasts, sofar without the gethostname('localhost') patch, could this have something to do with it? Don't think it's router related, have tried multiple routers and tried pinging from 2 computers and 1 mobile phone.

The UDP issue, is this only for sendto or also send? I do also use UDP broadcasts to local subnet once every 3 seconds

Kind regards
Jimmy

ii) For the mDns issues, after the WLAN connection is completed, please make a call to 'gethostbyname' with host_name set to "localhost".
After this, make calls to "mdnsAdvertiser".

This does not work in reality.I have tested for 2 weeks now and found that it causes TCP ack errors and eventually hangs in send.  Any other ideas?  

Chad

P.S. this did work to get MDNS working even though the CC3000 returns an error when using the string "localhost", it just screwed up the TCP eventually so that is not a good workaround as we need UDP and TCP.

Wanted to chime in that after the v1.13 upgrade I also started seeing issues with my own implementation of an MDNS responder (just code that listens to the multicast DNS port and responds with enough of a message to work with mac/linux/etc.).  Adding the workaround to call gethostbyname with localhost amazingly seems to fix the issue, even though as others say the gethostbyname call actually fails (I get a -95 response, any idea what that means?).

However it's a little concerning to see talk of there still being stability issues with the workaround.  Are there plans to issue an updated or new firmware patch to fix it so the workaround isn't required?  Is there any information we can get to help TI folks troubleshoot or resolve the issues?  Would love to have firmware that's stable for both TCP and UDP, thanks!

Chad,

Thanks for the update.  I was wondering if mine working was some fluke.  It's great that you're seeing the same thing.  One thing I have noticed is that the GetHostName stops working after a while.  I decided to work around this by doing my own DNS request/response using UDP sockets.  I have it working but I have yet to see if it is better.  We'll see.  I am hoping the next firmware release will resolve these issues.  However, I think I'll probably abandon the cc3000 in favor of the cc3100. 

Raghavendra Shenoy Mathav said:

ii) For the mDns issues, after the WLAN connection is completed, please make a call to 'gethostbyname' with host_name set to "localhost".
After this, make calls to "mdnsAdvertiser".

I found another possible solution before I found this post ;-)

My solution is to send a UDP packet to a destination outside local subnet. In my application, I send the packet to a NTP server.

For example, if your local subnet is 192.168.0.0/24, send a packet to 192.168.1.1 should work.

Hi Valkyrie-MT,

Any chance you would be willing to share your DNS code?

Kind regards

Jimmy