Re: Bluetooth 6LoWPAN and routing

[Alexander Aring <alex.aring@gmail.com>]

Hi Jukka,

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@linux.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
> of the networking subsystem.
> 

In [1] you use the fragmentation according rfc4944 which isn't for
bluetooth correct. [2] says:

"Since FAR in BT-LE is a function of the L2CAP layer, fragmentation
functionality as defined in RFC 4944 [RFC4944] MUST NOT be used in
BT-LE networks."

MUST NOT, so you can't use it.

[1] http://article.gmane.org/gmane.linux.bluez.kernel/39397
    lowpan_process_data function and the first part of evaluating dispatch
    value. This code is the most ugly code in 6lowpan but I will rework
    it this right now... Only few problems with the skb_checksum because
    I uncompress the header after fragmentation(I think so).
    
    Of course that's only the receiving side, you need to check the
    transmit side.
[2] http://tools.ietf.org/html/draft-ietf-6lowpan-btle-12#section-3.2

- Alex