Automake does. Otherwise, when you run an uninstall, it will delete
/usr/bin/nmap, not the nmap you might be staging elsewhere. This has no effect
if DESTDIR is undefined.
existing LUA library. A bashism caused one test to fail on system
which don't use bash as /bin/sh, and another bug fixed --with-liblua
configure option for specifying your own liblua. [Daniel
Roethlisberger]
Ensuring the safety of assert() calls by keeping NDEBUG undefined throughout
Nmap, Nbase and Nsock.
I've tested this on Linux and Windows XP without problems. On Windows I've
removed the definitions of _DEBUG and NDEBUG from the *.vcproj files.
Nmap 3.00 (July 31, 2002). Dates are in MM/DD/YY format. If someone
wants to track down dates for the last 22% of the file (pre-3.00), you
are welcome to do so and send a patch. Searching Google for the
version number and site:seclists.org seems to work well.
o Also started the process of preparing changelog for next release.
guide. They don't honor scan delay and may violate congestion control.
Both this things should be fixed. I was going to do it by having
get_next_target_probe just return the same probe multiple times, and
then either extend struct probespec to include a source address or have
sendIPScanProbe keep track of the decoy index and fill in source
addresses. But I was stopped by timing pings. Those should certainly be
decoyed, but in the code they are just sent as they are needed, and
don't have a dispatching function to modify. What would be good is a
global queue of probes waiting to be sent you could just insert all your
spoofed probes into, and then let the rest of the code take care of
scheduling them.
This change keeps a list of probes awaiting retransmit so that
doAnyOutstandingRetransmits doesn't have to search for them. At high
scan rates this function could take 100 ms or more. Now I have measured
it to take 2 ms or less.
The variable num_probes_waiting_retransmit has been renamed
num_probes_timed_out to better explain its purpose. This list of probes
that can be retransmitted immediately is called
probes_waiting_retransmits, but not all timed-out probes can be
retransmitted immediately. I've done my best to explain the distinction
in comments.
I thought long and hard about how to address this issue, and this is
what I decided on. But of course, every little optimization brings some
complexity and the chance of making a mistake. I'd appreciate someone
taking a look at this change.
-arch i386" when building a universal binary on Mac OS X, and you can't
generate dependencies while using those flags. Include directories were
previously moved to CPPFLAGS so the right dependencies are still found.
script. This is to enable us to use just CPPFLAGS where we don't want CXXFLAGS
also. An example of this is when we are generating dependencies with -MM. The
Apple GCC won't let us use this flag when we also give "-arch ppc -arch i386"
in CXXFLAGS, as we would when generating a universal binary.
metapackage (.mpkg) installer. The installer lets you pick if you want to
install Nmap or Zenmap or both. It puts Nmap in /usr/local and the previously
developed Zenmap.app in /Applications.
minutes. Part of what printStatusMessage does is display the total
elapsed time. The code looked like this:
log_write(LOG_STDOUT,
"Stats: %d:%02d:%02d elapsed; %d hosts completed (%d up), %d undergoing %s\n",
time/60/24, time/60 % 24, time % 60, o.numhosts_scanned - o.numhosts_scanning,
o.numhosts_up, o.numhosts_scanning, scantype2str(o.current_scantype));
where time is the number of seconds since the program started. However,
this code acts as though each hour has only 24 minutes. That is, after
0:23:59 it would become 1:00:00. This commit changes the 24s to 60s to
make it work right.
was always falling back to the system ARP cache. Of course this
raises the question of whether NmapArpCache is needed in the first
place. [Daniel Roethlisberger]
foudn that five files can be open on Mac OS X: stdin, stdout, stderr, /dev/tty,
and /private/var/run/utmpx. This could cause a non-root scan at a high scan
rateto fail with the message "Too many open files". I was able to cause this
with "nmap --min-rate 5000 localhost -p-".
That command still fails with the same error message, but for an entirely
different reason. After a while, one of the connect calls fails with an errno of
22 = EINVAL, Invalid argument. Whatever this means, the socket doesn't get
closed, Nmap just reports a "Strange error from connect". The socket is still
open but Nmap doesn't include it in its count of open sockets, so it's off by
one (or more, conceivably). This allows it to try to open one too many sockets
and bomb with an error message.
Note that running as non-root is important both because it uses a connect scan
and because non-root users have a lower limit on open files.
I've tried just closing the socket when EINVAL is returned, and that fixes the
problem. But that's likely to differ on different systems. Plus I don't know why
EINVAL is returned; maybe it's an OS bug. This only affects localhost scans and
only at high scan rates, so I'm leaving it alone.
