[Guy Harris <guy@xxxxxxxxxx>]

> In addition, it also deliberately asks the libpcap to, if the underlying
> packet capture mechanism libpcap uses supports that notion, buffer
> packets for 1/4 second so that libpcap gets more than one frame per
> read...
> 
> ...except on a certain BSD-based system from Cupertino, California,
> where an apparent bug in the underlying packet capture mechanism appears
> to cause buffering for less than 1 second not to work, in which case it
> asks the underlying packet capture mechanism to buffer for 1 second.

...although it doesn't do so in 0.9.0; that fix will be in the next
release.

The symptoms of that particular Darwin/MacOS X bug is that packets don't
show up until the packet capture mechanism's buffer fills, so they don't
get displayed for a while.

So the next release, which should come out soon, will fix that, but
there'll still be the one-second display update delay that exists on all
platforms.