On Tue, Sep 26, 2000 at 12:16:11PM -0700, Michael Morrison wrote:
> I think I found a bug in the data display of ethereal.
> When displaying a TCP/IP packet with 1 data byte, the hex dump at the
> bottom of the
> screen displays the 1 data byte followed by 5 bytes of bonus junk.
"That's not a bug, that's a feature."
The Ethernet spec requires that an Ethernet frame be at least 64 bytes
long, to make carrier and collision detection work. The last 4 bytes
are a CRC, so that's 60 bytes for the Ethernet header and data. Of
those 60 bytes, the first 14 are the Ethernet header, so that's 46 bytes
of data. For a TCP/IPv4 packet, that's at least 20 bytes of IPv4 header
and 20 bytes of TCP header, leaving 6 bytes.
Therefore, in an Ethernet packet containing a TCP segment in an IPv4
datagram, there are supposed to be at least 6 bytes in the packet
following the TCP header; the IP header contains a total datagram length
field, so IP knows that there are only 21 bytes of IP payload, and can
tell that to TCP, so that TCP knows that there is only one byte of TCP
payload.
However, there have to be 5 more bytes of padding.
At some point, we'll probably make Ethereal mark Ethernet padding bytes
as such; I'd like to do it in such a fashion as *not* to require IPv4,
IPv6, and other protocols that run atop Ethernet and that have their own
length field to have to do that - I want to let the Ethernet dissector
figure that out, which might be possible if all the dissectors called
by the Ethernet dissector use tvbuffs (which they don't do yet).