Re: [RFC bluetooth-next 20/20] 6lowpan: bluetooth: add new implementation

From: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
To: Alexander Aring <aar@pengutronix.de>,
	Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
	linux-wpan@vger.kernel.org, kernel@pengutronix.de,
	kaspar@schleiser.de,
	Jukka Rissanen <jukka.rissanen@linux.intel.com>,
	"linux-bluetooth@vger.kernel.org"
	<linux-bluetooth@vger.kernel.org>,
	Patrik Flykt <Patrik.Flykt@linux.intel.com>
Subject: Re: [RFC bluetooth-next 20/20] 6lowpan: bluetooth: add new implementation
Date: Tue, 19 Jul 2016 11:23:20 +0300	[thread overview]
Message-ID: <CABBYNZ+epQ6LPP4PfwXAstim_h5yY78GgbVLEH-i96g6u8p_Dw@mail.gmail.com> (raw)
In-Reply-To: <20160719054501.GA17979@t440s.P-661HNU-F1>

Hi Alex, Johan,

On Tue, Jul 19, 2016 at 8:45 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Alex,
>
> On Mon, Jul 18, 2016, Alexander Aring wrote:
>> > This is tricky because the even using privacy the address of the
>> > interface is defined by the time the connection is established, but
>> > perhaps there is a way to set this properly on the network interface,
>> > anyway I do agree the making the interface persistent is probably much
>> > more convenient.
>> >
>>
>> This is currently something which I don't understand. With "privacy" you
>> mean the LE_PUBLIC and LE_PRIVATE address, the address type?
>
> Might be worth to do a quick read-through of section 1.3 in Vol 6, Part
> B of the Bluetooth Core specification (v4.2) for a quick overview of LE
> addresses. On the top-level you have public & random, but random itself
> is further split into three different sub-types out of which two are
> considered "private". The third one, a static random address, is
> considered an identity address the same way a public address is.

The so called privacy, the use of RPA, is actually recommended by RFC 7668:

https://tools.ietf.org/html/rfc7668#section-3.2.2

>> I think, we don't need that when we doing an interface register. This is
>> currently one of the big issue which this RFC fixes, the 8 byte vs 6
>> bytes address.
>>
>> At Interface register we need to know the source address only, which is
>> my opinion the hdev->bdaddr. This address has (in my opinion) nothing
>> todo with the address type.
>>
>> I can argument here with rfc7668:
>>
>>  "This means that no bit in the IID indicates whether the
>>   underlying Bluetooth device address is public or random."

See above the rfc7668 actually recommends using RPAs.

>> The IID is for autoconfiguration the last 8 bytes of IPv6 address and
>> usually generated by "dev->dev_addr" (dev = struct net_device).
>> Also the "dev->dev_addr" will be used in address options for
>> NS/NA/RS/RA...
>>
>> In the current implementation the IID generation is mixed with the
>> "dev->addr" (dev as struct net_device) field which is wrong.
>>
>> In summary:
>>
>> We don't need to know to wait for connection to setting the
>> "dev->dev_addr" (struct net_device). This field should be "hdev->bdaddr"
>> and hdev should be the hdev which is bounded to the dev(lowpan struct
>> net_device).
>>
>> I see no issues to create interfaces before, except you saying that
>> "hdev->bdaddr" is unknown.
>
> hdev->bdaddr tracks the public address of a device, however the
> Bluetooth specification doesn't mandate that all devices have a public
> address, i.e. it can also be all zeroes. In particular, single-mode
> (LE-only) devices may only use a random address and have a static random
> address as their identity address. Maybe it's the identity address that
> you should be using instead of hdev->bdaddr?
>
> Right now the identity address isn't stored in any variable, but we do
> have a hci_copy_identity_address() function to fetch it (you'd just
> ignore the addr_type if you don't need that).
>
> Also note that the identity address isn't necessarily the same as what
> was used to create the connection, so if the connection address is of
> importance we track that in hci_conn->init_addr and hci_conn->resp_addr.

Following the recommendation of rfc7668 which say the node should
always change its address when connecting, which means advertise a
different address, also the router should periodically change is RPA,
thus the network interface may have to assume different MAC addresses
which I don't is currently possible or we are back to having the
interfaces created on demand.

-- 
Luiz Augusto von Dentz