CC3000 server socket still open, stops accepting client requests

Hi Florian,

I had a look at the logs, but it did not give more information about the error.

Also, In the logs I did not see any calls made to accept while waiting for a connection. How are you waiting for new connections?

If possible can you please capture the failure logs from the beginning? Just like the success logs that were captured from the beginning.
And when you capture the logs, please call the below API netapp_set_debug_level(0x1ff);

Apart from the SYN not being ACKed, do you see anything else in the air trace, like a RST before the new connection setup?

Are you using the same browser for testing the success and failure case? If not, then please try to use the same browsers for both the working case and the failure case, so that we have lesser parameters to consider.

Thanks & Regards,
Raghavendra

Raghavendra Shenoy Mathav said:

Also, In the logs I did not see any calls made to accept while waiting for a connection. How are you waiting for new connections?

We're waiting for new connections by repeatedly calling accept in an event loop (first it calls accept, then it dispatches any incoming data to other tasks if necessary).

We're pretty sure this works properly because if we open two server connections both handled by this single event loop, the second works fine once the first one starts failing.

I've also been manually triggering the following code snipped (through a serial debug command) to visualize the result of calling various network API commands once the socket is "dead" :

void wifi_test_sock(void)
{
    sockaddr_in clientAddr;
    socklen_t addrLen;
    fd_set writesds, readsds, errorsds;
    timeval timeout;
    int status, newsock;

    DEBUG("in test\n");

    newsock = -1;
    newsock = accept(serv_sck_80, (sockaddr*)&clientAddr, &addrLen);

    DEBUG("accept returned %d\n", newsock);

    FD_ZERO(&readsds);
    FD_ZERO(&writesds);
    FD_ZERO(&errorsds);

    timeout.tv_sec = 0; 
    timeout.tv_usec = 10000;

    status = select(5, &readsds, &writesds, &errorsds, &timeout);

    DEBUG("select returned %d\n", status);

    DEBUG("try close\n");
    status = closesocket(sck);
    DEBUG("close returned %d\n", status);

    return;
}

The result is that accept always returns -2 once we fail. Select returns no error, and close completes successfully.

Raghavendra Shenoy Mathav said:

If possible can you please capture the failure logs from the beginning? Just like the success logs that were captured from the beginning.

And when you capture the logs, please call the below API netapp_set_debug_level(0x1ff);

Ok, I'll do this and provide news logs. Do you need both driver and network logs or would network logs be enough ?

Raghavendra Shenoy Mathav said:

Apart from the SYN not being ACKed, do you see anything else in the air trace, like a RST before the new connection setup?

I'll double check but I have not seen anything that seems out of the ordinary

Raghavendra Shenoy Mathav said:

Are you using the same browser for testing the success and failure case? If not, then please try to use the same browsers for both the working case and the failure case, so that we have lesser parameters to consider.

Hi  Raghavendra,

Please find attached some new log with the more verbose debugging option activated.

7026.logs_060814.zip

_1: driver log
_2, _3: network stack logs

Florian Vallee said:

Apart from the SYN not being ACKed, do you see anything else in the air trace, like a RST before the new connection setup?

I'll double check but I have not seen anything that seems out of the ordinary

[/quote]

Actually scratch that, I'm seeing an interesting pattern before the server socket goes mute.

See :

 

In particular packets 1590 & 1591 : we receive a TCP keep alive packet followed by a RST. Shortly after that, the server socket stops responding to SYN requests. I've done several captures, and it looks like this pattern always occurs right before the socket stops responding.

I did a few more tests on both our failing workstations, and it appears that the issue is triggered way sooner when using windows XP. Under Windows 7 I can browse the HTTP website, sometimes during up to a few minutes, whereas under windows XP the issue is triggered almost immediately while loading the first page.

Hi Raghavendra,

Do you have any update on this issue ?

Thank you,

Regards,

Florian

I am also having this exact issue with the cc3000 stopping accepting incoming connections but is still able to be pinged. 

Is there going to be a firmware update to resolve this issue or is there a way around it a a library level?

Regards

Jasper

Still having this problem with 1.14.   There's gotta be a fix somehow.  Right?