Hello everybody, I'm sending a 1st frame with 0xDEADBEEF on datas on a virtual can bus (vcan0) And the second time there is the same without these datas. But wireshark(2.0.2) is interpreting the 2nd frame malformed... Any Idea ? asked 13 Apr '16, 09:08  lamoule74 |
Thanks in advance.
One Answer:
Hey everyone, the bug has been fixed by the team, that's perfect : https://code.wireshark.org/review/#/c/15110/ How do I apply this on my wireshark version now ? May I have to apply a patch or checkout the src then recompile them ? answered 25 Apr '16, 23:39 lamoule74 1 That depends on your OS. The change has been backported to 2.0, so any of the automated builds of 2.0.4rc0-x-... where x >= 6 than will have the fix. If you have built Wireshark yourself, you'll have to check out the source that includes the commit 23086b3a. (25 Apr '16, 23:50) grahamb ♦ OK, I recompiled the stuff; emtpy frames are no linger recognized as malformed ! :D (26 Apr '16, 01:59) lamoule74 |
This may be a bug, or actual invalid data. Looking at the code, the J1939 dissector expects the CAN Identifier to be < 0x20000000 and 0xDEADBEEF isn't. This means the J1939 dissector should refuse to dissect the frame, but that doesn't appear to be happening for you.
Can you share that capture file somewhere publicly?
@grahamb, 0xdeadbeef was the payload of the properly dissected packet, not the CAN ID of the "malformed" one. @lamoule74's real question is why a CAN frame with Frame-Length 0 and, consistently with that, no actual data is reported as a malformed one.
@lamoule74, I don't know whether the CAN specification permits void frames or not; depending on that, the "malformed packet" tag may be just (if void CAN frames are forbidden) or a dissector bug (if void CAN frames are permitted). As you venture to forge CAN frames, I'd guess you know enough of the specification so you should be able to decide whether to file a Wireshark bug or to fix your CAN frame generator. Note that the
Remote Transmission Requestflag may be relevant too, i.e. void frames may only be permitted if this flag is set.@sindy, good spot, so the id is 0x0c011201 and the J1939 dissector will try to dissect the 0 byte data frame. I'm in the same boat as you, I don't know if that's permitted.