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

1 files changed, 14 insertions, 1 deletions

diff --git a/capture.c b/capture.c
index 070ffbe44d..b28f330996 100644
--- a/capture.c
+++ b/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.