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
--
To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
