CC3235MODSF: HTTP: Getting a -3020 no connection error when opening a socket

we will wait till you gather more data.

So, Marty and I dug into this for a few hours this evening. On my device the problem was intermittent. Some observations:

1) We turned off MQTT, and the problem would still persist. So, it isn't the two functions interfering with each other.

2) It appears that one of the many calls to sprsend returns a -1 and then it bubbles up to to us as a -3020. 

3) We dragged the socket code back into the project even though that caused us problems in the past. We wanted to be able to single step the C code rather than the assembly. 

4) We validated that the task stacks are not blowing out. No problem there, plenty of head room

5) When we saw the problem, the stack trace looked like this:

6) And the CPU registers looked like this:

7) The code where it seemed things went off the rails was at line 2244 in function SendRequest. I'm not 100% confident in that as the debugger was being a bit unpredictable.

Hi Kobi,

Marty and I gathered more data this morning. We found the spot where the -3020 is emerging. It is in getStatus(HTTPClient_CB *cli).

Here is a screenshot of us stopped on the place where the error occurred:

The call stack looks like:

And just to be through the registers looked like:

Regards,

John

Also, I'd love to pull in the next layer down of the socket code to continue the single stepping, but that is the code that caused our hardfault issue the last time we pulled it in. If you guys could provide the appropriate compile flags so that we can generate proper code, that would be very helpful.

After looking at the code some more I thought you might also get value from the local variables in the SendRequest function:

the HTTPClient_ENOCONNECTION is used when the SlNetSock_recv returns 0. This will happen when the peer (HTTP server in this case) closes the connection. You can verify this by looking at a sniffer log (you will see a TCP FIN from the server. 

You can check logs from the server to find the reason. Typically it will be based on some idle timeout.

Looking at the code - it seems that sendRequest will try to re-connect in this case (see call to HTTPClient_connect when CONNECTED_STATE is 0).

Do you see that? (i.e attempts to reconnect)?

Maybe you can increment the HTTPClient_MAX_REQUEST_ATTEMPTS or add a sleep in the while loop in HTTPClient_sendRequest so the server will have more time to clear the socket and accept the new connection request.

I'm not sure you need to debug the internal structures of the driver for this issue (since it seems a reasonable behavior).

BTW you don't need to compile the with driver code with application to be able to debug it. I think the pre-built library already enables debugging. and if not you can import the host driver project and build it for debug.

Hi Kobi,

I don't have a packet sniffer at this end of the connection. That is something I intend to address this weekend. However, our Gateway team was able to both sniff and monitor the server for the logs. They never saw any attempt to establish the http connection. Wireshark and the server logs were empty.

I do see the attempt to reconnect. I bumped the HTTPClient_MAX_REQUEST_ATTEMPTS to 20, and then 100. In both cases we continued to get the -3020 issue and the connection failed.

We were able to connect from my PC to the server using Swagger and we were able to get a device token. So, it isn't a network problem.

The reason I wanted to bring the library into the project was because when we single step into any function that is provided out of the library we end up having to single step assembly code which is time consuming and difficult to interpret clearly because I just don't think like a compiler.

Any other ideas on things to try?

you should have an option to link the debugger to the folder with the source C files and not debug in assembly. I'm not using IAR so i can't give you instructions. Also as said, you can import the simplelink project and make sure it is build with "-g" option.

Regarding the sniffer at the server side - do they see the successful connections? (i remember your were able to connect before and thought this happens sporadically). Please check (print) the results from the "SlNetSock_connect". I don't see how the connect can succeed (return 0) which seems to be the case if you got to sending data, without getting to the server.

Thanks for that information.

I was able to get a sniffer going here locally. When I run our application, I see no traffic outbound to our server. When I get a token with Swagger, there is TLS traffic and other traffic between my machine and our server. The http_connect said it succeeded. 

John 

I set the breakpoints. Neither function call was hit. In httpclient_connect2() this if statement returned false:

if ((intFlags & ISSECURED) || getCliState(cli, ISSECURED_STATE))

intFlags had a value of 0x10, and ISSECURED is a 0x02

The cli state was 0x02, ISSECURED_STATE is a 0x80

In SlNetSock_connectURI this if statement returned false:

if ( (0 != (ISSECURED & URIFlags)) && (NULL != secAttrib) )

URIFlags was a 0x10, and ISSECURED is 0x04. secAttrib was NULL

ISSECURED should be 0x04 (what SDK are you using?) and it set to intFlags if the URI provided starts with "https://".. I believe this should be your case.

I thought the HTTP Client used to work... what happened since?

You are saying that SlNetSock_connect is not being called?

That was a typo on my part ISSECURED is indeed a 0x04. We are using SDK version 6.10.0.5

We did have the HTTP client working, not sure what changed. We had MQTT working as well, In fact yesterday I saw a successful publish from the server to our device.

No, SlNetSock_connect is being called. But, the preceding SlNetSock_startSec is not being called.

Currently the hostname being passed to httpclient_connect2 is a hard coded IP address. Below is a screen shot of the variables being passed to do the connection:

Even the hard coded ip address should contain the "https://", e.g. "">https://192.168.1.1".

OK, that is good to know. I set the hostname back to the symbolic "">intelliportgw.eastus.cloudapp.azure.com", and now the URI flags are 0x15 which includes setting the ISSECURE flag. I'll see what happens!