libpcap/WinPcap and the capture mechanism atop which they run might
either silently limit the buffer size to a smaller value or raise it to
a higher value - that's the part that's platform-dependent.
svn path=/trunk/; revision=32718
the code to print the machine-readable format into dumpcap, and have the
code in capture_opts.c just print the human-readable format.
svn path=/trunk/; revision=32714
standard error and, in Wireshark on Windows, create a console if
necessary. Have the cmdarg_err routines use them.
Use *fprintf_stderr() to print the output of -L, rather than using
cmdarg_err_cont(), so that we don't get extra newlines in the output (it
should look similar to the output of tcpdump).
svn path=/trunk/; revision=32711
interface by running dumpcap, so that if you need privileges to open an
interface, and dumpcap has those privileges, neither TShark nor
Wireshark need them.
svn path=/trunk/; revision=32710
pcap_set_buffer_size() did as well, so there aren't any libpcap releases
with pcap_create() but not pcap_set_buffer_size().
Only do one check for pcap_create.
svn path=/trunk/; revision=32695
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=475
BUT not activating the check for
pcap_create()
pcap_set_buffer_size()
This should make it possible to build with support for setting the buffersize if not capturing 802.11 traffic.
The code for handling the 'B' option should be OK in any case.
svn path=/trunk/; revision=32688
timeout bug.
Make the code for the workaround assume any 10.6.x release other than
10.6.2 requires it; that way we don't have to update the code until
either
1) Apple fixes the bug in a later 10.6.x update
or
2) Apple comes out with a major release that still has, or
reintroduces, the bug.
svn path=/trunk/; revision=32349
link-layer header types for interfaces; if special privileges are
necessary to open capture devices, Wireshark and TShark shouldn't have
those privileges, but dumpcap should.
svn path=/trunk/; revision=32104
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