patchlwIP - A Lightweight TCP/IP stack - Patches: patch #9364, RFC7668 - 6lowpan over Bluetooth...


You are not allowed to post comments on this tracker with your current authentication level.

patch #9364: RFC7668 - 6lowpan over Bluetooth Low Energy -- a new netif

Submitted by:  Aigner B. <aignerb>
Submitted on:  Mon 29 May 2017 04:37:21 PM UTC  
Category:  Network drivers Priority:  5 - Normal
Status:  Done Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Planned Release:  None

( Jump to the original submission)

Thu 22 Mar 2018 02:32:38 PM UTC, comment #16: 

Hi Simon,

I've added your mentioned methods to my example code (although I don't activate them until esp-idf updates to lwIP):

-) Address is set on L2CAP_EVENT_LE_INCOMING_CONNECTION via:
rfc7668_set_peer_addr_mac48(&rfc7668_netif,(uint8_t *)src.addr,6,1);

-) Input is sent directly to lwIP by using tcpip_inpkt:

I think SAC/DAC compression should be used in RFC7668:

Aigner B. <aignerb>
Wed 21 Mar 2018 10:02:10 PM UTC, comment #15: 

Benjamin, I've just pushed the change where lowpan6_ble uses common code. The 'ble_addr_to_eui64()' function will be moved to common code, so you should now use 'rfc7668_set_peer_addr_mac48()' if your BLE peer address changes.

Note that this combination adds support for compressed addresses to BLE from the IEE 802.15.4 implementation, which might or might not be correct...

Simon Goldschmidt <goldsimon>
Project Administrator
Thu 15 Mar 2018 06:45:42 PM UTC, comment #14: 

>  Q&D, but it works

No, it doesn't. Your function will simply get called with the arguments of the expected prototype. In your case, peer_adds will be random.

Simon Goldschmidt <goldsimon>
Project Administrator
Thu 15 Mar 2018 11:43:19 AM UTC, comment #13: 

-) I changed pbuf_alloc, and added a NULL pointer check
-) Moved ble_addr_to_eui64 into incoming connection

Regarding peer_addr: I had this problem, and had a workaround by passing an incompatible fpointer to tcpip_inpkt. Q&D, but it works.
I'm open to any clean solution :-)

To test this setup, you only need an ESP32 and a Linux machine with BLE (Raspi3 works as well). The readme of my projects shows how to open a connection.

Aigner B. <aignerb>
Wed 14 Mar 2018 09:15:47 PM UTC, comment #12: 

BTW: I have an ESP32 on my desk here, only waiting for a remote station to test it after all my source code conversions are done :-)

Simon Goldschmidt <goldsimon>
Project Administrator
Wed 14 Mar 2018 09:14:29 PM UTC, comment #11: 

OK while we're at it, you seem to be missing to set tot_len of the allocated pbuf. You should pass 'size' to pbuf_alloc() instead of 127. Then you only have to change p->payload. Also, check for NULL return value!

And I see no reason to call ble_addr_to_eui64() for every RX packet when 'peer_addr' only changes with L2CAP_EVENT_LE_INCOMING_CONNECTION packets...

Next, we'd need a way to pass 'peer_addr' via tcpip_inpkt(), which unfortunately only takes pbuf and netif pointers. Maybe a good solution is to somehow set 'peer_addr' as netif-related data. Something like 'rfc7668_if_set_peer_addr(peer_addr)'? Since we only have one peer for BLE for now, this might work.

Simon Goldschmidt <goldsimon>
Project Administrator
Wed 14 Mar 2018 09:07:25 PM UTC, comment #10: 

Thank you very much Simon for your efforts and your notes on my example (as I said, I've never done lwIP internals :-)).

Aigner B. <aignerb>
Wed 14 Mar 2018 02:40:07 PM UTC, comment #9: 

Exactly. By now, I have work in progress of merging the two 6LoWPAN netifs. I'll add a common address struct for the two. Just wanted to hear about your reasons to do it like you did.

Simon Goldschmidt <goldsimon>
Project Administrator
Wed 14 Mar 2018 02:07:49 PM UTC, comment #8: 

Regarding the input struct/address:

-) You mean the IPv6 struct, which is currently used in rfc7668_input

-) There should be a BLE_EUI64 struct, which is used in rfc7668_input, which is filled on L2CAP data event (like it is done now).

Am I right?

If yes, I will update the patch. If no, I need some additional advice :-)

Aigner B. <aignerb>
Wed 14 Mar 2018 02:03:39 PM UTC, comment #7: 

Example code is changed to use PBUF_REF.
Sry, never done anything in LwIP before :-).

Aigner B. <aignerb>
Wed 14 Mar 2018 01:48:44 PM UTC, comment #6: 

Well, the problem is you fill in the BLE IID (which is 64 bit) into the lower half of an ip6_addr_t and later move it to the upper half. This simply isn't correct. Being like that, I think a common address struct that indicates the address length without being accidentally taken as a valid IPv6 address is cleaner.

(BTW, looking at your example code, it's not allowed to assign p->payload of a PBUF_RAM to something else. Eventually things may go wrong if you do that. Use PBUF_REF instead.)

Simon Goldschmidt <goldsimon>
Project Administrator
Wed 14 Mar 2018 01:40:48 PM UTC, comment #5: 

Dear Simon,

it's good to see that something is happening with my code :-).
Although I think I'm focusing on BLE Mesh for this kind of application, but I still be glad to help you.

Of course its possible to use the ieee_802154_addr, I thought it should be an IPv6 address due to compatibility to IPv6 layers above this netif.

If you think it is no problem to use the other addr struct, its good.

Aigner B. <aignerb>
Tue 13 Mar 2018 07:16:36 PM UTC, comment #4: 

it seems like I'm maintaining the code :-)
I have refactored the 6LoWPAN/802.15.4 code a bit and it seems we could easily merge the two when changing the address passed into the module ('ieee_802154_addr' vs 'ip6_addr_t') and skipping fragmentation/reassembly for BLE.
That brings me to the question why you are using ip6_addr_t here when in fact you are only 8 bytes for the address, not 16.
I guess I'll clean that up and make up a common link layer address.

Simon Goldschmidt <goldsimon>
Project Administrator
Sun 04 Mar 2018 08:02:34 AM UTC, comment #3: 

Added to rep by Simon

Dirk Ziegelmeier <dziegel>
Project Administrator
Mon 29 May 2017 08:20:41 PM UTC, comment #2: 

Ok, I understand.
I can extract equal functionality to a different file, if you want. Or do you recommend a different approach?

Regarding the 6lowpan implementation:
I can put shared function in an extra file, but I cannot change the 6lowpan implementation (not enough time, no equipment to test).

Who is currently maintaining the 6lowpan code?

Aigner B. <aignerb>
Mon 29 May 2017 07:24:17 PM UTC, comment #1: 

The improved documentation is really a step forward for the 6lowpan code.

> Regarding the discussion on the similarity to 6lowpan:
> I think it should be separated code, due to some key
> differences on fragmentation (not used here, L2CAP takes care
> of it) and address handling.

I haven't found the time yet to compare the code in detail, but comparing your C file attached in this patch to the current version of our lowpan6.c file, there are far too many common or simila lines to keep them different!

We definitively can't afford to maintain this code twice!

Simon Goldschmidt <goldsimon>
Project Administrator
Mon 29 May 2017 04:37:21 PM UTC, original submission:  

Dear lwIP team,
I've implemented a new network interface, which supports the 6lowpan over BLE network.
Currently working with MQTT-SN, ICMPv6 and UDP6 (no further protocols tested).
Test setup:
ESP32 with BTStack as Bluetooth stack + Debian PC.

A connection can be made via the bluetooth_6lowpan kernel module (see Nordic Semiconductor docs: )

Further test software is available at the ESP-IDF repo:
I will do further programming on upper layers, so there might be an update on test cases,....

Best wishes & thx for this piece of software!

PS: @Simon: Hopefully you are satisfied with my homework :-).
Regarding the discussion on the similarity to 6lowpan:
I think it should be separated code, due to some key differences on fragmentation (not used here, L2CAP takes care of it) and address handling.

Aigner B. <aignerb>


Attached Files


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by dziegel (Posted a comment)
  • -email is unavailable- added by goldsimon (Posted a comment)
  • -email is unavailable- added by aignerb (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-03-04 dziegel StatusNone => Done
        Open/ClosedOpen => Closed
    2017-05-29 aignerb Attached File- => Added 0001-Added-a-RFC7668-netif.patch, #40809

    Back to the top

    Powered by Savane 3.5