GNRC's 6LoWPAN implementation. More...
GNRC's 6LoWPAN implementation.
Internally, 6LoWPAN is sub-divided into several sub-modules. They implement certain features of the 6LoWPAN standard. Currently implemented are
Each sub-module has a
recv function prefixed by their respective sub-module name with the following signatures
A 6LoWPAN frame
pkt must pass the sub-modules sequentially in the order of its dispatches on receive or the step that makes most sense next on send. After it was passed into another sub-module using the respective
recv function a sub-module must not operate on the
ctx parameter can be used to provide data structures of a sub-module to the next sub-module if that needs to modify or read them (e.g. reassembly buffer state for IPHC) otherwise, leave it
page parameter is to provide a sub-module the current parsing page context according to RFC 8025.
To interact with other modules this module handles the following GNRC communication interface message types:
GNRC_NETAPI_MSG_TYPE_RCV expects a Packet (referred to as "packet" in the following) in receive order (link-layer payload first, Generic network interface header last) with the payload marked with GNRC_NETTYPE_SIXLOWPAN. Every other packet will be silently discarded.
If the first byte of the payload is SIXLOWPAN_UNCOMP this byte will be removed by marking it with a new gnrc_pktsnip_t and then removing this gnrc_pktsnip_t, the remaining payload will be marked with GNRC_NETTYPE_IPV6 and this module will issue a GNRC_NETAPI_MSG_TYPE_RCV to all subscribers registered to GNRC_NETTYPE_IPV6 with demultiplex context GNRC_NETREG_DEMUX_CTX_ALL in the Network protocol registry with the packet. Otherwise, the packet will be silently discarded (except for the cases documented below).
Depending on which other modules are included the behavior can be a little different:
GNRC_NETAPI_MSG_TYPE_SND expects a Packet (referred to as "packet" in the following) in send order (headers first, payload last) with the first header being a valid GNRC_NETTYPE_NETIF header and the second a GNRC_NETTYPE_IPV6 header. Every other packet will be silently discarded.
The GNRC_NETTYPE_SIXLOWPAN header must at least have the gnrc_netif_hdr_t::if_pid field set to a legal, 6LoWPAN compatible interface referred to as
netif in the following, otherwise the packet will be discarded.
If IPv6 header compression (IPHC) is included and GNRC_NETIF_FLAGS_6LO_HC is enabled for
netif the GNRC_NETTYPE_IPV6 header will be compressed according to RFC 6282, section 3. If it is false the SIXLOWPAN_UNCOMP dispatch will be appended as a new gnrc_pktsnip_t to the packet. The false case also applies if IPv6 header compression (IPHC) is not included.
If the packet without GNRC_NETTYPE_NETIF header is shorter than gnrc_netif_t::sixlo::max_frag_size of
netif the packet will be send to the
netif's thread. Otherwise if 6LoWPAN Fragmentation is included the packet will be fragmented according to RFC 4944, section 5.3 if the packet is without GNRC_NETTYPE_NETIF header shorter than SIXLOWPAN_FRAG_MAX_LEN. If none of these cases apply, the packet will be discarded silently.
GNRC_NETAPI_MSG_TYPE_SET is not supported.
GNRC_NETAPI_MSG_TYPE_GET is not supported.
|6LoWPAN Fragmentation headers and functionality |
|6LoWPAN neighbor discovery|
|Neighbor Discovery Optimization for 6LoWPAN. |
|6LoWPAN selective fragment recovery|
|6LoWPAN selective fragment recovery implementation for GNRC |
|Contexts for 6LoWPAN address compression|
|Context buffer for stateful 6LoWPAN address compression. |
|GNRC 6LoWPAN compile configurations|
|IPv6 header compression (IPHC)|
|IPv6 header compression for 6LoWPAN. |
|Definitions for 6LoWPAN. |
|6LoWPAN internal functions |
|Initialization of the 6LoWPAN thread. More...|
Initialization of the 6LoWPAN thread.
If 6LoWPAN was already initialized, it will just return the PID of the 6LoWPAN thread.