[Alexis La Goutte <alexis.lagoutte@xxxxxxxxx>]

On Sat, Dec 20, 2014 at 1:24 AM, Matt <mattator@xxxxxxxxx> wrote:

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

Hi Matt,

Patches are always welcome :-)

I think it is better to kept mptcp stuff in packet-tcp.c

there is no global debut, but you can use proto_tree_add_debug.. with #if MPTCP_DEBUG define for example.

About your patches, after a quick look, need some (big) cleanup (comment, indent...) to be integrated

Also i think, it will better to propose 2 patches, one with change for packet-tcp and a other with change for (Qt) GUI

 

Regards,

[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
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe