TLDR

Use --immediate-mode* **, e.g.

tcpdump --immediate-mode -w out.pcap

And then use Ctrl+C to stop tcpdump whenever you feel like it, without fear of data loss.

* --packet_buffered should do the trick but is not present in older versions of tcpdump; see below.

** But if you’re just printing to the console (that is, not using -w to save to a file), then the non-lossy behavior will be enabled by default, so no need to use these options.

Is there a short option name?

No. tcpdump has short options, but only for the common, unwashed masses who are OK with data loss. Data loss, or carpal tunnel snydrome: Which is worse?

OK, since you asked, --packet-buffered has a -U synonym, and that should work; see discussion below.

Why

tcpdump has undefeated status in its role as the packet capture tool of choice for admins and hackers alike. If you Google ignorant questions like “how to stop tcpdump” (you imbecile), you will get even more ignorant answers, such as:

Use Ctrl+C, you dummy

This is kind of right but dangerously wrong! If you do this, it will often work, but with a silent failure: Any data buffered and not yet written to disk will be lost to the digital ether forever. This is especially dangerous if you’re trusting that output to tell you about something not being there, and if you’re stopping your packet capture promptly.

If you Google (or OpenAI, the Great Google Summarizer), you will get more lame (but sort of correct) suggestions:

1. Use the -C option to stop after capturing a certain number of packets. But who ever wants to capture a certain number of packets? Definitely not someone working on an actual system with actual network traffic.
2. Use the -G option to stop after capturing a certain amount of time. OK, I guess, but again see above.

In practice, I find that I often want to stop a capture after a different condition is met, for example, I have my HTTP response and know that a request has completed.

What’s a poor hacker to do?

Not to worry, I’ve braved the depths of the man pages and bring the answer here to you, in an effort to push the limits of Googleable knowledge forward by one tiny, human sized step:

--immediate-mode
    Capture in "immediate mode". In this mode, packets are delivered to tcpdump as soon as they arrive, rather than being buffered for efficiency. This is the default when printing packets rather than saving packets to a ``savefile'' if the packets are being printed to a terminal rather than to a file or pipe.

There you go! Simple!

--immediate-mode or --packet-buffered?

There is another tpcdump option with an eerily similar description:

--packet-buffered
    If the -w option is not specified, or if it is specified but the --print flag is also specified, make the printed packet output ``packet-buffered''; i.e., as the description of the contents of each packet is printed, it will be written to the standard output, rather than, when not writing to a terminal, being written only when the output buffer fills.

    If the -w option is specified, make the saved raw packet output ``packet-buffered''; i.e., as each packet is saved, it will be written to the output file, rather than being written only when the output buffer fills.

I read these three times and cannot tell the difference. Maybe the new --packet-buffered is more reliable? And/or faster? And/or less reliable and/or slower? You decide. If you do understand it, please write me and I’ll owe you a drink.

What I can tell you is that, as the man page continues:

    The -U flag will not be supported if tcpdump was built with an older version of libpcap that lacks the pcap_dump_flush(3PCAP) function.

So --immediate-mode will have more support in older versions anyway.

On the other hand, --packet-buffered has a shortname (-U), which --immediate-mode does not.

Don’t Forget It!

Here’s to reliable data capture and the elimination of obscure and difficult to track errors. Cheers!

PS/Shameless Plug: I wrote a [colorization gadget for tcpdump console output][./tcpdump-colors-with-rainbow] that avid tcpdump users may enjoy.