So I had a need to scan some hosts with nmap — in particular because ARD was too slow and tended to crash a lot scanning large networks, but also because I wanted to automate the process.
nmap seemed like it would would fit the bill pretty easily. A basic ping scan as tested from a FreeBSD host pretty quickly scanned 256 hosts and showed me the mac addr and matched it to a set of know mac addr prefixes, so the Apple gear could be singled out w/o even doing host detection.
Of course, the server hosts I need to use to run these scans aren’t FreeBSD they are all Mac OS 10.6.X, so I grabbed a package of a newish nmap and tried a couple of tests. I’ve used nmap occasionally from my OSX laptop, so I didn’t anticipate any issues — but, of course, I was wrong.
The first test scanning a couple of IPs went fine, except it didn’t display the mac addr’s manufacturer. Quickly retrying with host OS detection on two ports which should be open, got me all sorts of this sort of junk:
sh-3.2# nmap -v -O -Pn 10.20.2.1/24 -p22 Starting Nmap 5.51 ( http://nmap.org ) at 2011-08-19 16:14 EDT Initiating Parallel DNS resolution of 256 hosts. at 16:14 Completed Parallel DNS resolution of 256 hosts. at 16:14, 0.32s elapsed Initiating SYN Stealth Scan at 16:14 Scanning 256 hosts [1 port/host] sendto in send_ip_packet_sd: sendto(4, packet, 44, 0, 10.20.2.20, 16) => No route to host Offending packet: TCP 10.20.1.84:50502 > 10.20.2.20:22 S ttl=53 id=39041 iplen=11264 seq=2656158754 win=2048 Sleeping 15 seconds then retrying sendto in send_ip_packet_sd: sendto(4, packet, 44, 0, 10.20.2.20, 16) => Host is down Offending packet: TCP 10.20.1.84:50502 > 10.20.2.20:22 S ttl=53 id=39041 iplen=11264 seq=2656158754 win=2048 Sleeping 60 seconds then retrying
Well, that's no good. Seemed the more I tried nmap the more of these timeouts I got. I deployed google and friends and found several similar posts both recent and old but with no obvious resolution. I tried a few different versions of the nmap package and a few different OSX test machines. No luck. I started looking at the output a little more closely and also noticed that if I went back to my original machine and did a scan, it finished okay without these errors (though a lot slower than it's FreeBSD companion), but if I ran the same nmap again -- sleeping....
Looking at various things I tired to check for tcp/inet/icmp settings in the kernel, but nothing looked promising there. Eventually I started looking at arp and the routing table. It looks like on OSX one entry for each host tested appears in the routing table ( netstat -rn -f inet ), and once these are in there future attempts will try to use that (bogus but unexpired) route and throw an error when it can't get to the non-existent host. Eventually these entries expire and all is well again.