Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

ipv6_medium_ble.c -> on_ble_evt() does not implement BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST event which leads to LL request timeout with Linux 6lowpan module

Steps to reproduce:

1) Set up slave device

Device: nRF52832
SDK: v15.0.0
Soft Device: S132 v6.0
Examples: Any 6lowpan example (including ipv6_medium_ble)

Disable 6lowpan commissioning in the configuration (i.e. do not define COMMISSIONING_ENABLED)!

2) Set up master device

Device: any BT device with DLE
Linux Kernel: 4.15.0 with bluetooth_6lowpan module enabled

3) Use some BT sniffer and listen to the communication with the target device

4) Establish 6lowpan connection

#> echo 1 > /sys/kernel/debug/bluetooth/6lowpan_enable
#> echo "connect <peer address> 1" > /sys/kernel/debug/bluetooth/6lowpan_control

5) Observe DLE request

The linux device will emit a LL_LENGTH_REQ request due to the non-standard MTU of the 6lowpan connection.

Expected:

The example software should respond with a LL_LENGTH_RES packet.

Actual:

The example software never responds to the LL_LENGTH_REQ packet thereby causing an HCI LL response timeout error (0x22) on the linux device.

Suggested Fix:

Add the following in ipv6_medium_ble.c -> on_ble_evt():

case BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST:
{
ble_gap_data_length_params_t dl_params;

// Clearing the struct will effectively set members to @ref BLE_GAP_DATA_LENGTH_AUTO.
memset(&dl_params, 0, sizeof(ble_gap_data_length_params_t));
UNUSED_RETURN_VALUE(sd_ble_gap_data_length_update(p_ble_evt->evt.gap_evt.conn_handle, &dl_params, NULL));
break;
}

Related