Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 40108: / /trunk/epan/dissectors/: Ma
On 10 dec 2011, at 07:10, Guy Harris wrote:
> 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)?
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
