Subject: Re: [PATCH 0/3] bluetooth: 6lowpan: multiple peers and addresses
From:   Michael Scott <mike@foundries.io>
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>
 <12348b37-c8ef-cf4a-a86e-ab09fadbc792@foundries.io>
Message-ID: <eb35ff67-1ec8-d5b6-05b9-b065ade27335@foundries.io>
Date:   Wed, 6 Mar 2019 10:10:50 -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: <12348b37-c8ef-cf4a-a86e-ab09fadbc792@foundries.io>
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

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