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>
- fix TCP flags output description, by Christophe Rhodes <csr21@cantab.net>
Original patch submitted in http://bugs.debian.org/575724
- two remaining typo fixes, by A Costa <agcosta@gis.net>
Original patch submitted in http://bugs.debian.org/342310
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).
Don't get confused by some malformed frames - always return -1 - and
assign the result of extract_header_length() to an int, so we don't get
warnings when we compare it against -1. (Its return value always fits
in an int.)
We're eventually going to stop defining the SIZEOF_ values, as we
support, for example, building fat on Mac OS X, and SIZEOF_LONG, for
example, is different between 32-bit and 64-bit builds.
Instead of requiring the user to specify -arch options on OS X to build
a universal version of tcpdump, just default to universal on OS X by
default. Pick the particular targets to match the way tcpdump is built
for the OS for which we're building.
./configure --without-chroot will configure tcpdump with "no" as the
value of chroot directory and cause tcpdump to fail with:
tcpdump: Couldn't chroot/chdir to 'no': No such file or directory
This patch makes ./configure to avoid chroot directory when called with
--without-chroot.
They allow the user to specify flags to indicate the target
architecture(s) (yes, possibly plural - think, for example, Mac OS X)
for which we're building. Those might need to be used not only when
compiling, but also when linking and when building a shared library.
This is not for general cross-compiling, it's for use on platforms where
versions of the native OS support more than one instruction set and
where you want to build for the OS on which you're running but not for
the default build architecture on the machine on which you're running.
This may currently be less useful for tcpdump, as tcpdump currently
builds no libraries, but it's there for compatibility with libpcap.
Presumably the idea is that the technique is generally applicable as
long as the traffic being carried is either IPv4, IPv6, OSI CLNP, ES-IS,
or IS-IS.
Also, by the time we get there, we know we've reached the bottom of the
MPLS stack (the do loop either fails by running past the end of the
packet and going to trunc, or by terminating because we find a label
entry with the BOS bit set); there's no need to check for that.
