At Thu, 29 May 2008 11:04:02 -0400 (EDT), you wrote
>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.
>>>
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.
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) ?