Hi, On Tue, 15 Sep 2020 at 16:35, Michael Richardson <mcr@xxxxxxxxxxxx> wrote: > > > Achim Kraus <achimkraus@xxxxxxx> 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
