| Bug ID |
8950
|
| Summary |
Relative ACK number not applied to packet with ACK bit not set
|
| Classification |
Unclassified
|
| Product |
Wireshark
|
| Version |
1.10.0
|
| Hardware |
x86-64
|
| OS |
Windows 7
|
| Status |
UNCONFIRMED
|
| Severity |
Minor
|
| Priority |
Low
|
| Component |
Wireshark
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Created attachment 11243 [details]
Capture that exhibits bug and capture that doesn't.
Build Information:
Version 1.10.0 (SVN Rev 49790 from /trunk-1.10)
Copyright 1998-2013 Gerald Combs <[email protected]> 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 (64-bit) with GTK+ 2.24.14, with Cairo 1.10.2, with Pango 1.30.1, with
GLib 2.34.1, with WinPcap (4_1_3), with libz 1.2.5, without POSIX capabilities,
without libnl, with SMI 0.4.8, with c-ares 1.9.1, with Lua 5.1, without Python,
with GnuTLS 2.12.18, with Gcrypt 1.4.6, without Kerberos, with GeoIP, with
PortAudio V19-devel (built Jun 5 2013), with AirPcap.
Running on 64-bit Windows 7 Service Pack 1, build 7601, with WinPcap version
4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch
1_0_rel0b (20091008), GnuTLS 2.12.18, Gcrypt 1.4.6, without AirPcap.
Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz, with 16277MB of physical
memory.
Built using Microsoft Visual C++ 10.0 build 40219
--
In the attached "anonymized ftp capture.pcap" file the last packet is
identified by Wireshark as Bad TCP because the ACK bit is not set but the ACK
number is not zero. Based on other factors I suspect that this occurred because
the packet was sent by an IPS module and not the actual host represented in the
source address field.
When viewed with relative sequence numbers disabled (TCP preference) the last
packet shows the expected sequence number and ACK number based on the packets
before it. However, when relative sequence numbers are enabled, the sequence
number in the last packet shows up (correctly) as a relative sequence number
but the ACK number continues to be shown with its absolute number.
Theorizing that this bug was linked to the ACK bit being set to zero, I opened
the file with a hex editor, set the ACK bit of the last packet to one and saved
the modified file as "anonymized ftp capture-withackbit.pcap." With the ACK bit
turned on the relative ACK number is displayed properly.
You are receiving this mail because:
- You are watching all bug changes.