Recently I had to send a huge amount of ICMPpingpackets in a really short time, e.g. without any delay between two RTTs. When trying to rise the number of probes, I encountered the problem mentioned in this article's title. I found a solution working for me, which is described here.

Identifying the problem

To me, the problem occured when issuing the command

ping -i0 -c3000 1.1.1.1
ping got results for the first 198 probes -- all following were overlayed with the error
ping: sendto: No buffer space available
...which was not only frustrating but also reproducable. But reproducable means there has to be a systematic reason for the observed behavior, which can be found (and pehaps resolved). I started googling aroud with no real effort. Perhaps my googling skills are worse than expected or there was no simple answer. Thinking about it: What happens and may cause the problem? Where are buffers that can be unavailable (e.g. filled up)? Thepingprocess itself? Less likely. If I would have programmed it, I would have taken precaution to not run out of memory that quick. Follow-Up: What does ping? It uses a more-or-less raw socket to generate the ICMP packet and hand it to the kernel which then (hopefully) passes it to the network. Another place to look for buffers!

Solution

On FreeBSD, runtime kernel settings are issued using sysctl, which also allows to view all present options (using the switch -a). Looking carefully, I came across the net.inet.icmp.icmplim-setting. Raising its value above the default of 200 finally solved the problem, at least in my case.

Stichworte:


Impressum