Skip to contentSkip to conversation

Bluetooth 6LoWPAN and routing

DISCUSSION Jukka Rissanen 4 participants 10 messages Oct 24, 2013 – Nov 6, 2013

Subsystems (2)
Networking Network drivers
lore
Share & tools
lore

Jukka Rissanen

author
#0 lore raw

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?

Signature · 2 lines
Cheers,
Jukka
#1 lore raw

Hi!

Quoted 5 lines · Jukka Rissanen

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

Quoted 8 lines

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

#2 lore raw
In reply to Jukka Rissanen

Hi Jukka,

Quoted 7 lines · 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

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

author
#3 lore raw

Hi Alexander,

Quoted 5 lines · Alexander Aring

Hi Jukka,

Quoted 2 lines · Jukka Rissanen

Hi,

Quoted 7 lines
Quoted 5 lines

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.

Quoted 6 lines

I have a couple of patches to fix a lot of bugs in the current 6LoWPAN ieee802154 implementation.

Some bugs which I found:

Quoted 8 lines

- 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!

Quoted 5 lines

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?

Quoted 3 lines

- Alex

Signature · 2 lines
Cheers,
Jukka
#4 lore raw

Hi Jukka,

Quoted 34 lines · Jukka Rissanen

Hi Alexander,

Quoted 7 lines · Alexander Aring

Hi Jukka,

Quoted 3 lines · Jukka Rissanen

Hi,

Quoted 7 lines
Quoted 5 lines

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.

Quoted 10 lines

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

Quoted 7 lines
Quoted 4 lines

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

#5 lore raw
Quoted 44 lines · Claudio Takahasi

Hi Jukka,

Quoted 40 lines · Jukka Rissanen

Hi Alexander,

Quoted 7 lines · Alexander Aring

Hi Jukka,

Quoted 3 lines · Jukka Rissanen

Hi,

Quoted 7 lines
Quoted 5 lines

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.

Quoted 14 lines

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.

Quoted 9 lines
Quoted 1 line

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

author
#6 lore raw
In reply to Claudio Takahasi

Hi Claudio,

Quoted 44 lines · Claudio Takahasi

Hi Jukka,

Quoted 40 lines · Jukka Rissanen

Hi Alexander,

Quoted 7 lines · Alexander Aring

Hi Jukka,

Quoted 3 lines · Jukka Rissanen

Hi,

Quoted 7 lines
Quoted 5 lines

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.

Quoted 14 lines

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.

Quoted 7 lines
Quoted 1 line

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.

Quoted 8 lines

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

#7 lore raw

Hi Jukka,

Quoted 55 lines · Jukka Rissanen

Hi Claudio,

Quoted 44 lines · Claudio Takahasi

Hi Jukka,

Quoted 40 lines · Jukka Rissanen

Hi Alexander,

Quoted 7 lines · Alexander Aring

Hi Jukka,

Quoted 3 lines · Jukka Rissanen

Hi,

Quoted 7 lines
Quoted 5 lines

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.

Quoted 14 lines

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.

Quoted 7 lines
Quoted 1 line

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.

Quoted 5 lines

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

#8 lore raw
In reply to Jukka Rissanen
Quoted 50 lines · Jukka Rissanen

Hi Claudio,

Quoted 47 lines · Claudio Takahasi

Hi Jukka,

Quoted 41 lines · Jukka Rissanen

Hi Alexander,

Quoted 7 lines · Alexander Aring

Hi Jukka,

Quoted 3 lines · Jukka Rissanen

Hi,

Quoted 7 lines
Quoted 5 lines

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.

Quoted 6 lines

I have a couple of patches to fix a lot of bugs in the current 6LoWPAN ieee802154 implementation.

Some bugs which I found:

Quoted 8 lines

- 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!

Quoted 8 lines
Quoted 4 lines

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

#9 lore raw

Hi Jukka/Alexander:

Quoted 56 lines · Alexander Aring
Quoted 55 lines · Jukka Rissanen

Hi Claudio,

Quoted 51 lines · Claudio Takahasi

Hi Jukka,

Quoted 34 lines · Jukka Rissanen

Hi Alexander,

Quoted 7 lines · Alexander Aring

Hi Jukka,

Quoted 3 lines · Jukka Rissanen

Hi,

Quoted 7 lines
Quoted 5 lines

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.

Quoted 10 lines

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

Quoted 7 lines
Quoted 4 lines

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.

Quoted 7 lines
Quoted 3 lines

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