Bluetooth: Mesh: Persistent Storage: AppKey not restored

[MrPointer]

Hi all.
In the last couple of days my Team and I are attempting to use the BT-Mesh-Settings API, with our current implementation being based on self-provisioning and self-configuring (We have our reasons). After a bit of grappling, we found out the updated mesh_demo (We've had an offline copy of v1.12) which does exactly what we've been looking after.
However, the problem is it doesn't work for us as expected.

The Node's address, or more specifically, the Primary Element's address (As we don't have any more for now) is not restored upon a power-cycle, leading to error -49:EADDRNOTAVAIL when publishing data using a publication context/model.
Since we're self-provisioning, we could "overcome" this issue by manually calling the bt_mesh_comp_provision function, which from our understanding should assign the address - But it's an ugly solution and wouldn't work for prod-ready provisioning.

Now the question is - Is the address not restored on purpose? It seems rather foolish to restore settings on boot after a system reset of some kind just to wait for the node to be re-provisioned, isn't it?
If it's not, I'm afraid this is some kind of bug, or perhaps, we're using it wrong? @jhedberg

[jhedberg]

Storing and restoring the range of assigned addresses should work fine, and does work fine using the existing sample apps in the upstream tree. The relevant code is in subsys/bluetooth/host/mesh/settings.c where net_set() is responsible for restoring and store_pending_net() for storing. These deal with the device key and the primary element address (from which the remaining elements, if any, are derived).

I'm a bit confused by what you're doing - you say you're self-provisioning. What exactly do you mean by that? What APIs do you call and in what order?

[MrPointer]

I'm attaching the bt_ready function from the mesh_demo sample we're talking about, without the hb-related code at the end.

static void bt_ready(int err)
{
	if (err) {
		printk("Bluetooth init failed (err %d)\n", err);
		return;
	}

	printk("Bluetooth initialized\n");

	err = bt_mesh_init(&prov, &comp);
	if (err) {
		printk("Initializing mesh failed (err %d)\n", err);
		return;
	}

	printk("Mesh initialized\n");

	if (IS_ENABLED(CONFIG_BT_SETTINGS)) {
		printk("Loading stored settings\n");
		settings_load();
	}

	err = bt_mesh_provision(net_key, net_idx, flags, iv_index, addr,
				dev_key);
	if (err == -EALREADY) {
		printk("Using stored settings\n");
	} else if (err) {
		printk("Provisioning failed (err %d)\n", err);
		return;
	} else {
		printk("Provisioning completed\n");
		configure();
	}
}

Although not identical, our code is extremely similar to this one.
However, it's important to note that our code spreads over multiple source & header files, with the various parameters passed to the bt_mesh_provision being defined in sources other than main.c.

[jhedberg]

@MrPointer what value does your bt_mesh_provision() call return?

[jhedberg]

@MrPointer also, you earlier mentioned bt_mesh_comp_provision() - did you mean bt_mesh_provision() instead? If you're calling the stack-private bt_mesh_comp_provision() function that could explain some of the behavior you're seeing.

[MrPointer]

@jhedberg No no, I don't call the bt_mesh_comp_provision function, don't worry 😆
I mentioned it as a possible solution we've thought of, in case there's indeed a bug.

About the bt_mesh_provision function - On the first run after flashing the board i.e before any settings are persisted, the function exits successfully with error code 0.
On the 2nd run, after power-cycling i.e settings have been already persisted and loaded, it returns with error code EALREADY, which is exactly what we expect.

Maybe it's also worth mentioning that we test it on the nrf52840DK board.

[jhedberg]

@MrPointer are you sure your primary element's address is unassigned? There is no place in the mesh code that would return EADDRNOTAVAIL for that situation. That said, the publishing functions will return EADDRNOTAVAIL if you haven't configured a publishing address, or if there's no app key to use for publishing.

[MrPointer]

@jhedberg Actually I'm not sure about that, however, about the other thing you mentioned - It might possibly be the problem here, I'll need to do some checks.
Theoritically shouldn't the publication address be stored and restored?
Because I'm preety sure the App Key is persisted... I'm not wrong am I?

[jhedberg]

@MrPointer yes, both App Keys and Model Publication should be restored if previously set through the configuration model. Is that how you're configuring it? E.g. manually assigning an address to your publication context will not work since then the stack can't know that it needs to store something to flash.

[MrPointer]

@jhedberg Hmmm... That seems to be it - We're manually assigning the publication address, as part of the self configuration. Is there a way to use "restorable" publication contexts when self-configuring?

[jhedberg]

@MrPointer yes, by using the configuration client API. I.e. bt_mesh_cfg_mod_pub_set() from include/bluetooth/mesh/cfg_cli.h. The mesh_demo app already uses several configuration client APIs, so I'm surprised you didn't use it for model publication as well.

[MrPointer]

@jhedberg Sorry for the delay, have been busy with something else.
I think we misunderstood each other - When you said "manually", I thought you meant self-configuring.
That being said, we are using the bt_mesh_cfg_mod_pub_set function to configure the pub context.

Also, I've rerun our tests and the Node's address is indeed restored as expected. Publication address however, is not.