BLE over IPv6 between nrf52840 Dev kit and Rapberry 3 B+ border router : connection interface is removed after ~30 sec

[AKYR]

Hello everyone,

I'm running the IoT  CoAP example on my nrf52840 Development Kit. 

The border router is Rapberry 3 B+ on Jessie with Kernel version 4.19.46. I've put BLE_6LOWPAN_LEGACY_MODE to 0.

I've successfully connected the border router to the nrf52840 and pingued. 

My problem is that every time after approximately 30 seconds the bt0 interface goes down and the connection is lost. 

I guess it is some timeout or something that forces the interface to go down (BLE connection param : connection timeout ?) but I'm not sure how to fix it. 

I want to setup a permanent connection before trying to access the CoAP Server (nrf52840) with my CoAP Client (my computer). 

Here is the Segger log : 

<info> app: Application started.
<info> app: Physical layer in connectable mode.
<info> app: Physical layer: connected.
<info> app: Got IP Application Handler Event on interface 0x0x20004F9C
<info> app: New interface added!
<info> app: Sending Router Solicitation to all routers!
<info> app: Got IP Application Handler Event on interface 0x0x20004F9C
<info> app: Interface removed!
<info> app: Physical layer: disconnected.
<info> app: Physical layer in connectable mode.

Here is my raspberry script : 

#!/bin/sh

echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
sleep 1
service radvd restart
sleep 1
modprobe bluetooth_6lowpan
sleep 1
echo 1 > /sys/kernel/debug/bluetooth/6lowpan_enable
sleep 1
hciconfig hci0 reset
sleep 1
echo "connect 00:AA:BB:CC:DD:FF 1" > /sys/kernel/debug/bluetooth/6lowpan_control
sleep 1

I can ping the nrf52840 device with its global & local address and every time the same amount of pings resolve (seq = 36).

Finaly my question is : How to prevent the bt0 interface to go down ? 

Thanks in advance,

Regars,

Aloïs KYROU

[Edvin]

Hello,

Stian is out of office.

Is it possible to do a sniffer trace of the connection using the nRF Sniffer?

I am not sure whether Stian was talking about the nRF side or the Raspberry, but since the example is marked as experimental on infocenter, it may be the nRF. 

Can you please try to set a breakpoint in the BLE_GAP_EVT_DISCONNECTED event in on_ble_evt() in ipv5_medium_ble.c. What is the p_ble_evt->evt.gap_evt.params.disconnected.reason?

Let me know if you have difficulties setting up the sniffer. If you are able to capture a sniffer trace, can you send the .pcapng file?

[AKYR]

Hello, thaks for you answer ! 

Can't really use a sniffer now, eventually later.

I've looked into it and the p_ble_evt->evt.gap_evt.params.disconnected.reason value is 8 which is BLE_HCI_CONNECTION_TIMEOUT I think. 

Is it possible that the GATT/GAP layers are still waiting for request exchange while the 6LoWPAN stack is the one with data transfer ? Causing it to Timeout ? 

Is it easy to modify/request connection parameter modification as Slave in these examples (Or maybe as master in the RPi router seted-up following your doc) ? 

Note: I got disconnection even while pinging the device non-stop.

Thanks again :) 

[AKYR]

By the way do you know why we can't access the values of the disconnected (and others of the same type) struct in Segger ?

Had to add an access to the reason address in code to get the value. 

Thaks :) 

[Edvin]

Probably due to optimization. Try to turn it off:

Set it to "none".

Ok, so BLE_HCI_CONNECTION_TIMEOUT typically means that one of the events wasn't handled properly, and timed out.

Try to add the case BLE_GAP_EVT_DATA_LENGTH_UPDATE in on_ble_evt() in ipv6_medium_ble.c, and add the function on_data_length_update_evt() as it is in the ble_app_hrs example. Does that help?

[AKYR]

I've put a case for BLE_GAP_EVT_DATA_LENGTH_UPDATE in on_ble_evt() and a breakpoint inside and it never happens. 

Otherwise it is not direct to port on_data_length_update_evt() in the context of on_ble_evt() since we have no nrf_ble_gatt_t pointer. 

So I guess we are stuck until I use a sniffer ? 

[Edvin]

A sniffer trace would be useful. 

Do you use a DK or some custom board for your nRF? And does the disconnect always happen after e.g. 30 seconds, or is it a bit random?

If it is random, what are the LFCLK configurations you are using? The same as in the example, or did you change anything?

If it always takes the same amount of time, it is likely some event (on one side of the connection) that is not handled properly. A sniffer trace could help solve this. If it is not the BLE_GAP_EVT_DATA_LENGTH_UPDATE, it could be some other request that is not responded to.