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:
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
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
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.
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
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.