> I've seen other mail that shows, for some as-yet-unknown reason, what
> appears to be differences in the packet-capture behavior of "tcpdump"
> and Ethereal; the odd thing is that both programs are using the "pcap"
> library to do the capture and to write out the capture file....
>
> The ones I've seen mentioned here seemed to be differences in the
> handling of Ethernet packets shorter than the minimum of 60 octets (64
> octets minus the 4-octet frame check sequence); I *think* most if not
> all of them were seen on Linux systems. The frame check sequence might
> be, in part, involved, although the most recent one before yours (the
> zero-length ICMP packet one) was off by more than 4 bytes.
>
> I'll try looking into it.
Well, I tried it on Debian 2.1, with "tcpdump" and the "libpcap" it used
being the ones that come with Debian 2.1, and with a recent Ethereal and
a (modified, but not in a way that should make a difference) "libpcap"
0.4, and the only less-than-60-octet packet I saw was an ARP request; in
both cases, the captured length and actual length were less than 60.
The ARP reply, however, was, in both cases, 60 octets, with padding at
the end.
Perhaps the SOCK_PACKET code in the kernel in 2.1 doesn't hand up padded
packets, so the ARP request seen by "tcpdump" and the ARP request seen
by Ethereal wasn't padded, but whatever device replied padded the packet
(as required), and my machine had no way of knowing what the unpadded
frame length was from the Ethernet header, so it just said "60 octets".
Why, on other Linux distributions, "tcpdump" and Ethereal differ, I have
no idea.
