Re: NPing running out of sockets

["Luis MartinGarcia." <luis.mgarc () gmail com>]

On 10/15/2010 10:33 PM, David Fifield wrote:
> > +#ifndef MACOSX
> > +    #define MAX_IODS 1000  /**< Max number of IODs open at the same time */
> > +#else
> > +    #define MAX_IODS 250
> > +#endif
> >     
> Why does this work, Luis?
>
> David Fifield
>
>   

That's a good question. The thing is that for unprivileged modes
(TCP-connect and UDP-unpriv), Nping needs to use one socket per probe.
It probably doesn't need that many sockets for the UDP case, as you
pointed out before (that's why I said the patch is only temporary), but
it does need them for the TCP connection attempts. What is also true is
that Nping cannot just allocate space for unlimited socket/IOD
structures or have unlimited descriptors opened. I tried to solved this
problem by having an array of nsock descriptors of length "MAX_IODS"
where the return value of nsi_new() could be stored. What happens is
that when Nping has opened MAX_IODS descriptors, Nping just takes the
oldest IOD, closes the descriptor, and uses that position of the array
to hold a new IOD.

For example, in ProbeMode.cc::probe_tcpconnect_event_handler() you can
see the following:

        if( packetno>MAX_IODS ){
            nsi_delete(fds[packetno%MAX_IODS], NSOCK_PENDING_SILENT);
        }
        /* Create new IOD for connects */
        if ((fds[packetno%MAX_IODS] = nsi_new(nsp, NULL)) == NULL)
            outFatal(QT_3, "tcpconnect_event_handler(): Failed to create
new nsock_iod.\n");


So why does the #define MAX_IODS 250 work? Because on MACOSX,
unprivileged user processes may only have 256 open files by default,
while on Linux that number is 1024. So when 250 descriptors have been
opened, the oldest one is closed and the process never exceeds the
limit. I chose MAX_IODS values smaller than the limit to be on the safe
side because processes already start with at least 3 opened descriptors,
the echo mode may request additional iods, a "read payload from a file"
feature may be implemented at some point, etc.

Does this sound reasonable? I think it's OK at least for TCP-connect but
it may not be the best choice for UDP. Do you think we can/should start
using the new unconnected UDP sockets functionality in nsock?

Regards,

Luis MartinGarcia.



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