> On Sun, Jun 18, 2000 at 02:53:37AM -0500, Guy Harris wrote:
> Hmm, at first I thought this was a display filter bug (because I knew of
> something related in the display filter code). But I see what you're
> talking about, somehow your capturing facility saved 60 bytes of data,
> no matter what.
It may not have had a choice in the matter.
If a machine captures a packet that it is itself transmitting, and the
packet is an Ethernet packet smaller than the 60-byte minimum, the
capture mechanism can provide the actual length rather than the padded
length; however, if the packet has been received, the Ethernet driver
has no clue how long the packet was supposed to be (unless it digs into
headers above the Ethernet layer and intuits the length from that), and
thus probably always supplies 60 bytes or more.
I.e., at the Ethernet layer, there's no way to know that the "GIOP" in
the no-data TCP packets and the ARP packets are just padding junk.
(One could argue that perhaps the transmitting machine should have
cleared out that data, on the off chance that it contained data that
shouldn't be provided to machines other than the sender and the
receiver, although, given the existence of packet sniffer programs, the
packet whence that data came may also have been available to those other
machines if they caught the original packet.)
