https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5265
Guy Harris <guy@xxxxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #3 from Guy Harris <guy@xxxxxxxxxxxx> 2010-09-29 18:46:42 PDT ---
Nope, the problem had nothing to do with that.
The problem is that, in dumpcap:
1) when threads aren't used when capturing on a pipe, the timeout we used
on the select() call on the pipe is CAP_READ_TIMEOUT;
2) the timeout is set to tv_sec = 0, tv_usec = CAP_READ_TIMEOUT*1000
(CAP_READ_TIMEOUT is in milliseconds, as that's the units libpcap uses for
timeouts);
3) to work around a BPF bug that affects 64-bit applications in Snow
Leopard, CAP_PIPE_TIMEOUT si set to 1000, not 250, in 64-bit code on versions
of Snow Leopard that don't have a workaround for the bug in libpcap;
4) tv_usec >= 1000000 is an error in select() and causes the select() call
to fail with EINVAL.
This means that *any* capturing from a pipe - with Wireshark, TShark, or
dumpcap (as Wireshark and TShark have dumpcap do the capturing) - will fail in
OS X 10.6, 10.6.1, 10.6.3, and 10.6.4 (10.6.2 has a workaround in libpcap for
the bug; that workaround disappeared in 10.6.3).
I've checked in changes to
1) use 250ms as timeout in the select() for pipes (regardless of whether
this is one of the offending versions of Snow Leopard or not)
and
2) handle select() timeouts >= 1 second.
That appears to fix the problem. I'll mark those fixes for inclusion in 1.4.1.
For now, try one of the automated builds from
http://www.wireshark.org/download/automated/osx/
for version 34283 or later. (You would want one of the Intel 64.dmg builds.)
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.