CC3000 Gracefully close a lost socket?

Hi Nathan,

There is no time you should wait after calling closescocket() - the command is immediate.

connect() has a minimal timeout of 20s - BSD compliant.

You didn't mentioned but my guess is you are referring to a TCP socket.

If so, closing a socket actually triggers the closing of the TCP connection. Can you confirm the TCP connection is closed gracefully (sniffer capture)?

Did you try adding closesocket() for each of the four possible sockets (0,1,2,3) when the cc3000 driver inits?

Yael

Tested closesocket(), and it does close it gracefully:  When I have a TCP connection, and call closesocket() on that socket, the server gets that message and closes it. Then, I can open another socket and connect again immediately.

I have also added closesocket(x) on each of the 4 sockets, as suggested.  This didn't change anything.  It sometimes connects first try, other times it will fail a connect, close that socket, open another, and connect second try.  Sometimes its third or forth try before it connects successfully.  And each time it uses socket #0, since it closes the socket before it opens another.

Again, if I power cycle it over and over, it will connect immediately every other time.  Even though I am calling closesocket() on every socket after wlan_start() completes.

Hi Nathan

Does closesocket() close the TCP connection gracefully in all cases?

Also in the case that is followed by a failed connect()?

Yael

Sorry for the delay, we finished the first stage of our project with the problem still existing, and now we are trying to fix it.

If I use closesocket() with a healthy socket, the socket closes gracefully, and if I then reopen and connect, the connection opens just fine. 

We are still having the problem where a power cycle causes a delayed reconnect.  Which isn't always just delayed by 1 attempt, sometimes its 2-3.  

And I just witnessed after a power cycle of the entire device, the TiWi could not reconnect at all.  Even after many power cycles of the TiWi.  The TiWi connected to the network, got DHCP, opens the socket, but then would fail connect.  The device then closes that socket, turns off the TiWi with PW_EN, waits, then turns it back on.  This cycle lasted a long time and the device never reconnected.

If this problem isn't solved, we will probably move to another product for our 802.11 solution, since this is just causing us too much trouble.

 Hi Nathan,

I tried to reproduce the issue you encountered and these are my conclusions:

1. When I power cycle the entire device (while cc3000 acting as client in a TCP connection) the socket doesn't close gracefully (verifying with a sniffer capture – didn’t see any FIN\FIN ACK packets).

The server is not aware that the connection is closed, therefore when cc3000 try to open a new connection, the server doesn't answer the cc3000 SYN packet correctly - leads to the failed connect.

2. I set a TCP timeout at the server side of 1 second. Therefore the TCP connection is closed gracefully by the server and the next cc3000 attempt to connect always works.

Therefore I think the issue is in the server side – The CC3000 initiate the TCP connection every time a power cycle the device – send SYN packet. (I can supply sniffer captures if needed)

Can you set a TCP timeout at the server?

Yael 

Yael,

I have tried to reproduce your experiment, but did not get your results. 

1. I set the server to close the socket if there is no activity for 3 seconds.  

2. I connect the device successfully once, and it stays connected.  

3. I turn off the device

4. The server gets no activity for 3 seconds, so it closes the socket gracefully.  (At least, socket_close() returns success)

5. I turn on the device

6. It fails to connected 1,2,3 times and then connects.

My socket server is running in PHP, could that be the problem? What is yours programmed in?

What software do you use to sniff the SYN/FIN packets?

I believe I have confirmed that it is not the server, as I have now tried Roving Networks RN-131 in this same set up. 

1. Connect to server

2. cut power to device

3. server times it out

4. turn on device

5. connects first try every single time

Which cc3000 module are you using? I am using the TiWi SL on the EM board.  Could there be an error in LSR's implementation of the driver?

Hi Nathan,

I used the CC3000 Sensor Application to test this scenario ( http://processors.wiki.ti.com/index.php/CC3000_Wi-Fi_MSP430_FRAM_Getting_Started_Guide).

The sensor application implements client and server connection.

I that case the embedded side is the server.

so, I took the embedded side and tested it with another client application I wrote (connect to an AP, open a socket and then try to open a TCP connection).

I power cycle the device (client) over and over and it always seem to be connected after the reset.

Testing it shows me good connection every time I tried to connect.

You can download the sensor application and review the server implementation.

Also, I suggest using the air sniffer in order to understand to root cause of the issue. It's the only way we can determine whose "fault" is it....

I use WildPackets OmniPeek. You can also try Wireshark.

Yael

I believe I have the same or similar issue with the CC3000. After boot, the first time I establish a TCP connection everything works fine. After that, every other call to connect fails (I don't have any retries on the connect call so if it fails the socket is closed and comms are aborted). This only happens when I call wlan_stop() to power down the radio in-between events. If I never call wlan_stop and just keep the radio on, connect works every time.

Each time an event occurs that I have to establish a connection and send data, I call wlan_start and wait for the DHCP HCI event callback before doing anything with the socket API. When all the data is transferred I call closesocket and then wlan_disconnect and wlan_stop.

Any ideas why connect fails only when wlan_stop is called?

Kurt

Hi Kurt,

We didn't see this issue in houe.

Can you please try the following:

1. if the socket connect fails please try again, try doing it in a loop several times

2. Try addaing a small delay between closesocket to wlan_disconnect.

Thanks,
Alon.S

Alon,

When the connect fails it takes over 10 seconds to do so. It won't pay for me to do it in a loop because if I can't connect within 10 seconds, it is no use to even send the data so the whole procedure is aborted.

I added a 5 second delay in-between closesocket and wlan_disconnect and the problem is still there. I also wait for the disconnect callback event before calling wlan_stop.

Kurt

I get this problem too, I changed the BasicWifi Application to use TCP socket.

If I exit the program before it get a chance to close the socket.
And restart the program and it now will have problem connecting.

If I type in 37 a few times first (close socket) It work most of the time.

I get the same problem,does everybody resolve this ?  i hope one can  share the result ? 

thanks

I guess there is no official  explanation on how to do this, come on TI.

My fix is to close all sockets 0-3 at start, if it was not open in the first place I get -1 answer back

Hi,

Please note that this issue was fixed in release V1.10.

http://processors.wiki.ti.com/index.php/CC3000_Release_Notes#From_Version_1.9:

At bug fixes section number 8.

In general I recommend using the latest patches release which includes all the bug fixes.

For full bug list please refer to our release notes wiki page:

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

In order to download the latest patches please refer to our patch programmer download page:

http://processors.wiki.ti.com/index.php/CC3000_Wi-Fi_Downloads#CC3000.2BMSP430_FRAM

Patch Programmer utility wiki page:

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

Thanks,

Yael