12

I try to ping scan my local network using nmap, but it doesn't seem to find machines that are for sure alive. It responses to ping but on to ping scan.

Results for ping:

$ ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2): 56 data bytes 64 bytes from 192.168.0.2: icmp_seq=0 ttl=64 time=1.585 ms

And output of tcpdump:

$ tcpdump -i fxp0 -n host 192.168.0.2
12:43:07.624911 IP 192.168.0.222 > 192.168.0.2: ICMP echo request, id 61023, seq 0, length 64
12:43:07.625029 IP 192.168.0.2 > 192.168.0.222: ICMP echo reply, id 61023, seq 0, length 64

But when I try to use nmap it doesn't see it in spite of receiving response.

$ nmap -sn 192.168.0.2

Starting Nmap 5.61TEST5 ( http://nmap.org ) at 2012-05-13 12:44 CEST
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.02 seconds

Tcpdump output:

$ tcpdump -i fxp0 -n host 192.168.0.2
12:45:30.742933 IP 192.168.0.222 > 192.168.0.2: ICMP echo request, id 2715, seq 0, length 8
12:45:30.742974 IP 192.168.0.222.36388 > 192.168.0.2.443: S 3607279099:3607279099(0) win 1024 <mss 1460>
12:45:30.743001 IP 192.168.0.222.36388 > 192.168.0.2.80: . ack 3607279099 win 1024
12:45:30.743025 IP 192.168.0.222 > 192.168.0.2: ICMP time stamp query id 45449 seq 0, length 20
12:45:30.743061 IP 192.168.0.2 > 192.168.0.222: ICMP echo reply, id 2715, seq 0, length 8
12:45:30.743097 IP 192.168.0.2.443 > 192.168.0.222.36388: S 2602942480:2602942480(0) ack 3607279100 win 5840 <mss 1460>
12:45:30.743130 IP 192.168.0.222.36388 > 192.168.0.2.443: R 3607279100:3607279100(0) win 0
12:45:30.743134 IP 192.168.0.2.80 > 192.168.0.222.36388: R 3607279099:3607279099(0) win 0
12:45:30.743148 IP 192.168.0.2 > 192.168.0.222: ICMP time stamp reply id 45449 seq 0: org 00:00:00.000, recv 11:04:04.243, xmit 11:04:04.243, length 20
12:45:32.745245 IP 192.168.0.222 > 192.168.0.2: ICMP time stamp query id 48722 seq 0, length 20
12:45:32.745281 IP 192.168.0.222.36389 > 192.168.0.2.80: . ack 3607344634 win 1024
12:45:32.745307 IP 192.168.0.222.36389 > 192.168.0.2.443: S 3607344634:3607344634(0) win 1024 <mss 1460>
12:45:32.745340 IP 192.168.0.2 > 192.168.0.222: ICMP time stamp reply id 48722 seq 0: org 00:00:00.000, recv 11:04:06.245, xmit 11:04:06.245, length 20
12:45:32.745380 IP 192.168.0.2.80 > 192.168.0.222.36389: R 3607344634:3607344634(0) win 0
12:45:32.745401 IP 192.168.0.2.443 > 192.168.0.222.36389: S 2629695507:2629695507(0) ack 3607344635 win 5840 <mss 1460>
12:45:32.745421 IP 192.168.0.222.36389 > 192.168.0.2.443: R 3607344635:3607344635(0) win 0
12:45:32.745431 IP 192.168.0.222 > 192.168.0.2: ICMP echo request, id 38289, seq 0, length 8
12:45:32.745517 IP 192.168.0.2 > 192.168.0.222: ICMP echo reply, id 38289, seq 0, length 8

Why nmap says host seems down when it responds to requests?

Edit

Nmap version:

$ nmap --version

Nmap version 5.61TEST5 ( http://nmap.org )
Platform: i386-portbld-freebsd7.4
Compiled with: liblua-5.1.5 openssl-0.9.8q libpcre-8.30 libpcap-0.9.8 nmap-libdnet-1.12 ipv6
Compiled without:

To be sure, first filter rule in firewall is:

pass quick on fxp0
aadam
  • 221
  • 1
  • 2
  • 5
  • This is not normal behavior. If you check everything Tom H mentions in his answer below and still have the problem, send the output of `nmap --version`, `nmap --iflist`, and what you posted here to nmap-dev@insecure.org, the Nmap developers' mailing list. – bonsaiviking May 13 '12 at 13:04

5 Answers5

5

Just tried this with my OpenBSD 5.1. Yes, you have FreeBSD 7.4, but we are talking quite a similar beast.

As a regular user, nmap -sn my.host returns Host seems down for me, too, even though my test machine surely responds to ping as a regular user.

As root, however, nmap -sn my.host returns Host is up as it should.

Looking at your prompt, you are likely also trying to nmap as a non-root user. Try if nmap works as root.

EDIT: Just fired up my FreeBSD 9.0, there nmap ping scan works fine as non-root.

Janne Pikkarainen
  • 31,454
  • 4
  • 56
  • 78
1

My first observation would be that tcpdump -i fxp0 is dumping the packets that arrive on the fxp0, however nmap is running as a userspace process, hence a number of things could block nmap from seeing the response.

  1. such as an netfilter rule (user iptables -t filter -n -L)
  2. selinux (not seen this particular thing, but selinux is always a good bet when stupid sh*t happens
  3. also check the iptables nat tables to be sure iptables -t nat -n -L
Tom
  • 10,886
  • 5
  • 39
  • 62
  • umm. is fxp0 bsd? no idea then... – Tom May 13 '12 at 11:45
  • 1
    if you are on linux try is under strace and see if it gives you more of a clue... `strace -t -e trace=network nmap -sn 192.168.0.2` – Tom May 13 '12 at 11:50
  • OS is FreeBSD. I have updated original question with nmap version and info about firewall rule. – aadam May 15 '12 at 09:36
1

I just had this same problem and solved it with partial help from here.

I setup a new, headless RaspberryPi with WiFi dongle and edited the SD Card to put my WiFi credentials in wpa_supplicant.conf.

The RPi booted and connected to WiFi just fine, but the nmap ping scan on my Ubuntu laptop did not find it until I did TWO things:

  1. used sudo
  2. added the option --disable-arp-ping
HBruijn
  • 72,524
  • 21
  • 127
  • 192
Rob K
  • 11
  • 1
0

I had this issue with nmap 7.92 on Windows 11, and installing npcap resolved the issue for me.

0

I came across this post when trying to figure out why I could ping a Windows host but when I used nmap -sP, it would show as host down. This behavior seems to replicate with Windows and Palo Alto so far and not with Linux and iDrac; the resolution in my case was to re-run the scan with sudo.