Linux-Bluetooth Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH 0/3] bluetooth: 6lowpan: multiple peers and addresses
@ 2019-02-08 15:25 Josua Mayer
  2019-02-08 15:25 ` [PATCH 1/3] bluetooth: 6lowpan: search for destination address in all peers Josua Mayer
                   ` (5 more replies)
  0 siblings, 6 replies; 20+ messages in thread
From: Josua Mayer @ 2019-02-08 15:25 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: Josua Mayer

Dear maintainers,

This patch set deals with an issue I reported earlier this year, where
1) packets addressed to a non-link-local address
2) any packets when at least 2 peers are connected
were not delivered if they matched a direct peer i.e. no routing.

The full explanation of the issue including steps to reproduce are:
https://www.spinics.net/lists/linux-bluetooth/msg78486.html

Please comment if I am on the right track here, especially on the
second patch in this series where I am nto completely sure if I found
the right api call to the neighbour cache.

Josua Mayer (3):
  bluetooth: 6lowpan: search for destination address in all peers
  bluetooth: 6lowpan: check neighbour table for SLAAC
  bluetooth: 6lowpan: always check destination address

 net/bluetooth/6lowpan.c | 40 ++++++++++++++++++++++++----------------
 1 file changed, 24 insertions(+), 16 deletions(-)

-- 
2.20.1


^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH 1/3] bluetooth: 6lowpan: search for destination address in all peers
  2019-02-08 15:25 [PATCH 0/3] bluetooth: 6lowpan: multiple peers and addresses Josua Mayer
@ 2019-02-08 15:25 ` Josua Mayer
  2019-02-08 15:25 ` [PATCH 2/3] bluetooth: 6lowpan: check neighbour table for SLAAC Josua Mayer
                   ` (4 subsequent siblings)
  5 siblings, 0 replies; 20+ messages in thread
From: Josua Mayer @ 2019-02-08 15:25 UTC (permalink / raw)
  To: linux-bluetooth
  Cc: Josua Mayer, Marcel Holtmann, Johan Hedberg, David S. Miller

Handle overlooked case where the target address is assigned to a peer
and neither route nor gateway exist.

For one peer, no checks are performed to see if it is meant to receive
packets for a given address.

As soon as there is a second peer however, checks are performed
to deal with routes and gatways for handling complex setups with
multiple hops to a target address.
This logic assumed that no route and no gatway imply that the
destination address can not be reached, which is false in case of a
direct peer.

Signed-off-by: Josua Mayer <josua.mayer@jm0.eu>
---
 net/bluetooth/6lowpan.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index 9d79c7de234a..553dc719afde 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -187,10 +187,16 @@ static inline struct lowpan_peer *peer_lookup_dst(struct lowpan_btle_dev *dev,
 	}
 
 	if (!rt) {
-		nexthop = &lowpan_cb(skb)->gw;
-
-		if (ipv6_addr_any(nexthop))
-			return NULL;
+		if (ipv6_addr_any(&lowpan_cb(skb)->gw)) {
+			/* There is neither route nor gateway,
+			 * probably the destination is a direct peer.
+			 */
+			nexthop = daddr;
+		} else {
+			/* There is a known gateway
+			 */
+			nexthop = &lowpan_cb(skb)->gw;
+		}
 	} else {
 		nexthop = rt6_nexthop(rt, daddr);
 
-- 
2.20.1


^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH 2/3] bluetooth: 6lowpan: check neighbour table for SLAAC
  2019-02-08 15:25 [PATCH 0/3] bluetooth: 6lowpan: multiple peers and addresses Josua Mayer
  2019-02-08 15:25 ` [PATCH 1/3] bluetooth: 6lowpan: search for destination address in all peers Josua Mayer
@ 2019-02-08 15:25 ` Josua Mayer
  2019-03-07 10:41   ` Johan Hedberg
  2019-02-08 15:25 ` [PATCH 3/3] bluetooth: 6lowpan: always check destination address Josua Mayer
                   ` (3 subsequent siblings)
  5 siblings, 1 reply; 20+ messages in thread
From: Josua Mayer @ 2019-02-08 15:25 UTC (permalink / raw)
  To: linux-bluetooth
  Cc: Josua Mayer, Marcel Holtmann, Johan Hedberg, David S. Miller

Like any IPv6 capable device, 6LNs can have multiple addresses assigned
using SLAAC and made known through neighbour advertisements.
After checking the destination address against all peers link-local
addresses, consult the neighbour cache for additional known addresses.

RFC7668 defines the scope of Neighbor Advertisements in Section 3.2.3:
1. "A Bluetooth LE 6LN MUST NOT register its link-local address"
2. "A Bluetooth LE 6LN MUST register its non-link-local addresses with
the 6LBR by sending Neighbor Solicitation (NS) messages ..."

Due to these constranits both the link-local addresses tracked in the
list of 6lowpan peers, and the neighbour cache have to be used when
identifying the 6lowpan peer for a destination address.

Signed-off-by: Josua Mayer <josua.mayer@jm0.eu>
---
 net/bluetooth/6lowpan.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index 553dc719afde..4e14db230793 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -171,6 +171,7 @@ static inline struct lowpan_peer *peer_lookup_dst(struct lowpan_btle_dev *dev,
 	struct in6_addr *nexthop;
 	struct rt6_info *rt = (struct rt6_info *)skb_dst(skb);
 	int count = atomic_read(&dev->peer_count);
+	struct neighbour *neigh;
 
 	BT_DBG("peers %d addr %pI6c rt %p", count, daddr, rt);
 
@@ -222,6 +223,19 @@ static inline struct lowpan_peer *peer_lookup_dst(struct lowpan_btle_dev *dev,
 		}
 	}
 
+	// use the neighbout cache for matching addresses assigned by SLAAC
+	neigh = __ipv6_neigh_lookup(dev->netdev, nexthop);
+	if (neigh) {
+		list_for_each_entry_rcu(peer, &dev->peers, list) {
+			if (!memcmp(neigh->ha, peer->lladdr, ETH_ALEN)) {
+				neigh_release(neigh);
+				rcu_read_unlock();
+				return peer;
+			}
+		}
+		neigh_release(neigh);
+	}
+
 	rcu_read_unlock();
 
 	return NULL;
-- 
2.20.1


^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH 3/3] bluetooth: 6lowpan: always check destination address
  2019-02-08 15:25 [PATCH 0/3] bluetooth: 6lowpan: multiple peers and addresses Josua Mayer
  2019-02-08 15:25 ` [PATCH 1/3] bluetooth: 6lowpan: search for destination address in all peers Josua Mayer
  2019-02-08 15:25 ` [PATCH 2/3] bluetooth: 6lowpan: check neighbour table for SLAAC Josua Mayer
@ 2019-02-08 15:25 ` Josua Mayer
  2019-02-28 20:00 ` [PATCH 0/3] bluetooth: 6lowpan: multiple peers and addresses Josua Mayer
                   ` (2 subsequent siblings)
  5 siblings, 0 replies; 20+ messages in thread
From: Josua Mayer @ 2019-02-08 15:25 UTC (permalink / raw)
  To: linux-bluetooth
  Cc: Josua Mayer, Marcel Holtmann, Johan Hedberg, David S. Miller

BLE based 6LoWPAN networks are highly constrained in bandwidth.
Do not take a short-cut, always check if the destination address is
known to belong to a peer.

As a side-effect this also removes any behavioral differences between
one, and two or more connected peers.

Signed-off-by: Josua Mayer <josua.mayer@jm0.eu>
---
 net/bluetooth/6lowpan.c | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index 4e14db230793..62b57d3bc0c0 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -175,18 +175,6 @@ static inline struct lowpan_peer *peer_lookup_dst(struct lowpan_btle_dev *dev,
 
 	BT_DBG("peers %d addr %pI6c rt %p", count, daddr, rt);
 
-	/* If we have multiple 6lowpan peers, then check where we should
-	 * send the packet. If only one peer exists, then we can send the
-	 * packet right away.
-	 */
-	if (count == 1) {
-		rcu_read_lock();
-		peer = list_first_or_null_rcu(&dev->peers, struct lowpan_peer,
-					      list);
-		rcu_read_unlock();
-		return peer;
-	}
-
 	if (!rt) {
 		if (ipv6_addr_any(&lowpan_cb(skb)->gw)) {
 			/* There is neither route nor gateway,
-- 
2.20.1


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 0/3] bluetooth: 6lowpan: multiple peers and addresses
  2019-02-08 15:25 [PATCH 0/3] bluetooth: 6lowpan: multiple peers and addresses Josua Mayer
                   ` (2 preceding siblings ...)
  2019-02-08 15:25 ` [PATCH 3/3] bluetooth: 6lowpan: always check destination address Josua Mayer
@ 2019-02-28 20:00 ` Josua Mayer
  2019-02-28 20:30   ` Michael Scott
  2019-03-12 19:16 ` [PATCH v2 " Josua Mayer
  2019-05-13 10:11 ` [PATCH RESEND v2 0/3] bluetooth: 6lowpan: multiple peers and addresses Josua Mayer
  5 siblings, 1 reply; 20+ messages in thread
From: Josua Mayer @ 2019-02-28 20:00 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: marcel, johan.hedberg, davem, jukka.rissanen

Ping

Did anyone get a chance to look at this yet?
@Jukka I have added you in CC since this is about both 6lowpan and ble.

Am 08.02.19 um 16:25 schrieb Josua Mayer:
> Dear maintainers,
> 
> This patch set deals with an issue I reported earlier this year, where
> 1) packets addressed to a non-link-local address
> 2) any packets when at least 2 peers are connected
> were not delivered if they matched a direct peer i.e. no routing.
> 
> The full explanation of the issue including steps to reproduce are:
> https://www.spinics.net/lists/linux-bluetooth/msg78486.html
> 
> Please comment if I am on the right track here, especially on the
> second patch in this series where I am nto completely sure if I found
> the right api call to the neighbour cache.
> 
> Josua Mayer (3):
>   bluetooth: 6lowpan: search for destination address in all peers
>   bluetooth: 6lowpan: check neighbour table for SLAAC
>   bluetooth: 6lowpan: always check destination address
> 
>  net/bluetooth/6lowpan.c | 40 ++++++++++++++++++++++++----------------
>  1 file changed, 24 insertions(+), 16 deletions(-)
> 

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 0/3] bluetooth: 6lowpan: multiple peers and addresses
  2019-02-28 20:00 ` [PATCH 0/3] bluetooth: 6lowpan: multiple peers and addresses Josua Mayer
@ 2019-02-28 20:30   ` Michael Scott
  2019-03-06 18:10     ` Michael Scott
  0 siblings, 1 reply; 20+ messages in thread
From: Michael Scott @ 2019-02-28 20:30 UTC (permalink / raw)
  To: Josua Mayer, linux-bluetooth; +Cc: marcel, johan.hedberg, davem, jukka.rissanen

Hi Josua,

On 2/28/19 12:00 PM, Josua Mayer wrote:
> Ping
>
> Did anyone get a chance to look at this yet?
> @Jukka I have added you in CC since this is about both 6lowpan and ble.
>
> Am 08.02.19 um 16:25 schrieb Josua Mayer:
>> Dear maintainers,
>>
>> This patch set deals with an issue I reported earlier this year, where
>> 1) packets addressed to a non-link-local address
>> 2) any packets when at least 2 peers are connected
>> were not delivered if they matched a direct peer i.e. no routing.
>>
>> The full explanation of the issue including steps to reproduce are:
>> https://www.spinics.net/lists/linux-bluetooth/msg78486.html

Thank you for submitting these patches!  I've been debugging what seems 
to be the very same issue.

My setup:
- a Linux-based gateway running a fairly recent kernel (4.18) connected 
to my local network (and the internet) via wifi/ethernet.
- several Zephyr(RTOS)-based devices (mostly Nordic) connected via BLE 
6lowpan to the gateway
- the gateway provides DNS64 and NAT64 translation, so that the 
IPv6-based nodes can communicate with IPv4 services

Much as you describe, everything works flawlessly when only 1 BLE 
6lowpan node is connected.

Once a 2nd node is connected, all non-link local communication fails.  
Using tcpdump to watch bt0 interface traffic on the gateway: it *looks* 
like the packets are being sent back to the various nodes.  However, on 
the node side those packets are never received.   The very second you 
bring the 2nd node down so that only 1 node is connected, communication 
on non-link local IPs is immediately restored.

NOTE: I can reproduce the same behavior on a 4.20 kernel using my 
laptop, so this issue is still valid.

I should be able to apply these patches to my local setup today or 
tomorrow, and I'll write back regarding the experience.

Thank you again,

- Mike

>>
>> Please comment if I am on the right track here, especially on the
>> second patch in this series where I am nto completely sure if I found
>> the right api call to the neighbour cache.
>>
>> Josua Mayer (3):
>>    bluetooth: 6lowpan: search for destination address in all peers
>>    bluetooth: 6lowpan: check neighbour table for SLAAC
>>    bluetooth: 6lowpan: always check destination address
>>
>>   net/bluetooth/6lowpan.c | 40 ++++++++++++++++++++++++----------------
>>   1 file changed, 24 insertions(+), 16 deletions(-)
>>
-- 
Michael Scott
Embedded Software Engineer at Foundries.io
"microPlatforms™ for Connected Products"
E: mike@foundries.io
W: https://www.foundries.io


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 0/3] bluetooth: 6lowpan: multiple peers and addresses
  2019-02-28 20:30   ` Michael Scott
@ 2019-03-06 18:10     ` Michael Scott
  2019-03-07  9:16       ` Jukka Rissanen
  0 siblings, 1 reply; 20+ messages in thread
From: Michael Scott @ 2019-03-06 18:10 UTC (permalink / raw)
  To: Josua Mayer, linux-bluetooth; +Cc: marcel, johan.hedberg, davem, jukka.rissanen

Josua,

On 2/28/19 12:30 PM, Michael Scott wrote:
> Hi Josua,
>
> On 2/28/19 12:00 PM, Josua Mayer wrote:
>> Ping
>>
>> Did anyone get a chance to look at this yet?
>> @Jukka I have added you in CC since this is about both 6lowpan and ble.
>>
>> Am 08.02.19 um 16:25 schrieb Josua Mayer:
>>> Dear maintainers,
>>>
>>> This patch set deals with an issue I reported earlier this year, where
>>> 1) packets addressed to a non-link-local address
>>> 2) any packets when at least 2 peers are connected
>>> were not delivered if they matched a direct peer i.e. no routing.
>>>
>>> The full explanation of the issue including steps to reproduce are:
>>> https://www.spinics.net/lists/linux-bluetooth/msg78486.html
>
> Thank you for submitting these patches!  I've been debugging what 
> seems to be the very same issue.
>
> My setup:
> - a Linux-based gateway running a fairly recent kernel (4.18) 
> connected to my local network (and the internet) via wifi/ethernet.
> - several Zephyr(RTOS)-based devices (mostly Nordic) connected via BLE 
> 6lowpan to the gateway
> - the gateway provides DNS64 and NAT64 translation, so that the 
> IPv6-based nodes can communicate with IPv4 services
>
> Much as you describe, everything works flawlessly when only 1 BLE 
> 6lowpan node is connected.
>
> Once a 2nd node is connected, all non-link local communication fails.  
> Using tcpdump to watch bt0 interface traffic on the gateway: it 
> *looks* like the packets are being sent back to the various nodes.  
> However, on the node side those packets are never received.   The very 
> second you bring the 2nd node down so that only 1 node is connected, 
> communication on non-link local IPs is immediately restored.
>
> NOTE: I can reproduce the same behavior on a 4.20 kernel using my 
> laptop, so this issue is still valid.
>
> I should be able to apply these patches to my local setup today or 
> tomorrow, and I'll write back regarding the experience.

Apologies for the delay, work has been very busy.

I was able to test these patches and everything works well on my end.  
Feel free to add my Tested-By:

Tested-by: Michael Scott <mike@foundries.io>

>
> Thank you again,
>
> - Mike
>
>>>
>>> Please comment if I am on the right track here, especially on the
>>> second patch in this series where I am nto completely sure if I found
>>> the right api call to the neighbour cache.
>>>
>>> Josua Mayer (3):
>>>    bluetooth: 6lowpan: search for destination address in all peers
>>>    bluetooth: 6lowpan: check neighbour table for SLAAC
>>>    bluetooth: 6lowpan: always check destination address
>>>
>>>   net/bluetooth/6lowpan.c | 40 ++++++++++++++++++++++++----------------
>>>   1 file changed, 24 insertions(+), 16 deletions(-)
>>>
-- 
Michael Scott
Embedded Software Engineer at Foundries.io
"microPlatforms™ for Connected Products"
E: mike@foundries.io
W: https://www.foundries.io


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 0/3] bluetooth: 6lowpan: multiple peers and addresses
  2019-03-06 18:10     ` Michael Scott
@ 2019-03-07  9:16       ` Jukka Rissanen
  0 siblings, 0 replies; 20+ messages in thread
From: Jukka Rissanen @ 2019-03-07  9:16 UTC (permalink / raw)
  To: Michael Scott, Josua Mayer, linux-bluetooth; +Cc: marcel, johan.hedberg, davem

Thanks Mike & Josua,

On Wed, 2019-03-06 at 10:10 -0800, Michael Scott wrote:
> Josua,
> 
> On 2/28/19 12:30 PM, Michael Scott wrote:
> > Hi Josua,
> > 
> > On 2/28/19 12:00 PM, Josua Mayer wrote:
> > > Ping
> > > 
> > > Did anyone get a chance to look at this yet?
> > > @Jukka I have added you in CC since this is about both 6lowpan
> > > and ble.
> > > 

The patches looked ok.

Acked-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>


Cheers,
Jukka



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 2/3] bluetooth: 6lowpan: check neighbour table for SLAAC
  2019-02-08 15:25 ` [PATCH 2/3] bluetooth: 6lowpan: check neighbour table for SLAAC Josua Mayer
@ 2019-03-07 10:41   ` Johan Hedberg
  2019-03-12 16:23     ` Josua Mayer
  0 siblings, 1 reply; 20+ messages in thread
From: Johan Hedberg @ 2019-03-07 10:41 UTC (permalink / raw)
  To: Josua Mayer; +Cc: linux-bluetooth

Hi Josua,

Your patches look fine to me in general, just a very minor thing with
this one:

On Fri, Feb 08, 2019, Josua Mayer wrote:
> +	// use the neighbout cache for matching addresses assigned by SLAAC

C++ comment style isn't used - use /* ... */ instead.

Johan

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 2/3] bluetooth: 6lowpan: check neighbour table for SLAAC
  2019-03-07 10:41   ` Johan Hedberg
@ 2019-03-12 16:23     ` Josua Mayer
  0 siblings, 0 replies; 20+ messages in thread
From: Josua Mayer @ 2019-03-12 16:23 UTC (permalink / raw)
  To: linux-bluetooth

Hi Johan,

Am 07.03.19 um 11:41 schrieb Johan Hedberg:
> Hi Josua,
> 
> Your patches look fine to me in general, just a very minor thing with
> this one:
> 
> On Fri, Feb 08, 2019, Josua Mayer wrote:
>> +	// use the neighbout cache for matching addresses assigned by SLAAC
> 
> C++ comment style isn't used - use /* ... */ instead.
Will change that, and submit a v2 later today, thanks!
> 
> Johan
> 

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH v2 0/3] bluetooth: 6lowpan: multiple peers and addresses
  2019-02-08 15:25 [PATCH 0/3] bluetooth: 6lowpan: multiple peers and addresses Josua Mayer
                   ` (3 preceding siblings ...)
  2019-02-28 20:00 ` [PATCH 0/3] bluetooth: 6lowpan: multiple peers and addresses Josua Mayer
@ 2019-03-12 19:16 ` " Josua Mayer
  2019-03-12 19:16   ` [PATCH v2 1/3] bluetooth: 6lowpan: search for destination address in all peers Josua Mayer
                     ` (6 more replies)
  2019-05-13 10:11 ` [PATCH RESEND v2 0/3] bluetooth: 6lowpan: multiple peers and addresses Josua Mayer
  5 siblings, 7 replies; 20+ messages in thread
From: Josua Mayer @ 2019-03-12 19:16 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: Josua Mayer

This patch set deals with an issue I reported earlier this year, where
1) packets addressed to a non-link-local address
2) any packets when at least 2 peers are connected
were not delivered if they matched a direct peer i.e. no routing.

The full explanation of the issue including steps to reproduce are:
https://www.spinics.net/lists/linux-bluetooth/msg78486.html

Changes since v1:
- changed comment style to c++

Josua Mayer (3):
  bluetooth: 6lowpan: search for destination address in all peers
  bluetooth: 6lowpan: check neighbour table for SLAAC
  bluetooth: 6lowpan: always check destination address

 net/bluetooth/6lowpan.c | 41 +++++++++++++++++++++++++----------------
 1 file changed, 25 insertions(+), 16 deletions(-)

-- 
2.21.0


^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH v2 1/3] bluetooth: 6lowpan: search for destination address in all peers
  2019-03-12 19:16 ` [PATCH v2 " Josua Mayer
@ 2019-03-12 19:16   ` Josua Mayer
  2019-03-12 19:16   ` [PATCH v2 2/3] bluetooth: 6lowpan: check neighbour table for SLAAC Josua Mayer
                     ` (5 subsequent siblings)
  6 siblings, 0 replies; 20+ messages in thread
From: Josua Mayer @ 2019-03-12 19:16 UTC (permalink / raw)
  To: linux-bluetooth
  Cc: Josua Mayer, Jukka Rissanen, Michael Scott, Marcel Holtmann,
	Johan Hedberg, David S. Miller

Handle overlooked case where the target address is assigned to a peer
and neither route nor gateway exist.

For one peer, no checks are performed to see if it is meant to receive
packets for a given address.

As soon as there is a second peer however, checks are performed
to deal with routes and gateways for handling complex setups with
multiple hops to a target address.
This logic assumed that no route and no gateway imply that the
destination address can not be reached, which is false in case of a
direct peer.

Acked-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Tested-by: Michael Scott <mike@foundries.io>
Signed-off-by: Josua Mayer <josua.mayer@jm0.eu>
---
 net/bluetooth/6lowpan.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index a7cd23f00bde..50530561da98 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -187,10 +187,16 @@ static inline struct lowpan_peer *peer_lookup_dst(struct lowpan_btle_dev *dev,
 	}
 
 	if (!rt) {
-		nexthop = &lowpan_cb(skb)->gw;
-
-		if (ipv6_addr_any(nexthop))
-			return NULL;
+		if (ipv6_addr_any(&lowpan_cb(skb)->gw)) {
+			/* There is neither route nor gateway,
+			 * probably the destination is a direct peer.
+			 */
+			nexthop = daddr;
+		} else {
+			/* There is a known gateway
+			 */
+			nexthop = &lowpan_cb(skb)->gw;
+		}
 	} else {
 		nexthop = rt6_nexthop(rt, daddr);
 
-- 
2.21.0


^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH v2 2/3] bluetooth: 6lowpan: check neighbour table for SLAAC
  2019-03-12 19:16 ` [PATCH v2 " Josua Mayer
  2019-03-12 19:16   ` [PATCH v2 1/3] bluetooth: 6lowpan: search for destination address in all peers Josua Mayer
@ 2019-03-12 19:16   ` Josua Mayer
  2019-03-12 19:16   ` [PATCH v2 3/3] bluetooth: 6lowpan: always check destination address Josua Mayer
                     ` (4 subsequent siblings)
  6 siblings, 0 replies; 20+ messages in thread
From: Josua Mayer @ 2019-03-12 19:16 UTC (permalink / raw)
  To: linux-bluetooth
  Cc: Josua Mayer, Jukka Rissanen, Michael Scott, Marcel Holtmann,
	Johan Hedberg, David S. Miller

Like any IPv6 capable device, 6LNs can have multiple addresses assigned
using SLAAC and made known through neighbour advertisements.
After checking the destination address against all peers link-local
addresses, consult the neighbour cache for additional known addresses.

RFC7668 defines the scope of Neighbor Advertisements in Section 3.2.3:
1. "A Bluetooth LE 6LN MUST NOT register its link-local address"
2. "A Bluetooth LE 6LN MUST register its non-link-local addresses with
the 6LBR by sending Neighbor Solicitation (NS) messages ..."

Due to these constranits both the link-local addresses tracked in the
list of 6lowpan peers, and the neighbour cache have to be used when
identifying the 6lowpan peer for a destination address.

Acked-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Tested-by: Michael Scott <mike@foundries.io>
Signed-off-by: Josua Mayer <josua.mayer@jm0.eu>
---
 net/bluetooth/6lowpan.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index 50530561da98..29a4f3d65348 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -171,6 +171,7 @@ static inline struct lowpan_peer *peer_lookup_dst(struct lowpan_btle_dev *dev,
 	struct in6_addr *nexthop;
 	struct rt6_info *rt = (struct rt6_info *)skb_dst(skb);
 	int count = atomic_read(&dev->peer_count);
+	struct neighbour *neigh;
 
 	BT_DBG("peers %d addr %pI6c rt %p", count, daddr, rt);
 
@@ -222,6 +223,20 @@ static inline struct lowpan_peer *peer_lookup_dst(struct lowpan_btle_dev *dev,
 		}
 	}
 
+	/* use the neighbour cache for matching addresses assigned by SLAAC
+	 */
+	neigh = __ipv6_neigh_lookup(dev->netdev, nexthop);
+	if (neigh) {
+		list_for_each_entry_rcu(peer, &dev->peers, list) {
+			if (!memcmp(neigh->ha, peer->lladdr, ETH_ALEN)) {
+				neigh_release(neigh);
+				rcu_read_unlock();
+				return peer;
+			}
+		}
+		neigh_release(neigh);
+	}
+
 	rcu_read_unlock();
 
 	return NULL;
-- 
2.21.0


^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH v2 3/3] bluetooth: 6lowpan: always check destination address
  2019-03-12 19:16 ` [PATCH v2 " Josua Mayer
  2019-03-12 19:16   ` [PATCH v2 1/3] bluetooth: 6lowpan: search for destination address in all peers Josua Mayer
  2019-03-12 19:16   ` [PATCH v2 2/3] bluetooth: 6lowpan: check neighbour table for SLAAC Josua Mayer
@ 2019-03-12 19:16   ` Josua Mayer
  2019-03-30 15:51   ` [PATCH v2 0/3] bluetooth: 6lowpan: multiple peers and addresses Josua Mayer
                     ` (3 subsequent siblings)
  6 siblings, 0 replies; 20+ messages in thread
From: Josua Mayer @ 2019-03-12 19:16 UTC (permalink / raw)
  To: linux-bluetooth
  Cc: Josua Mayer, Jukka Rissanen, Michael Scott, Marcel Holtmann,
	Johan Hedberg, David S. Miller

BLE based 6LoWPAN networks are highly constrained in bandwidth.
Do not take a short-cut, always check if the destination address is
known to belong to a peer.

As a side-effect this also removes any behavioral differences between
one, and two or more connected peers.

Acked-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Tested-by: Michael Scott <mike@foundries.io>
Signed-off-by: Josua Mayer <josua.mayer@jm0.eu>
---
 net/bluetooth/6lowpan.c | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index 29a4f3d65348..0f64e9ef1a3a 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -175,18 +175,6 @@ static inline struct lowpan_peer *peer_lookup_dst(struct lowpan_btle_dev *dev,
 
 	BT_DBG("peers %d addr %pI6c rt %p", count, daddr, rt);
 
-	/* If we have multiple 6lowpan peers, then check where we should
-	 * send the packet. If only one peer exists, then we can send the
-	 * packet right away.
-	 */
-	if (count == 1) {
-		rcu_read_lock();
-		peer = list_first_or_null_rcu(&dev->peers, struct lowpan_peer,
-					      list);
-		rcu_read_unlock();
-		return peer;
-	}
-
 	if (!rt) {
 		if (ipv6_addr_any(&lowpan_cb(skb)->gw)) {
 			/* There is neither route nor gateway,
-- 
2.21.0


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v2 0/3] bluetooth: 6lowpan: multiple peers and addresses
  2019-03-12 19:16 ` [PATCH v2 " Josua Mayer
                     ` (2 preceding siblings ...)
  2019-03-12 19:16   ` [PATCH v2 3/3] bluetooth: 6lowpan: always check destination address Josua Mayer
@ 2019-03-30 15:51   ` Josua Mayer
  2019-05-13 10:11   ` [PATCH RESEND v2 1/3] bluetooth: 6lowpan: search for destination address in all peers Josua Mayer
                     ` (2 subsequent siblings)
  6 siblings, 0 replies; 20+ messages in thread
From: Josua Mayer @ 2019-03-30 15:51 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: johan.hedberg

Has anyone had another chance to look at this? Just hoping it hasn't
ended up in a spam folder ...

Am 12.03.19 um 20:16 schrieb Josua Mayer:
> This patch set deals with an issue I reported earlier this year, where
> 1) packets addressed to a non-link-local address
> 2) any packets when at least 2 peers are connected
> were not delivered if they matched a direct peer i.e. no routing.
> 
> The full explanation of the issue including steps to reproduce are:
> https://www.spinics.net/lists/linux-bluetooth/msg78486.html
> 
> Changes since v1:
> - changed comment style to c++
> 
> Josua Mayer (3):
>   bluetooth: 6lowpan: search for destination address in all peers
>   bluetooth: 6lowpan: check neighbour table for SLAAC
>   bluetooth: 6lowpan: always check destination address
> 
>  net/bluetooth/6lowpan.c | 41 +++++++++++++++++++++++++----------------
>  1 file changed, 25 insertions(+), 16 deletions(-)
> 

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH RESEND v2 0/3] bluetooth: 6lowpan: multiple peers and addresses
  2019-02-08 15:25 [PATCH 0/3] bluetooth: 6lowpan: multiple peers and addresses Josua Mayer
                   ` (4 preceding siblings ...)
  2019-03-12 19:16 ` [PATCH v2 " Josua Mayer
@ 2019-05-13 10:11 ` Josua Mayer
  2019-07-06 11:11   ` Marcel Holtmann
  5 siblings, 1 reply; 20+ messages in thread
From: Josua Mayer @ 2019-05-13 10:11 UTC (permalink / raw)
  To: linux-bluetooth
  Cc: Josua Mayer, johan.hedberg, davem, marcel, jukka.rissanen, mike

This patch set deals with an issue I reported earlier this year, where
1) packets addressed to a non-link-local address
2) any packets when at least 2 peers are connected
were not delivered if they matched a direct peer i.e. no routing.

The full explanation of the issue including steps to reproduce are:
https://www.spinics.net/lists/linux-bluetooth/msg78486.html

Changes since v1:
- changed comment style to c++

Josua Mayer (3):
  bluetooth: 6lowpan: search for destination address in all peers
  bluetooth: 6lowpan: check neighbour table for SLAAC
  bluetooth: 6lowpan: always check destination address

 net/bluetooth/6lowpan.c | 41 +++++++++++++++++++++++++----------------
 1 file changed, 25 insertions(+), 16 deletions(-)

-- 
2.21.0


^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH RESEND v2 1/3] bluetooth: 6lowpan: search for destination address in all peers
  2019-03-12 19:16 ` [PATCH v2 " Josua Mayer
                     ` (3 preceding siblings ...)
  2019-03-30 15:51   ` [PATCH v2 0/3] bluetooth: 6lowpan: multiple peers and addresses Josua Mayer
@ 2019-05-13 10:11   ` Josua Mayer
  2019-05-13 10:12   ` [PATCH RESEND v2 3/3] bluetooth: 6lowpan: always check destination address Josua Mayer
  2019-05-13 10:12   ` [PATCH RESEND v2 2/3] bluetooth: 6lowpan: check neighbour table for SLAAC Josua Mayer
  6 siblings, 0 replies; 20+ messages in thread
From: Josua Mayer @ 2019-05-13 10:11 UTC (permalink / raw)
  To: linux-bluetooth
  Cc: Josua Mayer, Jukka Rissanen, Michael Scott, Marcel Holtmann,
	Johan Hedberg, David S. Miller

Handle overlooked case where the target address is assigned to a peer
and neither route nor gateway exist.

For one peer, no checks are performed to see if it is meant to receive
packets for a given address.

As soon as there is a second peer however, checks are performed
to deal with routes and gateways for handling complex setups with
multiple hops to a target address.
This logic assumed that no route and no gateway imply that the
destination address can not be reached, which is false in case of a
direct peer.

Acked-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Tested-by: Michael Scott <mike@foundries.io>
Signed-off-by: Josua Mayer <josua.mayer@jm0.eu>
---
 net/bluetooth/6lowpan.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index a7cd23f00bde..50530561da98 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -187,10 +187,16 @@ static inline struct lowpan_peer
*peer_lookup_dst(struct lowpan_btle_dev *dev,
 	}
  	if (!rt) {
-		nexthop = &lowpan_cb(skb)->gw;
-
-		if (ipv6_addr_any(nexthop))
-			return NULL;
+		if (ipv6_addr_any(&lowpan_cb(skb)->gw)) {
+			/* There is neither route nor gateway,
+			 * probably the destination is a direct peer.
+			 */
+			nexthop = daddr;
+		} else {
+			/* There is a known gateway
+			 */
+			nexthop = &lowpan_cb(skb)->gw;
+		}
 	} else {
 		nexthop = rt6_nexthop(rt, daddr);
 -- 2.21.0


^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH RESEND v2 3/3] bluetooth: 6lowpan: always check destination address
  2019-03-12 19:16 ` [PATCH v2 " Josua Mayer
                     ` (4 preceding siblings ...)
  2019-05-13 10:11   ` [PATCH RESEND v2 1/3] bluetooth: 6lowpan: search for destination address in all peers Josua Mayer
@ 2019-05-13 10:12   ` Josua Mayer
  2019-05-13 10:12   ` [PATCH RESEND v2 2/3] bluetooth: 6lowpan: check neighbour table for SLAAC Josua Mayer
  6 siblings, 0 replies; 20+ messages in thread
From: Josua Mayer @ 2019-05-13 10:12 UTC (permalink / raw)
  To: linux-bluetooth
  Cc: Josua Mayer, Jukka Rissanen, Michael Scott, Marcel Holtmann,
	Johan Hedberg, David S. Miller

BLE based 6LoWPAN networks are highly constrained in bandwidth.
Do not take a short-cut, always check if the destination address is
known to belong to a peer.

As a side-effect this also removes any behavioral differences between
one, and two or more connected peers.

Acked-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Tested-by: Michael Scott <mike@foundries.io>
Signed-off-by: Josua Mayer <josua.mayer@jm0.eu>
---
 net/bluetooth/6lowpan.c | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index 29a4f3d65348..0f64e9ef1a3a 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -175,18 +175,6 @@ static inline struct lowpan_peer
*peer_lookup_dst(struct lowpan_btle_dev *dev,
  	BT_DBG("peers %d addr %pI6c rt %p", count, daddr, rt);
 -	/* If we have multiple 6lowpan peers, then check where we should
-	 * send the packet. If only one peer exists, then we can send the
-	 * packet right away.
-	 */
-	if (count == 1) {
-		rcu_read_lock();
-		peer = list_first_or_null_rcu(&dev->peers, struct lowpan_peer,
-					      list);
-		rcu_read_unlock();
-		return peer;
-	}
-
 	if (!rt) {
 		if (ipv6_addr_any(&lowpan_cb(skb)->gw)) {
 			/* There is neither route nor gateway,
-- 
2.21.0


^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH RESEND v2 2/3] bluetooth: 6lowpan: check neighbour table for SLAAC
  2019-03-12 19:16 ` [PATCH v2 " Josua Mayer
                     ` (5 preceding siblings ...)
  2019-05-13 10:12   ` [PATCH RESEND v2 3/3] bluetooth: 6lowpan: always check destination address Josua Mayer
@ 2019-05-13 10:12   ` Josua Mayer
  6 siblings, 0 replies; 20+ messages in thread
From: Josua Mayer @ 2019-05-13 10:12 UTC (permalink / raw)
  To: linux-bluetooth
  Cc: Josua Mayer, Jukka Rissanen, Michael Scott, Marcel Holtmann,
	Johan Hedberg, David S. Miller

Like any IPv6 capable device, 6LNs can have multiple addresses assigned
using SLAAC and made known through neighbour advertisements.
After checking the destination address against all peers link-local
addresses, consult the neighbour cache for additional known addresses.

RFC7668 defines the scope of Neighbor Advertisements in Section 3.2.3:
1. "A Bluetooth LE 6LN MUST NOT register its link-local address"
2. "A Bluetooth LE 6LN MUST register its non-link-local addresses with
the 6LBR by sending Neighbor Solicitation (NS) messages ..."

Due to these constranits both the link-local addresses tracked in the
list of 6lowpan peers, and the neighbour cache have to be used when
identifying the 6lowpan peer for a destination address.

Acked-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Tested-by: Michael Scott <mike@foundries.io>
Signed-off-by: Josua Mayer <josua.mayer@jm0.eu>
---
 net/bluetooth/6lowpan.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index 50530561da98..29a4f3d65348 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -171,6 +171,7 @@ static inline struct lowpan_peer
*peer_lookup_dst(struct lowpan_btle_dev *dev,
 	struct in6_addr *nexthop;
 	struct rt6_info *rt = (struct rt6_info *)skb_dst(skb);
 	int count = atomic_read(&dev->peer_count);
+	struct neighbour *neigh;
  	BT_DBG("peers %d addr %pI6c rt %p", count, daddr, rt);
 @@ -222,6 +223,20 @@ static inline struct lowpan_peer
*peer_lookup_dst(struct lowpan_btle_dev *dev,
 		}
 	}
 +	/* use the neighbour cache for matching addresses assigned by SLAAC
+	 */
+	neigh = __ipv6_neigh_lookup(dev->netdev, nexthop);
+	if (neigh) {
+		list_for_each_entry_rcu(peer, &dev->peers, list) {
+			if (!memcmp(neigh->ha, peer->lladdr, ETH_ALEN)) {
+				neigh_release(neigh);
+				rcu_read_unlock();
+				return peer;
+			}
+		}
+		neigh_release(neigh);
+	}
+
 	rcu_read_unlock();
  	return NULL;
-- 
2.21.0


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH RESEND v2 0/3] bluetooth: 6lowpan: multiple peers and addresses
  2019-05-13 10:11 ` [PATCH RESEND v2 0/3] bluetooth: 6lowpan: multiple peers and addresses Josua Mayer
@ 2019-07-06 11:11   ` Marcel Holtmann
  0 siblings, 0 replies; 20+ messages in thread
From: Marcel Holtmann @ 2019-07-06 11:11 UTC (permalink / raw)
  To: Josua Mayer
  Cc: linux-bluetooth, Johan Hedberg, David S. Miller, jukka.rissanen, mike

Hi Josua,

> This patch set deals with an issue I reported earlier this year, where
> 1) packets addressed to a non-link-local address
> 2) any packets when at least 2 peers are connected
> were not delivered if they matched a direct peer i.e. no routing.
> 
> The full explanation of the issue including steps to reproduce are:
> https://www.spinics.net/lists/linux-bluetooth/msg78486.html
> 
> Changes since v1:
> - changed comment style to c++
> 
> Josua Mayer (3):
>  bluetooth: 6lowpan: search for destination address in all peers
>  bluetooth: 6lowpan: check neighbour table for SLAAC
>  bluetooth: 6lowpan: always check destination address
> 
> net/bluetooth/6lowpan.c | 41 +++++++++++++++++++++++++----------------
> 1 file changed, 25 insertions(+), 16 deletions(-)

the patches no longer apply cleanly to bluetooth-next. Can you please update them. Thanks.

Regards

Marcel


^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, back to index

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-08 15:25 [PATCH 0/3] bluetooth: 6lowpan: multiple peers and addresses Josua Mayer
2019-02-08 15:25 ` [PATCH 1/3] bluetooth: 6lowpan: search for destination address in all peers Josua Mayer
2019-02-08 15:25 ` [PATCH 2/3] bluetooth: 6lowpan: check neighbour table for SLAAC Josua Mayer
2019-03-07 10:41   ` Johan Hedberg
2019-03-12 16:23     ` Josua Mayer
2019-02-08 15:25 ` [PATCH 3/3] bluetooth: 6lowpan: always check destination address Josua Mayer
2019-02-28 20:00 ` [PATCH 0/3] bluetooth: 6lowpan: multiple peers and addresses Josua Mayer
2019-02-28 20:30   ` Michael Scott
2019-03-06 18:10     ` Michael Scott
2019-03-07  9:16       ` Jukka Rissanen
2019-03-12 19:16 ` [PATCH v2 " Josua Mayer
2019-03-12 19:16   ` [PATCH v2 1/3] bluetooth: 6lowpan: search for destination address in all peers Josua Mayer
2019-03-12 19:16   ` [PATCH v2 2/3] bluetooth: 6lowpan: check neighbour table for SLAAC Josua Mayer
2019-03-12 19:16   ` [PATCH v2 3/3] bluetooth: 6lowpan: always check destination address Josua Mayer
2019-03-30 15:51   ` [PATCH v2 0/3] bluetooth: 6lowpan: multiple peers and addresses Josua Mayer
2019-05-13 10:11   ` [PATCH RESEND v2 1/3] bluetooth: 6lowpan: search for destination address in all peers Josua Mayer
2019-05-13 10:12   ` [PATCH RESEND v2 3/3] bluetooth: 6lowpan: always check destination address Josua Mayer
2019-05-13 10:12   ` [PATCH RESEND v2 2/3] bluetooth: 6lowpan: check neighbour table for SLAAC Josua Mayer
2019-05-13 10:11 ` [PATCH RESEND v2 0/3] bluetooth: 6lowpan: multiple peers and addresses Josua Mayer
2019-07-06 11:11   ` Marcel Holtmann

Linux-Bluetooth Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-bluetooth/0 linux-bluetooth/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-bluetooth linux-bluetooth/ https://lore.kernel.org/linux-bluetooth \
		linux-bluetooth@vger.kernel.org linux-bluetooth@archiver.kernel.org
	public-inbox-index linux-bluetooth

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-bluetooth


AGPL code for this site: git clone https://public-inbox.org/ public-inbox