Nmap Development mailing list archives
Re: IPv6 host discovery Bug in 6.47 -- perhaps newer versions
From: Allen Landsidel <landsidel.allen () gmail com>
Date: Mon, 28 Sep 2015 13:58:26 -0400
I saw that too, and thought it was suspicious.There's no firewall in play here. There is one between this host and the destination, however tcpdump is being run on the same host as nmap, which has no "local" firewall running. The tcpdump does show the traffic when testing with ping6, traceroute6, telnet -6, etc so I'm sure the stack itself is working.
My gut feeling is either that it's not actually sending the packets, or there is some sysctl knob in play that's preventing them from hitting the wire. Nothing is showing up in any of the system logs.
On 9/28/2015 11:07, Daniel Miller wrote:
Allen, Please keep dev () nmap org <mailto:dev () nmap org> CC'd on these messages so other developers can chime in; I'm far from a FreeBSD expert. I've excerpted your output below: SENT (0.1061s) ICMP [192.168.129.2 > 45.33.32.156 Echo request (type=8/code=0) id=57140 seq=0] IP [ttl=37 id=32712 iplen=28 ] SENT (0.1062s) TCP 192.168.129.2:60109 <http://192.168.129.2:60109> > 45.33.32.156:443 <http://45.33.32.156:443> S ttl=43 id=38851 iplen=44 seq=936660269 win=1024 <mss 1460> SENT (0.1063s) TCP 192.168.129.2:60109 <http://192.168.129.2:60109> > 45.33.32.156:80 <http://45.33.32.156:80> A ttl=58 id=5574 iplen=40 seq=0 win=1024 SENT (0.1063s) ICMP [192.168.129.2 > 45.33.32.156 Timestamp request (type=13/code=0) id=6201 seq=0 orig=0 recv=0 trans=0] IP [ttl=41 id=2108 iplen=40 ] RCVD (0.1456s) ICMP [45.33.32.156 > 192.168.129.2 Timestamp reply (type=14/code=0) id=6201 seq=0 orig=0 recv=50340359 trans=50340359] IP [ttl=52 id=44266 iplen=40 ] This clearly shows that Nmap believes it has sent an ICMP Echo request, a TCP SYN to port 443, a TCP ACK to port 80, and an ICMP Timestamp request. The host is marked "up" because it sent a reply to the last probe (timestamp). Is there any reason your tcpdump sniffer would not receive the packets that Nmap thinks it's sending? A filtering firewall between the sniffer and the scanner, or a capture filter (BPF) that is only including TCP traffic, for instance? Dan On Mon, Sep 28, 2015 at 9:02 AM, Allen Landsidel <landsidel.allen () gmail com <mailto:landsidel.allen () gmail com>> wrote: Daniel, No problem, thanks for getting back to me so quick. The host is indeed FreeBSD 10, though it's in need of an update, so I'll take care of that as well. In answer to your questions. 1. No problem. I'll download and build the beta tarball and get back to you. If there's an svn/git repo you want me to build from I can try that as well. 2. Results are attached as 'nmap test.result'. 3. Yes, I'm testing as root. 4. The setup is virtualized via VMWare ESXi 5.5. Other more "standard" tools are working fine, such as ping6, and as I said if I explicitly tell nmap to use an echo test with -PE, it also detects the target as up and proceeds with the scan. On 9/28/2015 09:52, Daniel Miller wrote: Allen, Thanks for reporting this. We were aware of a problem sending raw packets on FreeBSD 10 and later, because of a change in network address byte order, but that results in no packets being sent at all. I'm not sure what could be causing the problem you're describing, but please answer a few more questions for us, and we will try to debug: 1. Is there any way at all that you can use 6.49BETA5 for this test? It is always much easier to debug the current release than to work with an older release, and you will get a more capable product as a whole. 2. What is the output of this command, and what does tcpdump show?: nmap -d --packet-trace -sn -n scanme.nmap.org <http://scanme.nmap.org> <http://scanme.nmap.org> 3. Are you running Nmap with root privileges every time? The default behavior when root privileges are not available is to try a TCP connection to ports 80 and 443, without ICMP probes. 4. Is there anything unusual about your network environment? For example, when my FreeBSD VM was running under Oracle VirtualBox with NAT, VirtualBox dropped the ICMP Timestamp Requests and intercepted the raw TCP packets, trying to perform a complete TCP handshake instead of passing along the raw SYN and ACK packets expected. Dan On Sat, Sep 26, 2015 at 6:17 PM, Allen Landsidel <landsidel.allen () gmail com <mailto:landsidel.allen () gmail com> <mailto:landsidel.allen () gmail com <mailto:landsidel.allen () gmail com>>> wrote: It appears that when scanning a host with ipv6, if you don't specify any discovery options, that only the port 80 and port 443 checks described in the man page are actually tried -- the ICMP echo request isn't. Scanning with "nmap -6 -PE host::addr" works fine and detects the host is up, but scanning with just "nmap -6 host::addr" does not. Tcpdump indicates only the 80 and 443 packets are being sent, while the man page indicates the ICMP echo request is also tried. Using FreeBSD, so I don't know if this is fixed in 6.48 or 6.49, as 6.47 is the latest version available in ports. _______________________________________________ Sent through the dev mailing list https://nmap.org/mailman/listinfo/dev Archived at http://seclists.org/nmap-dev/
_______________________________________________ Sent through the dev mailing list https://nmap.org/mailman/listinfo/dev Archived at http://seclists.org/nmap-dev/
Current thread:
- IPv6 host discovery Bug in 6.47 -- perhaps newer versions Allen Landsidel (Sep 27)
- Re: IPv6 host discovery Bug in 6.47 -- perhaps newer versions Daniel Miller (Sep 28)
- Message not available
- Re: IPv6 host discovery Bug in 6.47 -- perhaps newer versions Daniel Miller (Sep 28)
- Re: IPv6 host discovery Bug in 6.47 -- perhaps newer versions Allen Landsidel (Sep 28)
- Message not available
- Re: IPv6 host discovery Bug in 6.47 -- perhaps newer versions Daniel Miller (Sep 28)