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

[Michal Sekletar <msekleta () redhat com>]

On Thu, Jan 08, 2015 at 06:57:08PM -0800, Guy Harris wrote:
> 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.

Is there any rational behind 1s value. Not saying it is wrong, just curious.

> 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.

Always there will be cases in which default setting are just not good enough. I
think that users doing high volume captures are minority so I'd not optimize
defaults for them.

> 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.)

I don't think using immediate mode is the right thing to do, because it defeats
the purpose of buffering done by kernel.

Can't we use new default timeout value (lower) if we detect TPACKET_V3, so we don't
defeat the purpose of buffering entirely but delay is short enough that output
looks realtime-ish to human observer looking at the console. If we are dumping
to savefile we should use higher value.

Michal

> _______________________________________________
> tcpdump-workers mailing list
> tcpdump-workers () lists tcpdump org
> https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers