Libpcap timeout settings in tcpdump - too long when printing to a terminal?

[Guy Harris <guy () alum mit edu>]

With TPACKET_V3 support, Linux users are discovering what those of us using BSD-flavored OSes have known for quite a 
while:

        http://askubuntu.com/questions/570885/can-tcpdump-on-ubuntu-14-04-show-packets-in-real-time

Tcpdump uses a timeout of 1 second when opening a capture device; this can, on platforms that do BPF-style buffering, 
cause a 1-second delay before packets show up.  TPACKET_V3 is the first Linux capture mechanism to do BPF-style 
buffering, so when a Linux user switches to a distribution version that introduces a kernel that supports TPACKET_V3 
and a libpcap that uses TPACKET_V3, they'll start seeing delays that they haven't seen before.

The longer timeout can reduce capturing overhead, and if you're capturing a high volume of traffic to a file, it's 
probably the right timeout to have.  If, however, you're printing packets to the console, you're probably doomed if 
it's a high volume of traffic, and may want less of a delay if it's a low volume of traffic.

Should we reduce the timeout if -w isn't specified - or do so if -w isn't specified *and* if we're outputting to a 
terminal (isatty(1) returns a non-zero value)?  Should we use immediate mode if libpcap supports it?  Should we offer a 
command-line option to override the default?  (I'd prefer to have the default be appropriate for most cases, which may 
mean a different default if printing packets or if printing them to the console rather than a file, but, in addition to 
that, a command-line option to allow more sophisticated users to tweak the timeout might be useful.)
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers