6lowpan: fix fragmentation on sending side

This patch fix the fragmentation on sending side according to rfc4944.

Also add improvement to use the full payload of a PDU which calculate the
nearest divided to 8 payload length for the fragmentation datagram
offset attribute.

The main issue is that the datagram_size of fragmentation header use the
ipv6 payload length, but rfc4944 says it's the ipv6 payload length inclusive
network header size (and transport header size if compressed).

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
net: add ieee802154_6lowpan namespace

This patch adds necessary ieee802154 6lowpan namespace to provide the
inet_frag information. This is a initial support for handling 6lowpan
fragmentation with the inet_frag api.

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
6lowpan: handling 6lowpan fragmentation via inet_frag api

This patch drops the current way of 6lowpan fragmentation on receiving
side and replace it with a implementation which use the inet_frag api.
The old fragmentation handling has some race conditions and isn't
rfc4944 compatible. Also adding support to match fragments on
destination and source address which is missing in the current
implementation.

This patch add also a lookup function for uncompressed 6LoWPAN header
size. This is needed to estimate the real size of fragmented packet.

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
6lowpan: handle return value on lowpan_process_data

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
6lowpan: fix udp nullpointer dereferencing

Sometimes a nullpointer dereferencing occurs because of using a wrong
pointer arithmetic in udp_uncompression.

This patch changes "**(hc06_ptr + 3)" to the right one "*(*hc06_ptr +
3)". Dereferencing like "**(hc06_ptr + 3)" works in a random case only.
6lowpan: fix udp compress ordering

In case ((ntohs(uh->source) & LOWPAN_NHC_UDP_8BIT_MASK) the order of
uncompression is wrong. It's always first source port then destination
port as second.

See:
http://tools.ietf.org/html/rfc6282#section-4.3.3

"Fields carried in-line (in part or in whole) appear in the same order
as they do in the UDP header format"
6lowpan: fix udp byte ordering

The incoming udp header in lowpan_compress_udp_header function is
already in network byte order.

Everytime we read this values for source and destination port we need
to convert this value to host byte order.

In the outcoming header we need to set this value in network byte order
which the upcoming process assumes.
6lowpan: add udp warning for elided checksum

Bit 5 of "UDP LOWPAN_NHC Format" indicate that the checksum can be elided.
The host need to calculate the udp checksum afterwards but this isn't
supported right now.

See:
http://tools.ietf.org/html/rfc6282#section-4.3.3
6lowpan: udp use lowpan_fetch_skb function

Cleanup the lowpan_uncompress_udp_header function to use the
lowpan_fetch_skb function.
6lowpan: udp use subtraction on both conditions

Cleanup code to handle both calculation in the same way.
6lowpan: Uncompression of traffic class field was incorrect

If priority/traffic class field in IPv6 header is set (seen when
using ssh), the uncompression sets the TC and Flow fields incorrectly.

Example:

This is IPv6 header of a sent packet. Note the priority/TC (=1) in
the first byte.

00000000: 61 00 00 00 00 2c 06 40 fe 80 00 00 00 00 00 00
00000010: 02 02 72 ff fe c6 42 10 fe 80 00 00 00 00 00 00
00000020: 02 1e ab ff fe 4c 52 57

This gets compressed like this in the sending side

00000000: 72 31 04 06 02 1e ab ff fe 4c 52 57 ec c2 00 16
00000010: aa 2d fe 92 86 4e be c6 ....

In the receiving end, the packet gets uncompressed to this
IPv6 header

00000000: 60 06 06 02 00 2a 1e 40 fe 80 00 00 00 00 00 00
00000010: 02 02 72 ff fe c6 42 10 fe 80 00 00 00 00 00 00
00000020: ab ff fe 4c 52 57 ec c2

First four bytes are set incorrectly and we have also lost
two bytes from destination address.

The fix is to switch the case values in switch statement
when checking the TC field.

Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>