Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: Options to replace select in Nsock
From: doug () hcsw org
Date: Sun, 21 Jun 2009 01:19:28 +0000

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

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault