https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2895
Summary: Reloading a trace during capture can cause a TCP
connection to be considered to have negative (large
positive) relative sequence numbers
Product: Wireshark
Version: 1.0.3
Platform: PC
OS/Version: All
Status: NEW
Severity: Normal
Priority: Low
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: jmmikkel@xxxxxxx
Created an attachment (id=2254)
--> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=2254)
don't dissect newly arrived packets if we are currently redissecting
Build Information:
wireshark 1.0.3
Copyright 1998-2008 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.12.11, with GLib 2.16.3, with libpcap 0.9.4, with libz
1.2.3, without POSIX capabilities, with libpcre 7.8, with SMI 0.4.8, without
ADNS, without Lua, with GnuTLS 2.2.5, with Gcrypt 1.2.4, without Kerberos,
without PortAudio, without AirPcap.
Running on NetBSD 4.0.0_PATCH, with libpcap version 0.9.4.
Built using gcc 4.1.2 20061021 prerelease (NetBSD nb3 20061125).
--
The easiest way I can explain this bug is to describe the functional aspects
of Wireshark which contribute to it first. None of these are particularly
earth-shattering alone:
* If a packet trace is reloaded, e.g. for a change in the Preferences dialog,
Wireshark starts from the beginning of the trace and reparses.
* When the TCP dissector first encounters a packet in a given stream it keeps
the sequence number and calls that "zero" for relative sequence number
computation.
* If traffic is still being received while the trace is reloading, that traffic
is parsed as it arrives.
Together, in a specific circumstance, they cause the bug. Imagine an open
trace with a fairly large amount of data in it from past, completed
connections, and with a current connection having a lot of traffic. If I go
to Preferences and change something (anything other than turning off relative
sequence numbers!) the trace starts reloading. The first action is to clear out
all the old state and start with a clean slate, then begin parsing the packets.
Meanwhile the busy, current connection is still going. After some amount of the
older data has been parsed, yet before any data from the current connection
has been reached, Wireshark will read in new packet data and *parse* it. This
means that, as of that moment, the first packet for the current active
connection will be the first packet from that stream that Wireshark is keeping
track of (since all the old state is gone).
This means that the TCP dissector's "zero" packet is some packet in the middle
of that current, busy connection. When Wireshark continues parsing the older
data and it arrives at the first packet for that current connection, the stream
has already been found. And it will have a "zero" value in the future, as it
were. So if, say, the first new data had a relative sequence number of 10000,
then the actual first packet in the stream will have a relative sequence number
of -10000, which is of course treated as an unsigned value, so it will be
given the relative sequence number 4294957296.
If the first packet of the current connection is parsed before new data is read
in and parsed, then "zero" will be set correctly and all is good. That is why
there must be a large enough amount of data from other connections in the trace
beforehand. If the current connection is not very busy such that no data
arrives in the window of opportunity, it will also be fine. And of course this
does not happen loading traces in files as no new data is processed out of
order. So this bug isn't very common, but it hurt me pretty badly when it
happened to me.
Here are the steps I used to reproduce it. Note that trying to use a loopback
connection can confuse the issue, I see a lot of missed packets there, so I use
two computers.
* I set up Wireshark to capture the traffic, and to auto scroll the packet
list. Of course, "Relative sequence numbers and window scaling" must be
enabled.
* On a computer, I used netcat to receive traffic:
computer1% nc -l -p 23456 > /dev/null
* On a different computer, I sent a large file (~ 20 MB seems to be plenty for
me):
computer2% nc computer1 23456 < a_20_MB_file
* Leaving Wireshark still capturing, I brought up the Preferences dialog and
turned off checksum validation (just for something to change) WITHOUT
clicking "Apply" or "OK" yet.
* I resent the file:
computer1% nc -l -p 23456 > /dev/null
computer2% nc computer1 23456 < a_20_MB_file
* As soon as that connection was started, I clicked "OK" to reload the trace,
and while I pushed the button I memorized the packet number showing at the
bottom of the trace.
* Once it has reloaded, I scrolled up to that number. The next packet will
usually be the packet with a relative sequence number or ack of 1. It will
be in that vicinity anyway.
If you have a nice clean network it is really not difficult to see something's
wrong since *everything* will be marked as a retransmission!
I am including the patch I made to address the issue, in case you would like to
use it.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
