Wireshark-bugs: [Wireshark-bugs] [Bug 6059] New: The SSL dissector can not resemble correctly th
Date: Sun, 26 Jun 2011 14:06:02 -0700 (PDT)

           Summary: The SSL dissector can not resemble correctly the
                    frames after TCP zero window probe packet
           Product: Wireshark
           Version: 1.6.0
          Platform: x86-64
        OS/Version: Windows 7
            Status: NEW
          Severity: Normal
          Priority: Low
         Component: Wireshark
        AssignedTo: [email protected]
        ReportedBy: [email protected]

Created an attachment (id=6562)
 --> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=6562)
Capture showing the problem

Build Information:
Version 1.6.0 (SVN Rev 37592 from /trunk-1.6)

Copyright 1998-2011 Gerald Combs <[email protected]> and contributors.
This is free software; see the source for copying conditions. There is NO

Compiled (64-bit) with GTK+ 2.22.1, with GLib 2.26.1, with WinPcap (version
unknown), with libz 1.2.5, without POSIX capabilities, without libpcre, without
SMI, with c-ares 1.7.1, with Lua 5.1, without Python, with GnuTLS 2.10.3, with
Gcrypt 1.4.6, without Kerberos, with GeoIP, with PortAudio V19-devel (built Jun 
7 2011), with AirPcap.

Running on 64-bit Windows 7 Service Pack 1, build 7601, with WinPcap version
4.1.2 (packet.dll version, based on libpcap version 1.0 branch
1_0_rel0b (20091008), GnuTLS 2.10.3, Gcrypt 1.4.6, without AirPcap.

Built using Microsoft Visual C++ 9.0 build 21022

Wireshark is Open Source Software released under the GNU General Public

Check the man page and http://www.wireshark.org for more information.
Please load the attached capture in Wireshark - it represents one TCP session
carrying SSL. You'll see that starting with packet 123, all packets from the
server to the client are marked by the GUI as "TLSv1 Ignored unknown record".
The reason for that is because the SSL dissector does not treat correctly the
TCP zero window probe packet that the server sent before that - packet 119. If
you remove packet 119 from the capture and load it again, everything will look
ok with the payload of the packets that were marked before as ignored unknown

I found this problem in version 1.4.6, then I upgraded to the latest 1.6.0 and
because the problem still existed, I decided to report it. Yes, there is a
simple workaround for this issue but it is kinda annoying to have to edit the
entire capture to get rid of all zero window packets in it in order to be sure
that the SSL dissector will run correctly on it.

Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.