osmocom
/
wireshark
14
0
Fork 1
Code Issues Pull Requests Projects Releases Wiki Activity

As per Michael Tuexen's suggestion, set the libpcap open timeout to 1 

second rather than 1/4 second on MacOS X, to workaround what appears to
be a MacOS BPF bug.

svn path=/trunk/; revision=4473
This commit is contained in:
Guy Harris 2002-01-04 06:27:42 +00:00
parent ae760a4caa
commit 9588f37fac
1 changed files with 14 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
capture.c
View File

@ -1,7 +1,7 @@
/* capture.c /* capture.c
* Routines for packet capture windows * Routines for packet capture windows
* *
* $Id: capture.c,v 1.164 2002/01/03 22:03:24 guy Exp $ * $Id: capture.c,v 1.165 2002/01/04 06:27:42 guy Exp $
* *
* Ethereal - Network traffic analyzer * Ethereal - Network traffic analyzer
* By Gerald Combs <gerald@ethereal.com> * By Gerald Combs <gerald@ethereal.com>
@ -992,8 +992,21 @@ signame(int sig)
/* /*
* Timeout, in milliseconds, for reads from the stream of captured packets. * Timeout, in milliseconds, for reads from the stream of captured packets.
*
* XXX - Michael Tuexen says MacOS X's BPF appears to be broken, in that
* if you use a timeout of 250 in "pcap_open_live()", you don't see
* packets until a large number of packets arrive; the timeout doesn't
* cause a smaller number of packets to be delivered. Perhaps a timeout
* that's less than 1 second acts like no timeout at all, so that you
* don't see packets until the BPF buffer fills up?
*
* The workaround is to use a timeout of 1000 seconds on MacOS X.
*/ */
#ifdef __APPLE__
#define CAP_READ_TIMEOUT 1000
#else
#define CAP_READ_TIMEOUT 250 #define CAP_READ_TIMEOUT 250
#endif
#ifndef _WIN32 #ifndef _WIN32
/* Take carre of byte order in the libpcap headers read from pipes. /* Take carre of byte order in the libpcap headers read from pipes.