Description
Describe the bug
Trying to connect two BLE devices using the "Central" application on the "samples/bluetooth" directory. I have only commented out the "bt_conn_disconnect" call inside the connected callback just to keep the connection alive.
The Central application runs on an ESP32-WROOM-32E chip and the other LE device is a beacon kind. The connection between the two devices has many instabilities. Sometimes the connection doesn't happen, other times it takes a few seconds to establish and, the majority of the times the connection is established but it automatically disconnects after a few seconds (reason 0x08).
I have a RF sniffer where I can see the data exchanged between the two devices. I can see that, after connection, sometimes there are a lot of MTU exchange packets. Like if the peers don't recognize the packet sent by the other end. I can also see a lot of L2CAP fragment packets with 135 bytes size in between these packet exchanges. I have the Wireshark log of the RF sniffer capture, but github doesn't allow me to upload it. But you can see screenshot of that capture below under the Logs and Console Output.
I also tried to adjust the interval (min and max), latency, and supervision timeout to match the ones on the beacon, but it didn't help. What could be causing this issue? A similar application running on Arduino framework works without any problem. So, it doesn't seem to be related to the beacon or to the ESP32 hardware.
Executing the same tests on older versions revealed that this issue was not present in version 3.7.0, but it was starting on 4.0.0 and forward.
To Reproduce
- Modify "Central" application to comment out the intentional disconnect call inside the connected callback.
- Build the application:
west build -b esp32_devkitc_wroom/esp32/procpu . - Flash the application on the ESP32:
west flash
Expected behavior
I expected to see connections between the two BLE being established and mantained without drops. The beacon was really close to the ESP32, optimal RSSI and no other BLE devices near by.
Impact
I had to stop using the latest version of Zephyr (v4.x).
Logs and console output
Capture from Wireshark using a RF sniffer:
Console output from the ESP32:
Device found: D3:C6:D4:C4:B9:24 (public) (RSSI -11)
Connected: D3:C6:D4:C4:B9:24 (public)
Disconnected: D3:C6:D4:C4:B9:24 (public), reason 0x08
Scanning successfully started
Device found: D3:C6:D4:C4:B9:24 (public) (RSSI -11)
Connected: D3:C6:D4:C4:B9:24 (public)
Disconnected: D3:C6:D4:C4:B9:24 (public), reason 0x3e
Scanning successfully started
Device found: D3:C6:D4:C4:B9:24 (public) (RSSI -12)
Connected: D3:C6:D4:C4:B9:24 (public)
Disconnected: D3:C6:D4:C4:B9:24 (public), reason 0x3e
Scanning successfully started
Device found: D3:C6:D4:C4:B9:24 (public) (RSSI -12)
Connected: D3:C6:D4:C4:B9:24 (public)
Disconnected: D3:C6:D4:C4:B9:24 (public), reason 0x08
Scanning successfully started
Device found: D3:C6:D4:C4:B9:24 (public) (RSSI -11)
Connected: D3:C6:D4:C4:B9:24 (public)
Disconnected: D3:C6:D4:C4:B9:24 (public), reason 0x08
Scanning successfully started
Environment (please complete the following information):
- OS: Kde Neon 22.04
- SDK 0.17.0
- Zephyr main branch. Also tried on version 4.1.0 and 4.0.0, and the issue was already there on these versions.