Nmap Development mailing list archives

OS scanning causes send_ip_packet: sendto() EAGAIN errors (Linux raw socket issue?)


From: Brandon Enright <bmenrigh () ucsd edu>
Date: Fri, 6 Mar 2009 01:12:33 +0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey all, especially the raw socket experts,

I've been running into an issue where Nmap calls sendto() on a raw
socket and receives EAGAIN (Resource temporarily unavailable).  I can
get this to trigger any time I do a OS scan (-O) against a large group
of hosts.

For example, during a printer discovery scan with this command:

$ sudo nmap -O -sV -v -d -T5 -PN -p 23,80,443,515,631,8000,8080,9100 --min-hostgroup 256 -n -iL cse.txt -oA 
cse_printers.txt

I got a whole bunch of:

Initiating OS detection (try #1) against 256 hosts
sendto in send_ip_packet: sendto(9, packet, 178, 0, x.y.10.182, 16) => Resource temporarily unavailable
Offending packet: ICMP x.y.1.115 > x.y.10.182 echo request (type=8/code=0) ttl=50 id=19072 iplen=178 
Sleeping 15 seconds then retrying
sendto in send_ip_packet: sendto(9, packet, 328, 0, x.y.10.93, 16) => Resource temporarily unavailable
Offending packet: UDP x.y.1.115:44903 > x.y.10.93:38709 ttl=52 id=4162 iplen=328 
Sleeping 15 seconds then retrying
sendto in send_ip_packet: sendto(9, packet, 328, 0, x.y.10.207, 16) => Resource temporarily unavailable
Offending packet: UDP x.y.1.115:44903 > x.y.10.207:41664 ttl=52 id=4162 iplen=328 
Sleeping 15 seconds then retrying


A few weeks ago David and I looked into this and he pointed out that
the "error" is EAGAIN which just means try again.  David suggested
using --send-eth to bypass the raw socket and that, indeed, takes care
of the problem.

My best guess is that raw sockets have a relatively small send buffer
and Nmap is filling the buffer before the OS can service it.

I've tried finding documentation on raw socket buffers but have come up
empty handed.  I'm also not seeing a way to tweak them in /proc or via
sysctl.  I haven't looked into whether or not setsockopt(...,
SO_SNDBUF, ...) works but I think it's worth a try.

Can anyone shed more light on this issue?  Does anyone know how to
tweak/see/test raw sockets and reproduce this error in a controlled way?

Brandon

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkmweI0ACgkQqaGPzAsl94LCcgCeN7+0LB/jqEBFTGxPLTxsyq6y
JWEAn0F/MBemuvaZdPtssjkXg+op9NiY
=b8Mh
-----END PGP SIGNATURE-----

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org


Current thread: