Bad-PDU when Provisioning add

[svhoy]

Hi,

I am trying to provision an new device with gateway.py prov --uuid <uuid> add . But this fails after a few seconds with error: bad-pdu. If If I am looking in my log Files I can see this:

mesh/pb-adv.c:send_adv_segs() Sending 1 fragments for 2 octets
mesh/pb-adv.c:send_adv_segs() max_seg: 00
mesh/pb-adv.c:send_adv_segs() size: 02, CRC: e6
mesh/pb-adv.c:pb_adv_packet() PB-ADV start with 0 fragments, 2 octets
mesh/prov-initiator.c:int_prov_rx() Provisioning packet received type: 09 (2 octets)
Expected 08, Got:09

The Device I am trying to connect with told me that:

bt_mesh_prov: Unexpected msg 0x09 != 0x07

So it seems for me there is something work with the config and the exchange the wrong msg. Do somebody know how I can fix this? Thanks for your help.

[dominikberse]

Not sure about this one. It looks like the error occurs at the BlueZ layer. If that is the case, then I think there is little I can do about it.

I would recommend that you try to provision the device using meshctl and see if that works. If you have the same problem there, then it's either a problem with BlueZ or you device.

[svhoy]

I tested it with meshctl, there I can provision my device. So both devices might be connectable.

Which release from bluez you running? Maybe my Version (5.65) isn't not compatible.

[dominikberse]

Okay, that is interesting. Not sure what is different when using meshctl.

I just had a quick look, the error message is coming from here: https://github.com/bluez/bluez/blob/1270afa5aa1cfa19927c3bce1b8f84dbe9f35a2f/mesh/prov-initiator.c#L646

The docker container currently uses version 5.66. Did you run the script locally or from the docker image?

[svhoy]

The difference is the provisioning method. meshctl use PD-GATT and mesh-cfgclient PD-ADV, so I think your program should use PD-ADV as well.

I run bluez locally on my raspberry. I am not that much into Docker I have to say.

[dominikberse]

I see. So can you provision with mesh-cfgclient then?

I must admit, my knowledge of the bluetooth mesh stack is quite limited. Given that this gateway is build upon a python library that is build upon BlueZ, I doubt that I can change the provisioning method. I followed the call stack and if I am not mistaken the provisioning process calls ManagmentInterface.add_node which I assume calls BlueZ's add_node_call. Inside that function initiator_start is called like this:

...
initiator_start(PB_ADV, uuid, 99, 60, add_pending->agent, add_start, add_data_get, add_cmplt, node, add_pending);
...

So it seems to me that PB_ADV is hardcoded as transport type. (PB_ADV and initiator_start are defined in provision.h.)

Nonetheless, if your device does support provisioning via PD-ADV, I did update the underlying library in the feature/improve-stability branch, maybe you can give that a try.

[svhoy]

Hey,

I had so other problems with mesh-cfgclient and the UUID. After resolve this I tired it a few times and on differnt platforms, I got always a bad-pdu with mesh-cfgclient. So it really seems that it is not a probleme with the python part, but rather a problem with bluez itself.

I opend for that a stackoverflow thread and hopfully can add a solution here when some helped me there.

But thank you for your help until now.