MIPS C and DEC C also can't be made to reliably Just Say No to those
flags, and they don't support those flags, so don't try them with those
compilers either.
service-names-port-numbers.txt) has assigned an official port for
VXLAN (4789). tcpdump uses this by default but we keep the -T
vxlan option as well (e.g. Linux is allowing different ports).
HP's C compiler cannot be made to exit with a non-zero exit status when
given an unknown compiler flag, so you can't use that to figure out if a
flag is supported, but it *will* print a warning, which we don't want.
In addition, it doesn't support -W flags for warnings in any case, so
let's not bother with them.
Don't base the question of whether to use a particular -W flag on
whether we're compiling with GCC or not, and on which version of GCC
we're using; some compilers, such as clang, also support many of those
-W flags. Base it on whether the compiler complains if we use it (which
means, for clang, that we have to force it to exit with a non-zero exit
status if it doesn't like a flag; otherwise, we'll specify it, and clang
will warn about it on every compile).
I modified the mac80211 and ath9k kernel module such that extra
information regarding rssi, etc are available, which is why I needed the
extra bitmap. Capturing the packets is simply a matter of using tcpdump
-i wlan0 -w dumpfile.
Test-file-not-changed-due-to-doing-pulls-in-the-wrong-order-by: Guy Harris <guy@alum.mit.edu>
This bug was discovered and pinned down by Wim Torfs.
The code in question handles DLT_IEEE802_11_RADIO datalink type, which
consists of a variable-sized header, a variable number of fields and the
actual 802.11 frame. The integers contained in the fields are aligned,
properly extracting them is exactly the purpose of the existing "cpack"
module. The issue with the current code is that it sets alignment base
for cpack at the end of the variable-sized header, in other words,
64-bit integers would be properly extracted only so long as the header
is 64-bit long, which only happens when the total number of bitmaps in
it is odd (the minimum number of bitmaps is one). Once this condition
isn't met, as is with two bitmaps, decoding becomes incorrect. The
reporter's point that the alignment base must be the beginning of the
variable-sized header is accurate.
This commit adds a new cpack_advance() function to fast-forward the
"c_next" pointer of a cpack_state context by an arbitrary number of
octets. The ieee802_11_radio_print() function now uses it to skip the
header and all its bitmaps, and the alignment base is now the header
start.
On AIX 5.1, at least when compiling with xlc, the statement
struct mp_remove_addr *rem_addr = (struct mp_remove_addr *) opt;
gets a complaint "Syntax error: possible missing '{'?"
"/usr/include/sys/xmem.h" #defines rem_addr; I've no idea whether we're
indirectly including that, but maybe we are and maybe that's causing the
problem.
So don't use it; it's not necessary on any of the platforms on which we
work. (The *only* ones that are needed are PRI[doux]64, because
sometimes you need %ll[doux], sometimes you need %l[doux], and with MSVC
you need whatever its run-time library requires.)
Avoid dereferencing rx_cache[RX_CACHE_SIZE], which is one past the last
valid element.
(This fixes SF bug 3599633 / GH bug 287. I could not identify the name
or email address of the original contributor. -- Denis)
Bitfields are not one of C's shining points. There is *NO* guarantee in
what order bitfields are put within a structure - it's *NOT* necessarily
the same as the byte order of the machine, and it's *ESPECIALLY* not
guaranteed to be correlated with the value of the LBL_ALIGN definition
(that definition has to do with whether unaligned accesses are supported
by the hardware). In addition, even if they're declared as unsigned,
that doesn't mean they're guaranteed to *be* unsigned. Don't use them.
Unaligned accesses are not guaranteed to work, and fields in packets are
not guaranteed to be naturally aligned. Use the EXTRACT_nBITS() macros.
__attribute((packed))__ is a GCCism, and is not guaranteed to be
supported by all compilers with which tcpdump can be compiled. Make
integral fields > 1 byte arrays of u_int8_t's (which also lets us avoid
the & in the EXTRACT_nBITS() macros).
Some systems don't define the PRI[doux]16 and PRI[doux]32 macros, and
others define them infelicitously (i.e., for PRI[doux]32, with an "l";
our 32-bit integer types are *not* longs, as we don't care about
16-bit-"int" platforms).
We've created a the-tcpdump-group organization on GitHub, and created
repositories for libpcap and tcpdump, owned by them. Those are now the
"official" GitHub locations for repositories from which to clone or
against which to file issues/pull requests.
When compressing output with -z, we do so by creating a child process to
run gzip and pipe to it, and we catch SIGCHLD to clean up after the
child process. We don't want the SIGCHLD to show up as an "Interrupted
system call" error, so we specify that SIGCHLD should restart, rather
than interrupting, system calls.
This commit adds the support of Multipath TCP (MPTCP). MPTCP is a new
extension to TCP standardized at the IETF. MPTCP allows to use several IP
addresses at the same time by distributing data across several subflows (TCP
connections) while still presenting the standard TCP socket API to the
application. Its benefits are better resource utilization, better throughput
and smoother reaction to failures.
This change adds new code to decode ZeroMQ datagrams, couples it with
the PGM decoder and extends the -T option to make all this work.
There are two new test cases based on existing captures of ZMTP/1.0
inside [E]PGM to decode the ZMTP/1.0 part of these.
This functionality enables decoding of the traffic zeromq library
produces for "pgm://" and "epgm://" protocol schemas.
The original PGM uses its own IP protocol number. "EPGM" or "PGM/UDP"
stands for UDP-encapsulated PGM, which has no assigned UDP port number
and can be decoded only by means of -T option, which now accepts "pgm"
protocol type for this purpose. There is also a sample capture of EPGM
now (similar to the one of native PGM, but produced using the "epgm://"
protocol schema) and a respective test case.
This commit adds a capture of a few PGM (IP protocol 113) packets
produced with version 2.2.0 of zeromq library built with PGM support
(using the "pgm://" protocol schema). Each of the three ODATA packets in
the capture contains a ZeroMQ datagram in the "Data" (application data)
field. There is a new test case covering the PGM part of the capture.
1. "TSDU Length" comes in network byte order on wire, add missing macro.
2. The (unused) justification of the number of bytes on wire wasn't
correct because one side of the comparison included header size and
another didn't (note the byte order as well). Besides that, the value of
TSDU Length was already output thus far. Don't justify the number of
bytes on wire and change the final printf() to make a use of it.
When compressing output with -z, we do so by creating a child process to
run gzip and pipe to it, and we catch SIGCHLD to clean up after the
child process. We don't want the SIGCHLD to show up as an "Interrupted
system call" error, so we specify that SIGCHLD should restart, rather
than interrupting, system calls.
On some platforms, such as SunOS 5.x, building the "do we have IPv6
support?" test program requires the extra networking libraries, so we
need to know what extra networking libraries are required before doing
that test.
Prior to this if pcap_breakloop() is called in cleanup() while reading
multiple files (via -V) the code would fall through and open the next
file in the list. With this change the list is cut short and the program
exits normally.
Before the previous change, we didn't print it; restore that behavior.
Also update a comment - DEFAULT_SNAPLEN is now pretty large, so we
should capture the entire packet by default.
Make the offsets and lengths 32-bit, so that they don't overflow.
Pull the handling of V4 fields into its own routine. Call it only if
the packet's been identified as a V4 packet and the length is sane; call
the routine to handle V3 fields before we do any V4 work.
The right format to use to print 8-bit quantities isn't
implementation-dependent, so no need to use the PRIu8 and PRIx8 macros.
There's also no need for an empty string after PRIu64. Separate it with
space from the strings with which it's being concatenated, however; we
do that elsewhere.
