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 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.
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.
