Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Feedback about Multipath TCP support

From: Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>
Date: Wed, 07 Jan 2015 20:21:44 -0500
On 01/04/2015 06:27 AM, Alexis La Goutte wrote:


On Sun, Dec 28, 2014 at 1:58 PM, Matt <mattator@xxxxxxxxx
<mailto:mattator@xxxxxxxxx>> wrote:

    Thanks for the comments.

    I will try to proceed as suggested by alexis via pushing to gerrit
    smaller (cleaned) patches.

Waiting your patches ;-)


    I have a question about the rules one attribute I added should conform
    to. I've added a "mptcp.stream" attribute to dissection, similar to
    "tcp.stream" with the difference that currently attributed numbers can
    be disjoint (ie you have packets matching "mptcp.stream == 0 or
    mptcp.stream == 3" but not packets for values 1,2 for instance) and I
    wonder if this is a problem (I believe it is) ?
    This is due to the fact that - according to my  implementation - some
    TCP flows are first attributed an mptcp.stream as soon as wireshark
    sees an MPTCP option. When later on they are associated with another
    MPTCP connection, all tcp flows adopt/share the "mptcp.stream" of that
    connection (referring to the previous example,  a TCP flow first got
    attributed mptcp.stream 1 while unassociated, then later it was
    associated to another TCP flow with "mptcp.stream == 0", thus giving
    up mptcp.stream 1, for which there is now 0 packets).
    I don't see any easy to have the mptcp.stream in order except if:
    - I don't give numbers to unassociated mptcp streams (which is wrong
    in my opinion, they should still be considered as streams)
    - I attribute mptcp.stream to unassociated flows at the end of
    dissection (when last packet get parsed), but I don't know how to do
    it. TCP flows can remain unassociated when wireshark didn't capture
    the interface on which the first TCP subflow of the MPTCP connection
    started.


    Hope it's clear x)  I wonder if there was a similar problem with SCTP
    associations dissections and how it got solved ?

Do you have look how to SCTP assoc works ?

Also Wireshark have 2 pass analysis, may be it will be help !

As far as I remember SCTP (rightly or wrongly) assigns a packet to a stream based strictly on the packets it's seen before and the current packet. That is, it never "re-assigns" the packet to a different stream.

This may be easier in SCTP since it has the (local and remote) vtag and ports which are quite good (quite unique) identifiers for an association.