Wireshark-bugs: [Wireshark-bugs] [Bug 2202] New: Wrong warning message of Wireshark: "PPPoE Payl
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2202
Summary: Wrong warning message of Wireshark: "PPPoE Payload
length XX incorrect, should be YY"
Product: Wireshark
Version: 0.99.7
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: Major
Priority: Low
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: Jewgenij.Bytschkow@xxxxxxxxxxxxx
Build Information:
Version 0.99.7 (SVN Rev 23910)
Copyright 1998-2007 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled with GTK+ 2.12.1, with GLib 2.14.3, with WinPcap (version unknown),
with libz 1.2.3, with libpcre 6.4, with SMI 0.4.5, with ADNS, with Lua 5.1,
with
GnuTLS 1.6.1, with Gcrypt 1.2.3, with MIT Kerberos, with PortAudio PortAudio
V19-devel, with AirPcap.
Running on Windows XP Service Pack 2, build 2600, with WinPcap version 4.0.2
(packet.dll version 4.0.0.1040), based on libpcap version 0.9.5, without
AirPcap.
Built using Microsoft Visual C++ 6.0 build 8804
Wireshark is Open Source Software released under the GNU General Public
License.
Check the man page and http://www.wireshark.org for more information.
--
In traces complains Wireshark about padding, if the value of the
PPPoE-Length-Field is smaller than 40. The format of the frame/packet is
correct. This is only a presentation problem of Wireshark.
An Ethernet Frame may not be smaller than 64 bytes. Therefore the Ethernet
Payload may not be for PPPoE smaller than 46 bytes (64-6-6-2-4=46). If the size
of Payload data in the Ethernet Payload is less than 46 bytes, like in this
Frame, the Ethernet Frame will be brought automatically(!) on the necessary
minimum length of 64 bytes - by PADDING (filled with 0x0) after the end of the
payload data and before the FCS.
Alternatively, the same could be reached if a small PPPoE Payload is
complemented with zeros (0x0) directly and explicitly in the payload data and
the payload reaches then, nevertheless, the minimum length of 46 bytes, so that
no automatic ethernet payload will be needed. As opposed to automatic
Ethernet-Padding I would name this procedure "PPPoE-Padding" or
"Application-Level-Padding". In this case the PPPoE Length field must also
contain the whole data length: payload + "PPPoE Padding". The Wireshark
programm expects this second case (with "PPPoE Padding"). In case of "PPPoE
Padding" the field "Length" in the PPPoE Header really should contain not 10
but 40:
46(min. Ethernet Payload for PPPoE) -1(Ver+Type fields) -1(code field)
-2(Session_Id field) -2(Length field) = 40 bytes
In all our traces, an Ethernet Padding and not "PPPoE-Padding" is available.
Thus, the error message of Wireshark is incorrect:
Frame NN:
- PPPoE session
...
Payload length: 10 [incorrect, should be 40]
This is a wrong alarm or a wrong error message of Wireshark, because,
nevertheless, immediately after 10 bytes PPPoE-Payload there are 30 bytes
Ethernet-Frame-PADDING (0x0). If this Ethernet-Padding (30 bytes) had been
absent in the Frame, the Frame would be smaller than 64 bytes and we would have
a wrong (to short) Ethernet-Frame and an Ethernet error.
Conclusion:
Ethernet frames of less than 64 bytes are always padded to 64 bytes! The Frame
in the Trace is exactly 64 bytes in size and contains 30 zero bytes as an
Ethernet Padding. Apart from the described Wireshark presentation mistake or a
wrong error message ("Payload length : 10 [incorrect, should be 40]"),
everything is alright with the Frame/Packet and the format. Everything is
standard-compliant (PPPoE, Ethernet standards). The mistake concerns only
Wireshark (tested with Wireshark 0.99.6a and 0.99.7). Even earlier, with
Ethereal, the presentation of 64 bytes Frames in traces (like this Frame, with
Padding) had still been korrekt, without warning or error message.
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
