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 <sake@xxxxxxxxxx> 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
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan