Apr 19, 2013
05:37 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 19, 2013
05:37 PM
[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.
Labels
- Labels:
-
TCPIP
- Tags:
- &available_data_length
- &rx_data_length
- &rx_packet
- 0&rx_data
- [wiced-sdk-2.2.1]
- appreciated
- connected
- contents
- continue
- delay
- endpoint
- equivalent
- failedrn
- hangs
- idea
- idle
- linux
- loop
- marco
- messages
- null
- number
- packet
- problem
- received
- receiving
- reception
- remaining
- result
- rx_data
- rx_data[rx_data_length]
- seconds
- secs
- send
- simple
- stops
- string
- suggestion
- terminate
- wiced_never_timeout
- wiced_packet_deleterx_packet
- wiced_packet_get_datarx_packet
- wiced_success
- wiced_tcp_receive
- wiced_tcp_receive&cometa_socket
- wprint_app_inforeceivedrn%srn
- wprint_app_infotcp
6 Replies
Anonymous
Not applicable
May 05, 2013
11:55 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May 05, 2013
11:55 PM
Maybe the TCP connection is timing out?If the tcp_receive() call fails, have you tried checking the connection state?
Anonymous
Not applicable
May 05, 2013
11:57 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May 05, 2013
11:57 PM
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.
May 26, 2013
02:57 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May 26, 2013
02:57 PM
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.
Anonymous
Not applicable
May 27, 2013
03:59 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May 27, 2013
03:59 PM
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.
May 28, 2013
11:31 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May 28, 2013
11:31 AM
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]
May 28, 2013
02:18 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May 28, 2013
02:18 PM
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.