Hi, On 07/19/2016 10:23 AM, Luiz Augusto von Dentz wrote: > Hi Alex, Johan, > > On Tue, Jul 19, 2016 at 8:45 AM, Johan Hedberg <johan.hedberg@xxxxxxxxx> wrote: >> Hi Alex, >> ... > > 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. > mhhh, I am not a bluetooth expert. What really means "periodically change is RPA" and how is this done in the Linux bluetooth? When "changing the RPA" happens, does that mean the all connections will be lost (unregister interface). Then the previous connections will be recreated (register interface) with a complete different MAC address? I think it will be a complete different MAC address and this happens all 15 minutes. "The recommended time interval before randomizing new private address is 15 minutes, as determined by timer T_GAP(private_addr_int) in Table 17.1 of the Bluetooth Generic Access Profile [BTCorev4.1]." If so, then I could understand the reason why recreation of interface. The only question would for me, how does the bluetooth subsystem handle such MAC address update with running l2cap channel connections. I suppose it will close all connections, otherwise the current mainline solution doesn't work here, because if all channels are disconnected we get an interface deregister, so far I understood. Afterwards somehow all connection will be re-established under a new interface, or? --- Another idea would be stop the interface which allows to change mac address. Maybe we can have some event handling here, that the mac address will be changed. If so, such event occur change dev->dev_addr and open the interface again. stop (ifdown) and open (ifup) with changing the mac address should be handled by IPv6 applications. We need at least to run [0] on mac address changes, this reacts on IFUP and CHANGE netdev notifiers. This will generate the SLAAC address, but it confuse me somehow to change this address all 15 minutes because the MAC address changed. :-/ Deregister and register the interface is a no-go in my opinion and we should have another solution. Especially when such deregister/register mechanism happens periodically all 15 minutes. --- I suppose the "RPA" will be the device address which also need to be filled in as source/target address option in NS/NA/RS/RA then. It's just difficult to deal with that when the address will be changed periodically in 15 minutes. btw: I talked with C. Gomez today, because I am at the IETF. He would like to help here to make everything clear and agreed that I cc him here. - Alex [0] http://lxr.free-electrons.com/source/net/ipv6/addrconf.c#L3333 -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
