Bug 172016

Summary:	nmap bogus ping scan
Product:	[Fedora] Fedora	Reporter:	udomsak chundang <udomsak>
Component:	nmap	Assignee:	Harald Hoyer <harald>
Status:	CLOSED WORKSFORME	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4	CC:	dpoon
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-05-10 13:00:30 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description udomsak chundang 2005-10-29 06:57:16 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050909 Fedora/1.0.6-1.2.fc4 Firefox/1.0.6

Description of problem:
When I use nmap with options -sP ( ping scan ) The result has bogus 
"Host appear up" in fact that host is disappear.. and when i use tcpdump for capture icmp package result below

16:19:25.033190 IP 192.1.40.4 > 192.2.31.218: icmp 8: echo request seq 17788
16:19:25.033342 IP 192.1.40.4 > 192.2.31.219: icmp 8: echo request seq 19068

and no icmp 'reply' back but they remain report as 'Host appear to be up'   

Version-Release number of selected component (if applicable):
nmap-3.81-3

How reproducible:
Sometimes

Steps to Reproduce:
In same networksubnet result are correct 
  

Additional info:

Comment 1 Harald Hoyer 2005-10-31 09:16:15 UTC

hmm, cannot reproduce:
# nmap -sP <host>
Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-10-31 10:15 CET
Host FC5.home (192.168.10.244) appears to be up.
MAC Address: 00:0C:29:0B:F4:E4 (VMware)
Nmap finished: 1 IP address (1 host up) scanned in 0.621 seconds

--> Shutdown <host>

#nmap -sP <host>

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-10-31 10:15 CET
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 2.039 seconds

[harald@jever redhat-config-network-HEAD]$ rpm -q nmap
nmap-3.81-3

Comment 2 udomsak chundang 2005-10-31 10:31:24 UTC

Harald

 Problem is when I use to scan Network across subnet the report are bogus, as I
say , but when scan in local or scan same subnet are correct

# nmap -P0 192.168.34.1-254

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-10-31 16:58 ICT
caught SIGINT signal, cleaning up

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-10-31 17:09 ICT
Host 192.168.34.250 appears to be up. << bogus
Host 192.168.34.251 appears to be up. << bogus
Host 192.168.34.252 appears to be up. << bogus 
Host 192.168.34.253 appears to be up. << bogus
Host .....
Host 192.168.34.254 appears to be up. << this is true [ see below ]

Tcpdump 
-------------------
01:33:02.829681 IP 192.168.31.4 > 192.168.34.250: icmp 8: echo request seq 27533
01:33:02.831036 IP 192.168.31.4 > 192.168.34.251: icmp 8: echo request seq 28813
01:33:02.831210 IP 192.168.31.4 > 192.168.34.252: icmp 8: echo request seq 30093
01:33:02.831364 IP 192.168.31.4 > 192.168.34.253: icmp 8: echo request seq 31373
01:33:02.831516 IP 192.168.31.4 > 192.168.34.254: icmp 8: echo request seq 32653
01:33:02.832484 IP 192.168.34.254 > 192.168.31.4: icmp 8: echo reply seq 32653
[correct ]

-----------------
In same Network
-----------------
 
01:33:16.239975 IP 192.168.33.4 > 192.168.33.3: icmp 8: echo request seq 55359
01:33:16.240025 IP 192.168.33.4 > 192.168.33.2: icmp 8: echo request seq 54079
01:33:16.240054 IP 192.168.33.4 > 192.168.33.1: icmp 8: echo request seq 52799
01:33:16.240136 IP 192.168.33.3 > 192.168.33.4: icmp 8: echo reply seq 55359
01:33:16.240186 IP 192.168.33.2 > 192.168.33.4: icmp 8: echo reply seq 54079
01:33:16.240284 IP 192.168.33.1 > 192.168.33.4: icmp 8: echo reply seq 52799
01:33:17.068036 IP 192.168.33.4 > 192.168.33.6: icmp 8: echo request seq 12315
01:33:17.068078 IP 192.168.33.4 > 192.168.33.5: icmp 8: echo request seq 11035
01:33:17.068199 IP 192.168.33.6 > 192.168.33.4: icmp 8: echo reply seq 12315
01:33:17.068315 IP 192.168.33.4 > 192.168.33.9: icmp 8: echo request seq 16155
01:33:17.068298 IP 192.168.33.5 > 192.168.33.4: icmp 8: echo reply seq 11035
01:33:17.068626 IP 192.168.33.9 > 192.168.33.4: icmp 8: echo reply seq 16155
------------------------------
result are correct

Comment 3 Harald Hoyer 2005-10-31 13:58:34 UTC

Across subnets:

$ nmap -sP 10.32.5.71

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-10-31 11:44 CET
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 3.006 seconds


dunno what's going wrong.

Comment 4 Karsten Hopp 2006-05-10 13:00:30 UTC

I'm closing this as I can't reproduce it either.
Please reopen this report if the problem still exists with the latest nmap package
(4.03) which will be available in Fedora Core 4 updates soon

Comment 5 Derek Poon 2013-04-09 22:16:05 UTC

http://serverfault.com/questions/451347/nmap-ping-scan-over-a-vpn-tunnel-return-all-hosts-alive

The explanation is that nmap's "Ping Scan" does more than just ICMP Echo.  It also  tries TCP SYN to port 443 and TCP ACK to port 80.  If a firewall sends RST packets in response to those TCP probes, then nmap will think that the host is up.