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.
