IPv6 over BLE: IPSP sample crashes and ble controller gets disconnected

[priyankaNXP]

Issue with testing IPv6 over BLE (IPSP sample):

Once the BLE connection is established, within few seconds BLE controller gets disconnected.
Either zephyr (recent master branch) crashes or BLE controller crashes or both. Often it is BLE controller that gets disconnected within few seconds.
Restarting zephyr might enable establishing the connection once again, but then ble controller goes down immediately.
After that, I should disconnect the boards and connect again (via usb connection) in order to set up the ble connection again.

While on Zephyr side, it always prints connection handle 32
On Linux side, the first time connection handle is 32, afterwards it is different (handle 65, 96, 128 etc.,) as shown with "hcitool conn".
btmon log shows for specific handle : remote user terminated connection or connection terminated by local host.

When the ble connection is established, during that very short span of connection, ping does not pass, there is a ping time out and then ble controller goes down.
And it prints error on zephyr side
[bt] [ERR] read_payload: Not enough space in buffer

Test set up for IPv6 over BLE :

[Kw41z (ble controller)+ k64f (zephyr IPSP)] <---------->[Kw41z (ble controller)+Linux host]

• At one end : Two boards frdm-kw41z and frdm-k64f are stacked together.
  kw41z (flashed with hci_blackbox firmware) is ble controller with k64f as ble host (flashed with zephyr sample IPSP).

$ sudo minicom -s -D /dev/ttyACMx -b 115200

[bt] [WRN] set_flow_control: Controller to host flow control not supported
[bt] [INF] show_dev_info: Identity: 00:04:9f:00:00:15 (public)
[bt] [INF] show_dev_info: HCI: version 4.2 (0x08) revision 0x000b, manufacturer 0x0025
[bt] [INF] show_dev_info: LMP: version 4.2 (0x08) subver 0x0121
[ipsp] [INF] init_app: Run IPSP sample
[ipsp] [INF] listen: Starting to wait

• At the other end: Second kw41z (flashed with hci_blackbox firmware) is ble controller attached to Linux host.

$ sudo hciattach ttyACMy any 115200 noflow sleep (in Linux terminal)

$ sudo hcitool lescan
$ sudo hcitool conn
$ sudo hcitool lecc 00:04:9f:00:00:15

$ sudo btmon (in Linux terminal)

• conf optons addition to prj.conf

CONFIG_NET_L2_ETHERNET=n
CONFIG_ETH_MCUX=n
CONFIG_ETH_MCUX_0=n

#CONFIG_BT_DEBUG_HCI_DRIVER=y
#CONFIG_BT_DEBUG_HCI_CORE=y

CONFIG_BT_PRIVACY=n
#CONFIG_BT_DEBUG=y
#CONFIG_BT_DEBUG_HCI_CORE=n
CONFIG_BT_DEBUG_CONN=y
CONFIG_BT_DEBUG_KEYS=y
CONFIG_BT_DEBUG_L2CAP=y
CONFIG_BT_DEBUG_SMP=y
CONFIG_BT_DEBUG_SDP=y

[priyankaNXP]

The issue gets resolved by disabling some debug options. Though unstable behavior still.
Once bt0 interface goes down due to some reason e.g., for a bigger ping packet, there are SDU length mismatch or/and unknown H:4 type at the Zephyr end.
In that case, simple restarting zephyr and/or reseting ble controller does not get connection up. It requires disconnecting everything and connecting again to make it work.

[bt] [ERR] h4_get_type: Unknown H:4 type 0x05
[bt] [ERR] h4_get_type: Unknown H:4 type 0x71
[bt] [ERR] l2cap_chan_le_recv_sdu: SDU length mismatch

[Vudentz]

[bt] [WRN] set_flow_control: Controller to host flow control not supported

It is already a bad start if there is no host flow control as that means the controller may push data when there are no buffer available.

[bt] [ERR] h4_get_type: Unknown H:4 type 0x05
[bt] [ERR] h4_get_type: Unknown H:4 type 0x71
[bt] [ERR] l2cap_chan_le_recv_sdu: SDU length mismatch

It looks like the data got corrupted at UART level which might be the packets for L2CAP that then fails with SDU length.

[carlescufi]

@priyankaNXP this has been open for a while and there's no certainty that Zephyr is at fault here. Closing this, please open a new issue if you reproduce this and find it to be an issue with Zephyr's BLE stack.