netdev - Re: Bluetooth 6LoWPAN and routing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 6 Nov 2013 12:17:12 -0200
From:	Claudio Takahasi <claudio.takahasi@...nbossa.org>
To:	Alexander Aring <alex.aring@...il.com>
Cc:	Jukka Rissanen <jukka.rissanen@...ux.intel.com>,
	netdev@...r.kernel.org
Subject: Re: Bluetooth 6LoWPAN and routing

Hi Jukka/Alexander:

On Tue, Nov 5, 2013 at 5:55 AM, Alexander Aring <alex.aring@...il.com> wrote:
> On Tue, Nov 05, 2013 at 10:36:29AM +0200, Jukka Rissanen wrote:
>> Hi Claudio,
>>
>> On ma, 2013-11-04 at 19:46 -0200, Claudio Takahasi wrote:
>> > Hi Jukka,
>> >
>> > On Thu, Oct 24, 2013 at 9:48 AM, Jukka Rissanen
>> > <jukka.rissanen@...ux.intel.com> wrote:
>> > > Hi Alexander,
>> > >
>> > >
>> > > On 24.10.2013 15:25, Alexander Aring wrote:
>> > >>
>> > >> Hi Jukka,
>> > >>
>> > >> On Thu, Oct 24, 2013 at 09:45:40AM +0300, Jukka Rissanen wrote:
>> > >>>
>> > >>> Hi,
>> > >>>
>> > >>> I have been prototyping with BT 6LoWPAN support (using this draft
>> > >>> http://tools.ietf.org/html/draft-ietf-6lowpan-btle-12 as a
>> > >>> reference). I sent first version yesterday to linux-bluetooth ml
>> > >>> http://thread.gmane.org/gmane.linux.bluez.kernel/39394
>> > >>>
>> > >> I see you take many code from the 6lowpan ieee802154 implementation.
>> > >> (Just notice you drop the original authors from there)
>> > >
>> > >
>> > > Hmm, those got dropped, I am sorry about that. I will add the original
>> > > authors information of course.
>> > >
>> > >
>> > >>
>> > >> I have a couple of patches to fix a lot of bugs in the current 6LoWPAN
>> > >> ieee802154 implementation.
>> > >>
>> > >> Some bugs which I found:
>> > >>
>> > >>    - Fix race conditions in fragmentation handling
>> > >>    - Fix UDP compression/uncompressionm, which is completly broken
>> > >>    - Fragmentation handling isn't rfc4944 compatible
>> > >>
>> > >> And some other improvements. I see your rfc has the same issues (e.g.
>> > >> fragmentation race conditions).
>> > >>
>> > >> Currently I preparing these patches for mainlining.
>> > >
>> > >
>> > > Excellent news!
>> >
>> >
>> > Is it necessary to implement 6loWPAN fragmentation/reassembling? For
>> > Bluetooth, I thought L2CAP FAR (Fragmentation and Reassembling) could
>> > handle the transfer of IPv6 packets that doesn't fit in one single
>> > BTLE PDU.
>>
>> Yes, the Bluetooth 6lowpan code I sent handles the L2CAP FAR already.
>> The question is who handles the IPv6 packets that are larger than
>> IPV6_MIN_MTU (1280 bytes), or is that automatically done by other parts
> ahh I understand now, yes that's handled by the normal IPv6 Fragmentation.
> But you don't want a high payload like this. ;)
>
> - Alex


I still not convinced that we need to worry about 6loWPAN
fragmentation now. Use fixed channel is only a way to implement the
initial 6loWPAN support, (if necessary) you can push the fragmentation
code later, it will make your upstreaming work easier.

Maybe you read this Bluetooth SIG draft already: IPSS (Internet
Protocol Support Service). It contains some infos about fixed vs
dynamic channels, MTU and flow control.

Regards,
Claudio
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html