The attached patch (/nmap-exp/kris SVN r4367) fixes the UDP scan from
picking up it's own port while scanning localhost. It stops a message
from being printed when doing TCP on localhost, too. The SVN log explains:
------------------------------------------------------------------------
r4367 | kris | 2007-01-20 14:39:48 -0600 (Sat, 20 Jan 2007) | 1 line
This fixes (I hope) the UDP scan on localhost picking up it's own port.
It also fixes the TCP one so that it doesn't print a message (with -d)
about receiving a response with unexpected flags (like getting a SYN for
a SYN scan because it's our port). The problem was that the IP ID wasn't
ntohs()'d while checking for this, so we still saw our port on UDP. I
simply copied this to the TCP part to avoid the message. Everything
works fine for me, and hopefully it works for everyone else too.
------------------------------------------------------------------------
So if anyone can give this a test, that'd be awesome.
Thanks a lot,
Kris Katterjohn
Index: scan_engine.cc
===================================================================
--- scan_engine.cc (revision 4366)
+++ scan_engine.cc (revision 4367)
@@ -2957,6 +2957,13 @@
} else if (USI->scantype == ACK_SCAN) {
newstate = PORT_UNFILTERED;
} else newstate = PORT_CLOSED;
+ } else if (probe->dport() == probe->sport() &&
+ ip->ip_src.s_addr == ip->ip_dst.s_addr &&
+ probe->ipid() == ntohs(ip->ip_id)) {
+ /* Sometimes we get false results when scanning localhost with
+ -p- because we scan localhost with src port = dst port and
+ see our outgoing packet and think it is a response. */
+ continue;
} else {
if (o.debugging)
error("Received scan response with unexpected TCP flags: %d\n", tcp->th_flags);
@@ -3120,7 +3127,7 @@
see our outgoing packet and think it is a response. */
if (probe->dport() == probe->sport() &&
ip->ip_src.s_addr == ip->ip_dst.s_addr &&
- probe->ipid() == ip->ip_id)
+ probe->ipid() == ntohs(ip->ip_id))
continue; /* We saw the packet we ourselves sent */
newstate = PORT_OPEN;
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org
Received on Jan 20 2007