All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: Johan Hedberg <johan.hedberg@gmail.com>
Cc: 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>,
	carlesgo@entel.upc.edu
Subject: Re: [RFC bluetooth-next 20/20] 6lowpan: bluetooth: add new implementation
Date: Wed, 20 Jul 2016 13:22:59 +0300	[thread overview]
Message-ID: <D2524A03-DF9F-4AA2-A046-C8FC1AADB1C1@holtmann.org> (raw)
In-Reply-To: <20160720073944.GA20780@t440s>

Hi Johan,

>> 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?
> 
> Connections aren't lost when the random address is changed. That's why
> we track the hci_conn->init_addr and hci_conn->resp_addr. The way this
> is dealt with e.g. the Security Manager protocol is that the connection
> creation address *is* the address for the remote device throughout the
> entire connection, no matter what happens to the local and remote random
> address during the connection. I would expect 6LoWPAN do do something
> similar.
> 
> What was still unclear to me (maybe I missed it in the thread): does the
> 6LoWPAN for LE spec require using the connection creation address or the
> identity address? If it would be the latter then that's something that
> will never change and the whole interface recreation issue goes away.

of course we do not want to leak the identity address if we don't have to. That is why I am thinking that the IPv6 link should always use something close to the link layer address.

The basic assumption should be that when hci0 is powered on, then you get a 6lo network interface. If you power the controller down, then the 6lo interface gets removed.

By default, the 6lo interface should not have a single address assigned to it if there are no connections. When a connection is created, then a new address should be assigned to it. If the connection drops, then it should be removed. And of course there needs to be usage counter attached to each address. If two connections use the same address, then it only gets removed once there is no connection with that source address active anymore (meaning it needs some sort of reference counting).

With usage of public address or static random address, then most likely only one address on 6lo interface is used. This is not strictly mandated by the spec since you can in theory have one connection with a public address and the other with the static random address. However ignore that fact for a bit since it will just work out when dealing with RPAs anyway. The importance is the link layer address that is used when establishing the connection.

In case you use RPAs, then every connection will have a new link layer address (we rotate the RPA when disabling advertising). As long as the connection is active, that source address should be represented on 6lo interface. However this is no difference either since per spec each new connection can have a different address from all the existing connections. That is always valid with the link layer.

Regards

Marcel


  parent reply	other threads:[~2016-07-20 10:22 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-11 19:50 [RFC bluetooth-next 00/20] bluetooth: rework 6lowpan implementation Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 01/20] 6lowpan: ndisc: don't remove short address Alexander Aring
2016-07-19 13:19   ` Michael Richardson
2016-07-19 18:03     ` Alexander Aring
2016-07-21  6:37       ` Alexander Aring
2016-07-21  7:10         ` Alexander Aring
2016-07-21  8:44       ` Michael Richardson
2016-07-11 19:50 ` [RFC bluetooth-next 02/20] nhc: add TODO for nhc work Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 03/20] ieee802154: 6lowpan: remove headroom check Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 04/20] ieee802154: 6lowpan: move skb cb BUILD_BUG_ON check Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 05/20] 6lowpan: remove LOWPAN_IPHC_MAX_HEADER_LEN Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 06/20] 6lowpan: hold netdev while unregister Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 07/20] 6lowpan: introduce generic default naming Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 08/20] 6lowpan: move rx defines to generic Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 09/20] bluetooth: introduce l2cap_hdev_chan_connect Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 10/20] bluetooth: add hci dev notifier Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 11/20] bluetooth: export functions and variables Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 12/20] 6lowpan: bluetooth: remove implementation Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 13/20] ieee802154: 6lowpan: move header create to 6lowpan Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 14/20] 6lowpan: move dev_init to generic Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 15/20] 6lowpan: iphc: override l2 packet information Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 16/20] ipv6: addrconf: fix 48 bit 6lowpan autoconfiguration Alexander Aring
2016-07-12 20:16   ` Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 17/20] 6lowpan: iphc: add handling for btle Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 18/20] 6lowpan: move multicast flags to generic Alexander Aring
2016-07-12 20:34   ` Alexander Aring
2016-07-13 11:15     ` Jukka Rissanen
2016-07-14  8:21       ` Alexander Aring
2016-07-14  8:36         ` Alexander Aring
2016-07-19 14:51       ` Michael Richardson
2016-07-19 18:20         ` Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 19/20] 6lowpan: delete addr_len handling " Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 20/20] 6lowpan: bluetooth: add new implementation Alexander Aring
2016-07-12 21:19   ` Alexander Aring
2016-07-14 11:40     ` Luiz Augusto von Dentz
2016-07-17 15:52       ` Alexander Aring
2016-07-18  8:59         ` Luiz Augusto von Dentz
2016-07-18 21:52           ` Alexander Aring
2016-07-19  5:45             ` Johan Hedberg
2016-07-19  8:23               ` Luiz Augusto von Dentz
2016-07-19 21:05                 ` Alexander Aring
2016-07-20  7:39                   ` Johan Hedberg
2016-07-20  8:14                     ` Luiz Augusto von Dentz
2016-07-20 10:22                     ` Marcel Holtmann [this message]
2016-07-19  8:49             ` Luiz Augusto von Dentz
2016-07-19 14:48               ` Michael Richardson
2016-07-19 21:24               ` Alexander Aring
2016-07-12 14:51 ` [RFC bluetooth-next 00/20] bluetooth: rework 6lowpan implementation Luiz Augusto von Dentz
2016-07-12 18:35   ` Alexander Aring
2016-07-13  9:12     ` Alexander Aring
2016-07-13 10:13       ` Luiz Augusto von Dentz
2016-07-13 10:56         ` Alexander Aring
2016-07-14 12:02           ` Luiz Augusto von Dentz
2016-07-19 12:58 ` Michael Richardson
2016-08-05  7:15 ` Bakke, Glenn Ruben
2016-08-05  9:18   ` Alexander Aring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D2524A03-DF9F-4AA2-A046-C8FC1AADB1C1@holtmann.org \
    --to=marcel@holtmann.org \
    --cc=Patrik.Flykt@linux.intel.com \
    --cc=aar@pengutronix.de \
    --cc=carlesgo@entel.upc.edu \
    --cc=johan.hedberg@gmail.com \
    --cc=jukka.rissanen@linux.intel.com \
    --cc=kaspar@schleiser.de \
    --cc=kernel@pengutronix.de \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-wpan@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.