Modem Firmware Version 1.2.3 Cannot connect to MQTT broker using certificates

[jbax92]

Hello,

We are trying to connect to an AWS MQTT broker using the nRF9160 with modem firmware version 1.2.3 and are not having any luck.

Project background:

Using modem firmware version 1.2.0, we have been able to load a root CA, Client Certificate, and private key using the following commands:

AT+CFUN=4
AT%CMNG=0,16842753,0,"root_ca"
AT%CMNG=0,16842753,1,"client_cert"
AT%CMNG=0,16842753,2,"private_key"

After which, we reboot the device and the application firmware goes through the normal connection process. This results in a successful connection to the AWS IoT Core MQTT broker.

Using the same method on modem firmware version 1.2.3, the modem successfully connects to LTE, but fails to connect to the MQTT broker. Our application firmware will then fall back to a locally hosted backup MQTT broker using username and password as an authentication. That connects successfully.

I know the certs load correctly, because I am able to load the certs onto the modem when it is running on 1.2.3, then go back to 1.2.0 and this results in a successful connection.

I'm not really sure what else to try, any inside knowledge to the changes between 1.2.0 and 1.2.3 would be appreciated.

Thanks,

Jordan

[Didrik Rokhaug]

Hi,

This sounds strange. I don't know about any changes between those two versions that could cause this.

Are you using the same application FW with both modem FW versions?

Do you have any logs from the application?

Could you take a modem trace (at least a failing one with mfw 1.2.3, though a working one with 1.2.0 to compare with would also be nice)?

Best regards,

Didrik

[Didrik Rokhaug]

Traces were shared privately, here are my comments:

Hi, and thanks for the traces.

Unfortunately, I am not able to successfully decode the 1.2.0 trace.

However, the 1.2.3 trace shows that the TLS handshake is fine, but the server closes the TLS connection after the device has sent the first packet with (TLS) application data. Presumably, this is the MQTT Connect request.

I assume you are running the same application in both cases?

Is the device ID correct?

Does AWS have any information about why the device is rejected?

Best regards,

Didrik

[jbax92]

Ok, let me see if I can get another version of the 1.2.0 trace. All elements of the connection process are the same except the modem firmware version.

Edit: To answer your question about AWS, there is no logging on aws below the MQTT data layer. So I have not been able to get any access logs from IoTCore

[Didrik Rokhaug]

This trace is better, I was able to decode it. However, in the trace, the device is not able to connect to the network.

There is one attach attempt, but it is rejected (by the network) with ESM reject cause 38:

Cause #38 – Network failure
This ESM cause is used by the network to indicate that the requested service was rejected due to an error
situation in the network.

After that, the device continues to search for a network, but doesn't find one.

[jbax92]

That's strange, because I watched traffic come through on mqtt when this trace was recorded.