6LoWPAN over BLE (RFC7668)

[Dominaezzz]

I'm looking at implementing this with an ESP32 and trouble.

From reading various RFCs it seems to be a somewhat straightforward affair.
One just needs a L2CAP channel and a minimal GATT service for advertising, which trouble supports.

The network forms a star topology where the "Central" is the router and the "Peripheral"s are nodes in the network.
All communications between nodes/peripherals happen via the router/central.
Central is responsible for connecting to nodes advertising themselves as nodes.
Each node (including the router) has a link-local IPv6 address derived from the BLE mac address, but can still register additional non-link-local addresses using standard IPv6 protocols like Neighbour Solicitation (NS).

The L2CAP channel takes care throttling (with the credits system) and disassembly/re-assembly.

The IPv6 headers sent over BLE are compressed in the same format used for IEEE 802.15.4, but the conditions for when to compress are different.

Multicast is an O(n) operation (where n is the number of nodes) rather than a O(1) operation, due to the star topology.

I've mostly gotten the mac logic down, I just need a networking stack to handle the networking.

I looked into implementing the Device trait and I'm trying to figure out which medium to use. Do I need to PR a BLE medium or can I just use the Ip medium.

I'm still trying to figure out if I need to modify smoltcp to work with BLE or if I can do it all behind the Device trait.

[Dominaezzz]

From discussions over Matrix with @Dirbaio it appears I just need a new medium for 6LowPan without ieee802154 headers, this can then be shipped over the L2CAP channel.

I just need to figure out if the IPv6 header compression is similar enough to just work on BLE as well

[Dominaezzz]

• The IPHC wire file needs to have ieee802154 removed from it. Not sure what the protocol-agnostic replacement is yet, maybe it could be generic. Or a EUI64 perhaps.

[thvdveld]

We should indeed rewrite parts of the wire IPHC file. The rules differ quite a lot for compression and decompression of the source and destination address, and only using an EUI64 address will not be enough. For example, for IEEE 802.15.4, the compression is based on the use of the short link layer address, the extended link layer address, or the use of the EUI64 address, while this is not the case for BLE.

Also note that Neighbor Discovery Optimization for 6LoWPAN is not implemented yet (https://datatracker.ietf.org/doc/html/rfc6775), which defines how to handle the 6LoWPAN Context Option. This option MUST be used by the 6LBR when sending a Router Advertisement. However, we are not able yet to process it.

As @Dirbaio says, we need a new medium that only uses 6LoWPAN compression and adapt the compression and decompression for the source and destination address.

[Dominaezzz]

Given the compression differs between the 6LoWPAN mediums, does a 6LoWPAN medium actually make sense by itself?
How would a Device let smol know which compression scheme to use?

[thvdveld]

We can do that by using the device capabilities.
https://github.com/smoltcp-rs/smoltcp/blob/main/src/phy/mod.rs#L232-L275

[Dominaezzz]

Sure but in that case the medium would have to be BLE, not 6LoWPAN.

Unless you're thinking Medium::Sixlowpan(Compression::Ble)

[Dominaezzz]

After some more reading I've figured out what changes need to be made to the iphc file.
We basically need something like UnresolvedAddress to replace the use of ieee802154::Address in Repr.
I'll try making a PR for this.

[Dominaezzz]

Looks like the decompression algo is incorrect here?

smoltcp/src/iface/interface/sixlowpan.rs

Line 728 in 3988338

length: ext_repr.length / 8,

It should be length: (ext_repr.length + 2).div_ceil(8) - 1

[thvdveld]

Yes, you are totally right! Is it possible that it could also be + 3 when the next header field is inlined?

[Dominaezzz]

We're calculating the decompressed length, which means the next header is always going to be inlined. The +2 accounts for that. +1 for next header and +1 for the length.

[thvdveld]

Ah yes, I was a bit confused, but I get it now. You're right about length: (ext_repr.length + 2).div_ceil(8) - 1. Could you make a pull request for that?

[Dominaezzz]

Could you make a pull request for that?

If it were that simple I would. There's another bug now that the length has been corrected.
There needs to be extra padding added to the end the data to make sure it aligns to 8 bytes.
Dunno the right way to do that in smoltcp. (I'm using etherparse for my encode/decode)