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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.