• State Verified Answer
  • Replies 15 replies
  • Subscribers 68 subscribers
  • Views 4602 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 231013
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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?

Parents
  • 0

    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.

Reply
  • 0

    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.

Children
  • 0 in reply to 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?

  • 0 in reply to 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!

Related