nmap wrongly reports host is blocking ping probes

[Noah Slater]

Binary package hint: nmap

I have a host which responds to ICMP echo-request packets but nmap thinks it is blocking ping probes.

Here is a working example of how nmap disagrees with the ping utility:

nslater@hinata: ~ $ nmap 80.68.88.8

Starting Nmap 4.20 ( http://insecure.org ) at 2007-03-09 23:48 GMT
Note: Host seems down. If it is really up, but blocking our ping probes, try -P0
Nmap finished: 1 IP address (0 hosts up) scanned in 4.012 seconds
nslater@hinata: ~ $ ping 80.68.88.8
PING 80.68.88.8 (80.68.88.8) 56(84) bytes of data.
64 bytes from 80.68.88.8: icmp_seq=1 ttl=48 time=38.5 ms
64 bytes from 80.68.88.8: icmp_seq=2 ttl=48 time=56.2 ms

--- 80.68.88.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 38.545/47.398/56.252/8.856 ms

[Christof Krüger (christofkr)]

Did you start nmap as unpriviledged user? Nmap does not use ICMP echo requests when run as unpriviledged user, instead it sends a SYN packet to port 80 of the target.

If you want to be sure to use icmp ping types, use the -PE, -PP and -PM options of nmap and be sure to have the right priviledges.

[James Troup (elmo)]

I'm having the same problem here. Worse, it doesn't even work if you pass it -P0.

% sudo nmap -P0 -vvvv 10.0.0.71

Starting Nmap 4.20 ( http://insecure.org ) at 2007-03-14 19:34 GMT
Initiating ARP Ping Scan at 19:34
Scanning 10.0.0.71 [1 port]
Completed ARP Ping Scan at 19:34, 0.22s elapsed (1 total hosts)
Nmap finished: 1 IP address (0 hosts up) scanned in 0.334 seconds
               Raw packets sent: 2 (84B) | Rcvd: 0 (0B)
%

[James Troup (elmo)]

nmap entirely non-functional, regression from edgy

[Noah Slater (nslater)]

Christof Krüger, thank you - your explanation solved my problem. User error.

James Troup , your problems should be opened as a new bug.

[Tollef Fog Heen (tfheen)]

Bringing milestone forward

[Steve Kowalik (stevenk)]

Neither Tollef or myself are able to reproduce this bug. I'm setting this bug to Needs Info.

[James Troup (elmo)]

Steve Kowalik <email address hidden> writes:

> Neither Tollef or myself are able to reproduce this bug. I'm setting
> this bug to Needs Info.

I can no longer reproduce this either - unfortunately I'm not sure
what network and what computer/device I was able to reproduce this on.
But it was definitely reproducable at the time for me and at least one
other person. Anyway, close the bug if you want, I can reopen it or
another one if it happens to me again.

[All that aside, setting a bug to needs info without giving the
 submitter some kind of clue as to what information you need or how he
 should get it, isn't terribly optimal ... ]

--
James

[Noah Slater (nslater)]

Well, um, I am the submitter and I can testify that the bug is not a bug AFAIK.

Please, close at will.