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
