Regarding dev->addr_len

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.

Hi Varka,

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.

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.

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.

Hi,

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.

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.

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.

Look at net/ipv6/ndisc.c in about one minute you will see that this will create problems of course.

- Alex