Bluetooth 6LoWPAN and routing

Bluetooth 6LoWPAN and routing

[Jukka Rissanen]

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

In this current prototype, after the BT connection is created, the code 
set ups the virtual network interface, sets the IPv6 LL address for it 
and creates an IPv6 route to peer (the BT 6LoWPAN connections are 
point-to-point connections). I am using ip6_route_add() function from 
net/ipv6/route.c file to do that. Unfortunately that function is not 
exported so I GPL exported it for this prototype. Will this kind of 
export accepted in upstream or should I figure out some other way to 
create the desired route?


-- 
Cheers,
Jukka

Re: Bluetooth 6LoWPAN and routing

[Hannes Frederic Sowa]

Hi!

On Thu, Oct 24, 2013 at 09:45:40AM +0300, Jukka Rissanen wrote:
> 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
> 
> In this current prototype, after the BT connection is created, the code 
> set ups the virtual network interface, sets the IPv6 LL address for it 
> and creates an IPv6 route to peer (the BT 6LoWPAN connections are 
> point-to-point connections). I am using ip6_route_add() function from 
> net/ipv6/route.c file to do that. Unfortunately that function is not 
> exported so I GPL exported it for this prototype. Will this kind of 
> export accepted in upstream or should I figure out some other way to 
> create the desired route?

I am very confident that a patch making ip6_route_add gpl exported will be
accepted.

Greetings,

  Hannes

Re: Bluetooth 6LoWPAN and routing

[Alexander Aring]

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)

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.

But my question is:

What we do now, make a generic 6LoWPAN implementation. Or bluetooth,
ieee802154 makes his own implementation?

- Alex

Re: Bluetooth 6LoWPAN and routing

[Jukka Rissanen]

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!

>
> But my question is:
>
> What we do now, make a generic 6LoWPAN implementation. Or bluetooth,
> ieee802154 makes his own implementation?

At least the compression/uncompression code and fragmentation could be 
shared. Could it possible to isolate relevant functions to separate file 
that would be usable by both BT and ieee802154?

>
> - Alex
>

-- 
Cheers,
Jukka

Re: Bluetooth 6LoWPAN and routing

[Claudio Takahasi]

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.
What am I missing here?

It seems that some BLE development kits/firmwares don't support FAR on
L2CAP Basic Mode, but this is another problem that should be fixed
soon.

Regards,
Claudio

Re: Bluetooth 6LoWPAN and routing

[Alexander Aring]

On Mon, Nov 04, 2013 at 07:46:06PM -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.
> What am I missing here?
>
mhh, I look a little bit deeper in the 6LoWPAN bluetooth draft and indeed
it can be handled via L2CAP FAR. I saw the fragmentation struct in the
rfc implementation(struct lowpan_fragment) but it isn't used in any case
so Jukka can drop this from the rfc implementation. Sorry about that.

But I don't see udp compression/uncompression in Jukka's rfc
implementation. But this is a part of rfc 6282 which should blte 6LoWPAN
should use?

So the 6LoWPAN fragmentation thing (rfc4944) is only ieee802154 specific.

- Alex

Re: Bluetooth 6LoWPAN and routing

[Jukka Rissanen]

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.

> What am I missing here?
> 
> It seems that some BLE development kits/firmwares don't support FAR on
> L2CAP Basic Mode, but this is another problem that should be fixed
> soon.
> 
> Regards,
> Claudio


Cheers,
Jukka

Re: Bluetooth 6LoWPAN and routing

[Alexander Aring]

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

Re: Bluetooth 6LoWPAN and routing

[Alexander Aring]

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
ahh I understand now, yes that's handled by the normal IPv6 Fragmentation.
But you don't want a high payload like this. ;)

- Alex

Re: Bluetooth 6LoWPAN and routing

[Claudio Takahasi]

Hi Jukka/Alexander:

On Tue, Nov 5, 2013 at 5:55 AM, Alexander Aring <alex.aring@gmail.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@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
> 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