[Matt <mattator@xxxxxxxxx>]

MPTCP connection identifiers are only sent during the 3WHS, or when
there is a failure (I don't know if SCTP sends vtag/ports it in every
packet ?)

The "re-assign" problem occurs when wireshark does not see a TCP flow
SYN packets (thus does not see the MPTCP connection identifier =>
assigns a new mptcp.stream) and later on there is an MPTCP failure =>
a MPTCP connection identifier is sent and only then wireshark can
associate tcp subflows with the same MPTCP identifier (ie assign the
same mptcp.stream to several tcp.stream).

I've listed a few alternatives I could think of:
1/ the SCTP approach (?!); wait for an MPTCP connection identifier
before assigning the mptcp.stream and mark the TCP subflow as
mptcp.unassociated meanwhile. If there is no failure on this subflow,
the subflow will never get assigned an mptcp.stream (except if we can
run some postprocessing once the first dissection pass is finished ?)
which I find problematic (makes harder to distinguish between
unassociated MPTCP subflows).
2/ each time there is reassignment, reassign other mptcp.streams so
that there is no gap (Complex implementation and compute-intensive)
3/ During the first pass, we use 2 "lists" (datastructures, not
necessarily a list), list1 for MPTCP subflows with known MPTCP
identifier, a second one list2 for MPTCP subflows wihout MPTCP
identifier (yet). During the second pass, unassociated subflows are
assigned [ max( mptcp.stream in list1) + number of items in list2],
then removed from list2.
This way every TCP flow with MPTCP options gets an mptcp.stream and
they are consecutive. This is the best option in my opinion.

Matt

2015-01-08 2:21 GMT+01:00 Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>:
> 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.
>
>
> ___________________________________________________________________________
> 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