6lowpan Support for Raspberry PI 3B+ - CYW43455

6lowpan Support for Raspberry PI 3B+ - CYW43455

[Achim Kraus]

Dear list,

spending some time in evaluating the current state of the 6lowpan
support for Raspberry PIs in order to use it together with
Eclipse/Californium CoAP/DTLS (I'm a committer in that project),
I found a lot using an external modules.
But I'm wondering, if there is any native support for a Raspberry PI 3B+
with a  CYW43455.

According articles as:

https://www.linux-magazine.com/Issues/2018/212/Raspberry-Pi-3-B/(offset)/3/(tagID)/383

"Bluetooth 4.2 takes this to a whole new level: The IPSP-supported
6LoWPAN (Internet Protocol Support Profile/IPv6 over low-power wireless
personal area networks) takes IPv6 to small, low-performance devices for
integration into the Internet of Things."

it seems to be possible for the hardware, but I could not find hints,
that it is working with the software. According

https://linux-wpan.org/hardware

it's not listed, but the nrf52840 is also not listed (but working with
the openthread setup from nordic).

So:
Does someone have tried to use a Raspberry PI 3B+ native CYW43455 for
6lowpan?

best regards
Achim Kraus

Re: 6lowpan Support for Raspberry PI 3B+ - CYW43455

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 977 bytes --]


Achim Kraus <achimkraus@gmx.net> wrote:
    > it seems to be possible for the hardware, but I could not find hints,
    > that it is working with the software. According

    > https://linux-wpan.org/hardware

    > it's not listed, but the nrf52840 is also not listed (but working with
    > the openthread setup from nordic).

    > So:
    > Does someone have tried to use a Raspberry PI 3B+ native CYW43455 for
    > 6lowpan?

I don't think anyone has done RFC7668
  _IPv6 over BLUETOOTH(R) Low Energy_

for any BT device.  I would love to be wrong!!

Running BTLE mesh is something I'd really like to do.
My guess is that one could probably prototype this in userspace on top of
bluez, and then use Alex' 6lowpan tap interface.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: 6lowpan Support for Raspberry PI 3B+ - CYW43455

[Alexander Aring]

Hi,

On Tue, 15 Sep 2020 at 16:35, Michael Richardson <mcr@sandelman.ca> wrote:
>
>
> Achim Kraus <achimkraus@gmx.net> wrote:
>     > it seems to be possible for the hardware, but I could not find hints,
>     > that it is working with the software. According
>
>     > https://linux-wpan.org/hardware
>
>     > it's not listed, but the nrf52840 is also not listed (but working with
>     > the openthread setup from nordic).
>
>     > So:
>     > Does someone have tried to use a Raspberry PI 3B+ native CYW43455 for
>     > 6lowpan?
>
> I don't think anyone has done RFC7668
>   _IPv6 over BLUETOOTH(R) Low Energy_
>

I tried to use BT 6LoWPAN and experienced a lot of races there, sadly
nobody is fixing it. I sent a RFC some years ago to tackle these
issues, also that the link-layer address is reconstructed by L3
address and not by a ndisc lookup is very weird. I don't know if this
is fixed or not.  However it was nothing related to the new BT mesh
stuff.

> for any BT device.  I would love to be wrong!!
>
> Running BTLE mesh is something I'd really like to do.
> My guess is that one could probably prototype this in userspace on top of
> bluez, and then use Alex' 6lowpan tap interface.

I did not do the "6lowpan tap" interface, the bluetooth people did
that and I complained about it and I never would accept this upstream.
It basically was working to "map" bluetooth link-layer addresses to an
ethernet interface (remember in Linux world TAP is an ethernet
specific interface only). Then the code was somewhat doing parsing the
ethernet link-layer addresses to feed the bt 6lowpan decompression
algorithm.
This might work until there is any draft which wants more than just
link-layer addresses from L2 header, I think you would agree here?
There are also corner cases that a bluetooth address is not an
ethernet address...

I am not against a "tap like" interface, but then the whole L2 header
needs to feed to a, I name it "generic tap" interface from userspace
(only describe receiving side, it's easier).

I _think_ we also need to have not just L2 headers... all layers below
6LoWPAN adaptation because the compression can use _any_ of this
information. You agree?

However, basically when people talk about TAP/TUN 6lowpan interfaces
my thoughts are:

6LoWPAN TAP:

Ethernet specific, need to be a generic TAP interface to feed all
layers below 6lowpan to kernel space/from kernel space. Ideal would be
that the kernel 6lowpan stack creates/receives all layers below
6lowpan... but then such interface makes no sense because it will
require a kernel stack for all these layers and you want to run these
in user space.
I think about an own header format which describes "6lowpan parameters
for everything to do in layers 6lowpan and above". Each is adaptation
specific, I would like to see a draft about that! It's not the full
info of all layers below, only the one what the upper-layer (6lowpan,
etc) needs.

That is for me the only thing that makes sense for me...

6LoWPAN TUN:

That wording makes no sense, TUN is RAW IPv6, there can't be RAW
6LoWPAN without having information below that, see 6LoWPAN TAP.

- Alex

Re: 6lowpan Support for Raspberry PI 3B+ - CYW43455

[Achim Kraus]

Hi Alex,

> I tried to use BT 6LoWPAN and experienced a lot of races there, sadly
> nobody is fixing it. I sent a RFC some years ago to tackle these
> issues, also that the link-layer address is reconstructed by L3
> address and not by a ndisc lookup is very weird. I don't know if this
> is fixed or not.  However it was nothing related to the new BT mesh
> stuff.

"a lot of races", recently? Or some time ago?

>
>> for any BT device.  I would love to be wrong!!
>>

Hi Michael,

The current Raspi OS (based on Debian, kernel 5.4) contains a
bluetooth_6lowpan module. With that it's possible to connect the
nrf52840 using a "plain raspi 3b+" (without extra rf module).

Unfortunately, nordic decided to provide precompile examples with the
old, deprecated address mapping and so I need to spend some time in
compile these examples before I can report, if it works at all, and the
experienced stability.

best regards
Achim

P.S.: though linux-wpan is not bluetooth, I hope the misuse of this list
is still OK ;-). But I guess, moving it to the right list will alos have
advantages. Does anyone know, which would be the proper list for that?

Re: 6lowpan Support for Raspberry PI 3B+ - CYW43455

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]


Alexander Aring <alex.aring@gmail.com> wrote:
    > I tried to use BT 6LoWPAN and experienced a lot of races there, sadly
    > nobody is fixing it. I sent a RFC some years ago to tackle these
    > issues, also that the link-layer address is reconstructed by L3
    > address and not by a ndisc lookup is very weird. I don't know if this
    > is fixed or not.  However it was nothing related to the new BT mesh
    > stuff.

    >> for any BT device.  I would love to be wrong!!
    >>
    >> Running BTLE mesh is something I'd really like to do.
    >> My guess is that one could probably prototype this in userspace on top of
    >> bluez, and then use Alex' 6lowpan tap interface.

    > I did not do the "6lowpan tap" interface, the bluetooth people did
    > that and I complained about it and I never would accept this upstream.

okay, what did you use to connect the OpenThread native-build processes together?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: 6lowpan Support for Raspberry PI 3B+ - CYW43455

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 1281 bytes --]


Achim Kraus <achimkraus@gmx.net> wrote:
    >>> for any BT device.  I would love to be wrong!!

    > Hi Michael,

    > The current Raspi OS (based on Debian, kernel 5.4) contains a
    > bluetooth_6lowpan module. With that it's possible to connect the
    > nrf52840 using a "plain raspi 3b+" (without extra rf module).

So, USB connection to this multi-radio device?

    > Unfortunately, nordic decided to provide precompile examples with the
    > old, deprecated address mapping and so I need to spend some time in
    > compile these examples before I can report, if it works at all, and the
    > experienced stability.

I am unclear what the split of effort between this mcu the kernel is.
I get the impression that we need to load firmware, and that it can in fact
run RIOTOS, etc. directly.

    > P.S.: though linux-wpan is not bluetooth, I hope the misuse of this list
    > is still OK ;-). But I guess, moving it to the right list will alos have
    > advantages. Does anyone know, which would be the proper list for that?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: 6lowpan Support for Raspberry PI 3B+ - CYW43455

[Achim Kraus]

Hi Michael,

Am 16.09.20 um 19:06 schrieb Michael Richardson:
>
> Achim Kraus <achimkraus@gmx.net> wrote:
>      >>> for any BT device.  I would love to be wrong!!
>
>      > Hi Michael,
>
>      > The current Raspi OS (based on Debian, kernel 5.4) contains a
>      > bluetooth_6lowpan module. With that it's possible to connect the
>      > nrf52840 using a "plain raspi 3b+" (without extra rf module).
>
> So, USB connection to this multi-radio device?

No, the raspberry PI on it's own is using bluetooth_6lowpan.
No USB to the nrf52840!

The nrf52840 is a separate peer, which communicates over
bluetooth_6lowpan with that raspberry PI.

>
>      > Unfortunately, nordic decided to provide precompile examples with the
>      > old, deprecated address mapping and so I need to spend some time in
>      > compile these examples before I can report, if it works at all, and the
>      > experienced stability.
>
> I am unclear what the split of effort between this mcu the kernel is.

It's not split, these are just the two peers, and they communicate with
each other using bluetooth_6lowpan. The raspberry PI uses the linux
protocol-stack, the nrf52840 the protocol-stack from nordic.

best regards
Achim

> I get the impression that we need to load firmware, and that it can in fact
> run RIOTOS, etc. directly.
>
>      > P.S.: though linux-wpan is not bluetooth, I hope the misuse of this list
>      > is still OK ;-). But I guess, moving it to the right list will alos have
>      > advantages. Does anyone know, which would be the proper list for that?
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
>

Re: 6lowpan Support for Raspberry PI 3B+ - CYW43455

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 1333 bytes --]


Achim Kraus <achimkraus@gmx.net> wrote:
    > Am 16.09.20 um 19:06 schrieb Michael Richardson:
    >>
    >> Achim Kraus <achimkraus@gmx.net> wrote:
    >> >>> for any BT device.  I would love to be wrong!!
    >>
    >> > Hi Michael,
    >>
    >> > The current Raspi OS (based on Debian, kernel 5.4) contains a
    >> > bluetooth_6lowpan module. With that it's possible to connect the
    >> > nrf52840 using a "plain raspi 3b+" (without extra rf module).
    >>
    >> So, USB connection to this multi-radio device?

    > No, the raspberry PI on it's own is using bluetooth_6lowpan.
    > No USB to the nrf52840!

    > The nrf52840 is a separate peer, which communicates over
    > bluetooth_6lowpan with that raspberry PI.

Ah okay. My bad.  There are a number of nrf52480 devices available that
connect via USB, have some firmware on them, and do "something" with the host
to enable the host to have BTLE.

But, you mean using the built-in BTLE chip on the RPI you were able to do
6lowpan over BTLE to this nrf device.
I expect that this did not involve any kind BT pairing first?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [




[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: 6lowpan Support for Raspberry PI 3B+ - CYW43455

[Achim Kraus]

Hi Alex,
Hi Michael,

after using the firmware with compliant address mapping for the
nrf52840, it starts to work.

With a linux kernel 4.15.0 stable over a couple of hours.
With a linux kernel5.4.0 or 5.4.51 it's possible to connect, but that
connection is dropped after a couple of seconds (30-40s).

So, seems, that the "old bug" is back in 5.4.

With "kernel lockdown", it seems to be not possible to connect.
At least I didn't find out how.

best regards
Achim

Am 16.09.20 um 07:38 schrieb Achim Kraus:
> Hi Alex,
>
>> I tried to use BT 6LoWPAN and experienced a lot of races there, sadly
>> nobody is fixing it. I sent a RFC some years ago to tackle these
>> issues, also that the link-layer address is reconstructed by L3
>> address and not by a ndisc lookup is very weird. I don't know if this
>> is fixed or not.  However it was nothing related to the new BT mesh
>> stuff.
>
> "a lot of races", recently? Or some time ago?
>
>>
>>> for any BT device.  I would love to be wrong!!
>>>
>
> Hi Michael,
>
> The current Raspi OS (based on Debian, kernel 5.4) contains a
> bluetooth_6lowpan module. With that it's possible to connect the
> nrf52840 using a "plain raspi 3b+" (without extra rf module).
>
> Unfortunately, nordic decided to provide precompile examples with the
> old, deprecated address mapping and so I need to spend some time in
> compile these examples before I can report, if it works at all, and the
> experienced stability.
>
> best regards
> Achim
>
> P.S.: though linux-wpan is not bluetooth, I hope the misuse of this list
> is still OK ;-). But I guess, moving it to the right list will alos have
> advantages. Does anyone know, which would be the proper list for that?

Re: 6lowpan Support for Raspberry PI 3B+ - CYW43455

[Alexander Aring]

Hi,

On Wed, 16 Sep 2020 at 13:01, Michael Richardson <mcr@sandelman.ca> wrote:
>
>
> Alexander Aring <alex.aring@gmail.com> wrote:
>     > I tried to use BT 6LoWPAN and experienced a lot of races there, sadly
>     > nobody is fixing it. I sent a RFC some years ago to tackle these
>     > issues, also that the link-layer address is reconstructed by L3
>     > address and not by a ndisc lookup is very weird. I don't know if this
>     > is fixed or not.  However it was nothing related to the new BT mesh
>     > stuff.
>
>     >> for any BT device.  I would love to be wrong!!
>     >>
>     >> Running BTLE mesh is something I'd really like to do.
>     >> My guess is that one could probably prototype this in userspace on top of
>     >> bluez, and then use Alex' 6lowpan tap interface.
>
>     > I did not do the "6lowpan tap" interface, the bluetooth people did
>     > that and I complained about it and I never would accept this upstream.
>
> okay, what did you use to connect the OpenThread native-build processes together?
>

sorry for the late reply. This was doing L2 and above in user space,
it was the Linux driver layer only... I thought it was about using
6LoWPAN until the transport layer in kernel and link-layer in user
space.
It also had some problems with ack handling and you will not really
use Linux then, however I was always thinking about to wrap a whole
library around openthread and do some daemon to using Linux then,
instead running an OS on an OS.

- Alex