Ask Your Question

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

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

p11188536 gravatar image

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

Guy Harris gravatar image

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.
(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 <>
This is free software; see the source for copying conditions. There is NO

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?

edit retag flag offensive close merge delete


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 gravatar imageChuckc ( 2021-03-05 17:00:52 +0000 )edit

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

p11188536 gravatar imagep11188536 ( 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 gravatar imageChuckc ( 2021-03-06 02:37:25 +0000 )edit

ok, I will try it.

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

2 Answers

Sort by ยป oldest newest most voted

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

p11188536 gravatar image

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

grahamb gravatar image

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

edit flag offensive delete link more


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 gravatar imageGuy 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 gravatar imageGuy Harris ( 2021-03-19 10:00:27 +0000 )edit

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

Guy Harris gravatar image

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

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools


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

Seen: 1,242 times

Last updated: Mar 19 '21