HTTPClient_readResponseBody() getting stuck

Hi Daniel,

Sorry for the delay. What SDK version are you using? Also, are you able to get a WireShark trace of this? Also, what data did you receive from HTTPClient_readResponseBody?

Todd

Hello Todd,

thank you for response.

I'm using SDK version 3.10.00.04. However, this particular function HTTPClient_readResponseBody() as well as the nested function SlNetSock_recv() remained unchanged throughout all SDKs from 3.10.00.04 to 4.10.00.07.

We have already products in the filed and it was working fine for several months until 12.5. Since 12.5. the function started locking up while getting data from maps.googleapis.com. I have not seen this problem before.

Using the function HTTPClient_readResponseBody I receive full response body from the maps.googleapis.com server, so there seems to be no problem with the data transfer itself. The problem is that the function never sets the flag moreDataFlag=0 when all data has been retrieved, but gets stuck instead.

The data I receive is following JSON:

{
   "results" : [
      {
         "access_points" : [],
         "address_components" : [
            {
               "long_name" : "London",
               "short_name" : "London",
               "types" : [ "locality", "political" ]
            },
            {
               "long_name" : "London",
               "short_name" : "London",
               "types" : [ "postal_town" ]
            },
            {
               "long_name" : "Greater London",
               "short_name" : "Greater London",
               "types" : [ "administrative_area_level_2", "political" ]
            },
            {
               "long_name" : "England",
               "short_name" : "England",
               "types" : [ "administrative_area_level_1", "political" ]
            },
            {
               "long_name" : "United Kingdom",
               "short_name" : "GB",
               "types" : [ "country", "political" ]
            }
         ],
         "formatted_address" : "London, UK",
         "geometry" : {
            "bounds" : {
               "northeast" : {
                  "lat" : 51.6723432,
                  "lng" : 0.148271
               },
               "southwest" : {
                  "lat" : 51.38494009999999,
                  "lng" : -0.3514683
               }
            },
            "location" : {
               "lat" : 51.5073509,
               "lng" : -0.1277583
            },
            "location_type" : "APPROXIMATE",
            "viewport" : {
               "northeast" : {
                  "lat" : 51.6723432,
                  "lng" : 0.148271
               },
               "southwest" : {
                  "lat" : 51.38494009999999,
                  "lng" : -0.3514683
               }
            }
         },
         "place_id" : "ChIJdd4hrwug2EcRmSrV3Vo6llI",
         "types" : [ "locality", "political" ]
      }
   ],
   "status" : "OK"
}

Hi Daniel,

I'm working to try to recreate the issue, but I may need some assistance debugging.

You mentioned "it was working fine for several months until 12.5." Is that a version for the Google APIs? Do you happen to have a version of the JSON from when it was working before?

Best regards,

Sarah

Hello Sarah,

thank you for your reply.

12.5.2020 is a date. Before this date it was working fine. Google didn't announce any API update this day, which makes it even more strange.

Anyway, I think you can replicate the issue if you open the example: httpget_CC3220SF_LAUNCHXL_tirtos_ccs and in the source file httpget.c change the defines as:

#define HOSTNAME              "https://maps.googleapis.com"
#define REQUEST_URI           "/maps/api/geocode/json?address=london&key=XXXX"
#define CA_CERT_GOOGLE                   "/cert/google.cer"  //File certificate
#define USER_AGENT            "HTTPClient (ARM; TI-RTOS)"
#define HTTP_MIN_RECV         (500)

where XXXX is your google API key and CA_CERT_GOOGLE is a path pointing to the Google CA root certificate in the memory structure, which is GlobalSign.

Then only add the certificate to the connection:

    httpClientSecParams.rootCa = CA_CERT_GOOGLE;
    httpClientSecParams.clientCert = NULL;
    httpClientSecParams.privateKey = NULL;

    ret = HTTPClient_connect(httpClientHandle,HOSTNAME,&httpClientSecParams,0);

Now if you launch the example with the settings above, you will get the JSON data and then the function HTTPClient_readResponseBody() gets stuck. It will never leave the loop (or after several minutes).

Also, if you run the same example, but with the following URI:

#define REQUEST_URI           "/maps/api/timezone/json?location=51.5073509,-0.1277583&timestamp=1590673228&key=XXXX"

you will not even get the JSON data. The function locks up immediately.

I hope it will help you to replicate the issue.

Thank you

Hi Sarah,

I believe Daniel was using European convention (day.month) and meant "May 12" (of 2020).

We are also experiencing this issue, which is seriously impacting our customer's ability to release their product to market.  We are experiencing the same symptom; we make two calls to HTTPClient_readResponseBody(); the first returns, the second hangs, causing the CC3220 to reboot endlessly.  Additionally, we are getting some leftover HTTP header garbage (about 84 bytes) in the start of the HTTP response body, followed by our actual response body (roughly 200 bytes), which is intact.  We've confirmed using Postman that the Google site (https://www.googleapis.com/oauth2/v4/token) is returning a normal, valid response.

We also have tested this functionality previously numerous times; our last round of intensive testing was in late March.  Today our customer notified us of this issue.  So it would certainly track if something changed with the Google API HTTP response in mid-May.

We will be calling our TI representative to hopefully expedite a solution to this issue.  If we get an update, we will post that information here.

(We are using SimpleLink 2.40.02 on a CC3220.)

David Rodgers

Dear all,

yes, I meant the date 12th of May 2020. Apologise for confusion.

I can confirm that the issue David has described is the same we are experiencing. HTTP header contains some garbage bytes, body is received correctly and then because the flag "moreDataFlag" is not cleared, the function is called again and gets stuck. We have a watchdog implemented which is then causing rebooting the CC3220 in a loop.

This caused us serious problems as we had to recall products from our customers.

Temporary fix might be setting function SlNetSock_recv() as non-waiting or decrease the wait timeout, which cause the function HTTPClient_readResponseBody() to return with an error instead of getting stuck. However, this does not fix the root cause of the problem.

Any updates on this will be appreciated.

Thank you

Hi Daniel, David,

Thanks for the ping on this. I'm working on it now and hope to have an update before the end of the week, (edit) but so far I have not recreated it on the latest SDK and servicepack. Could you test with the latest servicepack and see if the behavior changes? They are backwards-compatible with older host driver/SDK versions.

Daniel, what error do you see when you decrease the timeout?

If either of you have a sniffer capture or NWP log of this event, that could help speed this process too. Does this happen every time or intermittently?

Best regards,

Sarah

Sarah:

Where can we find the service pack that you mentioned?

Thanks in advance

Dave...

Hi Dave,

Servicepacks are distributed in the SDK package in the tools/cc32xx-tools/servicepack-cc3x20 folder. The latest SDK is available here: https://www.ti.com/tool/download/SIMPLELINK-CC32XX-SDK

Are you familiar with the UniFlash ImageCreator already? If you need a guide: https://dev.ti.com/tirex/explore/node?node=AH9w8QwBrpt-RLlf.VRAvg__fc2e6sr__LATEST

Best regards,

Sarah

All:

We updated to the latest SDK (ver 4.10.00.07), built the project with the latest code composer studio (ver 10.1.0.00010), and added the latest service pack when creating an official build and have not had any issues with HTTPClient_readResponseBody() getting stuck.

Maybe give that a try and see if it fixes the issue on your applications?

Dave....