Wireshark-bugs: [Wireshark-bugs] [Bug 1550] New: TCP dissector incorrectly assumes SYN's ACK fie
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1550
Summary: TCP dissector incorrectly assumes SYN's ACK field is
zeros
Product: Wireshark
Version: SVN
Platform: PC
OS/Version: All
Status: NEW
Severity: Minor
Priority: Low
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: luke@xxxxxxxx
Build Information:
wireshark 0.99.6 (SVN Rev 21511)
Copyright 1998-2007 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 with GTK+ 2.10.6, with GLib 2.12.4, with libpcap 0.9.4, with libz
1.2.3, without libpcre, without Net-SNMP, without ADNS, without Lua, without
GnuTLS, without Gcrypt, without Kerberos, without PortAudio, without AirPcap.
NOTE: this build doesn't support the "matches" operator for Wireshark filter
syntax.
Running on Linux 2.6.17-10-generic, with libpcap version 0.9.4.
Built using gcc 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5).
--
In the initial SYN of a TCP handshake, the value of the ACK field is undefined.
Currently, the TCP dissector assumes it is 0.
In certain configurations, Cisco PIX firewalls encode data (or randomize) this
field, which breaks the relative sequence number analysis of the TCP dissector
for that flow.
The fix is to not set tcpd->rev->base_seq=ack unless SYN isn't set. That way,
the SYNACK will set tcpd->fwd->base_seq to it's ISN, and we can still pick up
relative sequence numbers on the first frame if we didn't capture the handshake
for a flow.
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
