[Guy Harris <gharris@xxxxxxxxx>]

David Howland wrote:
> I'm trying to track all AIM messages that go through my computer.  I 
> collect the data with "tcpdump -w dumpfile" and send a few test 
> messages.  I can open the dumpfile in ethereal fine, and can locate the 
> AIM packets, however I can't retrieve any of the messages.  All the 
> important packets seem to just say [short frame: AIM] and there is no 
> data.  Can anyone explain what might be wrong with my method?

What's wrong with your method is the lack of a "-s 65535" - or, on newer 
versions of tcpdump, "-s 0", which means the same thing in newer 
versions - in the tcpdump command.

Tcpdump, by default, captures with a "snapshot length" of 68 (for 
non-IPv6-capable versions of tcpdump) or 96 (for IPv6-capable versions 
of tcpdump).  This means that no more than 68 or 96 bytes of packet 
data, *including* the link-layer header and all other headers (so it 
might be as little as 68-(14+20+20) = 14 bytes of payload above TCP, 
with Ethernet and minimum-length IPv4 and TCP headers, or even less if 
there are IP or TCP options), are captured.  A frame that was cut short 
by a snapshot length is reported as a "Short Frame" in Ethereal.

"-s 65535" or "-s 0" will specify a snapshot length of 65535 bytes, 
which is the largest snapshot length supported by libpcap (and thus the 
largest one supported, when capturing, by tcpdump and 
Ethereal/Tethereal; Ethereal and Tethereal, unlike tcpdump, default to a 
snapshot length of 65535), so it'll capture the entire packet on most if 
not all networks.