Closed g-oikonomou closed 10 years ago
I can confirm this bug. In my case, it appears on fragmented packets. I was suspecting that the checksum was not written at the correct position.
In any case, the problem is on both sides, i.e. both encoder and decoder, since the packets are interpreted by the Contiki stack like normal (even though Wireshark cannot dissect them).
I'm adding a 'bug' label to this one.
As you say, nodes appear to be communicating happily. It also appears that real devices can talk to each other happily as well.
One more reason I was suspecting fragmentation is the stuff I've documented under #193
Same here. I might have found the problem: this d1f12638b4c was submitted to solve a bad FCS error detected by COOJA. It seems that recent modifications by @fros4943 makes this obsolete. I reverted it locally and seems to be ok, I'll do more testing with @laurentderu and submit the revert if ok.
Would be nice to handle PR #465 asap, this issue is quite serious for anyone using Wireshark to parse COOJA pcaps.
I'm flagging this as a question rather than a bug cause I'm not sure whether it's just me.
I'm currently struggling with cooja pcap exports (I first spotted this a couple of weeks ago). I run the simple-rpl-udp unicast example inside cooja, with 6LoWPAN analyzer with PCAP enabled under Radio messages. I then open the resulting PCAP file with wireshark and all DIOs and DAOs are flagged as malformed and with a bad checksum. DIS packets show up fine. Some UDP datagrams appear OK, some do not.
Standard Ubuntu wireshark, nothing whacky:
I've also tried opening the PCAP on OS X, same results.
Clean contiki tree (6b9b457) other than ContikiMAC -> Null RDC, but the situation is the same with ContikiMAC.
I've tried to trace this with git bisect but I didn't get anywhere. I want to try with a capture from a real testbed to make sure there's nothing wrong with my wireshark. I am suspecting there's something going amiss with datagrams fragmented at the 6lowpan layer but that's just a hunch at the moment.