bluetooth: can't send advertising data bigger than 32 bytes

[MatMaul]

Currently bleps pads advertising data with 0 up to 32 bytes, and have no logic for bigger packet (triggers an out of bounds error).

If I try to remove the padding for bigger packets, remove the padding altogether, or use 64/128 padding, the HCI command can't be sent to libbtdm blob (Error 18).
Only padded 32 bytes exactly seems to work (36 with the 4 bytes HCI header).

I failed to find such a padding in esp-idf or the HCI spec, and theorical max size of a PDU seems to be quite bigger.

I am probably failing to understand something here but I don't know what and I am a bit stuck so any help appreciated :)

[MatMaul]

bjoernQ/bleps#2 mentions 32 bytes as a limit, but it seems to work with esp-idf so I am unsure where is the limit exactly, and if I can cut the packets somehow.

[MatMaul]

I found this in esp-nimble that also seems to point at a limit, but I am having no trouble when doing that with esp32-nimble in Rust:

let device = esp32_nimble::BLEDevice::take();
let ble_advertising = device.get_advertising().name("I have a big big big name");
ble_advertising.service_data(
  esp32_nimble::utilities::BleUuid::Uuid16(SERVICE_UUID),
  bytes.as_slice(),
);
_ = ble_advertising.start();

With the size of the name and the data quite bigger than 32 bytes.
I can see the packet in Android app nRF Connect.

I am clearly missing something but I still don't know what.

[MatMaul]

RIGHT so I think I found my answer: if the size is too big esp32-nimble puts the name in scan_rsp_data instead of adv_data, cf here.

[MatMaul]

Anddd I also found what I need in the spec. I just added support for scan_rsp in bleps, it works, closing this and I will soon open a PR to bleps, sorry for the noise.