The -B option of tcpdump on my machine doesn't seem to have any effect

[owlli]

The -B option of tcpdump on my machine doesn't seem to have any effect

[guyharris]

How can I determine if the memory allocation using the -B option was successful

If the memory couldn't be allocated at all, pcap_activate() will fail. However...

how can I observe how much memory I allocated with the -B option?

...there is no guarantee that the full size for which you asked is allocated. To find out how much space was allocated, you'll have to add a debugging printout just before

	handlep->mmapbuf = mmap(0, handlep->mmapbuflen, PROT_READ | PROT_WRITE, flags, handle->fd, 0);

in the pcap-linux.c source code, printing out the value of handlep->mmapbuflen, as that's the total size of the buffer allocated within the kernel.

Note that handlep->mmapbuflen is req.tp_block_nr * req.tp_block_size, where req.tp_block_nr is the number of blocks in the buffer and req.tp_block_size is the size of each block. Packets are added to the block as they arrive, and the process waiting for a block of packets is woken up either if the block is full (meaning that the next packet to arrive won't fit in that block and is therefore put in the next block) or the timeout expires with at least one packet in the block.

[guyharris]

However, why did the tcpdump process consume 400MB of memory when I set the parameter as 200000?

"Set the parameter" in a call to pcap_set_buffer_size() in your own program, or "set the parameter" in tcpdump?

If it's in tcpdump, the question amounts to "why does it consume about ~419,430,400 bytes when tcpdump sets the parameter to 204,800,000 bytes?"

If you're not using immediate mode - which tcpdump will not do unless you explicitly request immediate mode - libpcap will, on Linux, use TPACKET_V3, which means that the buffer is composed f a ring of sub-buffers; the current sub-buffer gets packets added to it until either 1) it fills up or 2) the packet buffer timeout (as set by pcap_set_timeout()) expires, at which point that sub-buffer is handed to userland and the kernel-mode code starts filling up the next buffer (unless userland gets so far behind that all sub-buffers have been handed to it and there are no sub-buffers one by the kernel-mode code).

With TPACKET_V3, the size of "frame" requested of the kernel is, in the current version of libpcap, 256KB (262144 bytes), and the total number of "frames" requested of the kernel is (total_buffer_size + 262144 - 1)/262144 (i.e., the total buffer size, rounded up to a multiple of 256KB, divided by the "frame" size). So libpcap will request 782 "frames", each 262144 bytes in size).

libpcap then computers the sub-buffer size to request as being the smallest power of 2 >= the page size of the machine and >= the "frame" size. Most machines running Linux support pages <= 256KB, so we'll assume the sub-buffer size is also set to 262144 bytes.

The number of "frames" per block is the block size divided by the frame size, which will be 1. The total number of sub-buffers is the total number of "frames" divided by the number of "frames" per block, so it's the same as the number of "frames".

That gets handed to the kernel.

From a quick look at the memory-mapping code in the kernel, that shouldn't have to round much up, so it should end up allocating not much more than 204,996,608 bytes, if any.

[guyharris]

Is the buffer not allocated by the tcpdump process?

The buffer is allocated in the kernel's address space. Either it's only in the kernel's address space, with libpcap reading packets from it using, for example, read() calls, or (as is the case on Linux) it's allocated in the kernel's address space, and not pageable, but is also mapped into the user-mode program's address space.

[owlli]

Is the buffer not allocated by the tcpdump process?

The buffer is allocated in the kernel's address space. Either it's only in the kernel's address space, with libpcap reading packets from it using, for example, read() calls, or (as is the case on Linux) it's allocated in the kernel's address space, and not pageable, but is also mapped into the user-mode program's address space.

Why is the packet loss ratio the same when using a buffer size of 1k and 1.9 while capturing packets under slightly higher network traffic than the tcpdump's capture performance? How can I determine if the memory allocation using the -B option was successful and how can I observe how much memory I allocated with the -B option?

[owlli]

Issue resolved

[owlli]

"I have encountered a new problem that I cannot understand. When using the -B option in tcpdump, the memory usage of its process remains unchanged. However, when I use the pcap_set_buffer_size function from the libpcap library in my own packet capture program and set a buffer size of 2GB, the memory usage increases by 2GB. What could be the reason for this? Isn't the -B option in tcpdump implemented using pcap_set_buffer_size?"

[guyharris]

Here's the code in tcpdump that handles the -B flag:

	if (Bflag != 0) {
		status = pcap_set_buffer_size(pc, Bflag);
		if (status != 0)
			error("%s: Can't set buffer size: %s",
			    device, pcap_statustostr(status));
	}

where Bflag is the value provided to the -B flag.

pcap_set_buffer_size() takes an argument that is in units of bytes.

Unfortunately, that argument is an int, which means that, on almost all if not all platforms on which libpcap/tcpdump runs, the maximum possible size is 2GB-1. Attempting to set it to 2GB, i.e. 2147483648, will, at least in newer version of libpcap, result in pcap_set_buffer_size() seeing the size as negative and ignoring the attempt to set it.

What version of libpcap are you using? And what argument did you pass to -B when you ran tcpdump?

[owlli]

Sorry, I didn't pay attention to the unit of the '-B' option parameter in tcpdump. I provided the parameter as '200M', so this option didn't take effect. However, why did the tcpdump process consume 400MB of memory when I set the parameter as 200000?

[owlli]

Thanks.