gnrc_sixlowpan: Preserve order when replacing 6lowpan header by decoded IPv6 header

[jnohlgard]

This fixes a very difficult to trace hard fault on a 6lbr when forwarding a reassembled fragmented UDP packet from 6lowpan to ethos (or another larger MTU device).
Without this change, the packet snips were arranged in the following order:
netiif->udp->ipv6
After this change the snips are:
udp->ipv6->netif

This caused a hard fault at gnrc_ipv6.c:826 trying to pktbuf release a NULL pointer.

The cause of the issue was that the 6lo header was the old head of the snip list:
6lo->netif
and in the old code, removing the 6lo header made netif the new head, and the decoded header was appended to the netif snip.

I tested this with #4544 and #4935 applied and IPHC UDP NHC reenabled.

The hard fault is gone but now the UDP checksum on the packet coming out on the ethos pipe is wrong, according to Wireshark.

[miri64]

Did you find out why the UDP checksum is wrong? Wrong decompression or wrong reassembly might be the cause. I would like to have this fixed beforehand.

[jnohlgard]

I'm guessing reassembly. I noticed that the packet is too small as well...

[miri64]

Is this with #4935 or without?

[jnohlgard]

both #4935 and #4544 applied

[miri64]

(#4935 does not reassemble the packet in an payload->udp->ipv6->netif manner because it was way easier to just reassemble the IPv6 datagram in one snip and let IPv6 do the disentangling as it does for Ethernet)

[miri64]

(so the result with #4935 after reassembly should be a packet payload->netif)

[jnohlgard]

Okay, then I believe the actual cause is not corrected, but this PR solves a crash

[jnohlgard]

rebased.

[jnohlgard]

@authmillenon ping

[miri64]

Just am looking into it… but I'm still trying to find a test scenario for this :/

[miri64]

Thought for some reason that this involved forwarding... Tested with a simple UDP example and it worked.

ACK and go.