| Bug ID |
12411
|
| Summary |
HTTP POST spanning 2 successive packets not decoded
|
| Product |
Wireshark
|
| Version |
2.0.2
|
| Hardware |
x86-64
|
| OS |
Windows 7
|
| Status |
UNCONFIRMED
|
| Severity |
Major
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Created attachment 14536 [details]
Packet trace
Build Information:
Version 2.0.2 (v2.0.2-0-ga16e22e from master-2.0)
Copyright 1998-2016 Gerald Combs <[email protected]> and contributors.
License GPLv2+: GNU GPL version 2 or later
<http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
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 (64-bit) with GTK+ 2.24.23, with Cairo 1.12.16, with Pango 1.36.8,
with
WinPcap (4_1_3), with libz 1.2.8, with GLib 2.42.0, with SMI 0.4.8, with c-ares
1.9.1, with Lua 5.2, with GnuTLS 3.2.15, with Gcrypt 1.6.2, with MIT Kerberos,
with GeoIP, with PortAudio V19-devel (built Feb 26 2016), with AirPcap.
Running on 64-bit Windows 7 Service Pack 1, build 7601, with locale
English_United Kingdom.1252, with WinPcap version 4.1.3 (packet.dll version
4.1.0.2980), based on libpcap version 1.0 branch 1_0_rel0b (20091008), with
GnuTLS 3.2.15, with Gcrypt 1.6.2, without AirPcap.
Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz (with SSE4.2), with 7888MB of
physical memory.
Built using Microsoft Visual C++ 12.0 build 40629
Wireshark is Open Source Software released under the GNU General Public
License.
Check the man page and http://www.wireshark.org for more information.
--
Hi All,
An HTTP POST request carried in packets ##4-5 in the trace attached is only
decoded as TCP when "Allow subdissector to reassemble TCP streams" is checked
in Preferences > Protocols > TCP. An HTTP 200 OK response carried in packets
##9-10 has the same issue. Unchecking this option enables the packets to be
decoded as HTTP. Could Wireshark be enhanced at some point so that such packets
are decoded HTTP with this option still checked?
Many thanks in anticipation,
Dmitriy
P.S. An attempt to use TCP FIN flag as criteria in a somewhat similar case was
successfully undertaken earlier:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9848
, however neither of packets ##4-5 in the trace attached carries FIN, so the
fix doesn't help on this occasion.
Both issues were first discussed here:
https://ask.wireshark.org/questions/30352/packet-with-http-302-redirect-decoded-as-tcp-not-http#
You are receiving this mail because:
- You are watching all bug changes.