Re: pipeline buffering

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

On Mar 10, 2012, at 12:01 PM, jedge wrote:

> I suppose if you don't HAVE_PCAP_DUMP_FLUSH....

If the libpcap with which tcpdump is built is a version released at the same time, or after, the time that version of 
tcpdump is released, it'll have pcap_dump_flush().  A version of tcpdump with -U support in the source will lack -U 
support only if linked with an older version of libpcap, e.g. if you have a system with an older version of libpcap 
(which will probably also include an older version of tcpdump), and you download a newer version of the tcpdump source 
and build it with the libpcap you have on your system.

> maybe for morons like me we can add a reference to -U in -w:

How about

      −w     Write the raw packets to file rather than parsing  and  printing
             them  out.  They can later be printed with the −r option.  Stan‐
             dard output is used if file is ‘‘‐’’.

             This output will be buffered if written to a file or pipe, so  a
             program reading from the file or pipe may not see packets for an
             arbitrary amount of time after they are received.   Use  the  −U
             flag  to  cause  packets  to  be  written  as  soon  as they are
             received.

             See pcap‐savefile(5) for a description of the file format.

I've checked that version into the trunk and the 4.2 branch.

> and since -U is conditional upon -w then it can be reflected in the usage.

Actually, it's not conditional upon -w; if you don't specify -w, -U means "flush the standard output after the 
information for each packet is printed" (which does a bit more buffering than -l - especially on Windows, where, 
apparently, "line buffering" means "no buffering", if I remember correctly).

And, yes, the man page needs to be updated to reflect that.  I'll do that.-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.