On Sat, Feb 07, 2004 at 05:38:45PM +0100, Ulf Lamping wrote:
> Filtering options
> -----------------
> -Limit each packet to xy bytes: Will limit the maximum size to be
> captured of each packet. This can be useful for example, when an error
> is known to be in the first 20 bytes of a packet, and the size of the
> resulting capture file should be reduced.
It should probably note that this number counts *all* bytes, including
the link-layer header and all subsequent headers (and pseudo-headers
such as the ATM pseudo-header and the extra radio information for
802.11); people might think that if the error is known to be in the
first 20 bytes of a DNS packet they should capture with a snapshot
length of 20, which isn't the case. (The minimum length is 68 bytes in
any case.)
The most common reason for capturing with a snapshot length is, I
suspect, that you're not looking for a particular error, but are
capturing a large amount of traffic on which to later do an aggregate
analysis of some sort. (I suspect tcpdump might originally have been
developed for Van Jacobson's analysis of TCP behavior that led to his
slow start, etc. work, which might explain why it defaults to a 68-byte
snapshot length, as he only wanted to dump TCP information.)
> -Capture packets in promiscuous mode: Usually a network card will only
> capture the traffic to it's own network address. If you want to capture
> all traffic that the network card can "see", mark this option.
Should this have a note referring people to the
capturing-on-switched-networks FAQ.
> Have a look at tethereal, the command line variant of ethereal, which
> is included in this package.
> XXX: add a list of possibly useful standalone capture programs.
There's also tcpdump/WinDump, although the code path through it should
be fairly similar to the code path through tethereal - if
tcpdump/WinDump can keep up but tethereal can't keep up *with the same
snapshot length* that's arguably a bug in tethereal.