Add wireshark dissector for native packets

[miri64]

I think we don't need that ZEP implementation ;-)

[miri64]

Discussion: maybe a next_header field in struct nativenet_header would be a good idea now.

[mehlis]

I still prefer #163 but let's discuss this

[miri64]

Do we want to add for every protocol we want to support in the future an extra native RIOT layer, then? I think an extra field in the nativenet_header is a lot simpler (in riot.lua this would just be a number of if-statements depending on that new field) + nativenet can identify the next header itself and marshal it to the corresponding layer accordingly.

[LudwigKnuepfer]

I also think there is something to be gained from the zep implementation. That's a different matter though. I'm looking forward to merging this PR if it does what I think it does =)

[mehlis]

@LudwigOrtmann with the zep header we get rid of any "native net header", right? so we don't need to have any changes on wireshar/tcpdump?

[LudwigKnuepfer]

zep is intended to be an option for nativenet, not a replacement for the current implementation. It does not only change the header format but also other properties of the network layer (maximum size).

[mehlis]

@LudwigOrtmann I see, so we will need both, a parser for "native net packets" and the zep encapsulation. they go hand in hand.

[OlegHahm]

One advantage of providing ZEP headers would be that one could just use Wireshark as is without installing an additional dissector. However, that could be additive.

[mehlis]

could install the dissector, with sixlowpan as next header I get "Malformed Packet: IPv6" with lua Error in line 37.

RIOT, 6lowpan are dissected correctly

[mehlis]

one of them is source

[miri64]

oops

[miri64]

Fixed

[miri64]

could install the dissector, with sixlowpan as next header I get "Malformed Packet: IPv6" with lua Error in line 37.

@mehlis It's just a parser. If you don't provide 6LoWPAN content directly after the RIOT header (I guess you did not change much of the of the network stacks code, which currently yields IEEE 802.15.4 packages on native) it will of course fail ;-).

But: Another problem I have realized is, that since IEEE 802.15.4 has its frame length in the PHY header (directly before the MAC header which is provided here), wireshark does not get the length of the frame and won't for that reason (I guess) parse the 6LoWPAN header. The optimal result would look somewhat like this (http://cloudshark.org/captures/18efd3ef7114) but with this dissector it stops after the IEEE 802.15.4 header.

@OlegHahm: the "installation" is just an addition of 2 lines in wireshark's config ;-), but with the problem stated above I see why we might need a ZEP layer (though I don't know if it is necessary to send it via UDP).

[mehlis]

@authmillenon I see, because of using 15.4 results in less output I assumed, that sixlowpan is the right next layer:)

[miri64]

But: Another problem I have realized is, that since IEEE 802.15.4 has its frame length in the PHY header (directly before the MAC header which is provided here), wireshark does not get the length of the frame and won't for that reason (I guess) parse the 6LoWPAN header. The optimal result would look somewhat like this (http://cloudshark.org/captures/18efd3ef7114) but with this dissector it stops after the IEEE 802.15.4 header.

okay nope, it's because the IEEE 802.15.4 checksum is calculated wrong (in the current implementation not at all, but set to a constant value).

[miri64]

Fixed it (see #644)

[LudwigKnuepfer]

Can't you put this stuff in $HOME/.wireshark/preferences? There are people who are working on multi user systems....

[OlegHahm]

ACK

[mehlis]

successfully tested, ACK, GO