Re: OSX - 'no route to host'

[Brandon Applegate <brandon () burn net>]

On Sat, 24 Sep 2011, David Fifield wrote:

> What's your output for "nmap --iflist"?
>
> I have seen OS X creating and destroying routes ephemerally sometimes.
> What happens if you ping the IP address immediately before trying to
> scan it? Does "nmap --iflist" differ immediately after a ping?
>
> David Fifield

First - thanks for the reply.

FYI - scanning an individual host seems to work okay.  It's the ping scan 
(sP) that gets stuck in the middle.

Here's my --iflist - sanitzied.

bash-3.2# nmap --iflist

Starting Nmap 5.51 ( http://nmap.org ) at 2011-09-24 14:12 EDT
************************INTERFACES************************
DEV (SHORT) IP/MASK          TYPE     UP MTU   MAC
lo0 (lo0)   127.0.0.1/8      loopback up 16384
en0 (en0)   192.168.x.x/24   ethernet up 1500  01:02:03:04:05:06

**************************ROUTES**************************
DST/MASK          DEV GATEWAY
x.x.x.x/32        en0 192.168.x.x
x.x.x.x/32        en0 192.168.x.x
x.x.x.x/32        en0 192.168.x.x
127.0.0.1/32      lo0 127.0.0.1
192.168.x.x/32    lo0 127.0.0.1
x.x.x.x/32        en0 192.168.x.x
127.0.0.0/8       lo0 127.0.0.1
0.0.0.0/0         en0 192.168.x.x

The x.x.x.x/32s are all the ephemeral cached host routes I think you are 
talking about.  The ones in this output are for things my machine is 
currently talking to.  I could be wrong - but isn't this a BSD-ish thing ? 
I come from a Linux background - so still getting used to the network nuts 
and bolts of OSX.  In linux to see this I would have to do something like 
'ip route show table cache'

Something I notice - is that nmap --iflist does NOT have a route for my 
connected interface.  In my case, that would be 192.168.x.x/24.

--iflist does NOT seem to change if I manually try to ping a host 
beforehand.

Again - excuse my OSX ignorance - but when I ping a host that doesn't 
exist - I get a /32 route entry with a destination of link#x (this is in 
'netstat -rnv').  A live host yields it's mac address in the 'gateway' 
column (successful arp).

So it seems that the incomplete ARP signalling isn't making it to nmap or 
getting used incorrectly ?  Probably not articulating that very well :(

As a test - nmap -sP $some_remote_net works great.  So scanning an offnet 
/24 completes fast with no timeouts or errors.  It seems like it's just an 
sP of a local connected network that gets bogged down in the middle due to 
incomplete ARP.

--
Brandon Applegate - CCIE 10273
PGP Key fingerprint:
7407 DC86 AA7B A57F 62D1 A715 3C63 66A1 181E 6996
"SH1-0151.  This is the serial number, of our orbital gun."



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