Fix a segfault with the -C option when the number of files grows
to 1000. Limit has been increased to 1,000,000, and the code
will check for exceeding this.
Also, add a -W option which will limit the number of files
created before 'wrapping around' and writing to the first file
again, creating a 'loop tape'. Very useful if you want to have
this running permanently to capture traffic up to a irregular
event.
Change the way that output files with -C are numbered. -C alone
goes <none>, 1, 2, 3.... -C with -W will number 0, 1, 2 ... or
00, 01, 02 ... etc, depending on the value of -W. I.e., it
sorts properly. (Old behaviour was to go <none>, 2, 3...)
Close the current capture file before trying to allocate the buffer for
the new file's name, so that if that allocation fails we've at least
written out all of the previous file.
Make some variables for command-line arguments, and some functions not
used outside tcpdump.c, static.
When saving to a file with "-w", have the "-v" flag make tcpdump
report, every 10 seconds, the number of packets captured.
Include <smi.h> if we're building with libsmi, to declare
"smiInit()" and "smiLoadModule()".
Digital/Tru64 UNIX has it as well (although the tty(7) man page doesn't
mention VSTATUS - stty(1) mentions "status", however, and signal(4)
mentions SIGINFO, and some Tru64->HP-UX transition pages mention SIGINFO
as a feature available in Tru64 but not HP-UX).
Note that on some systems (e.g., Mac OS X), you might have to set your
"status" character as it defaults, on those systems, to "not set".
Get rid of the reference to "traffic(1C)" (it's not referred to in the
man page, and about the only connection it has with tcpdump is that they
both watch network traffic; traffic(1C) is a SunOS 4.x-ism, not present
on other platforms), and add a reference to pfconfig(8) for
Digital/Tru64 (it *is* referred to, in the section of what privileges
you need in order to capture traffic).
The change adds left- and right-shift (<< and >>) to the list of
binary operators on the tcpdump man page. E.g. "tcp[12] >> 4 > 5" will
test for TCP options. The operators are listed in the '93 Usenix paper,
and appear to have been supported in libpcap since the 0.0 release.
appropriately, and that GNUmakefile and the MSVC++ project file define
it apppriately, as we do with libpcap, rather than defining it in
"interface.h".
Undo the rcsid-shuffling and addition of extra #includes, as we no
longer need to arrange that "interface.h" be included before using _U_
in an RCS ID or copyright.
processed - people often get confused by the "received by filter" count,
as they might not realize that, in some systems, it counts packets that
were handed to the filter mechanism regardless of whether they pass or,
if they pass, they have yet been read by the application and, on some
other systems, it counts packets that passed the filter but still counts
them in the kernel before they're read by the application.
They're probably mostly interested in the count of packets processed by
tcpdump; the "received by filter" count is probably of interest only if
you want to know how effective your filter is (and even then it's of
interest only if it counts packets handed to the filter rather than
packets that passed the filter).
Give more details on why the "received by filter" count doesn't
necessarily mean what you think it means.
that could, in theory, let non-root users capture packets, if there were
userland support for giving particular accounts capability bits and
having them set on their login processes when they log in.
Note that Mac OS X is like the other BSDs, in that all you need in order
to capture is read access on the BPF devices. Note also that on BSDs
with a devfs (which includes Mac OS X), giving a user that access isn't
as easy as running "chown" or "chmod" once.
the output stream for "-w" to be flushed after each packet is dumped.
Add checks for "pcap_dump_flush()", and only enable the "-U" flag if
it's present. Clean up the handling of the "getopt()" argument and the
usage message to get rid of the pile of #ifdefs.
Add documentation for the "-L" and "-y" flags.
Tweak the description of "-r" to properly format "-w" in the text.
Have "-xx" and "-XX" cause the link-level header to be dumped; don't
make "-e" affect that at all, as the fact that "-x" doesn't dump the
link-level header was documented, with no mention of "-e", at least as
far back as tcpdump 3.4, and scripts might depend on that working even
with "-e".
beginning of the raw packet data, the captured length of the raw packet
data, and the length of the link-layer header, and:
if "-e" was specified, prints all the raw packet data;
if "-e" was not specified, prints all the raw packet data past
the link-layer header, if there is any.
Use that routine in all the "xxx_if_print()" routines if "-x" was
specified.
Make "arcnet_encap_print()" static - it's not used outside
"print-arcnet.c".
Add missing info printing code to "atm_if_print()".
Print the packet data in "lane_if_print()", not in "lane_print()", as
"lane_print()" can be called from other "xxx_if_print()" routines, and
those routines will also print the packet data if "-x" was specified -
no need to print it twice.
of packet headers so that, in all expressions after it, the tests assume
LANE encapsulation of packets. (We also assume the emulated LAN is an
Ethernet LAN, rather than a Token Ring LAN.)
Allow ATM tests to be combined with non-ATM tests in expressions, so
that you can do, for example, "lane and icmp".
"wlan" as an alias for "link".
Clean up the description of the special cases for protocol matching at
the link layer.
Add in some more information about 802.11.
