nrf9160 connect client error -111 ECONNREFUSED

[AndriesTuinhof]

Hello, we are trying to get software running on our custom board.

Last week we tried to test the software written on a development kit of the NRF9160 on to our custom board. The chip is able to connect with the network and gives message about this. but it does not connect to AWS itself. The same software does work on the DK. The software breaks at the connect_client function in aws_iot.c. the error code is -111 which apparently means that something is wrong with the certifcates. The custom board is programmed in the same except for that i was not able to upload the certficates through the AT client. Because the board gets programmed through j link. I tried new cerficates. But again it worked on the DK but not on the custom board. I tried testing everything twice with no avail.

The only thing that i can think of is that with the DK I followed the tutorial that said i had to program the certficates with the AT client. Which have done with the DK but not with the custom board.

I tried looking into the matter but no concrete answered if the certficates had to programmed through that or the certificates.h header file. 

So i was wondering what the official way this done because in a latter state it would be interesting to have the certicates uploaded easier.

 

Furthermore I appreciate any suggestions on this matter.

 

[Didrik Rokhaug]

Hi,

I tried looking into the matter but no concrete answered if the certficates had to programmed through that or the certificates.h header file. 

We generally don't recommend to include the certificates in the application image (which is what you do with the certificates.h file) for two reasons:

1. Having the certificates as part of your application makes them more accessible for attackers, thus your device becomes less secure.

2. Often when the certificates.h method is used, the certificates gets written to the modem at every reboot. This can cause excessive flash wear, and shorten the life of the device.

That said, as long as the certificates gets written to the modem somehow, it should work. But, the recommended way is to write the certificates via AT commands from a host computer. The Link Monitor's certificate manager and the at_client is the easiest way to do it.

---

Are you using the same certificates on both the DK and the custom board?

What device IDs are you using?

The certificates are tied to the device ID, and if you are using the IMEI of the device in the ID, the ID will be different for the two boards.

Best regards,

Didrik

[AndriesTuinhof]

Okay we will try program the certificates through the AT client to see if that works.

I initial used the same code, certs and thing name on the custom board. Then i made a new one on AWS.

So i instered new certs and thing name but that didn't work afterwards i put those also DK to confirm if it works.

I assuming that you mean with ID the thing_name or in the config 'CONFIG_AWS_IOT_CLIENT_ID_STATIC'

We just used a random name, we did not use the IMEI.

i was wondering what bit or code or how does the selecting of the certificates work? i assume that the certifcates.h file just overriddes the same named variables in aws_iot. But how does it know to load the certificates from the memory?

[Didrik Rokhaug]

AndriesTuinhof said:

i was wondering what bit or code or how does the selecting of the certificates work? i assume that the certifcates.h file just overriddes the same named variables in aws_iot. But how does it know to load the certificates from the memory?

When the certificates are written to the modem, they are given a "security tag" (sec_tag), which identifies them (think of it as a file name). When the application opens a TLS socket, it will set the sec_tag of the certificates to be used as a socket option. Which sec_tag is used by the aws_iot sample is set in the prj.conf.

To help us debug further, could you take a modem trace?

The linked guide is for Trace Collector V1, but we also have a preview version available for the Trace Collector V2. With V2, you can decode the traces to see the IP and cellular traffic from the device. In this case, it will allow us to inspect the TLS handshake, which might tell us why the connection is refused.