The RFC 8684 introduced a new field in the MPC header: the data_len.
If the client has not seen yet a DSS sub-option from the server, it
must use MPC with data_lan instead of a DSS for the first packet
carrying a data payload.
This change print the data_len, if present, after the receiver_key.
The field is already there in the existent pcap test trace, we just
need to update the expected output.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
print "v1-echo" if the echo bit is set in the ADD_ADDR suboption (see
RFC8684 §3.4.1). While at it, dissect the 4 bits after the MPTCP option
subtype when the value is "ADD_ADDR" (0x3), according to protocol v0 and
v1. Add a selftest with a capture taken from a recent Linux kernel
implementation, and fix printout of add-addr in the existing selftests.
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
RFC6824bis-18 (MPTCP version 1) makes changes to the MPTCP
ADD_ADDR option format.
An HMAC field is added to the option and the IP version field is
removed and replaced with an Echo bit that provides a reliability
mechanism.
This change allows either v0 or v1 ADD_ADDR options
to be parsed and displayed correctly.
Signed-off-by: Peter Krystad <peter.krystad@linux.intel.com>
A new version of MPTCP protocol (RFC8684) has been published, with some
changes to the MP_CAPABLE options handling. Let tcpdump print the protocol
version, and adjust parsing of MP_CAPABLE options according to RFC8684.
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Replace more calls to ipaddr_string()/ip6addr_string() with calls to
GET_IPADDR_STRING()/GET_IP6ADDR_STRING() macros performing bounds
checking.
Add similar bounds-checking inline functions and macros to wrap
linkaddr_string(), etheraddr_string(), and isonsap_string() and convert
calls to them to use the macros as well.
Shuffle the inline functions in addrtoname.h around a bit, so that the
inline functions, external declarations, and macros are all in the same
order.
The exceptions are currently:
Some EXTRACT_ in print-juniper.c, not used on packet buffer pointer.
An EXTRACT_BE_U_3 in addrtoname.c, not always used on packet buffer
pointer.
This can prevent bizarre failures if, for example, you've done a
configuration in the top-level source directory, leaving behind one
config.h file, and then do an out-of-tree build in another directory,
with different configuration options. This way, we always pick up the
same config.h, in the build directory.
Now all the macros have a name meaning a count in bytes.
With _S_: signed, _U_: unsigned
e.g.:
EXTRACT_BE_32BITS -> EXTRACT_BE_U_4
EXTRACT_LE_32BITS -> EXTRACT_LE_U_4
...
EXTRACT_BE_INT32 -> EXTRACT_BE_S_4
and have:
EXTRACT_8BITS -> EXTRACT_U_1
EXTRACT_INT8 -> EXTRACT_S_1
Do the length checking inline; that means we print stuff up to the point
at which we run out of option data.
First check to make sure we have at least 4 bytes of option, so we have
flags to check.
This fixes a buffer over-read discovered by Kim Gwan Yeong.
Add a test using the capture file supplied by the reporter(s).
Have our own routines to convert between IPv4/IPv6 addresses and
strings; that helps if, for example, we want to build binary versions of
tcpdump for Windows that can run both on NT 5 (W2K/WXP), which doesn't
have inet_ntop() or inet_pton(), and NT 6 (Vista/7/8/10), which do. It
also means that we don't require IPv6 library support on UN*X to print
addresses (if somebody wants to build tcpdump for older UN*Xes lacking
IPv6 support in the system library or in add-on libraries).
Get rid of files in the missing directory that we don't need, and
various no-longer-necessary autoconf tests.
The purpose of this macro was to enable the file-by-file switch to NDO,
after which only tcpdump.c had a use of it and the definitions guarded
by it. Update tcpdump.c not to require them any more and dismiss the
unused definitions.
And, as we require at least autoconf 2.61, and as autoconf 2.61 and
later have AC_TYPE_UINTn_T and AC_TYPE_INTn_T macros, we use them to
define the uintN_t and intN_t macros if the system doesn't define them
for us.
This lets us get rid of bitypes.h as well.
Have them take a netdissect_options * argument, and get the "no name
resolution" flag from it.
Move the declaration of dnaddr_string to addrtoname.h, along with the
other XXX-to-string routines.
For headers included in only one source file, put the header contents in
the source file in question, and get rid of a bunch of stuff from the
header not used in the source file.
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.
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).
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.
