9160 production certificates and dynamically change MQTT client ID

[EivindTH]

Hello,

After looking at aws_iot sample files, I've stumbled upon the question regarding how one can dynamically change IDs and certificates for multiple 9160 devices? I've seen that it is possible to use %CMNG and store the credentials in the modem. However, it is stated from Nordic Semiconductor Infocenter that issuing the CMNG command will store credentials in NVM storage, is this a safe location for this? The best solution is probably to manufacture and upload the modem firmware/certificates at the same time for each device.. However:

1. What is the optimal and intended way to dynamically change the client ID used for connecting to MQTT? I saw that it is possible to store client_id in config before initializing aws library (using CONFIG_AWS_IOT_CLIENT_ID_APP), but after a FOTA, how would a device know it's ID, where would it make most sense to store the ID? It seems pretty redundant to create multiple app_update.bin's just because each device needs its own prj.conf...

2. Would it be possible to extract the ID from the certificates since the certificates are generated on the cloud based on the client ID?

3. Lastly, AWS(or the cloud service being used) also require client_id in their topic names, and an example of this is AWS_IOT_LAST_WILL_TOPIC which can be seen in client_broker_init, aws_iot.c. Maybe it's easiest to disable CONFIG_AWS_IOT_LAST_WILL, and store custom, dynamic last will topic name and message to client config, based on the acquired client_id? I expect other topics to not be an issue though, considering it is possible to just dynamically change the topic names prior to the aws_iot_subscription_topics_add call.

 

Thanks in advance,

Eivind

[Charlie]

Hi Eivind,

is this a safe location for this? The best solution is probably to manufacture and upload the modem firmware/certificates at the same time for each device..

Do you mean write certificates into modem firmware and program it at production? It is possible but not very common, writing certifications to chip in production is normally be done separately with writing firmware. No mether which way the certificates will be stored in NVM storage finally.

1. What is the optimal and intended way to dynamically change the client ID used for connecting to MQTT? I saw that it is possible to store client_id in config before initializing aws library (using CONFIG_AWS_IOT_CLIENT_ID_APP), but after a FOTA, how would a device know it's ID, where would it make most sense to store the ID? It seems pretty redundant to create multiple app_update.bin's just because each device needs its own prj.conf...

I just wonder if the issue that you concern about exists. When you build aws_iot firmware, it always contains the same client id, so a FOTA does not make the device forget or change its client id. The CONFIG_AWS_IOT_CLIENT_ID_APP is used to solve the issue of how to make a common firmware for different devices with distinguished client id. It allows application code to assembly client id at run-time. You can refer to the usage of asset_tracker_v2/src/cloud/aws_iot_integration.c/aws_iot_init, it extracts the device IMEI number as client id, so you do not need to manually assign different client id for every device firmware. Please explain your concern further if you do not agree.

Best regards,

Charlie

[EivindTH]

Hello,

I think I understand what you mean. Instead of giving custom IDs in the cloud, we give the devices their IMEI numbers instead, since they can get this from AT commands from the modem and SIM. But this raises my final question again, how can we then change the LAST_WILL_TOPIC since it uses the client id as topic name, since its already predefined in aws_iot.c, client_broker_init as a CONFIG variable?

Regards,

EivindTH

[Charlie]

Hi EivindTH,

Is your final purpose to know which device is disconnected with the MQTT broker when that happens? so you want the AWS_IOT_LAST_WILL_TOPIC or AWS_IOT_LAST_WILL_MESSAGE to contain client id(like nrf-IMEI) information? 

The LAST_WILL_TOPIC is a topic that will be published by the MQTT broker when the device is disconnected. As you know, our current aws_iot.c only support the predefined AWS_IOT_LAST_WILL_TOPIC and AWS_IOT_LAST_WILL_MESSAGE, you have to add client id string to either of them from line 951 to 961 like you have done to use IMEI as client id. 

Best regards,

Charlie