I personally believe not passing retransmitted frames is a better choice, besides that its implementation is narrower, I see it as natural for a transport protocol not to pass retransmissions to the upper layer. All in all the user has a link in the packet details to the originally-transmitted frame if they need to see the dissection of the payload.
L On Wed, May 28, 2008 at 10:24 PM, Sake Blok <[EMAIL PROTECTED]> wrote: > On Tue, May 06, 2008 at 03:41:39PM -0600, Stephen Fisher wrote: >> On Tue, May 06, 2008 at 10:17:54PM +0200, Sake Blok wrote: >> >> > Today I noticed that SSL decryption breaks when there is a tcp >> > retransmission. >> >> We never run out of things to fix, do we? :) > > It's a mixed up world, we should have all bugs fixed before the end of > the day and never run out of beer... and *not* the other way around ;-) > >> > To solve this issue, I can think of several options: >> > >> > - Make the TCP dissector not forward retransmitted segments to higher >> > layer protocols, just like the normal TCP stack will do on the >> > receiving host. This will have a major impact on the way retransmitted >> > frames are displayed. Then again, the fully dissected segment is >> > already available. >> >> Something about this just doesn't feel right. > > Well, at first no. But I reconsidered and to me it feels like the > sensible way to go. All statistics will have duplicates when > the retransmitted data is sent again to the upper layer dissector. > (remember my session on Sharkfest, where enabling or disabling > the "tcp.desegment_tcp_streams" preference gave different results). > > Dissecting the retransmitted data with the "data" dissector prevents > these glitches. > > Also, on the system that received the packets, the data is sent to > the upper layer only once (in case the ACK got lost and it indeed > received the data twice). > > >> > - Have a "retransmitted_data" flag in the frame-data structure which >> > can be set by a dissector to warn the called dissector that the data >> > is is receiving is actually a copy of earlier received data so that it >> > can take proper action in dissecting it. >> >> I like this idea. The next protocol can then use it if necessary or >> ignore it. > > Yep, but that means having to change each and every dissector which > has tcp as it's transport layer. > >> > - Accept that retransmitted frames will break SSL decryption and let >> > the user delete the retransmitted frames themselves with editcap. >> >> Too much work for the user :). > > Agreed, have a look at the users-list, there is a thread in which this > problem occurs :-) > > > Any objections to the following fix: > > Have a preference in the tcp profile like "show retransmitted frames > as data" with tooltip "Dissecting the same fragment of data twice > can disrupt the upper layer dissectors (ssl-decryption for example)". > By default this preference will be unchecked to not change the current > behavior. > > > Cheers, > Sake > _______________________________________________ > Wireshark-dev mailing list > [email protected] > http://www.wireshark.org/mailman/listinfo/wireshark-dev > -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
