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? :) > 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. > - 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. > Since the flag only has meaning between the calling and the called > dissector, I'm not so happy with it's presence in the frame-data > structure. The packet info struct is probably a better place for it based on what is already in epan/packet_info.h's declaration of packet_info. > - 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 :). Steve _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
