Thanks for the comments.
I will try to proceed as suggested by alexis via pushing to gerrit
smaller (cleaned) 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 ?
Regards
