WICED API for stream write returning errors

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

cross mob
Anonymous
Not applicable

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 */

0 Likes
1 Solution
GauravS_31
Moderator
Moderator
Moderator
10 questions asked 250 solutions authored 250 sign-ins

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.

View solution in original post

5 Replies
GauravS_31
Moderator
Moderator
Moderator
10 questions asked 250 solutions authored 250 sign-ins

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.

Anonymous
Not applicable

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];

}

0 Likes
Anonymous
Not applicable

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?

0 Likes
GauravS_31
Moderator
Moderator
Moderator
10 questions asked 250 solutions authored 250 sign-ins

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.

Anonymous
Not applicable

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.

pastedImage_0.png

0 Likes