> On Oct 20, 2024, at 12:11 AM, Garri Djavadyan <g.djavad...@gmail.com> wrote:
>
> On Sat, 2024-10-19 at 23:58 -0700, Guy Harris wrote:
>> On Oct 19, 2024, at 5:01 PM, Garri Djavadyan <g.djavad...@gmail.com>
>> wrote:
>>
>>> I am looking for a way to force tcpdump flush Linux OS buffer
>>> before
>>> terminating. I have checked the man page and the mailing list
>>> archives
>>> but did not manage to find anything related.
>>>
>>> When I terminate tcpdump process with SIGINT or SIGTERM, the
>>> process
>>> quits immediately, leaving packets in the buffer. I know that the
>>> signal USR2 forces the buffer to be flushed, but it does stop
>>> filling
>>> the buffer and the process remains active.
>>>
>>> I have to use a very big buffer with a very slow storage, much
>>> slower
>>> than the rate of coming packets received by the filter, and it is
>>> preferred not to lose a single packet after initiating termination
>>> the
>>> process.
>>
>> OK, so is the buffer to which you're referring the buffer that holds
>> captured packets for tcpdump to read, i.e. the *input* buffer for
>> tcpdump, rather than, for example, the standard I/O buffer containing
>> packet dissection text to be printed or the I/O buffer containing
>> packets to be written to the file specified by -w, i.e. an *output*
>> buffer for tcpdump?
>
> Correct. I meant the input buffer, specified with the -B flag.
OK, so by "flushing" the buffer - which, for an input buffer, usually means
discarding everything that's in the buffer and, for an output buffer, usually
means writing the buffer contents to the target file - you meant "draining" the
buffer, as in "processing all the packets in the buffer".
> When I terminate tcpdump process with SIGINT or SIGTERM, the process
> quits immediately, leaving packets in the buffer. I know that the
> signal USR2 forces the buffer to be flushed, but it does stop filling
> the buffer and the process remains active.
No, SIGUSR2 flushes the *output* buffer for the file being written to with -w.
The tcpdump man page does not make that clear; I will update it to do so.
> I have to use a very big buffer with a very slow storage, much slower
> than the rate of coming packets received by the filter, and it is
> preferred not to lose a single packet after initiating termination the
> process.
What do you mean by "with a very slow storage"? You can set the size with -B,
but that just tells the capture mechanism in the kernel how big a buffer to
allocate. It's not as if it tells it to be stored in some slower form of
memory.
> There are a few options to overcome the problem. For example,
> by dumping packets to the memory storage first (e.g. /dev/shm)
Presumably meaning you specified "-w /dev/shm" or something such as that?
If so, how does that make a difference?
> Still, I wonder if this can be done by tcpdump itself.
That would require that tcpdump be able to tell the capture mechanism to stop
capturing packets; otherwise, tcpdump could continue reading packets from the
buffer an processing them, but it's not as if the capture mechanism will stop
adding packets to the buffer, so that would behave as if tcpdump continued
capturing.
There is no current mechanism in libpcap by which tcpdump (or any other program
using libpcap to capture networking traffic, e.e. Wireshark) can indicate to
libpcap that it doesn't want any *more* packets from the network device, but
wants to be able to keep reading from the packets already *in* the buffer until
the last packet has been retrieved. That means tcpdump can't be told to do that
with any existing version of libpcap.
_______________________________________________
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
