From: Varka Bhadram <varkabhadram@gmail.com>
To: Alexander Aring <alex.aring@gmail.com>
Cc: linux-wpan - ML <linux-wpan@vger.kernel.org>
Subject: Re: Regarding dev->addr_len
Date: Fri, 08 Aug 2014 15:24:42 +0530 [thread overview]
Message-ID: <53E49E62.3010908@gmail.com> (raw)
In-Reply-To: <20140808093353.GC20055@omega>
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.
next prev parent reply other threads:[~2014-08-08 9:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-08 8:40 Regarding dev->addr_len Varka Bhadram
2014-08-08 9:33 ` Alexander Aring
2014-08-08 9:54 ` Varka Bhadram [this message]
2014-08-08 10:47 ` Alexander Aring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53E49E62.3010908@gmail.com \
--to=varkabhadram@gmail.com \
--cc=alex.aring@gmail.com \
--cc=linux-wpan@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox