Re: [PATCH linux-wpan v4] ieee802154: 6lowpan: ensure header compression does not corrupt ipv6 header

[Alexander Aring <alex.aring@gmail.com>]

On Tue, Sep 23, 2014 at 12:13:54PM +0300, Jukka Rissanen wrote:
> Hi Alex,
> 
> On ma, 2014-09-22 at 18:21 +0200, Alexander Aring wrote:
> 
> > grml, I overlooked something the last version. But I will fix it while
> > >  
> > > -	cb->ackreq = !lowpan_is_addr_broadcast(daddr);
> > > +	/* TODO: Currently we only support extended_addr */
> > > +	info->daddr.mode = IEEE802154_ADDR_LONG;
> > 
> > now IEEE802154_ADDR_LONG is no little endian value copied from mac
> > header. Somewhere else converted the little endian value to an host understandable
> > enum/define number. For the rework I will remove this value. We should never
> > ever convert this value for parsing.
> > 
> > We use it only for af_802154 and userspace specification what addresses
> > should be used. But the above one to make this __le16 is incorrect. For
> > userspace we should create some enums for declaring different address
> > types. Then we can use this for 802.15.4 sockets.
> 
> BTW, at some point we might want to change the IEEE802154_ADDR_LONG in
> net/6lowpan/iphc.c to more generic. Now this IEEE 802154 specific enum
> needs to be mentioned in net/bluetooth/6lowpan.c which looks quite
> confusing.
> 

Yep, the generic name for such address is EUI-64. Forget the hyphen
there. There is alot of 802.15.4 specific 6lowpan defines in iphc.c.
They are defined in include/net/6lowpan.h, which should moved into an
internal header of "net/ieee802154/...".

And also we could do this maybe not as address type, more a address
length. EUI64 is 8 and the SHORT address is 2 bytes long. No special
handling about some address types, only handling about different lengt,
only handling about different lengths.

so we have some:

switch (address_length) {
case IEEE_EUI64_ADDRLEN:
case IEEE802154_SHORT_ADDRLEN:
default:
	/* not supported */
}

the second case is only for IEEE802154 handling, maybe we could also
check the netdev type, but that's not necessary. bluetooth should never
set IEEE802154_SHORT_ADDRLEN by calling lowpan_header_create.

Also we don't support the case IEEE802154_SHORT_ADDRLEN right now. :-)
That's currently dead code, it's a complicated issue to support that...
but in near future we will support it, otherwise our stack is in an
unusable state.

I mean IEEE_EUI64_ADDRLEN, is in 802154 the extended address. In
bluetooth you need to generate the EUI64 with filling ff:fe pattern.
Like behaviour in ethernet. And drop the special type handling.

Is this okay?

- Alex