Re: [Wireshark-commits] rev 40108: / /trunk/epan/dissectors/: Makefile.common packet-eth.c packet-vssmonitoring.c /trunk/: AUTHORS

[Sake Blok <sake () euronet nl>]

On 10 dec 2011, at 07:10, Guy Harris wrote:

> On Dec 6, 2011, at 3:07 PM, sake () wireshark org 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)?

I know F5 makes a dissector for trailing data, where the capturing is done on the box. I did check on my virtual F5 box 
and it does seem to add padding first before adding their trailer.  But theoretically it is possible that the capturing 
mechanism of a device is handed a small frame and then adds a trailer. I wanted to keep this possibility open as before 
my change an ethernet-trailer-dissector would be handed that data. If we think we can skip this and always assume there 
is padding on small frames, then it is safe to skip this preference.


> > - 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

Thanks!


> 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.

I agree, checked in SVN 40146


> 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".

At first I thought that dissector_try_heuristic() would return the amount of bytes that were handled by the 
trailer-dissector. That would make it possible to check whether there are still 4 bytes left and assume those must be 
the FCS. But it returns true of false only.

Cheers,
Sake



___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe