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

From: Alexander Aring <aar@pengutronix.de>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: 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>,
	carlesgo@entel.upc.edu
Subject: Re: [RFC bluetooth-next 20/20] 6lowpan: bluetooth: add new implementation
Date: Tue, 19 Jul 2016 23:05:58 +0200	[thread overview]
Message-ID: <ae47fe95-3599-d3f7-49bf-66c02b067fca@pengutronix.de> (raw)
In-Reply-To: <CABBYNZ+epQ6LPP4PfwXAstim_h5yY78GgbVLEH-i96g6u8p_Dw@mail.gmail.com>

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@gmail.com> 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