Zephyr: HCI UART with Linux host cannot connect to nrf52 6lowpan peripheral

[glbsalazar]

When using a setup with one nrf52832 dev kit flashed as HCI UART device with a baudrate of 115200 attached to a Linux host running the 4.4.5 kernel and BlueZ tools version 5.47, it is not possible to connect to a nrf52840 dev kit running the ICMP example present in the Nordic SDK 15.

Steps to reproduce:

• Flash everything with the versions described above:

  • Linux Host with kernel 4.4.5 and BlueZ tools 5.47
  • nrf52832 dev kit with HCI UART Zephyr sample with 115200 baudrate
  • nrf52840 dev kit with Nordic SDK 15 ICMP example

• Start bluetoothd with the experimental flag
  /usr/libexec/bluetooth/bluetoothd --experimental

• Attach to the bluetooth controller using btattach
  btattach -B /dev/ttyXXX -S 115200 -P h4 --noflowctl

• Launch bluetoothctl and scan for the device using the following commands:
  bluetoothctl -> to drop into the bluetoothctl prompt
  [bluetooth]# power on
[bluetooth]# default-agent
[bluetooth]# set-scan-filter-transport le
[bluetooth]# scan on
  The device with name IPv6ICMP should be detected

• Ensure the bluetooth_6lowpan module is loaded (if not autoloaded use modprobe bluetooth_6lowpan) and enable the module and connect to the device:
  echo 1 > /sys/kernel/debug/bluetooth/6lowpan_enable
echo "connect 00:CB:DD:EA:E9:B7 1" > /sys/kernel/debug/bluetooth/6lowpan_control

• The connection is not possible, please check the attached btmon logs. btmon_log_29_05_18.log

• The nrf52840 logs present a checksum error as can be seen in the logs below:

app: Physical layer connected.
app: Got IP Application Handler Event on interface 0x20003D78
app: New interface added!
icmp6: Bad checksum detected. Got 0x00002301 but expected 0x0000FDFF, 0x00000020
app: Got ICMP6 Application Handler Event on interface 0x20003D78
app: ERROR 49473 [Unknown error code] at ../../../main.c:590
PC at: 0x0002F07B
app: End of error report

From my analysis of both logs it seems that the connection is established but something goes wrong in the communication to establish the IPv6 connection.

Thank you

[carlescufi]

@Vudentz regardless of the connection errors, is kernel 4.4.5 free of the infamous 6lopan bug?

[mike-scott]

@carlescufi @Vudentz there were 2 memory corruption bugs in bluetooth/6lowpan which were fixed around the 4.12 cycle:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=d2891c4d071d807f01cc911dc42a68f4568d65cf
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=6dea44f5acc3d63fbaa992146e92252329d9a2be

These were causing the gateway to randomly crash after a period of time.

NOTE: These may not have been present in the 4.4 kernel.

[carlescufi]

@GSlzr would it be possible for you to test with a more recent kernel, such as 4.15 or so? Just to rule out the kernel issues that @mike-scott mentions.

[glbsalazar]

@carlescufi due to the setup I'm using I can't really test this with a more recent kernel, I'm using an embedded platform and cannot update the kernel at this time.

[carlescufi]

@GSlzr since there are several known bugs in that kernel version, would it be possible for you to test the same setup on a desktop computer running a recent kernel?

[glbsalazar]

@carlescufi I will try to perform that test.
However I already managed to test 2 other things:

• One PC with kernel 4.4.0 with an integrated BLE controller, it worked without any problems
• One Raspberry Pi 3 with kernel 4.14.34 with an integrated BLE controller and it also worked perfectly

I also tested the same PC with the 4.4.0 kernel with the nrf52832 dev kit attached and it did not work.

[Vudentz]

@GSlzr 4.12 is recommended for Linux, that said the problem with earlier kernel was that the link-local address was wrong so it would only matter if that is used, well besides the bugs @mike-scott mentioned.

[glbsalazar]

@Vudentz I managed to test this with kernel 4.14.34, I followed the steps in this guide https://devzone.nordicsemi.com/b/blog/posts/nrf5x-support-within-the-zephyr-project-rtos by @carlescufi.

I manage to connect correctly and the interface comes up in ifconfig, however I cannot ping the device to which I just connect and when I try to do it the other way around, the device pinging the central I get no response even though the request is received (I see it in tcpdump)

The error I get is always:
Destination unreachable: Address unreachable

[glbsalazar]

When performing a ping from the dev kit to the central device, I managed to capture the output with tcpdump to see it in wireshark, conclusion the ping packets all have a bad checksum.
I attached the file if you want to take a look: bt0_1.pcap.zip

[Vudentz]

@GSlzr what address are you trying to ping? Perhaps the addresses don't match due to uid format, but with such new kernel that was supposed to work, or perhaps it drops because of checksum error? Btw, some distros such as Fedora appear to turn on USB autosuspend which apparently can cause transmission problems depending on the manufacturer, in that case I would sugget turning it off.

[glbsalazar]

@Vudentz I tried to ping all addresses ff02::1 and the ICMP example also allows me to ping the central device (I checked with wireshark and the IP matches the correct one).

With the new kernel the connection no longer drops.

[glbsalazar]

@Vudentz @carlescufi, I managed to do some more tests, I setup a PC with ubuntu 18.04, therefore kernel 4.15 and bluez tools 5.48. With the PC's internal bluetooth module, I can connect and ping the nrf52840 dev kit although I always get Bad Checksum on the kit application, when pinging in the other direction I have the exact same error, the ping packets have a bad checksum.

When using the nrf52832 as a bluetooth module I am able to connect to the dev kit but I cannot ping in any direction.

[glbsalazar]

@Vudentz and @carlescufi I figured out where the problem lies but I am not sure on where to keep looking.
Currently I can detect and connect with every device, however when using the nrf52832 as an HCI UART the nrf52840 dev kit with the NRF SDK ICMP example flashed believes that the device that it is connecting to has a PUBLIC_ADDRESS when in reality it is a RANDOM_ADDRESS one.
Since the version I am using still has the FLIP_BIT configuration (even though it is not part of the RFC anymore) I no longer have the correct address to communicate with. The Linux host however determines correctly that it has a RANDOM_ADDRESS
Do you know where in the address type is determined in the NRF SDK? Is it sent by the zephyr stack to the other device?
Thank you

[glbsalazar]

I realized that this occurred due to a mismatch in the nrf52 configuration. The nrf SDK supports "legacy" 6lowpan over BLE and that was set and should have not been set.

Thank you for the help

[j-shirazi]

I realized that this occurred due to a mismatch in the nrf52 configuration. The nrf SDK supports "legacy" 6lowpan over BLE and that was set and should have not been set.

Thank you for the help

Thanks to you. My problem solved due to your notice.
In "sdk_config.h" I changed "BLE_6LOWPAN_LEGACY_MODE 1" to "BLE_6LOWPAN_LEGACY_MODE 0" and problem solved.