Hi, On Fri, Jun 08, 2018 at 03:37:44PM -0400, Michael Richardson wrote: > > Alexander Aring <aring@xxxxxxxxxxxx> wrote: > Alex> I already see code outside who changed tun netdevice to the > Alex> ARPHRD_6LOWPAN type and I suppose they running into this > Alex> issue. (Btw: I don't know why somebody wants to changed that > Alex> type to ARPHRD_6LOWPAN on tun). > > so that they can have the kernel do 6lowpan processing, emitting 6lowPAN > packets into userspace to be transfered into a radio via some proprietary > interface (including, for instance SLIP over USB cable to Contiki or OpenWSN stack, > set up to act as radio only) > No, the datapath doesn't change. If the user space evaluate the dev->type (there exists some ioctl() for it) it will assume it has a 6LoWPAN type interface. A lot of user space software outside will doing interface specific handling after detect the type. E.g. wireshark will select some dissector handling. On a tun interface and switch to 6LoWPAN it will not change much the dissector view, because both raw IPv6 packets on datapath. For me as 6LoWPAN maintainer it makes no sense to switch to it. Currently some netdevice notifier will crash (if you a lucky it will not). Futhermore user space programs e.g. radvd will do 6lowpan specific handling on 6lowpan dev->type, it will not work either on tun devices. I know that wpantund from NestLabs do this switch, I am very curious about the reason but I think they do it because the name is 6LoWPAN. But wpantund is just a SLIP like protocol with additional radio/foo commands. --- According to the people who say "I like to have a 6LoWPAN tun device, that would be nice" - I don't know how this will ever work since 6LoWPAN header highly depends on MAC header information. Tun devices works because IP architecture allows a separation from MAC layer. I already saw protocols at IETF where MAC header information are needed on top of UDP payload in case of 6LoWPAN. (I talked about that at last netdev in Montreal). Bluetooth wanted to add a tun 6lowpan interface and I was curious how this works. At the end it was a "Bluetooth mapping to ethernet header" (not as tunnel, as propagated). I was not acking it, because if there are protocols who needs more information than just what you can map to ethernet... it will not work. At least it will also not work with IEEE 802.15.4 at all. They was just lucky that Bluetooth and ethernet use the same mac address length (And I had some questions to the multicast bit as well). Tunnel might work to get mac information. But so far 6loWPAN works it is that you have a L2 underlaying interface and on top (ip link set master) a raw IPv6 interface which do the adaptation automatically as a protocol translation (That's why I cannot understand Bluetooth 6LoWPAN use tx queues on their 6LoWPAN interface, they need to fix the queue in the underlaying L2 interface). As an alternative solution I think it should be something done like TAP like interface per subsystem. I mean NO ETHERTNET, but the ethernet in TAP interfaces out and replace it with Bluetooth or IEEE 802.15.4. I might can easily create a simple TAP IEEE 802.15.4 to show what I mean. With an IEEE 802.15.4 TAP device and a 6lowpan interface on top you can realize your use case and pass 802.15.4 L2 frames to device node -> pops up at 6LoPWAN interface and send IPv6 stuff and you can read on device node. I am still in the opinion the L2 TAP like interface is the way to go to offer such feature. - Alex -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
