| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Cast the pointers to uintptr_t; use AC_TYPE_UINTPTR_T to get uintptr_t
defined on older platforms that don't define it themselves.
|
| |
|
|
| |
Fixes GitHub issue #437.
|
| | |
|
| | |
|
| |
|
|
| |
Clean up a const issue while we're at it.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
Running out of packet length before running out of unreachable
destinations is an error; report it as such.
Don't worry about leftover data past the end of the list of unreachable
destinations.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
Have "struct aodv_rerr" just be the header, not including the actual
destinations.
Simplify the logic somewhat, and make it similar in the print routines
for the three types of error messages.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Don't run past the end of the captured data, and don't run past the end
of the packet (i.e., don't make the length variable go negative).
Also, stop dissecting if the message length isn't valid.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The line buffer is 256 bytes long, so the name subfield in the line
can't be bigger than 256 bytes, but
1) somebody could make the line buffer bigger
and
2) this way the format item and buffer size match
so we'll do it anyway.
|
| |
|
|
|
| |
MAXHOSTNAMELEN + 100 is only 164 which is less than 256 sscanf() buffer.
Fix it by increasing size of nambuf buffer.
|
| |
|
|
|
|
| |
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 <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).
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Added:
* option length check
* option type and TCP flags check
* more information printed
Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Some of those warnings are real bugs - some routines whose callers
expected them to return values weren't returning values.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
At least according to the Wireshark STP dissector, SNAP frames with the
Cisco OUI and a PID of 0x010c contain BPDUs, for "VLAN Bridge".
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
