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.

[AndriesTuinhof]

So in the end the problems was that the certifcates were not in the device. I was not able to do this through the 'certificates.h' file but i had to do it through the AT client. To make it work i had to adjust the pins of the uart that is being used by the code. This is because the custom board is using other pins. I was able to do this with an overlay. The correct way to fix this is with a custom board with its own devicetree from what i understand. But that is a lot of efferot for later. Futher i though i was not able to use the NRF Link monitor with the serial. But much later i found out that i had to turn of the checkbox 'show only supported devices'. With this i was able to quickly insert the certificates with the cerficate manager (only works if your follwing the instructions at the top correctly).

Thanks for the help, now the next step is making the can work on the NRF9160 using the MCP2515