"No buffer space available" reported when capturing high-volume traffic on nflog device on Linux

tshark
buffer
memory
retag add tags

When my tshark program was running in the background, I used the SFTP protocol to download resources on the server. At this time, tshark reported the following error:

$ tshark -ni nflog:40 -w capturefile.pcap -b filesize:131072 -b files:120
Running as user "root" and group "root". This could be dangerous.
Capturing on 'nflog:40'
6654 tshark: Error while capturing packets: Can't receive packet 105:No buffer space available
Please report this to the Wireshark developers.
https://bugs.wireshark.org/
(This is not a crash; please do not report it as such.)

I checked my memory usage, and the swap space was very big.

Tasks:  99 total,   1 running,  98 sleeping,   0 stopped,   0 zombie
%Cpu(s): 34.5 us,  4.9 sy,  0.0 ni, 58.9 id,  0.0 wa,  0.0 hi,  1.7 si,  0.0 st
KiB Mem :  2047960 total,   662668 free,   936364 used,   448928 buff/cache
KiB Swap:  4194296 total,  4011780 free,   182516 used.   903000 avail Mem

The version of tshark:

$ tshark -v
Running as user "root" and group "root". This could be dangerous.
TShark (Wireshark) 2.6.10 (Git v2.6.10 packaged as 2.6.10-1~ubuntu16.04.0)

Copyright 1998-2019 Gerald Combs <[email protected]> and contributors.
License GPLv2+: GNU GPL version 2 or later <http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with libpcap, with POSIX capabilities (Linux), with libnl 3,
with GLib 2.48.2, with zlib 1.2.8, with SMI 0.4.8, with c-ares 1.10.0, with Lua
5.2.4, with GnuTLS 3.4.10, with Gcrypt 1.6.5, with MIT Kerberos, with MaxMind DB
resolver, with nghttp2 1.7.1, with LZ4, with Snappy, with libxml2 2.9.3.

Running on Linux 4.4.0-193-generic, with AMD Ryzen 9 3900X 12-Core Processor
(with SSE4.2), with 1999 MB of physical memory, with locale en_US, with
libpcap version 1.7.4, with GnuTLS 3.4.10, with Gcrypt 1.6.5, with zlib 1.2.8,
binary plugins supported (13 loaded).

Built using gcc 5.4.0 20160609.

I'm wondering why this happened?

p11188536

asked 2021-03-05 15:36:31 +0000

19.9k

Guy Harris

updated 2021-03-19 20:19:21 +0000

edit flag offensive 0 remove flag close merge delete

Comments

tshark calls dumpcap which uses libpcap - that's an error bubbled up from libpcap

Can you add the output of tshark -v to your question?

Chuckc (2021-03-05 17:00:52 +0000) edit

Thanks for your reply, I have updated the output of tshark -v

p11188536 (2021-03-06 01:29:13 +0000) edit

Not always easy but if you could upgrade Wireshark and libpcap (Changelog)

There is a tshark '-B|--buffer-size' option.
The description in the man page seems very YMMV.

Chuckc (2021-03-06 02:37:25 +0000) edit

ok, I will try it.

p11188536 (2021-03-06 14:41:13 +0000) edit

add a comment see more comments

2 Answers

Sort by

oldest

newest

most voted

Please file this as an issue on the libpcap issues list.

19.9k

Guy Harris

answered 2021-03-06 02:29:27 +0000

edit flag offensive 0 remove flag delete link

Comments

add a comment see more comments

The reason why my tshark program collapsed is that I was using SFTP protocol to download some big file on the server and the bandwidth at that time was quite high. Tshark program with default buffer size 2 MB could not keep so many packets thus it collapsed.

As for solution, I use the -B argument just like Chuckc suggested above. Thanks for his suggestion again, it really helps me a lot!!!

Buffer size can be modified with -B argument, In my case, I increase buffer size from the default 2 MB to 12 MB, and the command used is as follows: shell tshark -ni nflog:40 -B 12 -w capturefile.pcap -b filesize:131072 -b files:120

p11188536

answered 2021-03-19 08:01:42 +0000

23.8k

grahamb

updated 2021-03-19 08:43:10 +0000

edit flag offensive 0 remove flag delete link

Comments

Tshark program with default buffer size 2 MB

That's the default buffer size on Linux with regular network adapters. You're capturing on a netlink socket, and the default buffer size is whatever the default socket buffer size is for netlink sockets, which is probably not 2 MB.

-B will cause tcpdump/dumpcap/TShark/etc. to set the socket buffer size, so that set it to whatever it gets set to if you ask for 12 MB.

That error message needs to do a better job of indicating the source of the problem.

Guy Harris (2021-03-19 09:57:16 +0000) edit

That error message needs to do a better job of indicating the source of the problem.

Newer versions of libpcap will, in the netlink capture code, just increase the count of ENOBUFS errors if it gets ENOBUFS, rather than reporting an error; the call to get capture statistics will report that count as the number of dropped packets. If you're getting too many dropped packets on any device, increasing the buffer size may be worth trying.

Guy Harris (2021-03-19 10:00:27 +0000) edit

add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer

"No buffer space available" reported when capturing high-volume traffic on nflog device on Linux edit

Comments

2 Answers

Comments

Comments