Mesh: 'Unexpected PDU' Error during Provisioning via GATT

[CSparn]

Describe the bug There occurs an "unexpected PDU error" when trying to connect the mesh_node_demo with a mesh app from an Android device. Like I understood the mesh node demo also provide the mesh proxy functionality, so I tried to connect with the proxy over an Android smartphone with different mesh apps("Bluetooth Mesh" by Silicon Labs and "Mesh" by Dialog Semiconductor). Both return an "unexpected PDU error" during connecting. Is this a bug or is the configuration of the proxy not correct?

To Reproduce Steps to reproduce the behavior:

1. Run example mesh_node_demo on linux or windows over Bluetooth dongle(port/windows_winusb or port/libusb)
2. Connect to the node demo with an android smartphone and a mesh app.
3. App will crash or show "unexpected PDU error"

Expected behavior I would expect that the app can connect to the proxy and the proxy would start provisioning the smartphone to other mesh nodes. Is this a wrong assumption?

HCI Packet Logs https://ufile.io/dzxgwrzq

Environment: (please complete the following information):

• Current BTstack branch: develop
• Bluetooth Controller [Asus BT400 USB]
• Remote device: [Samsung Galaxy]

[mringwal]

Thanks for reporting. The Mesh code is pretty much in a work-in-progress/alpha state. We did a major rewrite of the packet handling which can be found in 'mesh-message' branch. Feel free to try the same with that one.

What device did you try to provision indirectly? I've only use the different Mesh apps on iOS to test provisioning and basic models. We also tested provisioning in both roles via the Advertisement bearer. The proxy part also works as far as I know but I never tried to do use PB_ADV via a BTstack Proxy node.

The HCI Logs are not a good fit for the Advertisement bearer. However, in your log, I can see that the smartphone was only connected for 2 seconds. Is this where the 'unexpected pdu' happened? Does provisioning of the BTstack node works from the apps? That's what we've tested before and that should work.

[CSparn]

Hi, thanks for the tip, but I can't find the branch "mesh-message". I looked also in all branches. Where can I find it?

Maybe I explain what I want to achieve. I would like to build up a complete mesh network with some mesh nodes on raspberry pis, one proxy node on another machine (Windows or also any linux/ raspberry pi) and to connect an android smartphone to this network over the proxy. Then I would like to exchange messages between the smartphone and all mesh nodes.

Yes the smartphone tries to connect over the app to the mesh node and after 2 seconds the smartphone shows this error. What do you mean with " Does provisioning of the BTstack node works from the apps?" ? Greetings

[mringwal]

Sorry, I just saw that 'mesh-message' was only local. It's on github now. (it will be rebased occasionally, but you could check it out once).

When you start the mesh_node_demo, it is not provisioned. Then, you can use one of the smartphone Mesh apps to provision it via the GATT Bearer. I was asking if this step works, or not, as this did work in the past. Only after provisioning this BTstack Mesh Node, you would be able to provision other nodes via the ADV Bearer.

[CSparn]

Hi, I tested the "mesh-message" branch but I it does not change anything.

To your question. Sorry I didn't understand it before. But no the provisioning of the mesh node causes the error. It occurs in the authentication phase directly after exchanging the public keys. I attach the according output in a text file. output.txt

[mringwal]

Thanks for checking the mesh-message branch. As I said, provisioning via GATT did work in the past. We don't have much resources to continue work on Mesh currently, but I can check/fix the provisioning via GATT next week.

[CSparn]

OK sounds good. Thank you:) Was the provisioning via GATT maybe working in another branch?

[mringwal]

Well, I'm confident that it worked on the develop branch once in the past, but I cannot tell you when. I'm afraid you cannot do a quick bi-sect here, but going back e.g. month by month could work. Again, I should be able to look at the actual problem and also be able to just fix it - although I'm curious what broke it.

[mringwal]

Minor update: I've tried on iOS with nRF Mesh - Confirmation failed, and STM Mesh - it got stuck. In your original hci dump file, the Public key is sent twice - this could be the reason for the 'unexpected PDU' error (it did not expect the Public Key twice).

Which Mesh app did you use before? Could you try with nRF Mesh (that seems to work best resp. results in a clear error message).

[mringwal]

If you update the mesh-message branch and uncomment the #define ENABLE_SOFTWARE_AES128 in btstack_config.h of your port, provisioning via GATT works with nRF Mesh, but fails when getting the mesh composition data. (but it's a step closer...)

[mringwal]

I've implemented AES-CCM using Software AES128...

If you update the mesh-message - it was a force push -, provisioning via GATT works with nRF Mesh, but fails when getting the mesh composition data. (but it's a step closer...).

[CSparn]

Hi, thanks for the effort. I loaded the new version of the mesh-message branch and I tested it with 4 different android apps. Just one of it is working and can provision the proxy. The list of apps with their results:

1) nRF Mesh -> Shows me the unprovisioned node and when I click on it it it connects and gives me the offered services. But then there is no possiblity to provision it. There is just a identify button and this is doing nothing.

2) ST BLE Mesh -> Crashes while provisioning the proxy with no error message.

3) Bluetooth Mesh by Silicon Labs -> Provisioning stucks.

4) Mesh by Dialog Semiconductor -> Provisioning is working:) But it works just after typing in the right oob.

I think the problem with the 2. and 3. apps is that the provisioning with the oob is not possible.

Greetings

[mringwal]

The nRF Mesh is irritating as that one works for me. Could you share the pklg from nRF Mesh for comparison?

I would assume that the others also support OOB pairing - but you can modify the mesh-node-demo to use 'no authentication' (please check the .h file... or test/mesh/ .. as that contains a UI to configure any authentication mode)

[CSparn]

Ok I tested everything a bit more intensively with Windows(winusb) and Ubuntu(libusb). I got the following outcome:

Windows: nRF Mesh -> I see the device in unprovisioned devices and when I click add it connects and recieves the provisioning data of the proxy, but just name and app keys. From here the app shows no possibility to provision the proxy (maybe the proxy is not recognized as a proxy or the authentication method is not supported?) hci_dump.zip

Mesh by Dialog Semiconductor-> Provision of device is working. But proxy is disconnected directly after provisioning. hci_dump.zip

Ubuntu: nRF Mesh -> Same as for Windows Mesh by Dialog Semiconductor-> Provision of device is working. Fetching node composition data. But app has no possibilty to set proxy options or similar.

OOB pairing seems not to work for the other apps but I will try to use "no authentication" and provide further info.

Update: I disabled the oob output. Now the mesh app by silicon labs works. But after provisioning the actual proxy status is requested and the app crashes with the error code 254. I looked it up but couldn't find a definition. Here the dump if it helps: hci_dump.zip And the console output: console_output.txt

I also tested nRF Mesh on an IPad and I get a request timeout error when trying to recieve the proxy options after provisioning.