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:
parent
ae760a4caa
commit
9588f37fac
15
capture.c
15
capture.c
|
@ -1,7 +1,7 @@
|
|||
/* capture.c
|
||||
* 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
|
||||
* By Gerald Combs <gerald@ethereal.com>
|
||||
|
@ -992,8 +992,21 @@ signame(int sig)
|
|||
|
||||
/*
|
||||
* 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
|
||||
#endif
|
||||
|
||||
#ifndef _WIN32
|
||||
/* Take carre of byte order in the libpcap headers read from pipes.
|
||||
|
|
Loading…
Reference in New Issue