- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Could use some insight into an occasional error we are seeing in our http server application (WICED 6.2), specifically the WICED API “wiced_http_response_stream_write”. When we call this API to write chunks of a web page up to the browser the API will occasionally return the value 4, which from below WICED code is defined generically as “ERROR” (appears a macro is used to expand to “WICED_TCPIP_ERROR” so at least we can search the WICED code for that string). When this error occurs our web page is obviously not rendered correctly. The error is not easily reproducible nor is there any pattern to its occurrence. It is not a “hard” error, our application will continue to function following this error, meaning the user can navigate to another page which will be served and rendered correctly. When the API fails as described our application will retry the API several more times but those retries fail as well, with the same error code.
The generality of this error code makes it difficult to debug. Can you provide some insight into what “Error” may indicate, what may cause this situation, possibly WICED debugging options that can be enabled?
Another error that same library function will sometime return under the same conditions is “socket closed”. When this is seen the current page does not render correctly but typically can back to the previous page which will then be rendered fine. I retry the library function when it returns that error but that did not help. I’m not quite sure what this error may be implying, as the the connection is fine.
#define TCPIP_RESULT_LIST( prefix ) \
RESULT_ENUM( prefix, SUCCESS, 0 ), /**< Success */ \
RESULT_ENUM( prefix, PENDING, 1 ), /**< Pending */ \
RESULT_ENUM( prefix, TIMEOUT, 2 ), /**< Timeout */ \
RESULT_ENUM( prefix, PARTIAL_RESULTS, 3 ), /**< Partial results */ \
RESULT_ENUM( prefix, ERROR, 4 ), /**< Error */ \
RESULT_ENUM( prefix, BADARG, 5 ), /**< Bad Arguments */ \
RESULT_ENUM( prefix, BADOPTION, 6 ), /**< Mode not supported */ \
RESULT_ENUM( prefix, UNSUPPORTED, 7 ), /**< Unsupported function */ \
RESULT_ENUM( prefix, INVALID_PACKET, 7008 ), /**< Invalid packet */ \
RESULT_ENUM( prefix, INVALID_SOCKET, 7009 ), /**< Invalid socket */ \
RESULT_ENUM( prefix, WAIT_ABORTED, 7010 ), /**< Wait aborted */ \
RESULT_ENUM( prefix, PORT_UNAVAILABLE, 7011 ), /**< Port unavailable */ \
RESULT_ENUM( prefix, IN_PROGRESS, 7012 ), /**< Action in progress */ \
RESULT_ENUM( prefix, IP_ADDRESS_IS_NOT_READY, 7013 ), /**< IP_ADDRESS_IS_NOT_READY */ \
RESULT_ENUM( prefix, SOCKET_CLOSED, 7014 ), /**< Socket closed */
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I would suggest you to run the application in debug mode (append -debug in make target) to trace the error location along with call stack. The wiced_http_response_stream_write would execute function calls across multiple layers so tracing the error manually would be difficult. For instance, one scenario could be that the API calls wiced_tcp_stream_write()->wiced_tcp_send_packet()->wiced_tls_encrypt_packet()->wiced_packet_get_data() and this would return WICED_ERROR if not successful. The implementation inside wiced_packet_get_data() which is network stack dependent would give you the exact reason behind the error. I'm assuming that you have used TLS security.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I would suggest you to run the application in debug mode (append -debug in make target) to trace the error location along with call stack. The wiced_http_response_stream_write would execute function calls across multiple layers so tracing the error manually would be difficult. For instance, one scenario could be that the API calls wiced_tcp_stream_write()->wiced_tcp_send_packet()->wiced_tls_encrypt_packet()->wiced_packet_get_data() and this would return WICED_ERROR if not successful. The implementation inside wiced_packet_get_data() which is network stack dependent would give you the exact reason behind the error. I'm assuming that you have used TLS security.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks,
I'm developing in Eclipse and have no capability to single step. I did follow your functions calls and put a strategic printf in the below WICED function and was able to duplicate the second error I mentioned, wiced_http_response_stream_write returning 7014 (socket closed). The low level error code was 0x38 ( NX_NOT_CONNECTED). Despite the error code I am still connected. The current page did not render given this error code but I can hit the browser back button or refresh and the pages then render correctly.
wiced_result_t network_tcp_send_packet( wiced_tcp_socket_t* socket, wiced_packet_t* packet )
{
UINT result;
WICED_LINK_CHECK_TCP_SOCKET( socket );
result = nx_tcp_socket_send(&socket->socket, packet, NX_TIMEOUT(WICED_TCP_SEND_TIMEOUT) );
if (result)
wiced_log_printf("nx_tcp_socket_send returns %d !!!!!!!!!!!!!!!!!!!!!!!!!!\n",result); //pjs
return netx_returns[result];
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Update,
It appears the WICED_TCPIP_ERROR is due to nx_tcp_socket_send() returning NX_TX_QUEUE_DEPTH, Does this imply I'm attempting to send packets too fast? Or too many bytes per packet?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You can use wireshark TCP capture logs to investigate the socket close issue. You would need to find out which device is closing the socket and why. The NX_TX_QUEUE_DEPTH simply means that the device reached the maximum transmit queue depth. You can slow down the rate of packet transfer and check if the error frequency reduces.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks.
So for the socket closing, there is only ever 1 client. When I see from my application debug output NX_NOT_CONNECTED being returned, Wireshark seems to confirm this as there is a TCP RST command sent from our application to the client (browser on my PC). As to "why", good question. Nothing special going on just continuously browsing between 2 pages and occasionally this error occurs. And as I said, it's not a hard error. If I browse to the next page it is rendered just fine.