on the following versions (the last one is from SVN):
55554/tcp open metasploit Metasploit Framework msfd 3.0-beta-dev
55554/tcp open metasploit Metasploit Framework msfd 3.0
55554/tcp open metasploit Metasploit Framework msfd 3.1-release
55554/tcp open metasploit Metasploit Framework msfd 3.2-release
ports instead of just TCP ports. This made it very slow in the
common case where there are many UDP ports in the open|filtered
state. Thanks to Jason DePriest for reporting the problem and Jah
for tracking it down and fixing it.
o A bug was fixed that could cause Zenmap to crash when loading a
results file that had multibyte characters in it. The error looked
like
Gtk-ERROR **: file gtktextsegment.c: line 196 (_gtk_char_segment_new): assertion failed: (gtk_text_byte_begins_utf8_char (text))
The necessary libraries (lib and dll) and headers required for compilation and
linking are in mswin32/OpenSSL. A detailed upgrade guide is available in
mswin32/OpenSSL/upgrade-guide.txt.
Thanks to Thomas Buchanan for doing the initial work and writing up the initial
build guide.
My openssl-testing branch has been posted on nmap-dev for 12 days and has been
tested by (at least) Thomas, Jah and I, with no reports of failure.
http://seclists.org/nmap-dev/2008/q2/0249.html
better by AC_PROG_CXX and caused a failure when configured with ccache:
CXX="ccache /usr/bin/g++-4.0" ./configure
checking build system type... i386-apple-darwin9.2.2
checking host system type... i386-apple-darwin9.2.2
checking for gcc... ccache /usr/bin/gcc-4.0
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether ccache /usr/bin/gcc-4.0 accepts -g... yes
checking for ccache /usr/bin/gcc-4.0 option to accept ISO C89... none needed
checking for inline... inline
checking for gcc... (cached) ccache /usr/bin/gcc-4.0
checking whether we are using the GNU C compiler... (cached) yes
checking whether ccache /usr/bin/gcc-4.0 accepts -g... (cached) yes
checking for ccache /usr/bin/gcc-4.0 option to accept ISO C89...
(cached) none needed
checking whether we are using the GNU C++ compiler... yes
checking whether ccache /usr/bin/g++-4.0 accepts -g... yes
checking for ccache /usr/bin/g++-4.0... MISSING
configure: error: Could not locate a C++ compiler. If it exists, add it
to your PATH or give configure the CXX=path_to_compiler argument.
Otherwise, install a C++ compiler such as g++ or install a binary
package of Nmap (see http://nmap.org/download.html ))
On Windows, this ID has to be a numeric index. On Linux and some
other OS's, this ID can instead be an interface name. Some examples
of this syntax:
fe80::20f:b0ff:fec6:15af%2
fe80::20f:b0ff:fec6:15af%eth0
This was a lot simpler than the method I previously implemented and posted
to nmap-dev. Now I just extract the zone ID from the already available
getaddrinfo() data rather than parsing it out myself.
might negitivly effect how efficiently nmap stores cache values in a hash
table. Now ntohl is called to correctly reorder the values on little endian
platforms before the hash calculation is preformed.
within a larger scan. The information is added to the XML host
element like so: [host starttime="1198292349" endtime="1198292370"]
(but of couse with angle brackets rather than square ones). It is
also printed in normal output if -d or "-v -v" are
specified. [Brandon, Kris, Fyodor]
x86. This was due to a workaround for an Ancient Solaris 2.1 bug
which activated when the OS string matched "solaris2.1*". The
problem has now been resolved until Solaris 20 comes out and hits
our "solaris2.2*" bug workarounds. Thanks to Nathan Bills for the
problem report. Fixed by Fyodor.
