Issue sending payloads > 245 between esp32-c6

[hicklin]

Environment

This issue was observed while running the ble_l2cap examples on esp32-c3 and esp32-c6 devices.

Happy path

There are a few cases where the following issue is not observed. This might help identify what the issue might be.

esp32c6 <--> esp32c3

When running the bel_l2cap_central example on the esp32-c6 and the ble_l2cap_peripheral example on the esp32-c3, the example works. If the PAYLOAD_LEN is set to 500 or more, the example still works.

esp32c6 <--> esp32c6 with PAYLOAD_LEN < 246

When running both the bel_l2cap_central and example ble_l2cap_peripheral on two separate esp32-c6s the example works.

The issues

The following issues are observed when running both the bel_l2cap_central and example ble_l2cap_peripheral on two separate esp32-c6s.

PAYLOAD_LEN > 248

In this case, the ch1.send::<_, L2CAP_MTU>(&stack, &tx).await.unwrap(); fails with the error

====================== PANIC ======================
panicked at /home/whicklin/Documents/openRepos/trouble-dyson/examples/apps/src/ble_l2cap_central.rs:55:61:
called `Result::unwrap()` on an `Err` value: Controller(Unknown)

Backtrace:

0x420118c2
0x420118c2 - trouble_example_apps::ble_l2cap_central::run::{{closure}}::{{closure}}
    at ??:??
0x4200dfae
0x4200dfae - embassy_futures::join::MaybeDone<Fut>::poll
    at /home/whicklin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/embassy-futures-0.1.1/src/join.rs:24
0x4200b286
0x4200b286 - embassy_executor::raw::util::SyncUnsafeCell<T>::get
    at /home/whicklin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/embassy-executor-0.7.0/src/raw/util.rs:55
0x420150c8
0x420150c8 - main
    at /home/whicklin/Documents/openRepos/trouble-dyson/examples/esp32/src/bin/ble_l2cap_central.rs:14
0x420055e8
0x420055e8 - hal_main
    at /home/whicklin/.cargo/git/checkouts/esp-hal-42ec44e8c6943228/5d0145e/esp-hal/src/lib.rs:511

This error was tracked to the .write_acl_data call in AclSender::send method. This calls the AclPacket's write_hci method in the bt-hci-0.2.0/src/data.rs:202 which returns the error Full on the final line writer.write_all(self.data).

Possible cause

This may be caused by incorrect chunking of larger payloads when the L2CAP_MTU != 251. For the esp32-c3, the L2CAP_MTU == 251 while for the esp32-c6 this is set to 255. Hence, when the esp32-c6 and esp32-c3 are communicating, an L2CAP_MTU of 251 is negotiated, and the example works. However, when two esp32-c6s are communicating, an L2CAP_MTU of 255 is used. This may why it works when an esp32-c3 is involved.

248 >= PAYLOAD_LEN > 245

With payloads in this range, the following different error is observed.

====================== PANIC ======================
panicked at /home/whicklin/.cargo/git/checkouts/esp-hal-42ec44e8c6943228/5d0145e/esp-wifi/src/ble/mod.rs:70:18:
range end index 257 out of range for slice of length 256

Backtrace:

0x420187d8
0x420187d8 - core::slice::index::slice_end_index_len_fail::do_panic
    at /rustc/9fc6b43126469e3858e2fe86cafb4f0fd5068869/library/core/src/intrinsics/mod.rs:3535
0x42021fca
0x42021fca - <core::ops::range::Range<usize> as core::slice::index::SliceIndex<[T]>>::index_mut
    at /home/whicklin/.rustup/toolchains/1.84-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/index.rs:449
0x42007018
0x42007018 - esp_wifi::ble::controller::asynch::<impl bt_hci::transport::Transport for esp_wifi::ble::controller::BleConnector>::write::{{closure}}
    at /home/whicklin/.cargo/git/checkouts/esp-hal-42ec44e8c6943228/5d0145e/esp-wifi/src/ble/controller/mod.rs:218
0x42011ca2
0x42011ca2 - trouble_host::channel_manager::ChannelManager::send::{{closure}}
    at /home/whicklin/Documents/openRepos/trouble-dyson/host/src/channel_manager.rs:556
0x4200e000
0x4200e000 - embassy_futures::join::MaybeDone<Fut>::poll
    at /home/whicklin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/embassy-futures-0.1.1/src/join.rs:24
0x4200b286
0x4200b286 - embassy_executor::raw::util::SyncUnsafeCell<T>::get
    at /home/whicklin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/embassy-executor-0.7.0/src/raw/util.rs:55
0x420150ca
0x420150ca - main
    at /home/whicklin/Documents/openRepos/trouble-dyson/examples/esp32/src/bin/ble_l2cap_central.rs:14
0x420055e8
0x420055e8 - hal_main
    at /home/whicklin/.cargo/git/checkouts/esp-hal-42ec44e8c6943228/5d0145e/esp-hal/src/lib.rs:511

There seem to be issues in payload management for larger MTUs != 251.

[lure23]

When running both the ble_l2cap_central and example ble_l2cap_peripheral on two separate esp32-c6s the example works.

..and

The following issues are observed when running both the ble_l2cap_central and example ble_l2cap_peripheral on two separate esp32-c6s.

Am I missing something.. or you have a typo there? Both of these cannot be true.

[lure23]

@hicklin Are you aware of this esp-hal issue esp-rs/esp-hal#2984 ?

[hicklin]

Am I missing something.. or you have a typo there? Both of these cannot be true.

I have added some clarifications.

• The happy path only works for specific payload lengths.
• The issues have two section for two separate issues depending on the value of the payload len.

[lure23]

We didn't really touch the L2CAP side of things, making a workaround for the esp-hal issue I link to above. So what can be done is:

• extend a workaround to L2CAP
• wait until the solutions @bjoernQ suggests on that side are done

How much rush do you have? Is there a meaningful workaround you can do, on your end?

[bjoernQ]

wait until the solutions @bjoernQ suggests on that side are done

FYI: we will definitely make more things configurable on our side but it might not happen too soon since we are currently busy with a few higher prio tasks

[lulf]

@hicklin Could you provide the output of this log line for the different cases? https://github.com/embassy-rs/trouble/blob/main/host/src/host.rs#L863-L866

I'm wondering if this might be related to different max acl data size vs. l2cap mtu. The l2cap channel does not do fragmenting according to ACL max (https://github.com/embassy-rs/trouble/blob/main/host/src/channel_manager.rs#L592), which causes issues if ACL max is lower than l2cap mtu.

[hicklin]

For all of the mentioned payload ranges between two esp32-c6s, that log says the same thing.

INFO - [host] setting txq to 24, fragmenting at 255
INFO - [host] configuring host buffers (8 packets of size 255)