- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I'm using SDK 3.5.2, ThreadX/NetX_Duo, and I run a TCP server on my device. Sometime when an incoming connexion arrives, accept won't work, and then I can't even get to the connect event callback.
I run the following code in a worker thread (triggered by the connect callback):
static wiced_result_t
eci_connect_process (void *user_data)
{
wiced_tcp_socket_t *sock = user_data;
unsigned char *addr = (unsigned char *) &sock->socket.nx_tcp_socket_connect_ip.nxd_ip_address.v4;
LOG_PRINT (LOG_DEBUG, "[eci] Accepting new connection from %u.%u.%u.%u on %d\n",
addr[3], addr[2], addr[1], addr[0], sock->socket.nx_tcp_socket_connect_port);
wiced_result_t r = wiced_tcp_server_accept (&eci_server, sock);
if (r != WICED_SUCCESS)
LOG_PRINT (LOG_ERROR, "[eci] accept failed\n");
return r;
}
And I get the following output:
LOG_DEBUG: [eci] Accepting new connection from 192.168.1.34 on 59211
Error accepting connection 2 (38)
LOG_ERROR: [eci] accept failed
I'm a bit confused because nx_tcp_server_socket_accept is not supposed to return 0x38 (NX_NOT_CONNECTED), or at least not from the NetX documentation I have from the SDK.
Did someone encounter the same issue ? Is there anyway to fix this (different that rebooting) ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Partial answer has been found: wiced_tcp_server_accept doesn't listen again if the call to accept fails. Hence, once an error is encountered, I need to restart the TCP server.
But it doesn't explain why the return code isn't documented.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
olivierdufour the error code you seeing is not because of this _nx_tcp_server_socket_accept api call, there is a check for tcp socket before that either of these calls are happening and you are seeing that.
nx_tcp_socket_bytes_available
nx_tcp_socket_receive
nx_tcp_socket_peer_info_get
Did you try increasing the timeout ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I added one print in wiced_tcp_accept to get the return value of NetX function, so I don't understand why these call would change anything.
result = nx_tcp_server_socket_accept( &socket->socket, NX_TIMEOUT(WICED_TCP_ACCEPT_TIMEOUT) );
if ( result != NX_SUCCESS )
{
printf ("Accept returned %x\n", result);
nx_tcp_server_socket_unaccept( &socket->socket );
}
result = netx_returns[result];
I get the following result:
LOG_DEBUG: [eci] Accepting new connection from 192.168.1.15 on 65428
Accept returned 38
LOG_ERROR: [eci] accept failed 1b66
So I don't understand the 0x38 result (unless you did a wrapper around NetX function that we can't access).
Edit: increasing timeout of accept to 1 minute didn't solve the issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Have you solved the problem? I'm having the exact same problem, it happens randomly.
Thank you.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
no I didn't manage to get rid of it. I also suspect it to make WAC fail sometimes (since HTTP server uses wiced_tcp_server_accept ...).
I did a workaround, but I'm not sure it will always work.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Could you please share the workaround? I've been struggling with the same bug for days now.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
First thing, is that even if accept fails, you need to relisten to the socket. Otherwise on first failure, no more incoming transmission will be accepted.
Then you have to retry on client side when connect fails. As far as I have seen, when local port changes, it usually works (which happens if you retry connecting).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can confirm the issue as well, quite often when performing an accept I will get the 0x38 (socket closed) error code.
Using Wiced SDK 4.0.0
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Issue still present with SDK 4.1.0, accept still fails randomly.