Bug 172016 - nmap bogus ping scan
nmap bogus ping scan
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: nmap (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-29 02:57 EDT by udomsak chundang
Modified: 2013-04-09 18:16 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-05-10 09:00:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description udomsak chundang 2005-10-29 02:57:16 EDT
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 04:16:15 EST
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 05:31:24 EST
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 08:58:34 EST
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 09:00:30 EDT
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 18:16:05 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.