used for this purpose and using it also prevents the 2 signals the child gets:
- the user's Ctrl-C (which is sent as a SIGINT to both *shark and its
child dumpcap)
- the signal *shark generates to shut down the child
from colliding (and running 2 signal handlers in the child).
It might be possible for tshark to not send the signal at all when it gets
SIGINT, but it doesn't do any harm now.
Also, do not call g_log() within the signal handler: doing so can cause
aborts (if g_log is being called by the process when the signal comes, the
2nd entrance into g_log is detected as a recursion).
This fixes https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2767
svn path=/trunk/; revision=29881
pipes. Enable this by default on Windows. Remove code that tried to
use WaitForSingleObject on a pipe (which Windows doesn't support). Use
native file handles and system calls on Windows (which fixes a problem
with partial reads I ran into during testing).
This should fix bug 1759.
svn path=/trunk/; revision=29574
[PATCH] Fix dumpcap believing error on ^C i.e. pcap_breakloop()
When ^C was pressed during a packet capture, dumpcap believed a pcap
error had occurred. We check the return value more closely to avoid
this problem.
svn path=/trunk/; revision=29510
I've created a new bug rather than reopening 1181 as the scope is constrained
somewhat more.
Basically, when capturing from a named pipe the wireshark display lags by one
packet. This is especially frustrating when the packets arrive at low rates.
tshark is fine. But the packet count in dumpcap also lags by one.
Looking at the code, the problem appears to be in cap_pipe_select(). It
attempts to use WaitForSingleObject() on the named pipe but AFAICT this never
blocks.
I've attached a diff for some code that fixes the issue for me. The semantics
of overlapped IO in Win32 is quite different from the select/read model - hence
the other changes!
I've tested this fix on WinXP, 2k server and 2003 server. I've also checked
that my changes compile on a Freespire box that I have lying around.
From me:
Adapt the changes for dumpcap, which is where the affected code now lives.
svn path=/trunk/; revision=28452
dumpcap should terminate if exactly the maximum number of packets have been captured
(or greater) as specified by the user: "-c <capture packet count>". The current behavior
waits until an additional packet is captured until this threshold check occurs.
svn path=/trunk/; revision=27208
capinfos and dumpcap don't need to depend on libwireshark nor directly pull
in those modules). Because capinfos and editcap were only being linked with
privileges.c if we had plugins, this allows those programs to be linked when
someone is compiling --without-plugins.
svn path=/trunk/; revision=25640
setting, and is used only in dumpcap.c, and needs to get at information
set by dumpcap's signal handlers so it can respond to ^C; move it to
dumpcap.c, rename it print_statistics_loop(), and make it set ld.go to
TRUE before looping and loop only as long as ld.go is TRUE.
That fixes bug 2592 (at least on Mac OS X, and probably on other UN*Xes;
it should fix it on Windows as well).
svn path=/trunk/; revision=25492
libwireshark (and the plugins using those functions) do not depend on
wiretap on Windows.
While doing that, rename the eth_* functions to ws_*.
svn path=/trunk/; revision=25354
On glib-1.2 systems g_ascii_strcasecmp() is in libwireshark (which we don't
want to include in dumpcap) and anyway our code should be the only thing
calling dumpcap with "-Z"--so hopefully there's no need for doing a
case-insensitive comparison.
(This is another argument for adding a "utils" library.)
svn path=/trunk/; revision=24462
1. Clean up dumpcap 'as a child' err msg handling so that:
- all err msgs are properly formatted when being sent
back to the parent.
- any log Critical, Warning, etc messages
are sent back to parent and are properly formatted.
2. Change handling of -w <...> slightly in capture_opts.c
so that wireshark provides a good error message if
there is a 'write permissions' issue on the file.
(Previously the error popup said only
"Child exited with status 2").
This fixes bug #2288.
Add some conditionalized DEBUG_CHILD_DUMPCAP code for
dumpcap debug logging to a file.
svn path=/trunk/; revision=24446
opening the capture device. That somewhat fixes bug 2273, although the
second and subsequent files don't have the right group ownership,
probably because of the problem described in the comment before
relinquish_special_privs_perm().
We should also relinquish special privileges *before* trying to open the
capture pipe, so that we can't open a pipe to which the real user
doesn't have access.
svn path=/trunk/; revision=24347
does capturing any more. (We will be inserting a call to give up
privileges after the pcap_open_live(), which should fix 2273; we're
currently only giving up privileges on platforms with libcap.)
svn path=/trunk/; revision=24345
- retrieving the list of remote PCAP interfaces
- password authentication support
- UDP data fransfer
- packet sampling (available in WinPcap 4.x)
etc.
fix problem if non-default rpcap port is used
svn path=/trunk/; revision=23750