Stack overflow when provisioning mesh nodes

RE: Stack overflow when provisioning mesh nodes

Elfving — Fri, 28 Feb 2025 09:27:16 GMT

Quick update on this:

We had another case in which this was tried on a default sample, and increasing the stack size (CONFIG_BT_MESH_ADV_STACK_SIZE) to 1024 helped there. Though in your case I still think it would pay off to not go for an embedded provisioner, and not to base something too much on this sample if you want to create an embedded gateway provisioner.

Regards,

Elfving

RE: Stack overflow when provisioning mesh nodes

Elfving — Tue, 18 Feb 2025 12:20:53 GMT

I don't think the default sniffer supports this, but we have applications that do.

RE: Stack overflow when provisioning mesh nodes

susenka — Tue, 18 Feb 2025 11:32:24 GMT

I have done some digging around and I assume that the smart device manufacturer requires some sort of message to be sent after provisioning to let the device know that it has successfully registered with the manufacturer's application. My question is - can I somehow capture the mesh traffic between the provisioner and the device using Wireshark or some such tool? I have a nrf dongle at hand that I can use. Can I decrypt the traffic given that I know the appkeys and device keys used to encrypt it? If so, can you give me a little hint on how to accomplish this? Thanks.

Regards,

Viktor

RE: Stack overflow when provisioning mesh nodes

Elfving — Tue, 18 Feb 2025 08:50:52 GMT

[quote user="susenka"]Is it possible that the device manufacturer has some mechanism that prevents provisioning when not using their application or sdk?[/quote]

I guess that is possible. I don't think we do this on our app, but when SoC manufacturers provide apps like this for free I suppose that is one way they can make sure that they end up making money in the end. What Nordic typically does is just to provide high quality, and assume that people will end up going for their products in the end.

I am not sure about what other products for taking care of a large mesh network are available in the market, but I would recommend contacting your local RSM about this. They might know something.

[quote user="susenka"]But all models (except configuration) are unresponsive[/quote]

If this happens with other SoCs than nordic, ie. Telink chips, then it is ofcourse easy to think it is their BLE stack that is at fault, though this generally shouldn't happen.

Regards,

Elfving

RE: Stack overflow when provisioning mesh nodes

susenka — Sun, 16 Feb 2025 10:12:48 GMT

I know that nrf mesh is for development only, so I would eventually write my own application to handle the provisioning. The thing is, I have tried many applications like nrf mesh and all of them failed in the same way. Is it possible that the device manufacturer has some mechanism that prevents provisioning when not using their application or sdk? Just to note the current state - with the application im able to

1) set app & dev keys
2) get composition data
3) bind app key to all models

But all models (except configuration) are unresponsive - so I cannot turn the lights on/off for example. After 30 seconds the device disconnects - maybe there is some kind of properitery check or something that prevents the device from working with provisioner that follows the generic spec?

If this is beyond the scope of this forum or you cannot help me with this, no worries! Thanks.

Regards,
Viktor

RE: Stack overflow when provisioning mesh nodes

Elfving — Fri, 14 Feb 2025 12:04:09 GMT

I just recalled that I had a previous case in which some provisioner sample, either our old one or this one from zephyr, used the assumption that each node had just one element. If that is not the case then of course addressing will run into an issue. Maybe something similar is happening here as well.

[quote user="susenka"]I need to be able to provision about a thousand lights in our building. [/quote]

Ah I see. The provisioner is an extremely important and powerful role for the network, so I would generally recommend a host device similar to a smart phone (or multiple) for this. I guess there are scenarios in which using an embedded device is warranted, like if you need to work on the network over LTE and need a gateway, like you mention. Though in that case I would make this from scratch and not base it too much on the provisioning samples (as they are not that great as a starting point for this), and add external flash for all the data that needs to be stored.

Our nRF Mesh app is mainly a development tool, not an end-customer product. So I wouldn't use that for a proper network like this either. Though if your goal is to make a tool that does this job then we do have libraries for android and ios that you can use.

But if you want something that just works for this network, I am not sure if we can provide what you want. I bet there are tools in the market that allready have this gateway functionality.

Regards,

Elfving

RE: Stack overflow when provisioning mesh nodes

susenka — Thu, 13 Feb 2025 22:01:09 GMT

[quote userid="103347" url="~/f/nordic-q-a/118777/stack-overflow-when-provisioning-mesh-nodes/522859"]Could you try increasing CONFIG_BT_RX_STACK_SIZE as well?[/quote]

This does not seem to have made any difference - still same issue.

[quote userid="103347" url="~/f/nordic-q-a/118777/stack-overflow-when-provisioning-mesh-nodes/522859"]

I should mention that you typically do not use an embedded device as a provisoner in a typical setting, since that role is so important to the network, which I believe is why nordic does not provide a sample for this in NCS. Though we do have an open-source smart-phone application for it. I see that we did have a sample for this in the old nRF5 SDK which mentions this in the documentation: "Because of the limited amount of memory available in embedded processors, using a standalone provisioner limits the amount of nodes that can be provisioned. This limit corresponds to the maximum size of the Bluetooth mesh network." I guess for the same reason this zephyr provisioner might be a bit limited. Of course an attempted provisioning shouldn't result in a stack overflow, but I just wanted that mentioned.

So if your end goal is just to provision this chip I think the smart-phone app is the best option.

[/quote]

Okay, can you suggest the best approach for my use case? I need to be able to provision about a thousand lights in our building. As you said, this can and probably should be done using a mobile device. The tricky part is that I also need to be able to control the lights over the internet - so I thought that many of these embedded devices will act as a sort of "mesh to internet gateways". Is there a better way to approach this?

Kind regards,

Viktor

RE: Stack overflow when provisioning mesh nodes

Elfving — Thu, 13 Feb 2025 12:58:49 GMT

[quote user="susenka"]

I cannot flash anything on the telink chip since it is already consumer packaged in the light itself. it does seem to provide a uart interface that i can i theory use, but i would like to avoid the need to modify the firmware on the light itself.

[/quote]

Hehe that is understandable. I just assumed it was some sort of development kit.

[quote user="susenka"]However, I can get basic configuration data using the nrf mesh application, which I cannot do using the development kit because the provisioning process never advances to the configuration data retrieval stage.
[/quote]

Ah, so that works. That is interesting.

Could you try increasing CONFIG_BT_RX_STACK_SIZE as well?

So if your end goal is just to provision this chip I think the smart-phone app is the best option.

Regards,

Elfving

RE: Stack overflow when provisioning mesh nodes

susenka — Wed, 12 Feb 2025 09:49:47 GMT

[quote userid="103347" url="~/f/nordic-q-a/118777/stack-overflow-when-provisioning-mesh-nodes/522590"]You could check if you able to provision the telink chip from the nRF Mesh app.[/quote]

I have looked at the problem you linked to, and it seems to have some similarities. Im seemingly able to provision the light using the nrf connect app, but theres a catch. According to the manual of the light im trying to provision, there is a 30 second so-called configuration phase. If the device is not configured in this time window, the device will flash several times and then become unresponsive.

However, I can get basic configuration data using the nrf mesh application, which I cannot do using the development kit because the provisioning process never advances to the configuration data retrieval stage.

[quote userid="103347" url="~/f/nordic-q-a/118777/stack-overflow-when-provisioning-mesh-nodes/522590"]Are you seeing the same issue with other samples running on the telink chip? If you are able to flash other sw on that.[/quote]

Regards,

Viktor

RE: Stack overflow when provisioning mesh nodes

Elfving — Wed, 12 Feb 2025 08:56:54 GMT

[quote user="susenka"]

Sorry, I've actually forgot to mention that I'm provisioning a non nRF device a light to be exact, that uses telink chip. According to the manual, the light implements full bluetooth mesh spec. I assumed, that I can utilize the DK from nordic to provision and communicate with bluetooth chips for other brands, but correct me if I'am wrong. Thanks

[/quote]

Yeah that shouldn't be a problem , given that the telink chip follows the spec, which I assume it does. Though I have seen some issues like this in the past. You could check if you able to provision the telink chip from the nRF Mesh app.

Are you seeing the same issue with other samples running on the telink chip? If you are able to flash other sw on that.

Regards,

Elfving

RE: Stack overflow when provisioning mesh nodes

susenka — Tue, 11 Feb 2025 10:13:49 GMT

I'm using the 2.9 tag SDK, by latest I meant the latest installable version through vscode.

Regards,

Viktor

RE: Stack overflow when provisioning mesh nodes

Elfving — Tue, 11 Feb 2025 08:45:23 GMT

Ah you are right, sorry about that. I am not familiar with all the samples that comes directly from zephyr, like this one. I assumed it worked a bit like the mesh shell.

When you say you are using the latest SDK and toolchain, you mean 2.9? Just want to make sure you're not using the main branch.

What are you provisioning? Do you see the same thing when trying to provision a default sample?

Regards,

Elfving

RE: Stack overflow when provisioning mesh nodes

susenka — Mon, 10 Feb 2025 13:56:03 GMT

I think there is some miscommunication, I am having problem with the provisioner while provisioning other devices. The sample I am flashing should serve as a provisoner for other devices or?

RE: Stack overflow when provisioning mesh nodes

Elfving — Mon, 10 Feb 2025 13:44:44 GMT

And could you show me what you are writing to provision it?

RE: Stack overflow when provisioning mesh nodes

susenka — Mon, 10 Feb 2025 13:24:30 GMT

Hello Elfving,

I am flashing the application using vscode and nrf connect toolchain as explained in the official video series.

https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/bluetooth/mesh_provisioner - this is the sample i am using.

I tried setting the options as such, but the program is ending in same kernel panic error.

CONFIG_MAIN_STACK_SIZE=4096
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096

Regards,

Viktor

RE: Stack overflow when provisioning mesh nodes

Elfving — Mon, 10 Feb 2025 10:10:31 GMT

Hi Viktor,

[quote user=""]I have recently purchased an nRF52 development kit which I would like to use for my project. Currenty, I would like to provision external devices using this board, howerer, I cant seem to succeed in getting the provisioning process to work with the default unmodified example from nrf5 connect sdk.[/quote]

I assume you are then doing something on the cli that makes this happen. Could you show me what?

What sample is this?

Does increasing the stack size help? Eg.

CONFIG_MAIN_STACK_SIZE

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE

Regards,

Elfving