Nmap Development mailing list archives
Re: NSE Connection Problems on Windows?
From: David Fifield <david () bamsoftware com>
Date: Wed, 17 Oct 2012 17:52:53 -0700
On Wed, Oct 17, 2012 at 10:09:15AM +0100, Rob Nicholls wrote:
-----Original Message----- From: David Fifield [mailto:david () bamsoftware com] Sent: 11 October 2012 18:09 To: Rob Nicholls Cc: Nmap dev Subject: Re: NSE Connection Problems on Windows? On Thu, Oct 11, 2012 at 03:59:18PM +0100, Rob Nicholls wrote:I've recently experienced some weird behaviour running NSE scripts using a version of Nmap I've built myself from SVN on Windows. It seems to affect scripts that access the same port (e.g. ntp, snmp), where one or more of them seem to execute properly and then the remaining ones seem to hang (presumably forever). When it happens, Nmap will just say something like:...Maybe you can bisect this and find a revision where it broke?The issue appears to start with r29631: 29479 - works 29567 - works 29625 - works 29627 - works 29628 - works 29631 - bad 29638 - bad 29648 - bad 29787 - bad It's not immediately obvious to me why it starts with that revision, but maybe it's another UDP port bug in the rpc-grind code? I should probably mention that the host I'm scanning doesn't respond to any requests on that range of UDP ports (100-200), so service/version scanning shouldn't identify any services, but perhaps it sets some default service names? When I disable service/version detection the scan completes fine. I've also just tried replacing the portrule in rpc-grind.nse to always return false and then the scan runs okay too.
I can reproduce this with the command line nmap -sUCV -n -Pn --version-intensity 0 -p 100-200 -d --packet-trace -d2 --stats-every 10s <target> When the hang happens, it's one or a few UDP-using scripts, and they are all stuck in "connect". Nsock is never selecting the relevant socket descriptors readable or writable. I don't know if it's because the descriptors have somehow been removed from the fd_sets, if they are in the fd_sets but for some reason Windows doesn't consider them selectable, or for some other reason. The connection attempts never time out because the events have a timeout tv_sec of 0, which prevents this code in nsock_core.c from running: if (!nse->event_done && nse->timeout.tv_sec && !TIMEVAL_AFTER(nse->timeout, nsock_tod)) handle_connect_result(nsp, nse, NSE_STATUS_TIMEOUT); That is probably another bug. Somehow the large number of connectionless packets sent by rpc-grind have something to do with it, but I don't think it's the exact cause. It's not just the sheer number of port either; if you leave ports 137 and 161 out of the specification (-p 100-136,138-160,162-200), then the scan finishes. David Fifield _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- NSE Connection Problems on Windows? Rob Nicholls (Oct 11)
- Re: NSE Connection Problems on Windows? David Fifield (Oct 11)
- RE: NSE Connection Problems on Windows? Rob Nicholls (Oct 17)
- Re: NSE Connection Problems on Windows? David Fifield (Oct 17)
- RE: NSE Connection Problems on Windows? Rob Nicholls (Oct 17)
- Re: NSE Connection Problems on Windows? David Fifield (Oct 11)