https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16468

--- Comment #4 from Jason Cohen <kryojen...@gmail.com> ---
(In reply to Sake from comment #3)
> 2011 is quite a while ago, but in my memory I created this preference
> exactly for the case presented in this bug-report. As using ethernet
> trailers is not defined by any standard and there are different
> implementations adding trailers in different ways, it is not possible to
> create one heuristic that will work in 100% of the cases.
> 
> Normal ethernet padding usually uses 00's to pad, but I have seen traces
> where that was not the case. When you make traces and know there are
> trailers, you can just set the preference to display the trailers correctly.
> Trying to add detection might work in this case, but will result in another
> bug report later on where normal padding is interpreted as a trailer.
> 
> So I would vote to just keep it as is and let the user use the preference
> for which it was created.

I've actually got some changes to the preference staged, just doing another
pass over it and will probably get it submitted today.

The 802.3 spec states

...ComputePad function of the MAC sublayer appends an array of arbitrary bit to
the MAC client data to pad the frame  to the minimum frame size...

Older implementations just added whatever was left in the buffer without
zeroing out.  That was the basis of EtherLeak
(https://www.cvedetails.com/cve/CVE-2003-0001/)

RFC 1042 (IP transmission over IEEE 802) states:
      IEEE 802 packets may have a minimum size restriction.  When
      necessary, the data field should be padded (with octets of zero)
      to meet the IEEE 802 minimum frame size requirements.

It is IP specific and pre-RFC2119 so "should's" definition could be ambiguous.

-- 
You are receiving this mail because:
You are watching all bug changes.
___________________________________________________________________________
Sent via:    Wireshark-bugs mailing list <wireshark-bugs@wireshark.org>
Archives:    https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
             mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

Reply via email to