Regarding dev->addr_len

Regarding dev->addr_len

[Varka Bhadram]

Hi Alex,

I need some clarification regarding address length for the netdevice.
We are always setting up that to IEEE802154_ADDR_LEN [1].

If i receive a packet (RS: Router Solicitation) with short addressing mode,
it is discarding at higher layers.

If the linux node receives the RS packet from TinyOS node its discarding
at [2] due to address length field. Here [2] we are getting *lladdr* as NULL.


Actually we have to update the dev->addr_len filed as per the packet info it received ..?

How can we make it work..?

  
[1]:http://lxr.free-electrons.com/source/net/mac802154/wpan.c#L375
[2]:http://lxr.free-electrons.com/source/net/ipv6/ndisc.c#L991

-- 
Regards,
Varka Bhadram.

Re: Regarding dev->addr_len

[Alexander Aring]

Hi Varka,

On Fri, Aug 08, 2014 at 02:10:48PM +0530, Varka Bhadram wrote:
> Hi Alex,
> 
> I need some clarification regarding address length for the netdevice.
> We are always setting up that to IEEE802154_ADDR_LEN [1].
> 
> If i receive a packet (RS: Router Solicitation) with short addressing mode,
> it is discarding at higher layers.
> 
> If the linux node receives the RS packet from TinyOS node its discarding
> at [2] due to address length field. Here [2] we are getting *lladdr* as NULL.
> 

yes, I said about some months ago to Martin that he should not use short
addresses in 6lowpan because it's simply not working currently.

> 
> Actually we have to update the dev->addr_len filed as per the packet info it received ..?
> 

If you look at net/ipv6/ndisc.c code you will notice that when you
change the addr_len of netdevice during runtime will end in an
unexecpted behaviour.

> How can we make it work..?
> 

I already open a thread to related this question [0]. Please don't open a
new one! David wrote something I need to answer him, but need to
consider how I can describe the current behaviour in words.

We can't just do own changes in net/ipv6/ndisc.c, only very very small
changes and changes which don't brake the ethernet, etc... neighbor
discovery. I have several ideas to deal with, some need a complete
change of architecture to deal with short and extended addresses.

Currently we have in dev_addr the extended address and the addr_len is a
static value. And that's also what the neighbor discovery use from L2,
the addr_len and dev_addr only.

Okay, there are also the header_ops callbacks, I need to take a closer
look into that to have some idea.

- Alex

[0] http://www.spinics.net/lists/netdev/msg291767.html

Re: Regarding dev->addr_len

[Varka Bhadram]

On 08/08/2014 03:03 PM, Alexander Aring wrote:
> Hi Varka,
>
> On Fri, Aug 08, 2014 at 02:10:48PM +0530, Varka Bhadram wrote:
>> Hi Alex,
>>
>> I need some clarification regarding address length for the netdevice.
>> We are always setting up that to IEEE802154_ADDR_LEN [1].
>>
>> If i receive a packet (RS: Router Solicitation) with short addressing mode,
>> it is discarding at higher layers.
>>
>> If the linux node receives the RS packet from TinyOS node its discarding
>> at [2] due to address length field. Here [2] we are getting *lladdr* as NULL.
>>
> yes, I said about some months ago to Martin that he should not use short
> addresses in 6lowpan because it's simply not working currently.
>
>> Actually we have to update the dev->addr_len filed as per the packet info it received ..?
>>
> If you look at net/ipv6/ndisc.c code you will notice that when you
> change the addr_len of netdevice during runtime will end in an
> unexecpted behaviour.
>
>> How can we make it work..?
>>
> I already open a thread to related this question [0]. Please don't open a
> new one! David wrote something I need to answer him, but need to
> consider how I can describe the current behaviour in words.
>
> We can't just do own changes in net/ipv6/ndisc.c, only very very small
> changes and changes which don't brake the ethernet, etc... neighbor
> discovery. I have several ideas to deal with, some need a complete
> change of architecture to deal with short and extended addresses.
>
> Currently we have in dev_addr the extended address and the addr_len is a
> static value. And that's also what the neighbor discovery use from L2,
> the addr_len and dev_addr only.
>
> Okay, there are also the header_ops callbacks, I need to take a closer
> look into that to have some idea.
>
> - Alex
>
> [0] http://www.spinics.net/lists/netdev/msg291767.html

Entire Network layer may be working with 48-bit or 64-bit MAC address only.

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

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

If yes, dynamically updating dev_addr and addr_len creates problems..?

-- 
Regards,
Varka Bhadram.

Re: Regarding dev->addr_len

[Alexander Aring]

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