Wireshark-bugs: [Wireshark-bugs] [Bug 3464] New: tshar silently failes after blocking of stdout
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Fri, 15 May 2009 00:45:33 -0700 (PDT)
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.