wiced_tcp_receive() stops receiving after idle for more than 10 secs

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
MaGr_2160016
Level 4
Level 4
First like received First like given

[WICED-SDK-2.2.1]

Any idea why wiced_tcp_receive() stops receiving after remaining idle for more than 10 seconds?

I have the following simple loop:

while (1) {

        result = wiced_tcp_receive(&cometa_socket, &rx_packet, WICED_NEVER_TIMEOUT);

        if( result != WICED_SUCCESS ) {

            WPRINT_APP_INFO(("TCP packet reception failed

"));

            continue;

        }

        /* Get the contents of the received packet */

         wiced_packet_get_data(rx_packet, 0, (uint8_t**)&rx_data, &rx_data_length, &available_data_length);

         /* Null terminate the received string */

         rx_data[rx_data_length] = x0;

         WPRINT_APP_INFO(("Received:

%s

", rx_data));

         wiced_packet_delete(rx_packet);

  }

The other endpoint can send any number of messages to this loop but if there is a delay of more than 10 seconds between them, nothing is received and the loop hangs at wiced_tcp_receive().

I have an equivalent loop on a linux box connected with the same endpoint that doesnt have this problem.

Any suggestion would be appreciated.

-Marco G.

0 Likes
6 Replies
Anonymous
Not applicable
Maybe the TCP connection is timing out?

If the tcp_receive() call fails, have you tried checking the connection state?
0 Likes
Anonymous
Not applicable
Once wiced_tcp_receive() does not return WICED_SUCCESS you should check the state of the TCP connection. If the TCP connection is closed by the other side after 10 seconds of inactivity you will loop endlessly in failed calls to wiced_tcp_receive().

A sniffer trace of this event would be very helpful.
0 Likes
MaGr_2160016
Level 4
Level 4
First like received First like given
Thank you for your suggestions.

It seems the client side (the Broadcom board) is closing the connection.

I am including a tcp dump. Client is IP 173.8.149.222.

I have tried with using LwIP with similar results.

The only way I can make the receive loop working consistently is with a 10 seconds heartbeat parallel thread.

Thanks in advance.

-Marco G.
0 Likes
Anonymous
Not applicable
Please provide a wireless sniffer trace.

There may be some issue at the wireless layer causing an issue that is not visible with a wired trace.
0 Likes
MaGr_2160016
Level 4
Level 4
First like received First like given
Please provide a wireless sniffer trace.

There may be some issue at the wireless layer causing an issue that is not visible with a wired trace.

I am including a new wireless capture. Thank you for looking at this. It appears to me the WICED board is closing the connection while in the receive loop and I am hitting a dead end because of this.

[ATTACH]148[/ATTACH][ATTACH]148[/ATTACH]
0 Likes
MaGr_2160016
Level 4
Level 4
First like received First like given
I found out that a possible reason the receive loop failing on a WICED board and not on a linux based system, may be related to the fact that a wiced_tcp_bind() specifying WICED_ANY_PORT is in reality always using the same port number across power cycles. After a power cycle chances are the server has not closed that port yet and what on linux/unix would be a "port in use" error, happens. Interestingly enough is not the bind to fail but the first wiced_tcp_receive().

If I make sure the previously used port is closed on the server - I have changed the "keepalive" parameter to 3 minutes - it seems the receive loop on the WICED board doesnt fail anymore. Still testing though but it looks promising.

Please let me know if there is a know way for WICED_ANY_PORT to get a random port, short from creating a simple randomizer.

Thanks,

-Marco G.
0 Likes