Abhik, I did take a look at it, but have not found the time yet to create a proper fix.
Cheers, Sake On Mon, Jul 07, 2008 at 04:03:28PM +0400, Abhik Sarkar wrote: > 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 <[EMAIL PROTECTED]> 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@wireshark.org > > http://www.wireshark.org/mailman/listinfo/wireshark-dev > > > _______________________________________________ > Wireshark-dev mailing list > Wireshark-dev@wireshark.org > https://wireshark.org/mailman/listinfo/wireshark-dev > _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev