How best to begin new nRF91 MQTT project connecting to AWS

[craig.goldman]

I am re-starting a project to send MQTT topics to AWS.  At this point, is MQTT_Simple still the best way to start and then modify the endpoint as suggested in case 224855 or would it be better to start with something like Asset_Tracker (or maybe something else)?  I am particularly concerned about the effort to add certificate and keys to MQTT_Simple code.

[Didrik Rokhaug]

Hi.

mqtt_simple is probably the easiest place to start from, as there is very little "extra" other than just connecting to a broker. However, the mqtt_simple does not support TLS. For this, asset_tracker or the nrf_cloud library is a good place to look. Especially nrf_cloud_transport.c which contains all the MQTT related code. Adding TLS to mqtt_simple requires very few changes. If the certificates are already provisioned, e.g. with AT commands and the Certificate Manager tab in the Link Monitor, the only changes needed is to configure the mqtt_client to use TLS. The result should be something like this (from case 224855):

/**@brief Initialize the MQTT client structure
 */
static void client_init(struct mqtt_client *client)
{
	mqtt_client_init(client);

	broker_init();

	/* MQTT client configuration */
	client->broker = &broker;
	client->evt_cb = mqtt_evt_handler;
	client->client_id.utf8 = (u8_t *)CONFIG_MQTT_CLIENT_ID;
	client->client_id.size = strlen(CONFIG_MQTT_CLIENT_ID);
	client->password = NULL;
	client->user_name = NULL;
	client->protocol_version = MQTT_VERSION_3_1_1;

	/* MQTT buffers configuration */
	client->rx_buf = rx_buffer;
	client->rx_buf_size = sizeof(rx_buffer);
	client->tx_buf = tx_buffer;
	client->tx_buf_size = sizeof(tx_buffer);

	/* MQTT transport configuration */
#if defined(CONFIG_MQTT_LIB_TLS)
	client->transport.type = MQTT_TRANSPORT_SECURE;

	static sec_tag_t sec_tag_list[] = {MY_SEC_TAG};
	struct mqtt_sec_config *tls_config = &client->transport.tls.config;
	
	tls_config->peer_verify = 2;
	tls_config->cipher_list = NULL;
	tls_config->sec_tag_list = sec_tag_list;
	tls_config->sec_tag_count = ARRAY_SIZE(sec_tag_list);
	tls_config->hostname = CONFIG_MQTT_BROKER_HOSTNAME;

#else
	client->transport.type = MQTT_TRANSPORT_NON_SECURE;
#endif
}

If you want to provision from the application, you can use the provision function from nrf_cloud_transport.c. Note that it expects CONFIG_NRF_CLOUD_PROVISION_CERTIFICATES=y to be set in prj.conf, and the certificates to have the same name as in the certificates.h file found in asset_tracker.

Best regards,

Didrik

[craig.goldman]

Thank you.  This is a very good answer.

I'm going to take a look at the cloud library.

It now appears to me that I should try something with mqtt_simple (modified as described above), then look to build a new application using the nrf_cloud library.

Just to make sure I understand you, for the provision function, do you mean "nct_provision"?

-Craig

[Didrik Rokhaug]

Yes, I meant nct_provison.

The nrf_cloud library is built specifically for nRF Cloud, and so while the transport layer can be used without too much modification, you might have more problems with the upper layers of the library, as they implement more nRF Cloud specific functionality. However, it can still be used as an inspiration on how to build your own cloud-interfacing library.

[craig.goldman]

I'm a bit confused by your answer.  Are you saying that the upper layers of the nrf_cloud library are not built to work with AWS?

[craig.goldman]

The "prj.conf" file under "mqtt_simple" does not contain CONFIG_NRF_CLOUD_PROVISION_CERTIFICATES; is it as easy as simply adding a new line or am I looking in the wrong "prj.conf" file?

Should I also add "CONFIG_MQTT_LIB_TLS=y" to this file?

[Didrik Rokhaug]

nRF Cloud is built on AWS, but we have configured AWS for our use. I am not familiar enough with AWS to say how much impact this has, but I can not guarantee that all the upper layers of the nrf_cloud library work with your (or other) AWS setups.

To give an example:

A DK can be in several different states: It can be associated with a user account, it can be waiting for a user to input a sequence of button presses, etc.

When a DK connects to nRF Cloud, it receives a message informing it of what state it should be in. It will then decode the message, and perform the appropriate actions.

As your cloud implementation will have other requirements and uses, the received state might not make sense to the nrf_cloud library (leading to an error), or the corresponding action might not be what you want.

[Didrik Rokhaug]

craig.goldman said:

Should I also add "CONFIG_MQTT_LIB_TLS=y" to this file?

 Yes, you will need to add CONFIG_MQTT_LIB_TLS=y to your prj.conf.

 

craig.goldman said:

The "prj.conf" file under "mqtt_simple" does not contain CONFIG_NRF_CLOUD_PROVISION_CERTIFICATES; is it as easy as simply adding a new line or am I looking in the wrong "prj.conf" file?

 It is almost as simple as that. In addition to the adding CONFIG_NRF_CLOUD_PROVISION_CERTIFICATES (=y the first time you run the application, =n afterward to avoid flash wear) to prj.conf, you must also declare the configuration option in the Kconfig file. I.e., add the following lines (from <ncs>/nrf/subsys/net/lib/nrf_cloud) to the Kconfig file in your project folder (same folder as your prj.conf and CMakeLists.txt):

config NRF_CLOUD_PROVISION_CERTIFICATES
	bool "nRF Cloud library provision of certificate"
	help
		Enable run-time provisioning of certificates from the
		certificates header file selected by using NRF_CLOUD_CERTIFICATES_FILE

The text after "help" can be changed to something else, and I would remove NRF_CLOUD from the name of the configuration as you are no longer using it for nRF Cloud (you would, of course, have to change the name all places you are using it, i.e., in prj.conf and the provision function).

[craig.goldman]

Thank you for your help.  I'm sorry about the delay getting back to here.  Sometimes "Life Happens".

[Didrik Rokhaug]

You are welcome.

Just one note:

While the provisioning function is useful during development, you should avoid having your certificates present in the production binaries. A more secure way is to use the AT command AT%CMNG to write certificates. During development, you should also try to avoid unnecessary writing of your certificates, as this will wear out the flash.

Best regards,

Didrik