Buffer size for capturing packets in kernel space?

Question

Going through the man page of tcpdump here It seems kernel can drop the packets if the buffer is full. I was wondering if

1) that size is configurable and/or 2) where can I see the size for my distro?

From the man page (for easy reference):

packets ``dropped by kernel'' (this is the number of packets that were dropped, due to a lack of buffer space, by the packet capture mechanism in the OS on which tcpdump is running, if the OS reports that information to applications; if not, it will be reported as 0).

Solution 1

There are several areas you might check to mitigate packets dropped by kernel:

• Look at configuring /proc/sys/net/core/netdev_max_backlog and /proc/sys/net/core/netdev_budget. The default is probably pretty low; try setting each to something like 2000.
• Writing to the output device screen may be blocking/slowing the tcpdump process long enough to fill the recv buffer
  • Use -nn to turn off DNS lookups and port naming
  • Write to file instead of the screen
  • Try a tool such as gulp
• If you have a multi-processor machine look at using taskset
• Use nice to set the priority of the process

Even with those settings, it may just be that you can not keep up with the speed of the traffic you are trying to capture. Look at the details of your NIC and machine and ensure that what you expect is even possible.

Solution 2

1) It's configurable but not precisely as it would decide a proper size from your request.

2) Use setsockopt / getsockopt with SO_RCVBUF / SO_SNDBUF

I'm not familiar with linux but it seems this link explains it well. http://linux.die.net/man/7/socket

Comments

[Anon]

Thanks for your answer. I tried your suggestion and the answer I got was around 48kb. Which does not seem right. It is size of the socket buffer, not the buffer size which kernel keeps for receiving packets. Thank you for your hard work.

[Anon]

Thanks. Modifying /proc/sys/net/core/netdev_max_backlog did the trick for me. Off topic question here in case you happen to see this comment, Why would writing to file be faster/better than writing to screen when in unix both are practically files?

[ezpz]

I'm not an expert but I'd imagine it boils down to the buffering techniques that can be used in either case. I'm sure you'd get a more definitive answer if you asked a formal question ;)

[Anon]

I can ask a formal question but I need to be sure that this is the case. Do you have any first hand experience / case study at hand right now , where you observed this? I would really love to know the answer if writing to file instead of screen is faster. Thank you for taking time out to answer my question.

[ezpz]

It is going to very dependent on the output device. A quick run on my machine using gnome-terminal vs aterm set to capture 100000 packets on a heavy download: gnome-terminal (to file) : 20 dropped gnome-terminal (to screen) : 27217 dropped aterm (to file) : 0 dropped aterm (to screen) : 0 dropped

[caf]

@Anon: ezpz is right, writing to a file can be much faster than writing to screen. Writing to "screen" tends to actually mean writing to a PTY, and PTYs have a very limited buffer size. If the displaying program on the other side of the PTY isn't reading fast enough, then that buffer will fill and writes to the PTY will start to block. Most displaying programs are slower than disk (and disk has much larger buffers, too).