Ethernet Length field not recognized ... Tshark and Wireshark

This issue was migrated from bug 2726 in our old bug tracker.

Original bug information:

Reporter: jose gonzalez
Status: RESOLVED NOTABUG
Product: Wireshark
Component: TShark
OS: All
Platform: x86
Version: 1.0.2

jose gonzalez said:

Build Information: TShark 1.0.2

Copyright 1998-2008 Gerald Combs <gerald@‍wireshark.org> 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 GLib 2.16.4, with libpcap 0.9.8, with libz 1.2.3.3, with POSIX capabilities (Linux), with libpcre 7.4, without SMI, without ADNS, without Lua, without GnuTLS, without Gcrypt, without Kerberos.

Running on Linux 2.6.24-19-generic, with libpcap version 0.9.8.

Built using gcc 4.2.3 (Ubuntu 4.2.3-2ubuntu7).

wireshark 1.0.2

Copyright 1998-2008 Gerald Combs <gerald@‍wireshark.org> 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.9, with GLib 2.16.4, with libpcap 0.9.8, with libz 1.2.3.3, with POSIX capabilities (Linux), with libpcre 7.4, without SMI, without ADNS, without Lua, without GnuTLS, without Gcrypt, without Kerberos, without PortAudio, without AirPcap.

Running on Linux 2.6.24-19-generic, with libpcap version 0.9.8.

Built using gcc 4.2.3 (Ubuntu 4.2.3-2ubuntu7).

Per the manual for wireshark-filter and http://www.wireshark.org/docs/dfref/e/eth.html, eth.len is a field.  The length of the Ethernet packet does not appear in wireshark's "Paket Details" section.  If I apply eth.len as a filter in wireshark, all of the packets disappear. I had these problems in Windows (wireshark 1.0.0) and linux (wireshark 1.0.2). Using tshark to obtain the data from the eth.len field results in no data.

exampe command
command:  tshark -r test.pcap -T fields -E header=y -e frame.number -e ip.addr -e eth.len

added clitshark version1.0 labels

Guy Harris said:

Not all Ethernet packets *have* a length field.  The Ethernet header has a 6-octet destination address, a 6-octet source address, and a 2-octet type/length field.  If the type/length field has a value <= 1500, it's a length field; if it has a value >= 1536, it's a type field.  (It's presumably invalid if it has a value in the range 1501 through 1535.)

Almost all Ethernet packets have a type field; the main exceptions I know of are:

    NetBEUI Framing protocol packets (rarely seen these days - the main NetBIOS-based application is SMB, and it usually uses NetBIOS-over-TCP or direct SMB-over-TCP);

    NetWare packets with non-"Ethernet II" encapsulation;

    possibly some OSI and SNA protocols;

    various protocols that don't have an Ethernet type but *do* have an OUI/protocol ID pair and that thus require a SNAP header.

It might be that you have so little traffic on your network with a length field that "eth.len" matches few if any packets.

Sake said:

"Works as designed" -> Closing this bug

closed