Use strtol() and only treat the argument as a number if it's *all*
number, so that interface names such as 192_1_2 aren't treated as
"interface number 192".
NAME_MAX is the maximum length of a file pathname *component*; PATH_MAX
is the maximum length of a file pathname. We're dealing with pathnames,
so use PATH_MAX. (On some systems, NAME_MAX can be as low as 14,
presumably for binary compatibility with V7-era data structures
containing file names, as there are probably few if any non-historic
UN*Xes around with 14-character file name limitations.)
Boost the default PATH_MAX to 1024 while we're at it.
Unfortunately, the DLT_PFSYNC support depends on header files included
from the pfctl command's source tree, and trying to arrange to find that
would be too much trouble.
From FreeBSD PR bin/124825: tcpdump(8) does not support pfsync(4) data,
which in turn was ported over from OpenBSD. We already have CARP
support, so we did not port that part over.
CARP and VRRP both use IP protocol number 112, so there needs to be a -T
flag to specify that protocol 112 be dissected as CARP rather than VRRP.
Also update the man page.
I was rudely surprised to find that "tcpdump -h" wasn't printing a usage
message, and I'm the person who *added* the "-h" option. Make it "-H",
and add an explicit "-h" option to print a usage message, so nobody else
makes the same mistake. Also, don't clear opterr, so that if you give
an illegal command-line option, you get an explanatory error message.
To: tcpdump-workers@lists.tcpdump.org
Date: Sat, 09 Apr 2011 12:51:14 +1000
Subject: [tcpdump-workers] Printing PPI packets
Printing PPI packets with tcpdump does not turn out
to be that hard.
My simple tests have produced the output as below.
It would be worthwhile having some changes made into
the tcpdump code base that were similar to the attached
that print them out.
Based on a patch from cr4ckn@sourceforge.net, but with a macro
PLURAL_SUFFIX() defined to return either "s" or "" (rather than possibly
printing a NUL character with %c), and with that macro used in a couple
of cases where the equivalent had been done by hand, and with one case
the patch missed fixed as well.
Rather than hardcode the WIN32 define, add proper fork checks to the
configure script and check those. This fixes building for nommu systems
which lack the fork function.
While we're here though, add support for this functionality via vfork
so that it does work on nommu systems. And fix an old bug where we
exit properly in the forked child when the exec failed instead of just
returning to the calling code (which isn't expecting it).
Reviewed-By: Guy Harris <guy@alum.mit.edu>
In addition to Paul's change, I added a comment explaining why we do
this, and explaining that doing so after opening the first savefile
doesn't help with subsequent savefiles, so you'll have to come up with a
better fix if you want the savefiles opened by the original UID or
outside the chroot.
Reviewed-By: Guy Harris <guy@alum.mit.edu>
Reading from a capture file that has not yet received any packets fails
with "truncated dump file"; to avoid this, flush the file (forcing the
pcap header out) immediately after opening it.
(Added Romain to the credits.)
Reviewed-By: Guy Harris <guy@alum.mit.edu>
I give up. I have no access to the 802.11s drafts, I can't find
anything that suggests whether a heuristic check for an 802.11s header
should check for To DS and From DS both being set or either being set or
unset, or whether it should check for a QoS frame type (the examples in
all the documentation I can find have To DS and From DS set, and have a
QoS field, in the 802.11 header, but that might just be an example
802.11 header showing all the fields), so I'm just adding a -h
command-line flag; you need to specify it to get tcpdump to try to guess
whether a frame has a mesh header or not. I'll leave it up to somebody
else to figure out what the best heuristic for detecting the presence of
mesh headers is (note that tcpdump and Wireshark have different
heuristics, both of which can probably get false positives, especially
with encrypted frames where the first payload byte just *happens* not to
have any of the reserved bits in the mesh header flags set).
device for which they're being reported, so if no -i flag was given
people don't think it's something such as the union of of all link-layer
types supported by all devices, and, if we can determine whether the
device supports monitor mode (with libpcap 1.0.0 and later), indicate
whether the link-layer types are the ones supported when not in monitor
mode (if -I wasn't specified) or when in monitor mode (if -I was
specified), so people don't wonder why some types aren't available (as
some are available only in monitor mode, and others are available only
when not in monitor mode, on some platforms).
on OpenSolaris, or Solaris Express Community Edition, build 125 and later.
The attached patch introduces support for printing out the IPNET headers used
for packet capture inside of zones that share their networking with the global
zone and for packets "transmitted" between zones.
tcpdump 4.0.0 will ship with builds 129 and later of OpenSolaris/SXCE and
when run as root with the '-L' option, should behave as below to indicate that
the system is fully functional:
Data link types (use option -y to set):
DOCSIS (DOCSIS) (printing not supported)
IPNET (Solaris IPNET)
EN10MB (Ethernet)
Cheers,
Darren
