TM4C129ENCPDT: HTTPS request is getting failed

Sorry for the delay. An engineer will look at this today.

Hi,

I think you are probably using the CC3100 WiFi booster pack, but please confirm that this is true.

I would first make sure that you are able to successfully run the HTTPS example for the CC3100. Have you tried that? It's located here:

C:\ti\TIRTOS\tirtos_tivac_2_16_01_14\tirtos_tivac_2_16_01_14_examples\TI\EK_TM4C1294XL\httpsgetCC3100

Please make sure to read the README file that's included with the example (it's also in the above folder).

As for your stated problem, are you sure that there is no problem with your certificates? The error you are getting is defined as follows:

#define SL_ESECBADCERTFILE  (-457)  /* error secure level bad Certificate file */

(see tirtos_tivac_2_16_01_14\products\tidrivers_tivac_2_16_01_13\packages\ti\mw\wifi\cc3x00\simplelink\include\socket.h for decoding these errors)

Again, I think the best thing to do at this point is to make sure that you are able to run the example first.

Steve

Any update on this?

Hi Steve,

Actually the problem is a bit weird. The https is working fine IN the US office on the same code and hardware. But in India, the situation is like this-

First, it tries to connect and it failed while giving the error -457. It does the same for 13 times and at 14th time, it connects and works in a proper way as expected. I don't know the reason. 

Each time on rebooting, it does the same. Only for the first time, it connects at 14th time, otherwise, later on, it works properly.

And yes, I am using cc3100. Can anyone explain this??

Thanks

Can anyone explain the above-posted thing?

If you are seeing different outcomes in India vs. US, then perhaps there is a difference on the server side (or somewhere in between if you're connecting to the same actual physical server in both cases).

So ... what is the server you're trying to connect to? Is it the same in both cases?

Can you take a Wireshark capture of this scenario? I realize that this connection is happening over the WiFi interface on your board, so it may be difficult to get a proper capture.

Or maybe the server isn't something external, but rather is a local PC? If so, can you run Wireshark on that PC to see what's going on.

In any case, it would be good to know your exact network topology in both of these scenarios.

Finally, were you able to run the example as suggested?

Steve

AKhilesh,

Did this get resolved?

Todd

Thanks tod for asking. Right now, I was busy at some other task. Now, I am following this and will let you know. We are using the same server for both the offices. Server is not running on some local pc. I am trying wireshark and will let you know in couple of days. 

A couple of other things to try:

From both the US and India offices, can you get some info about the network path between a host PC in each office and the server? (make sure that the host PC used for the following tests is on the same network as the embedded device so that the routes traversed are as close as possible):

1. Run a "traceroute" command from the PC to the server.
   1. This will just provide some insight into the path taken to reach the server in both cases.
   2. The results of this for India vs US will be quite different, but maybe the path from India is more complex and more likely to have errors.
2. Run the command "pathping" from the PC to the server
   
   1. "pathping" is a Windows only command (at least, last time I checked).
   2. this command is like traceroute, in that it also computes the routes between the server and PC, but additionally it computes packet loss between your PC and each hop to the server.
   3. I have used this command in the past to debug an issue which turned out to be due to a faulty server in in the path. This server had a very high packet loss and was the culprit of a performance issue.

Steve

AKhilesh,

Did this get resolved? If not, can you try the things Steve recommended?

Todd

Hi Todd, for now, I am trying the things Steve recommended but did not get any key thing there. 

Hi Tod,

I was using 3G for the same purpose, sending the requests to the server from the India office and luckily that 13 times error (-457) is not coming at all. URL and server are the same in this case, just the technology is changed from wifi (cc3100 simple link) to 3G. Do you have any idea about this? 

Thanks

Please tell us your network topology for each of these scenarios. We need to understand what's different in how you're connecting to the server in each case.

For each case, please describe how it is connected to the network (e.g. to a home style router? A corporate WiFi connection? A 3G hotspot such as a cell phone or dedicated hot spot? The corporate Ethernet LAN? Etc. Please provide as much detail as you can

1. PC
2. CC3100 (when you get the -457 error)
3. CC3100 (when you DO NOT SEE the -457 error)

Additionally, please provide the output of the pathping command when you run it from the PC from India. If you do not wish to provide that output on the public forums, you can message me privately through this e2e.ti.com forum and send it to me only.

Thanks,

Steve

Hi Steve, I am noting down all the details-

1. We are using cc3100 with simple SDK 1.2 along with ti - tirtos_tivac_2_16_01_14. This is the wifi part. We are using https and library httpcli. During the first time after a reboot, it tries to handshake but it fails and gives an error of -457. It tries again and fails. This happens 13 times and then at 14th time, it connects. Then it works very well until the next reboot.  This happens in the India office only, not in the US office. I am sending you the pathping trace inbox. Whether we are using the home router, mobile 4G hotspot, or any other router, the problem remains the same. 

2. In this case, we are using the 3G sim module of Telit. The application layer of the code remains the same where we are using the https with library httpcli. Here, we are using the ndk stack. In this case, it does not throw any error related to the handshake. At the first time itself, it connects to the server. Handshaking is the same in both cases and in this case, there is no error at all. This also we are trying in the India office as well as in the US office. No error in both the places. 

Let me know if you need anything else. I am sending you the pathping in the inbox.

Thanks

Hi Steve,

Any progress on this? Please let me know.

Thanks

Thanks for providing those extra details, this clarifies a lot because those 2 scenarios are quite different. In the former, (fail case), you're using the CC3100 which uses the simplelink network stack and that has the TLS built into the NWP (network processor). The Simplelink 1.2 SDK version is helpful, too.

In the latter case, which is working, you're on the NDK and you are probably using WolfSSL but possibly another TLS stack.

In the fail case, how are you flashing your certificates? Are you using the Uniflash tool?

Can you please verify that your certificate names that you're loading in your code match the names of the files you have flashed (you should be able to see the certs you've flashed in the Uniflash tool).

Steve

Hi Steve,

We are using httpcli library and tls from the same library. The certificate is hardcoded in code. 

Thanks

Hi,

How are you hardcoding the certificate? Are you making sure to convert the certs to der format?

Regards,

Michael

Yes

Hi,

For these der encoded certificates, how exactly are you hardcoding them? Are you converting them to a C byte array? I suggest you use Uniflash to flash the certs instead, to avoid any issues that might be due your hardcoding method.

Regards,

Michael