netdev - Re: [PATCHv2 bluetooth-next 04/10] ndisc: add addr_len parameter to ndisc_opt_addr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <240084aa-2751-6f24-c07b-662b19a74475@stressinduktion.org>
Date:	Sat, 7 May 2016 00:23:20 +0200
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Alexander Aring <aar@...gutronix.de>, linux-wpan@...r.kernel.org
Cc:	kernel@...gutronix.de, marcel@...tmann.org,
	jukka.rissanen@...ux.intel.com, stefan@....samsung.com,
	mcr@...delman.ca, werner@...esberger.net,
	linux-bluetooth@...r.kernel.org, netdev@...r.kernel.org,
	"David S . Miller" <davem@...emloft.net>,
	Alexey Kuznetsov <kuznet@....inr.ac.ru>,
	James Morris <jmorris@...ei.org>,
	Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
	Patrick McHardy <kaber@...sh.net>
Subject: Re: [PATCHv2 bluetooth-next 04/10] ndisc: add addr_len parameter to
 ndisc_opt_addr_space

On 04.05.2016 14:30, Alexander Aring wrote:
> Hi,
> 
> On 05/02/2016 09:37 PM, Hannes Frederic Sowa wrote:
>> On 20.04.2016 10:19, Alexander Aring wrote:
>>> This patch makes the address length as argument for the
>>> ndisc_opt_addr_space function. This is necessary to handle addresses
>>> which don't use dev->addr_len as address length.
>>
>> Would it make sense for patch 4, 5 and 6 to add the operation to ndisc_ops?
>>
> 
> not sure if I understand this question right,
> 
> We have now the ndisc_ops where we can could change the send/recv of
> NS/NA, also is_useropt (for add 6CO RA is userspace option field).
> 
> In case of 802.15.4 we have two MAC addresses with different length:
> 
>  - extended address - 8 bytes => EUI64
>  - short address - 2 bytes
> 
> Now [0] describes how to make the source/target address option for
> NS/NA/RS/RA/... to deal with both addresses.
> 
> The short address is a special case in 802.15.4 and not always
> available. If available we add both addresses as option field in
> NS/NA (RS/RA will follow in future, but currently NS/NA only).
> 
> At this point the understanding of [0] differs in 6LoWPAN
> implementations.
> 
> Some people handles it like:
> 
> Handle the short address/extended address in XOR case of 6LoWPAN
> interface. The interface has as MAC address the extended XOR short (if
> available), depends on setting.
> 
> Then dev->addr_len is 8 XOR 2.
> 
> Other people (inclusive me) handle it like:
> 
> Handle the short/extended address in case of OR, but never short address
> alone. The interface can be accessed by extended address or short
> address and each neighbour stores both information.
> 
> The case "short address never alone" means that the extended address is
> always available and MUST be there.
> 
> Furthermore, depends on L3 addressing it could be useful to have the
> possibility to decide if using or short OR extended address as L2 address
> for do better compressing stuff.
> 
> ---
> 
> I implement it as OR case, so we add both addresses when short address
> is available. Also we drop NS/NA when the short address is given only,
> in theory we could also react on this and store a "dummy" 0x00..00
> address for extended address then.
> 
> Not sure how it need to be handled correctly, for now I implemented how
> I understand it.
> 
> In case of the OR case, we need to add two option fields for the
> address, extended and short. This is why I do the calculation stuff more
> accessible with different address lengths, so we can use 8 or 2 and not
> dev->addr_len which stores always the 802.15.4 EUI64 address length.
> 
> And the answer would be, no it makes no sense because we need to call
> these functions with 8 (dev->addr_len) and 2 (if short addr is
> available).

I had to understand the usage in patch 9. It seems you are right, the
decision cannot be done based on the protocol alone but based on the
context, so we need to pass in different lengths based on the context.
Thanks for your explanation.

I would still suggest to not use net_device as an argument but just the
type and length to keep the API cleaner, but this is not a strong opinion.

Thanks,
Hannes