## TL;DR
Your scan is transmitting faster than the network interface or its driver can buffer, so the kernel refuses the send. Slow the scan down with --max-rate and --scan-delay, or drop to a gentler timing template. The scan gets slower but stops aborting.

```text
sendto in send_ip_packet: sendto(4, packet, 44, 0, 192.0.2.5, 16) => No buffer space available
```

## Use this when
- Fast scans abort with the sendto / No buffer space available error.
- You are scanning from a VM, a small test box, or Windows.
- The targets are in your authorized scope.

## Not for this skill when
- The scan runs but finds nothing. That is filtering, not a send failure.
- The error is on receive. Check the capture path instead.

## Steps
1. Cap the send rate explicitly: `nmap --max-rate 100 -sS 192.0.2.0/24`. Verify: the sendto error stops appearing.
2. Add a small delay between probes: `nmap --scan-delay 10ms -sS 192.0.2.0/24`. Verify: the scan progresses steadily instead of bursting and dying.
3. Drop to a gentler timing template as an alternative: `nmap -T2 -sS 192.0.2.0/24`. Verify: the run completes without send errors.
4. On Windows, confirm Npcap is installed and current; the bundled WinPcap-era drivers buffer poorly. Verify: the Npcap version matches your nmap build.
5. For large scopes, split the range and run the halves sequentially rather than one giant fast scan. Verify: each half completes cleanly at the throttled rate.

Compatibility: nmap 7.x. --max-rate and --scan-delay are stable across recent versions.

## Variant phrasings
### nmap no buffer space available
Same fix path, common phrasing.
### nmap sendto failed send_ip_packet
The function-name search.
### nmap scan too fast buffer error
Symptom-level search.

## Why it happens
nmap's parallel prober can generate packets faster than a virtual NIC, a USB adapter, or an old driver can queue them. The kernel returns ENOBUFS, nmap reports it via send_ip_packet, and the scan aborts. Aggressive timing (-T4/-T5) and very high --min-rate values trigger it on modest hardware.

## Edge cases / pitfalls
- The right rate depends on the path. Start at 100 pps and raise it until the error returns, then back off.
- --scan-delay applies per probe and compounds with parallelism. Small values are enough.
- Do not "fix" this by raising socket buffers blindly. Throttling is the supported fix.
- A throttled scan of a large scope takes real time. Plan the engagement schedule around it and tell the client.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_4na2tQKWGa-ZdRUy2o5ioA