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

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

On Jan 9, 2015, at 2:09 AM, Michal Sekletar <msekleta () redhat com> wrote:

> Can't we use new default timeout value (lower) if we detect TPACKET_V3,

The first sentence of my original mail was "With TPACKET_V3 support, Linux users are discovering what those of us using 
BSD-flavored OSes have known for quite a while:"

This is not a TPACKET_V3 issue, it's a buffering issue.  I notice it when testing tcpdump on Macs, which don't have 
PF_PACKET sockets of any sort, they have BPF; if, for example, I test on the generally-low-traffic loopback interface 
by pinging 127.0.0.1, the packets don't show up continuously, they show up in batches, with a 1-second delay.

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

Yes, that's what I was suggesting - have tcpdump only use the 1-second timeout when writing to a file, and use a lower 
timeout, such as 1/10 second or less, when writing to a terminal, *regardless of what capture mechanism is being used*. 
 That will remove the display delay for BPF-like capture mechanisms (BPF itself - except on AIX, where we use immediate 
mode due to bugs, TPACKET_V3, possibly the Tru64 UNIX mechanism) and have no effect on capture mechanisms that don't do 
timeout-based buffering (all other Linux mechanisms, IRIX, BPF on AIX, DLPI on HP-UX).  DLPI+bufmod on Solaris, as I 
remember, does the timeout differently - it's an inter-packet timeout - but I think it might help there.

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