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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 4 May 2016 14:30:43 +0200
From:	Alexander Aring <aar@...gutronix.de>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>,
	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

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).

- Alex

[0] https://tools.ietf.org/html/rfc4944#section-8