Guy Harris [Sun, 19 Oct 2014 20:42:00 +0000 (13:42 -0700)]
Use the length field in the UDP header.
If it's less than the length of the IP payload, use it as the size of
the UDP packet. If it's greater than the length of the IP payload,
and we're not dissecting the payload, report the length as bad.
Guy Harris [Wed, 12 Nov 2014 03:05:48 +0000 (19:05 -0800)]
Further cleanups.
Use ND_TCHECK() rather than home-brew bounds checks. Do simpler length
checks.
Let i be the length of the actual remaining packet data; use ND_TCHECK()
inside loops that iterate over the remaining data.
Let the printers for particular message types cast the raw data pointer
to a pointer of the appropriate type, rather than passing two pointers,
with different types, to the same data.
Guy Harris [Wed, 12 Nov 2014 01:24:12 +0000 (17:24 -0800)]
Add initial bounds check, get rid of union aodv.
Fetch the type field without using a structure, and check to make sure
it's not past the end of the packet.
Pass to each dissection routine a pointer to the appropriate message
type structure, rather than a pointer to a union of all the message type
structures.
Guy Harris [Sun, 23 Jun 2013 01:02:43 +0000 (18:02 -0700)]
Some changes didn't make it into 4.4.0.
Fix the CHANGES list by moving some changes that got in after the 4.4.0
release was made into a list for 4.4.1, and add some additional fixes to
that list.
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 <[email protected]>
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.
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.
Guy Harris [Mon, 6 May 2013 02:47:48 +0000 (19:47 -0700)]
Not all platforms on which we compile define PRI[doux]16.
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.)
Guy Harris [Mon, 6 May 2013 01:52:54 +0000 (18:52 -0700)]
Avoid bitfields, unaligned accesses, packed structures, and PRI[ux]{16,32}.
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).
Guy Harris [Tue, 16 Apr 2013 04:09:24 +0000 (21:09 -0700)]
Point people to the the-tcpdump-group repositories, not the mcr repositories.
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.
Denis Ovsienko [Thu, 14 Mar 2013 17:17:53 +0000 (21:17 +0400)]
use existing PGM decoder for UDP-encapsulated PGM
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.
Denis Ovsienko [Thu, 14 Mar 2013 16:24:22 +0000 (20:24 +0400)]
add a test case for native PGM
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.
Denis Ovsienko [Thu, 14 Mar 2013 15:58:51 +0000 (19:58 +0400)]
fix two issues with PGM length handling
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.
Gregory Detal [Mon, 25 Feb 2013 16:00:02 +0000 (17:00 +0100)]
Multipath TCP (RFC 6824) support
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.
Alexandra Kossovsky [Sun, 14 Apr 2013 18:57:56 +0000 (11:57 -0700)]
If we get SIGCHLD, restart whatever system call it interrupted.
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.
Guy Harris [Sat, 6 Apr 2013 20:03:58 +0000 (13:03 -0700)]
Check for extra networking libraries before checking for IPv6.
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.
Wesley Shields [Thu, 28 Mar 2013 02:28:11 +0000 (22:28 -0400)]
Stop reading multiple files properly on cleanup.
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.
Guy Harris [Tue, 26 Mar 2013 09:35:14 +0000 (02:35 -0700)]
Fix handling of V3 and V4 BPDUs.
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.
Guy Harris [Tue, 26 Mar 2013 09:01:31 +0000 (02:01 -0700)]
We don't define PRIu8 or PRIx8 if the C environment doesn't; don't use it.
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.
Romain Francoise [Sat, 23 Feb 2013 17:50:06 +0000 (18:50 +0100)]
Add two MS NLB test captures
msnlb1.pcap contains two heartbeat packets from a single cluster (two
nodes). msnlb2.pcap is the same capture with a lower snaplen to exercice
the truncation code path.
Denis Ovsienko [Sat, 9 Feb 2013 13:36:24 +0000 (17:36 +0400)]
ZeroMQ initial support (ZMTP/1.0 framing)
This change adds support for ZMTP/1.0 (ZeroMQ Message Transport Protocol
1.0) framing in TCP packets, as defined in http://rfc.zeromq.org/spec:13
and implemented in zeromq library.
Since there is no assigned port number for ZeroMQ, the user is left
responsible for making only the related TCP packets captured and
enforcing ZMTP/1.0 decoding through the "-T zmtp1" option.
Each ZMTP/1.0 frame of a packet will produce a single additional line of
output. The "-v" flag will add up to 8 lines (128 bytes) worth of
hex+ASCII dump of the frame body, and "-vv" and higher will dump the
full frame body, however long.
Beware that this code handles neither IP fragmentation nor TCP
segmentation and will incorrectly decode segments not starting at a
frame boundary.
The included sample capture stands for a short ZeroMQ session between a
REQ/REP socket pair doing 3 anonymous 2-way exchanges. It was produced
using version 2.1.9 of zeromq library patched to fix its bug #293, so
that all MBZ bits of the flags field are set to 0.