Hi Sake,
I was curious to know - Are you working on this? I just wanted to know
because some work I am doing depends (slightly) on this and I will put
comments in the code accordingly.
Thanks!
Abhik.
On Thu, May 29, 2008 at 9:38 PM, Sake Blok <sake@xxxxxxxxxx> wrote:
> 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
> segment).
>
> Cheers,
> Sake
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
