mode, without having to guess if network device does it automatically or not
and being forced to handle it in your (higher level) code
(Corrected, compilation-errors free version)
https://tools.ietf.org/html/rfc4944#section-5.3 says:
> If a link fragment that overlaps another fragment is received, as
> identified above, and differs in either the size or datagram_offset
> of the overlapped fragment, the fragment(s) already accumulated in
> the reassembly buffer SHALL be discarded. A fresh reassembly may be
> commenced with the most recently received link fragment.
This patch fixes overflow, which is caused by
(pkt->size - aligned_size). This happens if pkt->size and
new size are unaligned and the difference
between pkt->size and new size is less than four.
When ENABLE_DEBUG is 1, `out` is dereferenced unconditionally, but
`_parse_options` in `gnrc_rpl_control_messages.c` calls it with NULL.
Clarified `out` must not NULL and fixed `_parse_options`.
When `gnrc_ndp_node_next_hop_l2addr` cannot resolve L2 address, it creates a
temporary neighbor cache entry with interface `KERNEL_PID_UNDEF` (unless the
interface is already known) to send a neighbor solicitation. When another packet
directed to the same address is going to sent before receiving a neighbor
advertisement, `gnrc_sixlowpan_nd_next_hop_l2addr` gets the temporary neighbor
cache entry and calls `gnrc_ipv6_netif_get` with `KERNEL_PID_UNDEF`, resulting
get a `NULL`. We must check `NULL` before dereference it.
FYI, both `gnrc_ndp_node_next_hop_l2addr` and
`gnrc_sixlowpan_nd_next_hop_l2addr` are enabled when
`gnrc_sixlowpan_border_router_default` module is enabled with `GNRC_NETIF_NUMOF`
is greater than 1:
gnrc_sixlowpan_border_router_default
→ gnrc_ipv6_router_default
→ gnrc_ndp_router (if GNRC_NETIF_NUMOF > 1)
→ gnrc_ndp_node
→ gnrc_ndp_node_next_hop_l2addr is called from _next_hop_l2addr
gnrc_sixlowpan_border_router_default
→ gnrc_sixlowpan_nd_border_router
→ gnrc_sixlowpan_nd_router
→ gnrc_sixlowpan_nd
→ gnrc_sixlowpan_nd_next_hop_l2addr is called from _next_hop_l2addr
The forms of the Source/Target Link-layer Address option for 6LoWPAN are defined
in RFC 4944 Section 8:
https://tools.ietf.org/html/rfc4944#section-8
The address is 16 bit if length is 1, 64 bit if length is 2.
