Wireshark-dev: Re: [Wireshark-dev] SSL decryption breaks after retransmission
From: Sake Blok <[email protected]>
Date: Thu, 29 May 2008 19:38:23 +0200
On Thu, May 29, 2008 at 12:19:31PM -0400, Bill Meier wrote:
> >>> >
> >>> > - 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.
> 1. Given that TCP is a streaming protocol, ISTR that a "retransmitted frame"
> can actually consist partially of bytes previously sent and partially of
> additional bytes not previously sent.
> If this is the case (and I'm not missing something), then presumably the tcp
> dissector would need to forward any "new" bytes of a frame.

Yes indeed. When tcp reassembly is enabled, this will be taken care of
unless the extra data is actually the start of a new upper layer PDU. I
will either try to incorporate this case in my fix, or put some notes in 
the code that it should be fixed in the future. I think there will not be
many cases where this happens...

> 2. How does re-assembly play into this discussion ?
> I haven't looked at the SSL dissector so I don't know how it works. Is
> re-assembly being used ?
> Doesn't re-assembly in effect take care of retransmissions (at least in some
> cases) ?

It does, unless the retransmitted segment is the last part of the upper layer
PDU (which of course includes the case where the PDU consists of only one tcp