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 TCP stack work well on local LAN but is unreliable over the Internet.

Our company uses your WIFI module CC3000 in one of our products. I am developing the embedded software using CC3000, specifically SMTP client for sending sensor notifications over internet. We are facing a problem within CC3000 TCP stack. The SMTP session initiated by our device via CC3000 works perfectly if the destination host is on the local LAN. The same SMTP session hangs at different points if the destination host is on the internet. The only difference between working and non working cases is the network delay when sending / receiving IP packets. Tracing the IP router facing the internet shows that CC3000 fails to send a TCP ack to a TCP segment received from SMTP server. Once this happens, sometimes retransmissions by SMTP server recover the problem, but very often - it does not help - the SMTP session closes down. I have detailed traces to prove my point.

Perhaps the timeout (retransmission timer?) values in the CC3000 TCP stack are too short? Is there any way to increase them via API?

To be honest I am very surprised that the module can be released with this kind of problems.

This problem is critical for my company, and we do appreciate your help as soon as possible.

  • Hi Alex,

    Do you have an air sniffer log for this scenario? I would like to see the packets to understand a bit more.
    At present the CC3000 host API supports only the timers configured by netapp_timeout_values. There is an inactivity timeout which can be increased if you think CC3000 times out waiting for a frame from the server.

    Regards,
    Raghavendra
  • Hi, Raghavendra,

    Please have a look the wireshark capture here.

    The capture is taken between the wireless access point and the gateway internet router.

    It shows a typical behaviour I am observing: at some point during TCP connection, the CC3000 seems to be ignoring (or loosing?) TCP segments received from server. In this particular case one segment is able to get through after a number of retransmissions. In many cases it stops even earlier and retransmissions don't help. In maybe 5 % of cases the SMTP session is successfull- very rarely. The same SMTP session, to the same SMTP server is 100% successfull when forwarded through a transparent TCP proxy - in this case the TCP server is on the local LAN - and of course the network delay is much shorter.

    I do not think it is related to the socket timeouts - this is a deeper TCP level problem.

    The CC3000 module I am using has firmware version 1.10 - if it helps.

    The host driver I had to write myself, and the original host driver provided by TI did not work out of the box and had to be modified anyway.

  • Hi, Raghavendra,

    I provided the capture in the previous post, did you or anyone else from TI had a look at the issue?

    Regards,

    Alex.

  • I can't down load your file. I am experiencing a similar situation I believe. I've only started working on this project yesterday so I have very limited info/data right now. My company has a problem in what I would call "congested environments". Have you had any luck with this yet?
  • Did you get any further with this problem. I am working on a project where I use a CC3000 shield and an Arduino Mega2560 microcontroller. I have reliability problems which are likely caused by the WiFi comms. It sometimes works fine for a while and then it becomes erratic. I don't have the equipment to test the comms. What is the latest firmware and how can I upload it?

  • I managed to install the latest firmware on my CC3000. I also minimised the size of webserver. None of these actions actually improved the situation very much. I am still waiting for TI to come up with a reply. In the meantime I have found a workaround. I use an Arduino Nano to generate a hardware interrupt of the main board every 10 minutes. That interrupt restarts the CC3000, keeps track of the main board settings and returns these after the interrupt. This solution works very well but it is far from elegant. The WiFi chip should ensure a reliable link itself, irrespective of number of calls etc. I had expected a better product from a renowned company.