Possible BLE Link Layer issues with LL_CHANNEL_MAP_REQ?

[genedyne]

I'm trying to work on 'link robustness' between an android platform (Panasonic FZ-B2 tablet, Android 6), and an ESP32 BLE app. Everything currently works, but the link will periodically (no set time period for this) be lost. Sometimes the link is automatically re-established, sometimes it is not.

I've been sniffing the BLE radio traffic with an Adafruit (Nordic) USB dongle & wireshark. I know that packet capture is not reliable with this arrangement, but nevertheless, I've encountered some odd behaviour that _might_ help to explain my periodic loss of connection, so I'm posting my findings here - hopefully to get clarification and/or resolution.

The attached ZIP contains a wireshark packet log. It shows:
- a few advertising packets from the ESP32;
- a connection request from the Android tablet;
- several (repeated) 'LL_VERSION_IND' packets from the tablet to the ESP32 (not sure why these are repeated - clearly the tablet is not getting the response it expects, but it eventually gives up).
- pkt 48: the first 'value indication' from the ESP32 to the tablet (normally, this should be acknowledged by the tablet - in this case it's not, presumably because the tablet already has a channel map request in queue).
- pkt 49: the tablet sends LL_CHANNEL_MAP_REQ on channel 7. This packet is mal-formed.
- pkt 50: the tablet sends LL_CHANNEL_MAP_REQ on channel 17. Event counter is 34, instant is 40.
- pkt 51: the tablet sends LL_CHANNEL_MAP_REQ on channel 27. Event counter is 35, instant is 40.
- pkt 52: the tablet sends LL_CHANNEL_MAP_REQ on channel 0. Event counter is 36, instant is 40.
- pkt 53: the tablet sends LL_CHANNEL_MAP_REQ on channel 10. Event counter is 37, instant is 40.
- pkt 54: the tablet sends LL_CHANNEL_MAP_REQ on channel 20. Event counter is 38, instant is 40.
- pkt 55: the tablet sends LL_CHANNEL_MAP_REQ on channel 30. Event counter is 39, instant is 40.
- pkt 56: the tablet sends LL_CHANNEL_MAP_REQ on channel 13. Event counter is 41, instant is 40.

... etc. At this point, the 'instant' of the request is in the past, and according to the bluetooth spec (Core v5.0, Vol 6, Part B, section 5.5):

Code: Select all

When a slave receives such a PDU where (Instant – connEventCount ) modulo
65536 is greater than or equal to 32767 (because the instant is in the past), the
Link Layer of the slave shall consider the connection to be lost, shall exit the
Connection State and transition to the Standby State, and shall notify the Host
using the error code Instant Passed (0x28).

As I understand it, the ESP32 BLE Link Layer functions in the ESP-IDF are provided as libraries (i.e., no source), so I'm unable to investigate / confirm further, but it appears from this that the behaviour of the Link Layer is not compliant with the spec.

Please note that I HAVE also captured LL_CHANNEL_MAP_REQ exchanges that appear to operate as expected, so this 'failure to respond correctly' does NOT always occur.

For it's part, Android is expecting some acknowledgement/confirmation of the new channel map, and continues to send the request for 20 seconds (which is hard-coded in Android - a source of much frustration for developers) before giving up, at which point I see ESP32 advertisements begin again (at the end of the supplied wireshark trace). I believe this is trace is indicative of the 'periodic failure to communicate, which eventually recovers' scenario I mentioned at the start of this post.

Thanks,
R. Main.

[genedyne]

I have addressed some issues with my code (I was setting task priorities too high - they would have interfered with tasks internal to the bluetooth stack. I now limit my tasks to configMAX_PRIORITIES-10 (and below) to ensure the bluetooth stack can maintain real-time response).

However, I have captured numerous logs that clearly show the ESP-IDF Bluetooth stack is NOT responding as required by the Bluetooth Specification when a LL_CHANNEL_MAP_REQ is received with an instant that has already passed (i.e., the 'time-to-change' is in the past), as I pointed out in my earlier post.

Bluetooth spec (Core v5.0, Vol 6, Part B, section 5.5)

Code: Select all

When a slave receives such a PDU where (Instant – connEventCount ) modulo
65536 is greater than or equal to 32767 (because the instant is in the past), the
Link Layer of the slave shall consider the connection to be lost, shall exit the
Connection State and transition to the Standby State, and shall notify the Host
using the error code Instant Passed (0x28).

Android definitely has it's own bugs in this regard, (such as the first request sent already specifying an instant in the past), but that's no excuse for the ESP Bluetooth spec. to fail to meet the specification.

I have attached a second trace (PCAP log file, & text dump) that clearly shows the ESP Bluetooth stack Link Layer does NOT respond as the specification mandates. I believe it may simply ignore the LL_CHANNEL_MAP_REQ as invalid & continue to use the previous (now invalid?) map.

The Link Layer code responsible for this is not available. Can someone at Espressif please investigate & possibly fix this issue?

Thank you.