Wireshark-bugs: [Wireshark-bugs] [Bug 10335] New: 1.12.0 does not dissect HTTP correctly (both G
Date: Sat, 02 Aug 2014 03:52:43 +0000
Bug ID 10335
Summary 1.12.0 does not dissect HTTP correctly (both GTK+ and QT)
Classification Unclassified
Product Wireshark
Version 1.12.0
Hardware x86
OS Windows Vista
Status UNCONFIRMED
Severity Major
Priority Low
Component GTK+ UI
Assignee bugzilla-admin@wireshark.org
Reporter Jim@agdatasystems.com

Build Information:
Version 1.12.0 (v1.12.0-0-g4fab41a from master-1.12)

Copyright 1998-2014 Gerald Combs <gerald@wireshark.org> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (32-bit) with GTK+ 2.24.23, with Cairo 1.10.2, with Pango 1.34.0, with
GLib 2.38.0, with WinPcap (4_1_3), with libz 1.2.5, with SMI 0.4.8, with c-ares
1.9.1, with Lua 5.2, without Python, with GnuTLS 3.1.22, with Gcrypt 1.6.0,
with
MIT Kerberos, with GeoIP, with PortAudio V19-devel (built Jul 31 2014), with
AirPcap.

Running on 32-bit Windows Vista Service Pack 2, build 6002, with WinPcap
version
4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch
1_0_rel0b (20091008), GnuTLS 3.1.22, Gcrypt 1.6.0, with AirPcap 4.1.1 build
1838,  from the PortableApps U3 device in drive L:.
AMD Athlon(tm) 64 X2 Dual Core Processor 4000+, with 1917MB of physical memory.


Built using Microsoft Visual C++ 10.0 build 40219

--
See the attached trace file, which is a download from the Wireshark web site.

All Wireshark settings were at default, except that "TCP > Allow subdissector
to reassemble TCP streams" was disabled.

Both the client and the server listed their HTTP version as 1.1 in their
http.request.version headers.

There are 30,918 packets in the trace. Only 71 packets are listed as "HTTP" in
the Protocol column. 290 packets are listed as HTTP2, and have one of the
following messages in the Info column:

  DATA [Packet size limited during capture]
  BLOCKED
  GOAWAY
  HEADERS [Packet size limited during capture]
  PING
  RST_STREAM
  WINDOW_UPDATE
  ALTSVC[Packet size limited during capture]
  SETTINGS[Packet size limited during capture]
  PUSH_PROMISE[Packet size limited during capture]
  PRIORITY
  CONTINUATION[Packet size limited during capture]

Even though a number of the messages include "[Packet size limited during
capture]", the capture snaplen was not limited, and in every case the values
for "bytes on wire" and "bytes captured" are the same.

The remaining 30,557 packets are shown only as "TCP" in the protocol column,
even though 19,826 of them have data and should have been identified by
Wireshark as HTTP. In these 19,826 packets, "Transmission Control Protocol" is
the highest layer protocol listed in the Packet Details pane. HTTP data is not
displayed in the Packet Details pane, even though it is visible on the Packet
Bytes pane.

Build information is from the GTK+ version, because that's where I did my
analysis, but I saw the same display in the QT version.


You are receiving this mail because:
  • You are watching all bug changes.