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
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
Anders Broman