https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3464
Summary: tshar silently failes after blocking of stdout
Product: Wireshark
Version: 1.0.5
Platform: x86
OS/Version: Linux (other)
Status: NEW
Severity: Normal
Priority: Medium
Component: TShark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: gkrames@xxxxxxx
Build Information:
TShark 1.0.5
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 GLib 2.18.2, with libpcap 0.9-PRE-CVS, with libz 1.2.3, without
POSIX capabilities, without libpcre, with SMI 0.4.5, without ADNS, without Lua,
without GnuTLS, without Gcrypt, without Kerberos.
NOTE: this build doesn't support the "matches" operator for Wireshark filter
syntax.
Running on Linux 2.6.27.7-9-default, with libpcap version 0.9-PRE-CVS.
Built using gcc 4.3.2 [gcc-4_3-branch revision 141291].
--
Running thsark in a pipe as follows:
"/opt/wireshark_1_0_5/bin/tshark -i eth0 -w mydump.pcap -S -T pdml -n |
myprog"
(often also using -f....)
Whenever myprog cannot catch up processing the input, tshark seems to enter an
error state where it continues to run (including its child dumppcap), but no
more packets are appended to the PCAP file.
This error state is persistent: Even if traffic goes down again (and myprog has
processed all backlog in the pipe), tshark will not resume writing the PCAP
file.
-----
The problem is that there is no way to detect that this overload
condition as occured. ("Does the PCAP end because there was no traffic any more
or because of a transient overload?")
So I think this error condition should be reported somehow, e.g. by non-zero
exit status or a suitable message on stderr.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
