Wireshark mailing list archives
Feedback about Multipath TCP support
From: Matt <mattator () gmail com>
Date: Sat, 20 Dec 2014 01:24:30 +0100
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 ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- Feedback about Multipath TCP support Matt (Dec 19)
- Re: Feedback about Multipath TCP support Guy Harris (Dec 19)
- Re: Feedback about Multipath TCP support Alexis La Goutte (Dec 21)
- Re: Feedback about Multipath TCP support Matt (Dec 28)