MQTT connect error -45

[Jagruti]

Hello,

I am using MQTT+TLS on nRF9160DK. In the development stage, I followed this link https://devzone.nordicsemi.com/guides/cellular-iot-guides/b/software-and-protocols/posts/enabling-and-testing-tls-in-mqtt_5f00_simple to use MQTT+TLS. Everything worked properly without any errors.

Now we are in the pre production. We have created 50 custom boards with nRF9160 on it. I created the tls certificates and programmed in the similar manner. All the custom boards could connect to the mqtt server and there was the communication between nRF9160 and the mqtt server.

After 3-4 months of testing, on few cards there is mqtt connect -45 error. Before few days these cards were completely functional.

I am using sec_tag 16842753. Can I use this sec_tag? What might be the cause of this error?

I re-programmed few non-functional cards by putting the application file + certificates in this way:

cred.py --CA_cert root.crt --client_cert BT36-chain.crt --client_private_key BT36.key --sec_tag 16842753 --program_app nRF9160.hex

These cards are working again.

So the question is why the cards doesn't connect to the mqtt server after few days even after the application hex file and the certificates are same?

[Jagruti]

I have 2 questions:

1. Is it possible that the certificates are deleted from the modem at the given security tag after the ON/OFF of the nRF9160 various times?

2. Is this https://devzone.nordicsemi.com/guides/cellular-iot-guides/b/software-and-protocols/posts/enabling-and-testing-tls-in-mqtt_5f00_simple the correct method to store the tls certificates and use them?

[Øyvind]

Hello, 

Can you please provide some more details on what modem fw and nRF Connect SDK version you are running on your device? It would also be good to have full log output from the device when you get the error. We might also need a modem trace

Jagruti said:

1. Is it possible that the certificates are deleted from the modem at the given security tag after the ON/OFF of the nRF9160 various times?

No, the certificate should stay in that security tag as long as you have not deleted them. Please see AT command  Credential storage management %CMNG.

Jagruti said:

2. Is this https://devzone.nordicsemi.com/guides/cellular-iot-guides/b/software-and-protocols/posts/enabling-and-testing-tls-in-mqtt_5f00_simple the correct method to store the tls certificates and use them?

This looks correct, but I have not tested this way myself. One way to verify on your side is to provision the certificates using the Certificate Manager in LTE Link Monitor. In our documentation you should be able to follow the Provisioning the nRF Cloud certificate

After 3-4 months of testing, on few cards there is mqtt connect -45 error. Before few days these cards were completely functional.

Have you updated anything on your devices? Are the SIMs the same, any updates on the network? What about the MQTT server? 

I am using sec_tag 16842753. Can I use this sec_tag? What might be the cause of this error?

This sec tag is used to store the certificates for nRF Cloud. If you are not expecting to connect to nRF Cloud then it's OK to use this.

Kind regards,
Øyvind

[Jagruti]

Hello,

One of the nRF9160 chip's image (I guess this what you meant for device's markings)

Actually I can not use at_client on my custom board as there is no provision of UART.

To check the existence of the certificates at the sec_tag, I sent %CMNG AT command in my application program and received the respone by SMS. The reponse for AT+CFUN? will be very long and will not fit in one sms. I will check if I can do something.

Yes I will switch to the latest version of ncs for the new batch of custom boards.

Also, I found this post on the devzone: https://devzone.nordicsemi.com/f/nordic-q-a/70134/sec_tag-wiped-from-the-modem-if-low-battery-power/290582#290582

I see that the same problem is encountered. The certificates and keys for mqtt are deleted from the modem at the provided sec_tag. The writer describes that it was because of the low battery power. Do you think this is the reason for the deletion of the certificates? Are there any tests carried out at Nordic related to this problem and observed the same problem?

Edit: 

The reply received for AT+CFUN? is

+CFUN: (0,1,4,20,21,30,31,40,41,44)

[Øyvind]

Jagruti said:

To check the existence of the certificates at the sec_tag, I sent %CMNG AT command in my application program and received the respone by SMS. The reponse for AT+CFUN? will be very long and will not fit in one sms. I will check if I can do something.

This is very confusing. Why are you receiving an SMS? This should be printed in e.g. LTE Link Monitor. Is your device connected to the computer?

AT+CFUN?
+CFUN: 1
OK

[Jagruti]

No I can not use at client on my custom board as there is no provision for UART.

From nRF9160, I send SMS using CMGS command. (In my custom application, the SMS is used for other purpose). Now to check the response of the AT commands, I send them by SMS from nRF9160 on my phone.

For example, for the mqtt functional card, for the command  AT%CMNG=1,16842753,0, the reply received by SMS is

%CMNG: 16842753,0,"0000000000000000000000000000000000000000000000000000000000000000"

So that I got to know that the root certificate is present in the modem.

For mqtt non-functional card, the reply received is blank.

[Øyvind]

Jagruti said:

The reply received for AT+CFUN? is

+CFUN: (0,1,4,20,21,30,31,40,41,44)

Based on this response, you have issued test command CFUN=?. The test command lists supported functional modes. Please issue CFUN? without equals sign.

Jagruti said:

For example, for the mqtt functional card, for the command  AT%CMNG=1,16842753,0, the reply received by SMS is

%CMNG: 16842753,0,"0000000000000000000000000000000000000000000000000000000000000000"

This looks correct. Here is my output when I issue CMNG=1

2022-04-26T08:57:28.575Z DEBUG modem >> AT%CMNG=1
2022-04-26T08:57:28.595Z DEBUG modem << %CMNG: 0,6,"0606060606060606060606060606060606060606060606060606060606060606"
2022-04-26T08:57:28.604Z DEBUG modem << %CMNG: 42,0,"0000000000000000000000000000000000000000000000000000000000000000"
2022-04-26T08:57:28.610Z DEBUG modem << %CMNG: 321,0,"0000000000000000000000000000000000000000000000000000000000000000"
2022-04-26T08:57:28.621Z DEBUG modem << %CMNG: 321,1,"0101010101010101010101010101010101010101010101010101010101010101"
2022-04-26T08:57:28.627Z DEBUG modem << %CMNG: 321,2,"0202020202020202020202020202020202020202020202020202020202020202"
2022-04-26T08:57:28.638Z DEBUG modem << %CMNG: 1337,0,"0000000000000000000000000000000000000000000000000000000000000000"
2022-04-26T08:57:28.643Z DEBUG modem << %CMNG: 287290,0,"0000000000000000000000000000000000000000000000000000000000000000"
2022-04-26T08:57:28.655Z DEBUG modem << %CMNG: 287290,1,"0101010101010101010101010101010101010101010101010101010101010101"
2022-04-26T08:57:28.659Z DEBUG modem << %CMNG: 287290,2,"0202020202020202020202020202020202020202020202020202020202020202"
2022-04-26T08:57:28.668Z DEBUG modem << %CMNG: 16842753,0,"0000000000000000000000000000000000000000000000000000000000000000"
2022-04-26T08:57:28.674Z DEBUG modem << %CMNG: 16842753,1,"0101010101010101010101010101010101010101010101010101010101010101"
2022-04-26T08:57:28.683Z DEBUG modem << %CMNG: 16842753,2,"0202020202020202020202020202020202020202020202020202020202020202"
2022-04-26T08:57:28.690Z DEBUG modem << %CMNG: 4294967293,10,"0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A"
2022-04-26T08:57:28.700Z DEBUG modem << %CMNG: 4294967292,11,"0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B"
2022-04-26T08:57:28.704Z DEBUG modem << OK

[Jagruti]

Yes you are right. Previously it was with equal sign.

The reply for AT+CFUN? is:

+CFUN: 1