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

Hi Alex,

On Mon, Jul 18, 2016, Alexander Aring wrote:

quoted

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.

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

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.

Johan