Re: NPing running out of sockets

[David Fifield <david () bamsoftware com>]

On Wed, Oct 20, 2010 at 01:19:26AM +0200, Luis MartinGarcia. wrote:
> On 10/16/2010 07:43 PM, David Fifield wrote:
> > Yeah, this looks good. It's better if you can ask the system for the
> > limit instead of basing it on a heuristic like MACOSX. The function
> > max_sd in tcpip.cc shows how to get the open descriptor limit. In
> > ConnectScanInfo::ConnectScanInfo in scan_engine.cc, I found that you
> > have to be at least 5 fewer than the limit on OS X.
> >
> > If this works for UDP as well, it's fine. Using an unconnected socket
> > might be easier because you only need one of them, but you don't have to
> > do that if the current system works well.
>
> I've been working on it and this is what I've come up with. I attach two
> patches. The first one is for nmap and moves max_sd() to libnetutil. It
> also creates two new functions, get_max_open_descriptors() which returns
> the current limit and set_max_open_descriptors(int desired_max) which
> tries to increase that limit.
>
> The second one is for nping: instead of using a hardcoded value, the
> local system is queried for the current limit on opened descriptors. If
> the current limit is not enough, nping tries to increase it. Also, if
> the get_max_open_descriptors() call fails, then the harcoded values are
> used (1024 for linux, 256 for Mac, etc).

It looks good. The logic with calloc and get_max_open_descriptors is
complicated and should be factored out, if possible, into a shared
function. An alternative is that you can just set an arbitrary maximum
like 1024, and then use a static buffer in each place. If the operating
system offers 65,000 descriptors, maybe we don't want to allocate that
many anyway.

Please commit it, either before or after de-duplicating the allocation
function.

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