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. > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
