Subject: Re: [PATCH 0/3] bluetooth: 6lowpan: multiple peers and addresses
To:     Josua Mayer <josua.mayer@jm0.eu>, linux-bluetooth@vger.kernel.org
Cc:     marcel@holtmann.org, johan.hedberg@gmail.com, davem@davemloft.net,
        jukka.rissanen@linux.intel.com
References: <20190208152519.16181-1-josua.mayer@jm0.eu>
 <a0d7f533-964c-7d5b-69be-840c26d05fd8@jm0.eu>
From:   Michael Scott <mike@foundries.io>
Message-ID: <12348b37-c8ef-cf4a-a86e-ab09fadbc792@foundries.io>
Date:   Thu, 28 Feb 2019 12:30:44 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <a0d7f533-964c-7d5b-69be-840c26d05fd8@jm0.eu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

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