The new file openflow-1.0.h is a verbatim copy of the file openflow.h
from the openflow-1.0.0.tar.gz distribution. The new file
print-openflow-1.0.c contains a set of functions for OpenFlow 1.0 (wire
protocol 0x01) decoding. Of these functions only
of10_header_body_print() is exported and used by the minimal OpenFlow
decoder.
It is intended that future (1.1, 1.2, 1.3.0) OpenFlow version decoders
are implemented the same way (in modules of their own), since different
versions of OpenFlow specification reuse the same symbols for different
numeric values. This way, print-openflow-1.1.c would include
openflow-1.1.h and so on.
The new test case "of10_p3295-vv" was produced using a Pica8 P-3295
switch and Trema controller running a purpose-built sample application.
Babel sub-TLVs are a work in progress, a backward-compatible extension
to Babel version 2 protocol encoding. This update implements encoding
explained by Juliusz Chroboczek to decode ChanInfo sub-TLV of the Update
TLV.
The Pad1 TLV consists only of the Type field (RFC6126 Section 4.4.1),
thus the check for Pad1 type must be done before the Length field is
consumed, if ever. This change brings tcpdump decoder into line with the
spec and Babel implementation's own TLV iterator.
The packet capture consists of two datagrams produced with a modified
version of Quagga-RE babeld, such that each TLV of the datagrams is
followed with one Pad1 TLV. This encoding is not what a Babel speaker
would typically send, but it is otherwise valid and up to the spec
(RFC6126 Sections 4.2 onwards).
The current version of the decoder has a bug iterating over Pad1.
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.
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.
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.
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.
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.
This change updates Babel decoder output format to match terminology of
draft-ovsienko-babel-hmac-authentication-00 and reverts recent addition
of DLen field to TLV type 12.
This change reflects a new Digest Length field added to Hash Digest TLV
in the current draft of Babel authentication spec. babel_print_v2() is
updated to fetch and validate the new field. Test files too.
This change addresses a few issues in rip_entry_print_v2() and
rip_print():
1. In the case of Simple Password (RFC2453) authentication the last
(16th) character of a password was never printed. Other password
characters were printed regardless of existing isprint() test.
2. In the case of Cryptographic (RFC4822) authentication there were no
details available for fixed-size auth header and variable-size auth
trailer.
3. Depending on particular hash function used, a normal authentication
trailer "RTE" may be 20 or more bytes long. Iteration over packet RTEs
should stop once a trailer is decoded. Exact number of RTEs in a message
cannot be told from message size any more.
Test cases are added for Request and Response messages with Simple
Password, Keyed-MD5, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 and
HMAC-SHA-512 authentication modes. Earlier test case is updated to match
new "number of routes" output format.
RIP Request and Response messages have the same structure. Update a
switch block in rip_print() to proceed with decoding of both.
A Request message may contain an AFI 0 RTE standing for a full table
request, normally sent on a router start. Update rip_entry_print_v1()
and rip_entry_print_v2() to treat IPv4 and AFI 0 as two valid,
distinguishable cases.
This change extends existing Babel protocol decoder to recognise
experimental authentication TLVs (types 11 and 12) and includes
a respective test case for the new code.
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.
Multiple nexthops in MP-BGP were not getting separated, so you are
left wondering "what kind of address is dead:beef::1fe80::1ff:fe01:0"?
Separate them with ", " so that it is more clear that they are
multiple nexthops.
