[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1326.1528682979@localhost>
Date: Sun, 10 Jun 2018 22:09:39 -0400
From: Michael Richardson <mcr+ietf@...delman.ca>
To: Alexander Aring <aring@...atatu.com>
cc: netdev@...r.kernel.org, linux-wpan@...r.kernel.org,
linux-bluetooth@...r.kernel.org
Subject: Re: netdevice notifier and device private data
Alexander Aring <aring@...atatu.com> wrote:
>> It totally seems like broken behaviour. Maybe it's not even
>> intentional. Maybe they are just foobar.
> They simple don't know what they doing... somebody thought 6LoWPAN need
> to be 6LoWPAN, but they actually don't use the 6LoWPAN handling inside
> the kernel. _Except_ they doing out of tree stuff which I don't
> believe.
So, it seems like this ioctl() should be disabled, or restricted to cases
that actually work. hate to break their code, but if it's broken anyway, at
least the kernel won't crash under them.
> According to [0] it also works with tun default (I suppsoe raw IPv6),
> because ifdef. And they should not change it because they don't use
> in-kernel 6LoWPAN functionality.
> I really think that this tun/tap feature makes a lot of trouble for
> some type changes. I probably introduce lowpan_dev pointer to netdevice
> and then check if it's really a 6LoPWAN interface, a dev->type will not
> garantuee anymore you have a 6LoWPAN interface. At least in user space
> it's not possible to have a check if you really have a 6LoWPAN
> interface.
> - Alex
> [0]
> https://github.com/openthread/wpantund/blob/master/src/util/tunnel.c#L180
> [1] https://github.com/reubenhwk/radvd/blob/master/device-linux.c#L75
--
Michael Richardson <mcr+IETF@...delman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
Download attachment "signature.asc" of type "application/pgp-signature" (465 bytes)
Powered by blists - more mailing lists