HTTP Get fails for reponse with multiple TCP segments

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

cross mob
Anonymous
Not applicable

We are trying HTTP Get using the sample http client sample application. What we see is that the HTTP get requests returns success and prints the response data only if the response is received in one TCP segment. If the response spans over multiple segments we see that the just one segment is received and the code wait infinitely to receive remaining segments. We are using wiced SDK 3.4.0 with LwIP-FreeRTOS. We are using Murata type 1DX (BCM4343W) talking over SDIO with STM32F4.

Is there any setting that we are missing for multiple segment awareness for LwIP.

0 Likes
14 Replies
Anonymous
Not applicable

Any updates on this?

0 Likes

Confirmed with Murata that this is a WICED issue, so I moved to the WICED Wi-Fi Forums

Adding abirjepatil​ and seyhan​ so they can take a look.

0 Likes
Anonymous
Not applicable

Any update on this issue?

0 Likes

Do you see the issue on 3.5.2 ? Could you point me to the url where I could check for multiple segment responses?

0 Likes
Anonymous
Not applicable

You can use google.com which gives you reply in multiple segments.

I have not tried on 3.5.2 yet.

0 Likes

I've verified as is example in 3.5.2 and do not see this issue, would recommend you to try it.

0 Likes
Anonymous
Not applicable

We tried with 3.5.2 and we are stuck up in the loop to enable High throughput clock in bus_init()

0 Likes

FreeRTOS and LwIP has bunch of issues, developers are working on fixing these, would suggest you to try ThreadX and NetX/NetX_Duo.

0 Likes
Anonymous
Not applicable

hi vik86,

We use FreeRTOS+LwIP in our product.

Can you explain a bit about the "FreeRTOS and LwIP has bunch of issues" here.

We need to know if it has impact on our product.

0 Likes
Anonymous
Not applicable

This is exactly the the issue we have been having, and to be honest, inspecting the HTTP_Client/http_client.c implementation reveals code that I find quite bizarre.  I have no idea what the implementer had in mind, and I have a fix you can experiment with.

First, if you examine the function client_recieve_handler() in the above file, you will see that it does the following:

  1. If the packet contains an "HTTP/" header line (usually the first line of a valid request), it pops the first request off the queue and then removes the request from the queue, thereby assuring that no further data will be sent to the client callback!
  2. Otherwise, the first request is used, but not popped off the queue.  In other words, if the status line is not present, packets are delivered normally to the first request in the queue.   This is actually what you want to have happen all the time, I believe.

Given the complete lack of any meaningful documentation, I can only conclude that http_client.c was designed for some purpose other than normal HTTP client operation.  It can only do "pings" where it returns the first packet, or return streams that contain invalid HTTP.   I'm confounded.

But, you can get it to work by replacing the following lines of client_receive_handler():

   if ( find_status_line( (char*) data, fragment_available_data_length, &parsed_data, &parsed_data_length ) == WICED_SUCCESS )
     {
         /* Status line is found i.e. first data fragment */
         if ( client->response_received == WICED_TRUE )
         {
             /* Remove obsolete element from the list */
             linked_list_remove_node_from_front( &client->request_list, (linked_list_node_t**) &request );
             linked_list_get_front_node( &client->request_list, (linked_list_node_t**) &request );              }
         else
         {
             linked_list_get_front_node( &client->request_list, (linked_list_node_t**) &request );
             client->response_received = WICED_TRUE;
         }
     }
     else
     {
         linked_list_get_front_node( &client->request_list, (linked_list_node_t**) &request );
     }

with this single line of code...

 linked_list_get_front_node( &client->request_list, (linked_list_node_t**) &request );

I would really to hear more from the implementers of this function.  My "fix" above completely discards the code which checks for the status header because it really serves no purpose other than to terminate the request, which is undesirable.

However, with the above change, we've been able to implement our HTTP client with no trouble.   But, I really do not trust this code.  It is obviously designed to handle multiple requests simultaneously, but there is no apparent logic to discern multiple instances of interleaved requests properly, and so I can't see how it can do anything useful except handle a set of serialized single-packet transactions.  Perhaps I'm daft.

0 Likes
Anonymous
Not applicable

One important note I should add, because it's not clear which http client sample the poster is referring to.  The above code is for the apps/snip/httpbin_org example... which uses the HTTP client library documented in the WICED 3.5.2 SDK.  I noted you were using the 3.4.0 SDK, which ships with different examples.  So, though my code above is correct for the protocols/HTTP_Client library that is now documented and shipped, it may not apply to your example.

What is the actual path to the HTTP client example you're talking about above?

0 Likes
Anonymous
Not applicable

We got the issues fixed with lowering the TCP_MSS value in lwipopts.h. We had to lower this value to as low as 67 to make it work. Can anyone from Broadcom please clarify on this? I suspect there is some buffer constraint in lwip that is causing this.

0 Likes
Anonymous
Not applicable

You probably found a method to avoid trigger the bug, but I don't think this is a correct fix. Reduce TCP_MSS to 67 will result in slow throughput.

0 Likes
Anonymous
Not applicable

May not be a correct fix but this is the only thing that we could find. Any updates from Broadcom on this ???

0 Likes