Re: Options to replace select in Nsock

[doug () hcsw org]

On Sat, Jun 20, 2009 at 08:07:20PM -0400 or thereabouts, Michael Pattrick wrote:
> As a side note, the default limit of fd_set in windows is 64 according
> to [0], Surprising that someone noticed an overflow on Linux before
> Windows.

As Brandon says in a later email it possibly hits some limitation earlier
than that on windows.

Also, on unix don't forget that the maximum descriptor is also limited
by the RLIMIT_NOFILE resource limit. On my linux laptop this defaults
to 1024 so nmap will need to do a setrlimit(2) to use descriptors higher
than that anyways. On OpenBSD you will also have to change the system-wide
resource limit:

# sysctl kern.maxfiles=10000

> On Sat, Jun 20, 2009 at 7:28 PM, David Fifield<david () bamsoftware com> wrote:
> > > In the meantime, couldn't Nsock be quickly adapted to use multiple
> > > calls to select with different FD_SET arrays when tracking >
> > > FD_SETSIZE items?
> >
> > I don't think you can use select that way. Each fd_set is indexed
> > starting at zero.
>
> I was referring to something like this:

David is right. You can only use select() if you're interested in
descriptors 0 through 1023 because select doesn't accept a descriptor
offset. Some libcs may allow you to extend the size of an fd_set
but this is not portable enough to be useful for nmap.

With respect to my previous email about recommending a stateful API:
I was ignoring the difficulty of converting a stateless event loop to
a stateful one. This in fact is quite difficult and will probably take
a re-write of the event loop.

A poll implementation with a select fallback is probably fine.

Is this really a common issue? The ways I use nmap usually only opens
a few hundred descriptors at most in which case a stateful API provides
little benefit. But of course I'm not doing things like NSE scanning /16s
and whatnot like Brandon is. :)

Doug

Attachment: _bin
Description:

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