https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3303
--- Comment #6 from didier gautheron <[email protected]> 2009-04-22 10:07:00 PDT --- (In reply to comment #4) > Created an attachment (id=2959) --> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=2959) [details] > SVN-28088.cap > > Hi Didier, > > This is the trace which caused me to write the fix of SVN-28088. Have a look > at > frame 7 in which the "Certificate" message which starts in frame 6 is > continued > by reading X more bytes. After that there is still data left, but control is > given back at the TCP dissector which created a new SSL subtree for the > "ServerHelloDone" message that is also present in frame 7. Having another > subtree makes one belief that this message is actually an SSL record within an > SSL record, which is not the case. By supplying the whole frame to the SSL > dissector, it loops through the available SSL records in the frame and lists > them under the SSL subtree. > Thanks a lot for the capture but most dissectors with multiple PDUs inside the same TCP segments create a new subtree for each PDU. I agree that your way make more sense but It's not a ssl specific bug. The fact that ServerHelloDone isn't displayed in the column info is a separate bug, for example the X11 dissector is able to get it right. What's bother me is that in my understanding your use of ONE_MORE_SEGMENT is incompatible with the caller function desegment_tcp(). For example if your look at the first attached capture, now ssl doesn't get the size of the PDU right (cf frame 14). About the bug report. In frame 14 the certificate is not decoded because its size is wrong (55326 for a TLS record size of 16384), the ssl dissector assumes that the handshake type is a false positive and gives up. The last TLS record is not decoded because desegment_tcp() never decodes incomplete PDU on TCP reset if TCP_FLOW_REASSEMBLE_UNTIL_FIN is not set. Didier -- Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. ___________________________________________________________________________ Sent via: Wireshark-bugs mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://wireshark.org/mailman/options/wireshark-bugs mailto:[email protected]?subject=unsubscribe
