Do the AT%CMNG commands function properly for writing credentials in mfw_nrf9160_0.7.0-29.alpha

[jbrzozoski]

I've used the nrf_inbuilt_key_write to store certificates/keys in the past, but I am still unable to do it using the "AT%CMNG" modem command.

I can list and delete items using "AT%CMNG=1" and "AT%CMNG=3,x,x", but every attempt to write with "AT%CMNG=0,x,x,"xxx"" seems to hang forever.

Our device is providing access to a modem console for factory provisioning and debug, so it would be nice to not have to implement a special method when this should be able to handle it, but I just can't get it to work.

Is this expected to be working in mfw_nrf9160_0.7.0-29.alpha?

[jbrzozoski]

Please if you could provide suggestions of how to force my modem credentials to a sane/empty state I would appreciate it. I've already tried "CMNG=1" and nrf_inbuilt_key_delete(), but those are apparently not enough by themselves.

I managed to get my certificates reloaded using the nrf_inbuilt methods after several attempts, but something is still messed up.  The call to mqtt_connect now hangs unless I set peer_verify=0.  My system had been running properly with peer_verify=2 for months before I started playing with certificates this week.  Watching on the server side with "openssl s_server" I can see that the modem is using the cert I am expecting.

[jbrzozoski]

Yep, this NRF9160 is definitely confused.  Even with peer_verify=0, my system has been having random lockups all day while doing BSD library calls.  I've been developing this application in some form or another for months and haven't had this much bad behavior in one day since I upgraded the original modem firmware.

Would a BSD trace be useful to the Nordic engineers?

[jbrzozoski]

For Pete's sake!  I'm 0 for 5 in getting this thing to hang while bringing up MQTT with BSD trace enabled and peer_verify set back to 2!  (I was 5 for 5 earlier today with BSD trace disabled...)

Are these modem traces easily cropped?  I'm considering just leaving the trace always running in the background while I go back to my other development work, but I don't want to make you guys sift through hours of trace when only the final minutes matter.

This feels a lot like an uninitialized variable in the modem firmware or maybe the certificates are supposed to be null-terminated and mine didn't get stored that way and it's semi-random what happens to be in memory after it...

Bah humbug!

[Martin Lesund]

Hi Justin,
I see that you have shared your trace in a private ticket and the traces will be followed up and analyses will be posted there.

[jbrzozoski]

We eventually realized that the bulk of the issue, and likely the original root of my troubles, was that the buffers being used by the at_host library are simply too small in both directions, causing silent truncation and loss of data.  There is now a ticket for a Nordic engineer to fix this, and I expect an official fix in the not too far future.

If you can't wait, start digging through the at_host code, looking in particular at CONFIG_AT_CMD_RESPONSE_MAX_LEN or CONFIG_AT_HOST_SOCKET_BUF_SIZE depending on what version you're at.  I also recommend turning on CONFIG_LOG if you can support it so that the failures aren't so silent.