Seperate IPv6 and 6LoWPAN

[mehlis]

alternative to #357

it builds for native and msba2

missing peace: start lowpan thread

[OlegHahm]

There seems to be a lot of duplicate code in this PR. Maybe we could consolidate this.

[mehlis]

consolidated -> rewrote my code -> force commit + push

problem: we now use lowpan as a layer, to access with the msg system: sending a radio_packet_t does not work because an ipv6 addr is longer that a layer 2 address....

todo: start lowpan layer thread

[OlegHahm]

Maybe we could also merge recv_ieee802154_frame with the lowpan_layer_thread, in order to not have two threads running on this layer.

Regarding the problem with the address size: this could be solved by replacing the uint16_t for the src and dst member by using a typedef, right?

[mehlis]

@OlegHahm I wanted to use these fields for the ip address:

RIOT/sys/include/radio/types.h

Line 71 in 9817043

uint16_t src; ///< Radio source address

but unfortunately they are too small....we can use a typedef to manage this (for the cc1100 hardware this filed has the size uint16_t but perhaps an other transceiver has an other mac layer address size)

[OlegHahm]

Actuallay cc1100 has 8bit hardware addresses, but we should rethink this. The transceiver module is meant to provide a generic driver interface. Hence, it assumes a link layer address, not a network layer address.

[mehlis]

totally right!

[miri64]

After some consideration I am not sure if it is that good an idea to decide the usage of 6LoWPAN by a compiler set macro. Wouldn't it be better to make it dependable on the maximum packet size of the radio?

if (packet_size < 1280) (MTU of IPv6) use 6LoWPAN.

EDIT: This could also be determined at compile time.

[kaspar030]

@authmillenon: well, if the minimum MTU is <1280, then IPv6 can't be used anyways, so the code can fallback to 6lowpan.

[OlegHahm]

However, there might be other reasons to use 6lowpan.

[mehlis]

as discussed, I close this PR, because it will get superseded by the general sixlowpan restructuring.