Re: Socket troubles: Too many open files

[David Fifield <david () bamsoftware com>]

On Fri, Sep 14, 2012 at 08:36:16AM -0700, David Fifield wrote:
> On Thu, Sep 13, 2012 at 04:43:28PM -0500, Christopher Clements wrote:
> > nmap -A -sSUCV --script '(discovery or default or safe)' T:1-65535,U:(top
> > 75 UDP ports)  --reason --open -oA nmap-output <targets>
> >
> > I'm afraid I didn't look at the scan phase it was on (had kicked off the
> > scan and went home for the night).
>
> I'm guessing this has the same cause as the error messages reported by
> starlight,
>
> http://seclists.org/nmap-dev/2012/q3/889
> http://seclists.org/nmap-dev/2012/q3/att-889/nmap_crash4.txt
>
> The log has the same "Too many open files" message appear during the
> script scanning phase.

I've committed a partial fix for this in r29840. The culprit was
rpc.Comm.Connect, called from rpc-grind, which would try connecting from
around 400 reserved local ports for each RPC connection. The rpc code
used a pattern that would leak all but one of the many sockets created.
When all the connections were guaranteed to fail, as in Christopher's and
starlight's cases where the target always returned SYN/ACK, it meant
leaking 400 descriptors for each remote port. It didn't take long to run
out of sockets at that rate.

The pattern that leaks sockets is this:

local s = nmap.new_socket()
s:connect(host, port) --> TIMEOUT/ERROR
s:connect(host, port) --> TIMEOUT/ERROR
s:connect(host, port) --> TIMEOUT/ERROR
s:connect(host, port) --> TIMEOUT/ERROR
s:connect(host, port) --> TIMEOUT/ERROR
s:close()

The descriptors created in the first four calls would be lost, and only
the last would be reclaimed by the close. I think this is a bug in Nsock
or in the NSE binding to Nsock.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/