https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5818
rdtransient@xxxxxxxx changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rdtransient@xxxxxxxx
--- Comment #4 from rdtransient@xxxxxxxx 2011-04-28 15:06:48 PDT ---
(In reply to comment #1)
> Can you attach a capture file that triggers the bug? You can mark it private if
> needed.
I also see this with gentoo bleeding edge (zlib-1.2.5-r2, wireshark 1.4.6).
Attaching a capture file is probably not helpful. It doesn't seem to be a bug
in the pcap file, because reading it with another wireshark instance using -r
/tmp/wireshark<foo> reads past the point where the live capture is
stalled/corrupted. Right now I'm looking at a live capture stuck at packet
31431, and another (using -r ) that read in more than 40k packets from the same
temp file the live capture is using.
The only hint of what may be going wrong is in the last packet captured live.
Packet 31430 looks fine (0-length tcp ack), while packet 31431 is corrupt,
starting with frame info arrival time of Oct 4, 2068 19:04:18.-825688888.
Wireshark complains in the frame info that negative fractional values are
wrong; everything else in the packet is corrupt, starting with the MAC
addresses reported in the ethernet layer being corrupt. After more than a few
minutes of letting it sit, it made progress reading some additional frames, but
they're all corrupt as well (arbitrary protocol ids, highest dissector being
ethernet II) They tend to be 66 or 1484 bytes long, with the notable exception
that the first corrupt packet is 16896 bytes. Before the corruption, most of
the frames were 66 or 1484 bytes long as well, so the record start/end markers
must be interpreted ok.
I'm not familiar with pcap file formats but maybe that info will mean something
to someone?
It was easy to reproduce with 1.4.6 by starting a capture and letting it run
for a while few minutes.
Trying out 1.5.1, on the same system, same flags except with python disabled
(it broke the compile), it seem not to have the problem. It's been running for
45 minutes now without corruption.
wireshark 1.4.6
Copyright 1998-2011 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 (64-bit) with GTK+ 2.24.3, with GLib 2.28.6, with libpcap 1.1.1, with
libz 1.2.5, with POSIX capabilities (Linux), with libpcre (version unknown),
without SMI, without c-ares, with ADNS, with Lua 5.1, with Python, with GnuTLS
2.10.5, without Gcrypt, without Kerberos, without GeoIP, without PortAudio,
without AirPcap.
Running on Linux 2.6.38.4, with libpcap version 1.1.1, with libz 1.2.5, GnuTLS
2.10.5.
Built using gcc 4.5.2.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
