https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15427
Bug ID: 15427
Summary: New data not passed to TCP subdissector if part of
data is retrasmission
Product: Wireshark
Version: 2.6.4
Hardware: x86-64
OS: Windows 7
Status: UNCONFIRMED
Severity: Normal
Priority: Low
Component: Dissection engine (libwireshark)
Assignee: bugzilla-ad...@wireshark.org
Reporter: zirafa_go...@yahoo.com
Target Milestone: ---
Created attachment 16847
--> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=16847&action=edit
dissector and capture file
Build Information:
Version 2.6.4 (v2.6.4-0-g29d48ec8)
Copyright 1998-2018 Gerald Combs <ger...@wireshark.org> 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 Qt 5.9.5, with WinPcap (4_1_3), with GLib 2.42.0, with
zlib 1.2.11, with SMI 0.4.8, with c-ares 1.14.0, with Lua 5.2.4, with GnuTLS
3.4.11, with Gcrypt 1.7.6, with MIT Kerberos, with MaxMind DB resolver, with
nghttp2 1.14.0, with LZ4, with Snappy, with libxml2 2.9.4, with QtMultimedia,
with AirPcap, with SBC, with SpanDSP, with bcg729.
Running on 64-bit Windows 7 Service Pack 1, build 7601, with Intel(R) Core(TM)
i7-5820K CPU @ 3.30GHz (with SSE4.2), with 32678 MB of physical memory, with
locale English_United States.1252, with Npcap version 0.99-r7, based on libpcap
version 1.8.1, with GnuTLS 3.4.11, with Gcrypt 1.7.6, without AirPcap, binary
plugins supported (14 loaded). Built using Microsoft Visual C++ 14.12 build
25835
Wireshark is Open Source Software released under the GNU General Public
License.
Check the man page and http://www.wireshark.org for more information.
--
I have a lua dissector for my custom protocol. The dissector works fine and
reassembles PDUs well in all but one use case:
When TCP ZeroWindowProbe happens because of the full window, one byte of data
is sent. My dissector detects that this is not enough for the header and asks
for more data (by setting pinfo.desegment_len = DESEGMENT_ONE_MORE_SEGMENT).
The problem is that when ACK is finally received, the new packet sent includes
the one byte used for probe (as well as additional 1459 bytes of new data) and
the whole packet gets treated as a retransmission and is not handed over to the
dissector (I'm not sure the retransmission is the cause, but it seems related).
I tried turning off the "Do not call subdissectors for error packets" and with
"Allow subdissectors to reassemble TCP streams" options and in that case my
dissector gets called, but when I try to signal that I need more data (when I
get to the last, partial message in the packet), the left over data is ignored
and not passed to the dissector with the next packet.
I attached a TCP stream capture file and a stripped down lua dissector that
reproduces the problem. The entries of interest are [5693-5699] (when run with
the dissector). For some reason, in similar situations that occur later in the
stream (e.g. entries [5703-5711]), packets containing the retransmitted byte
are not marked as a retransmission and the data is passed to the dissector.
If it helps, all valid messages either start with 0x1a04 or 0x3200 - other
messages are badly parsed due to lost bytes in the stream.
--
You are receiving this mail because:
You are watching all bug changes.___________________________________________________________________________
Sent via: Wireshark-bugs mailing list <wireshark-bugs@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
