On Sat, Dec 20, 2014 at 1:24 AM, Matt <matta...@gmail.com> 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@wireshark.org> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe >
___________________________________________________________________________ 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-requ...@wireshark.org?subject=unsubscribe
