Wireshark mailing list archives
Re: Feedback about Multipath TCP support
From: Jeff Morriss <jeff.morriss.ws () gmail com>
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 () gmail com <mailto:mattator () gmail com>> 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 () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- Re: Feedback about Multipath TCP support Alexis La Goutte (Jan 04)
- Re: Feedback about Multipath TCP support Jeff Morriss (Jan 07)
- Re: Feedback about Multipath TCP support Matt (Jan 08)
- Re: Feedback about Multipath TCP support Jeff Morriss (Jan 08)
- Re: Feedback about Multipath TCP support Matt (Jan 08)
- Re: Feedback about Multipath TCP support Jeff Morriss (Jan 07)