give the error: SCRIPT ENGINE: C:\Program
Files\Nmap\nselib/http.lua:77: attempt to call field 'parse' (a nil
value) [Jah]
Also added Win2K dependencies section to nmap-install (I should have
done a separate checkin for that)
the parsing of the standard nmap data files (e.g. nmap-services,
nmap-protocols, etc.) now uses those generic routines. NSE scripts
and libraries may find them useful for dealing with their own data
files, such as password lists. [Jah]
o Nmap sometimes sent packets with incorrect IP checksums,
particularly when sending the UDP probes in OS detection. This has
been fixed. Thanks to Gisle Vanem for reporting and investigating the
bug. [David]
o In the interest of forward compatibility, the xmloutputversion
attribute in Nmap XML output is no longer constrained to be a
certain string ("1.02"). The xmloutputversion should be taken as
merely advisory by authors of parsers.
liblua and libm. This is necessary for static builds of Nmap, such as RPM
builds. Before this the error that was caused looked like
SCRIPT ENGINE: error while initializing script rules:
error loading module 'bit' from file '/usr/libexec/nmap/nselib-bin/bit.so':
/usr/libexec/nmap/nselib-bin/bit.so: undefined symbol: lua_pushnumber
stack traceback:
[C]: ?
[C]: in function 'require'
/usr/share/nmap/nselib/packet.lua:12: in main chunk
[C]: in function 'require'
/usr/share/nmap/scripts/rpcinfo.nse:10: in main chunk
[C]: ?
[C]: in function 'Entry'
/usr/share/nmap/scripts/script.db:8: in main chunk
[C]: ?
[C]: ?
periods itself rather than relying on NSE's old behavior of replacing non-
printable characters with periods. Thanks to Rob Nicholls for reporting the
problem. [Kris]
with a data length of -1 (which means the data is a NULL-terminated string
and Nsock should take the length itself) and the Nsock trace level was at
least 2. [Kris]
This occurs because memcpy() is called with datalen as it's length argument and
then fails.
Another noticable change is that instead of saying a write request of -1 bytes
was registered, it now prints the correct length.
available rather than lines if neither the "bytes" nor "lines" options are
given. Thanks to Brandon for reporting a problem which he noticed in the
dns-test-open-recursion script. [Kris]
o Fixed host discovery probe matching when looking at the returned TCP data in
an ICMP error message. This could lead to incorrectly discarded responses
and the debugging error message: "Bogus trynum or sequence number in ICMP
error message" [Kris]
Fyodor was getting the error message "Got ICMP error with a TCP header that was
too short" while scanning, and looked at the code to see a comment I made about
requiring 12 bytes of TCP data in an ICMP error message instead of the minimum
RFC requirement of 8 bytes.
I made this comment and requirement because tcp_trynum_pingseq_decode() was
being called on the TCP data, and was using the ACK field (which is just past
the 8 byte range). However, upon further inspection, we came to the conclusion
that this code was broken because examining the ACK field should only be done
on a TCP response, not on our own probe (which is what we're looking at in the
ICMP data).
This assumes that -g is used (the only reason that the SEQ/ACK is checked since
the source port number is used otherwise), but the code is also broken without
it because the *_decode() function checks the destination port number rather
than the source port (which should be checked since it's our own probe we're
looking at).
So I've removed the 12-byte requirement and pingseq checking calls, and just
check that the received SEQ number matches the probe SEQ number.
Should we just work with the SEQ/ACK matching when using TCP and leave the
pingseq/trynum port number encoding to UDP? This means behavior won't change
with the use of -g, and it should be guaranteed to be there since we'll only
be looking at whole TCP headers rather than any smaller chunks. Plus, the SEQ
number is already getting encoded with the pingseq/trynum info, we're just not
decoding the ACK responses unless -g is used.
-Raw TCP (not SYN to an open port)
-ICMP information queries (echo request, timestamp request, netmask req)
-ARP
-Raw TCP (SYN to an open port)
-UDP, IP protocol, or other ICMP
-TCP connect
-Anything else
The order used to be
-ARP
-Raw TCP (not SYN to an open port)
-UDP, IP protocol, or ICMP
-Raw TCP (SYN to an open port)
-TCP connect
-Anything else
o Nsock now supports binding to a local address and setting IPv4 options
with nsi_set_localaddr() and nsi_set_ipoptions(), respectively. [Kris]
o Nmap's Nsock-utilizing subsystems (DNS, NSE, version detection) have been
updated to support the -S and --ip-options flags. [Kris]
o Added the undocumented (except here) --nogcc option which disables
global/group congestion control algorithms and so each member of a
scan group of machines is treated separately. This is just an
experimental option for now. [Fyodor]
and closed ports. [Vladimir]
o Fixed the "resolution errors not showing up" bug. Actually, from now
on, all errors will be displayed properly in the Zenmap window, since
stderr is also redirected there (until now, only stdout was
displayed). [Vladimir]
Visual C++ 2008 runtime components if they aren't already installed
on a system. These are some reasonably small DLLs that are
generally necessary for applications compiled with Visual C++ (with
dynamic linking). Many or most systems already have these installed
from other software packages. The lack of these components led to
the error message "The Application failed to intialize properly
(0xc0150002)." with Nmap 4.65. A related change is that Nmap on
Windows is now compiled with /MD rather than /MT so that it
consistently uses these runtime libraries. The patch was created by
Rob Nicholls.
