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 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.
The most notable difference between RFC5006 and RFC6106 is the addition
of DNSSL RA option. This commit adds DNSSL handling code to make tcpdump
fully RFC6106-aware. This code has been tested against RA packets
generated by Quagga and radvd.
Unfortunately, the DLT_PFSYNC support depends on header files included
from the pfctl command's source tree, and trying to arrange to find that
would be too much trouble.
From FreeBSD PR bin/124825: tcpdump(8) does not support pfsync(4) data,
which in turn was ported over from OpenBSD. We already have CARP
support, so we did not port that part over.
CARP and VRRP both use IP protocol number 112, so there needs to be a -T
flag to specify that protocol 112 be dissected as CARP rather than VRRP.
Also update the man page.
I was rudely surprised to find that "tcpdump -h" wasn't printing a usage
message, and I'm the person who *added* the "-h" option. Make it "-H",
and add an explicit "-h" option to print a usage message, so nobody else
makes the same mistake. Also, don't clear opterr, so that if you give
an illegal command-line option, you get an explanatory error message.
The Wireshark routine is based on the BSD in-kernel portable checksum
routine (thus BSD-licensed); it takes a vector of pointers and lengths
and checksums the concatenation of the buffers in question (just as the
BSD in-kernel routine checksums a chain of mbufs).
This simplifies the "with a pseudo-header" checksums; hopefully it'll
fix up the problems being seen on some big-endian platforms, which might
be due to hand-calculating some or all of the checksum and doing so
incorrectly. It also gets rid of some code that might be dereferencing
unaligned pointers.
Use it in netdissect.h, where it's defined; otherwise, we get a bunch of
warnings when compiling modules that include interface.h but don't yet
include netdissect.h.
To: tcpdump-workers@lists.tcpdump.org
Date: Sat, 09 Apr 2011 12:51:14 +1000
Subject: [tcpdump-workers] Printing PPI packets
Printing PPI packets with tcpdump does not turn out
to be that hard.
My simple tests have produced the output as below.
It would be worthwhile having some changes made into
the tcpdump code base that were similar to the attached
that print them out.
This prevents GCC on SPARC from generating code that assumes those
structures are aligned naturally, which they are not guaranteed to be.
Move some #defines from interface.h to tcpdump-stdinc.h to make them
available to code that doesn't include interface.h.
Move the declaration of nextproto6_cksum() to ip6.h, so that only files
that use it get it declared, and thus so that you don't need to define
"struct ip6_hdr" in everything that includes interface.h. Don't include
ip6.h in tcpdump-stdinc.h.
At least some versions of GCC will, on SPARC, generate code for
if (bp->bp_htype == 1 && bp->bp_hlen == 6 && bp->bp_op == BOOTPREQUEST) {
where bp is a pointer to a struct bootp, that loads the first 4-byte
word in that structure, masks out the field in that structure that's not
being compared, and compares against a word with the appropriate values
in the other fields. That won't work, because there's no guarantee that
bp points to a value aligned on a 4-byte boundary.
Declaring "struct bootp" to be packed appears to keep at least GCC 4.2.4
from performing that optimization; we define an "UNALIGNED" tag to apply
to structures to prevent that optimization, and apply that tag to the
structures in bootp.h. (We'll apply it to other structures as we
discover the need for it.)
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).
Instead of having the Ethernet-type handler process the VLAN and Alteon
jumbo frame Ethernet type values, process them in the Ethernet (and
Linux cooked-mode) dissectors. This makes it easier for the right MAC
addresses to be printed for those packets.
As part of that, rename ether_encap_print() to ethertype_print() - it
doesn't print encapsulated Ethernet frames, it prints payloads whose
packet type is indicated by an Ethernet type field value - and remove
the no-longer-needed "extracted Ethernet type" argument. That also lets
us eliminate it from the SNAP print routine.
Make ether_print() take a function, and an argument to pass to that
function, as parameters, so that, for example, the ATM LANE printer can
use it and put the LEC ID into the link-layer headeer printout.
The configure script doesn't define BYTE_ORDER, so they can't validly be
compared against BYTE_ORDER; don't leave them around for people to think
they can.
on OpenSolaris, or Solaris Express Community Edition, build 125 and later.
The attached patch introduces support for printing out the IPNET headers used
for packet capture inside of zones that share their networking with the global
zone and for packets "transmitted" between zones.
tcpdump 4.0.0 will ship with builds 129 and later of OpenSolaris/SXCE and
when run as root with the '-L' option, should behave as below to indicate that
the system is fully functional:
Data link types (use option -y to set):
DOCSIS (DOCSIS) (printing not supported)
IPNET (Solaris IPNET)
EN10MB (Ethernet)
Cheers,
Darren
Unfortunately OLSR uses the same IDs for IPv4 and IPv6 packets, even
though the size of "messages" differ. The version of the internet protocol
is therefore handed to the "olsr_print" function.
The code isn't very nice, due to a high density of #ifdef INET6'es. If
IPv6-support really should be optional, I'm afraid this is inevitable.
Both, compilation with and without IPv6 support has been tested.
The patch addresses fixes other issues, too. The length given in the packet
was used for pointer arithmetic without checking if the value was in a
reasonable range first in several places. It should now be possible to
decode more than one "namespace message" within a single packet. Other
changes remove trailing whitespace or fix lines indented with tabs (the
majority of the file is indented using spaces).
Signed-off-by: Florian Forster <octo@leeloo.lan.home.verplant.org>
printed when trying to print packets for a DLT_ for which we don't have
a printer to indicate that you can still save to a capture file in that
case. (Slightly changed not to require DLT_USB_LINUX_MMAPPED to be
defined, for older libpcaps that only define DLT_USB_LINUX.)
The shared secret is passed using the already existing -M option which is
used for TCP-MD5 checking.
add initial supoort for RSVP Integrity object verification.
