Nmap Development mailing list archives
Re: [NSE] rpc.lua fix for binding to reserved ports (tcp)
From: David Fifield <david () bamsoftware com>
Date: Thu, 20 Sep 2012 17:59:25 -0700
On Thu, Sep 20, 2012 at 09:39:41AM -0500, Daniel Miller wrote:
rpc-grind and possibly other scripts will take a long time timing out with every source port between 600 and 1024, since that portion of rpc.lua doesn't check the type of failure (timeout vs. port in use, specifically).
I didn't realize that rpc.lua was doing this, testing up to 400 local ports for *every* call to Comm.Connect. I don't think it's a good idea. It turns out to be an indirect cause of running out of sockets in rpc-grind as described in http://seclists.org/nmap-dev/2012/q3/864 http://seclists.org/nmap-dev/2012/q3/872 Old pos_scan didn't do this, right? Even if there is a good reason for it (maybe some services require the other side to be bound to a privileged port), what is the chance that after we've failed to bind to the first 200 local ports, that any of the remaining 200 will work? Why don't we just try, say, five ports at random, and give up after that? 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] rpc.lua fix for binding to reserved ports (tcp) Daniel Miller (Sep 20)
- Re: [NSE] rpc.lua fix for binding to reserved ports (tcp) David Fifield (Sep 20)
- Re: [NSE] rpc.lua fix for binding to reserved ports (tcp) David Fifield (Sep 20)
- Re: [NSE] rpc.lua fix for binding to reserved ports (tcp) Daniel Miller (Sep 20)
- Re: [NSE] rpc.lua fix for binding to reserved ports (tcp) David Fifield (Sep 20)
- Re: [NSE] rpc.lua fix for binding to reserved ports (tcp) Daniel Miller (Sep 20)