Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 40108: / /trunk/epan/dissectors/: Ma
From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Fri, 9 Dec 2011 22:10:12 -0800
On Dec 6, 2011, at 3:07 PM, sake@xxxxxxxxxxxxx wrote:

> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=40108
> 
> User: sake
> Date: 2011/12/06 03:07 PM
> 
> Log:
> - Make a distinction between ethernet padding and an ethernet trailer
> - ... and make that distinction configurable for capture files that do not have padding in small frames, but do have trailers

How would you have small frames without padding, unless you're capturing packets before they're put onto the wire (e.g., capturing packets being sent by your machine, in which case you're not going to have a trailer added by any monitoring hardware)?

> - Add VSS-Monitoring dissector to show by the TAP inserted time- and portstamps

That dissector won't actually dissect anything if the trailer length is < 8 and is 0 modulo 3.  However, it does not reject trailers with a length of 0 or 4; this keeps frames with an FCS from being handled correctly.  I've checked in a changed to reject packets with a length < 8 and that's 0 mod 3.

I've also checked in a changed to packet-eth.c not to even try calling *any* of the heuristic trailer dissectors if the "real trailer" length is 0.

These changes fix the dissection of some captures

If the FCS is known to be present (fcs_len = 4), we should probably make sure the FCS is *not* part of the tvbuff we hand to the heuristic trailer dissectors; we definitely should make sure it's dissected as an FCS.

If it's not known to be present, and the "real trailer" is exactly 4 bytes long, is there any way to determine whether it's a trailer or an FCS?  Short of the 4-byte trailer failing all the heuristics, that's about it.

We also currently have no way for the trailer dissector to say "OK, there's a trailer, followed by an FCS".