Hi,
Upstream wireshark can display Multipath TCP (MPTCP) options. I work
on MPTCP for my studies and I have improved MPTCP support in my
wireshark branch in various ways. I am looking for some feedback on
the overall direction to follow for converting this *prototype* code
(relatively untested yet) towards sthg potentially upstreamable.
Here is a list of the improvements made compared to upstream (easier
to understand if you know MPTCP [2]):
-the code can compute Initial Data Sequence Number (IDSN) and token
during MPTCP 3 Way HandShake (3WHS). Both are generated from the MPTCP
cryptographic key.
-thus it allows to map TCP subflows to their respective MPTCP
connection (ie wireshark can tell "tcp.stream 0,4,5 belong to the same
MPTCP connection, e.g. mptcp.stream == 0").
-MPTCP follows the same sequence number/ack scheme as TCP, except
MPTCP sequence numbers/acks are passed as TCP options (and are 64bits
instead of 32). If wireshark saw the initial 3WHS, then it is able to
display relative MPTCP sequence numbers.
-MPTCP analysis can be disabled via the options (maybe it should be
the default behavior as MPTCP analysis can be quite demanding).
-wireshark can map TCP seq numbers to MPTCP sequence numbers and tell
from which packet it got the mapping
Here are a few thoughts:
- outsourcing MPTCP identifiers (token/key) in a new linked list could
speed up MPTCP connection search
- I moved tcp.options.mptcp.* to mptcp.* because it's faster to type.
I can revert this but MPTCP can be considered as a protocol by itself.
- I could not find any global "debug utility". I use macros (to be
able to quickly disable printf so that I can test tshark with my dev
version) but it's a bit annoying.
- I wonder if some of the code should go to a new file
tcp-packet-mptcp.c else tcp-packet.c will be get too big ? or be moved
to a tap-mptcp.c ? I am not that familiar with taps, I see them more
like "to generate statistics".
I believe wireshark may need to implement some data structures/GUIs
helping with upcoming multipath protocols such as TRILL, SCTP, LISP,
MPTCP... it could be a structure that would map "flows" to a "node".
For instance SCTP and MPTCP support multihoming so we may see multiple
"conversations" that belong to a same endhost. For instance with MPTCP
you can tell TCP connections belong to a same MPTCP connection , in
SCTP you can associate secondary paths to a primary path, in LISP you
can map IPs to the encapsulating routers etc...
Code is available here [0].
And for those who just want a quick look, you can find 2 screenshots
in [1] (and an MPTCP pcap for test + a diff of the code between my
branch and an old master branch):
Again, this is work in progress, just looking for some advice here
with in mind possible upstreaming.
Feel to ask any question related to MPTCP or the code.
Best regards
Matt
[0] https://github.com/teto/wireshark/tree/mptcp_assoc
[1] http://downloads.tuxfamily.org/bluecosmos/wireshark/
[2] http://www.rfc-editor.org/rfc/rfc6182.txt
