Wireshark-bugs: [Wireshark-bugs] [Bug 7008] New: TCP picks wrong sub-dissector if both dissector
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7008
Summary: TCP picks wrong sub-dissector if both dissector
choices have the same "minimum segment size"
Product: Wireshark
Version: 1.7.x (Experimental)
Platform: x86
OS/Version: Windows XP
Status: NEW
Severity: Normal
Priority: Low
Component: Wireshark
AssignedTo: bugzilla-admin@xxxxxxxxxxxxx
ReportedBy: mmann78@xxxxxxxxxxxx
Created attachment 8105
--> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=8105
SendRRData dissection (good)
Build Information:
Version 1.7.1 (SVN Rev 41818 from /trunk)
Copyright 1998-2012 Gerald Combs <gerald@xxxxxxxxxxxxx> 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.10, with Cairo 1.10.2, with Pango 1.29.4, with
GLib 2.28.8, with WinPcap (4_1_2), with libz 1.2.5, without POSIX capabilities,
with SMI 0.4.8, with c-ares 1.7.1, with Lua 5.1, with Python 2.7, with GnuTLS
2.12.18, with Gcrypt 1.4.6, with MIT Kerberos, with GeoIP, with PortAudio
V19-devel (built Mar 28 2012), with AirPcap.
Running on Windows XP Service Pack 3, build 2600, with WinPcap version 4.1.2
(packet.dll version 4.1.0.2001), based on libpcap version 1.0 branch 1_0_rel0b
(20091008), GnuTLS 2.12.18, Gcrypt 1.4.6, without AirPcap.
Built using Microsoft Visual C++ 9.0 build 30729
--
Attached are 3 traces of Ethernet/IP traffic, but only 1 is decoded as
Ethernet/IP (SendRRData_Reference_sample.pcap). From what I can tell from
debugging the issue is that the other two aren't decoded as Ethernet/IP because
1. the "source port" value is lower than the "dest port" value, so Wireshark
chooses the dissector with the lower registered port value
2. The "source port" dissector has the same size requirement for the first
"segment" of data, so Wireshark can't not use it on those grounds.
Since Ethernet/IP's registered IANA port number is so large (44818), most
TCP/IP stacks will end up picking a lower port number when a TCP socket is
opened. If that port number coinsides with a Wireshark dissector that
1. supports TCP reassembly
2. has the same "minimum size" of a packet segment as Ethernet/IP (4)
Wireshark will dissect it incorrectly.
I see in the TCP dissector, it will try the "lower port" first, but shouldn't
there be more weight to the conversation in regards to where the SYN bit is?
The attached traces are the "ideal" conversation, where Wireshark could use the
destination port of the packet with the initial SYN.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
