zsock_connect TLS debugging

[Arnout]

Hello,

I am trying to get an MQTT TLS connection to AWS up and running on my thingie91 (nrf9160). 
I am using SDK 1.5.0 and the sample "aws_iot".

Even though there is a file certificates.h, it seems this is not used by default, and it seems the recommended way to upload them to the modem (which actually then sets up the TLS I presume) is to flash the AT firmware, and use the LTE link monitor to update the certificates (private key, client cert and CA). 

So I did that, but I still don't get a connection. Eventually mqtt_connect returns -22.

When debugging, as far as I can get is the zsock_connect call from v1.5.0\zephyr\subsys\net\lib\mqtt\mqtt_transport_socket_tls.c. This eventually goes into nrf_connect which does some RPC with the modem core presumably, but that becomes pretty hard to follow. 

So, my main question is: How can we debug the TLS setup further? Even if I were to provision a wrong private key etc, how can we debug which "type" of TLS error happened? For now, error -22 (invalid argument) does not really make it very easy to debug.

Thanks for your feedback!

[Albrecht Markus Schellenberger]

Hello Arnout,

finding the root cause of your problem via debugging can be a challenge with AWS IoT, as you probably already have noticed. The thing is that on both ends (the modem firmware and the server) you can not access the code. And the wrapper functions of Zephyr do not contribute to the whole debugging process neither. You basically have to know in which function you will end up and set a breakpoint there.

However, there are some things you can check:

1. Is the endpoint configured correctly ?

2. Is the client ID configured correctly ? (That probably isn’t the problem right now, because a wrong client ID will result in the server immediately kicking the device out after a connection has been established.)

3. Are the certificates and its tags correct?

You can cross-check the stored certificates in the modem by using the Credential storage management %CMNG command. 

Until you have solved the problem, I recommend you to delete all other certificates.

I hope this will help you!

Regards,

Markus

[Arnout]

Hi,

Thanks for the reply. So there's no way to get more verbose output. (e.g. on the TI's CC3220, they also run the TLS stack on another core, but they do return a douzen error codes which .. at least segment the type of errror a bit more).

Note: I have a python script (based on the aws example) running, which does connect to the thing succesfully and publishes (I can see the messages coming in into the iot core). Hence my cert, key, endpoint, and clientID "should" be correct. 

The tag is indeed something that I had to fix (caused the -22) error, but should be fine now. (now its the -95 error)

AT%CMNG=1 shows

AT%CMNG=1%CMNG: 0,6,"0606060606060606060606060606060606060606060606060606060606060606"%CMNG: 201,0,"0000000000000000000000000000000000000000000000000000000000000000"%CMNG: 201,1,"0101010101010101010101010101010101010101010101010101010101010101"%CMNG: 201,2,"0202020202020202020202020202020202020202020202020202020202020202"%CMNG: 4294967293,10,"0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A"%CMNG: 4294967292,11,"0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B"OK

(My tag is 201, which the aws code uses (CONFIG_AWS_IOT_SEC_TAG=201). I tried to delete all others (managed to delete the one from nrf cloud, but no luck so far)

(BTW, my modem version is 1.3.0 and I am using rev1 silicon (%HWVERSION: nRF9160 SICA B0A))