Re: Regarding dev->addr_len

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

Hi,

On Fri, Aug 08, 2014 at 03:24:42PM +0530, Varka Bhadram wrote:
> 
> Entire Network layer may be working with 48-bit or 64-bit MAC address only.
> 

That's not correct. The network layer can handle xx bit mac addresses
depends on addr_len. Our mac layer have something special which isn't in
any other mac layers. We have two kinds of mac addresses which can be
used mixed in destination and source address in the mac header.

The problem is 6LoWPAN is an adaption layer and the whole
net/ipv6/ndisc.c implementation can handle only one kind of mac address
with one addr_len.

According we have two kinds with different length we need also other
ICMPv6 nd messages. The neighbor discovery cache need to hold a
information if it's a short or extended and send the right nd messages.

> May be we need to change this behavior to work with 16-bit also ...?
> 

Okay, create patches to change the core netdev api to handle two kinds
of dev_addr's. I am prerry sure this will not accept at mainline. We
need another idea and if you read my other mail on netdev you will get a
imagine about that what I try to do. Sorry, this is hard but we can't
change the whole network API only for 802.15.4.

One reply talked about a private data isnide a neighbor entry which is
set by L2, that's another option and I like it.

> Also for a interface we are going to have one netdevice structure ...?
> 

I don't know what you mean here. But another idea of mine was to have a
second interface for short addresses only, but this can't work because
short and extended addresses can be used at the same time. If you mean
that.

> If yes, dynamically updating dev_addr and addr_len creates problems..?
> 
Look at net/ipv6/ndisc.c in about one minute you will see that this will
create problems of course.

- Alex