single connection and then exit, just like in normal listen mode.
Use the --keep-open option to get the old default inetd-like
behavior. This was suggested by David Millis. [David]
o Nmap now works with "teamed" network interfaces on Windows. In order
to distinguish the interfaces, their textual descriptions are now
compared in addition to their MAC addresses. Without this, Nmap
would send on the wrong interface and not receive any replies. A
symptom of this problem was all scans failing except when
--unprivileged was used. Norris Carden reported this bug. [David]
o Made eth_get_pcap_devname compare interface descriptions as well as
MAC addresses when assigning interface names like eth0 on Windows.
Only comparing MAC addresses failed in the case of "teamed"
interfaces, when three interfaces (two physical, one virtual) could
have the same hardware address.
eth_get_pcap_devname as a wrapper.
In addition to the hardware address check, add a check of the textual interface
descriptions in order better to distinguish interfaces. It appears to me that
the pcap description (pdev->description) is the same as what is returned by a
call to PacketRequest with an OID of OID_GEN_FRIENDLY_NAME, so that's what I'm
comparing. That differs from OID_GEN_VENDOR_NAME, which is what you get in
ifrow.bDescr from GetIfTable.
We've found that simply comparing hardware addresses is not enough when using
Windows "teamed" (link-aggregated) interfaces. In a simple example, two NICs
are teamed together, leading to three interfaces visible to libdnet: the two
physical NICs and the virtual teamed interface. All three of these have the
same MAC address. What was happening was the eth0 interface was being assigned
to one of the physical NICs, packets were sent over it, but the replies were
not necessarily coming back to the same physical NIC.
report. It looks like this.
$ ./nmap google.com -sn
Starting Nmap 5.30BETA1 ( http://nmap.org ) at 2010-05-10 23:57 MDT
Nmap scan report for google.com (66.102.7.99)
Host is up (0.073s latency).
Other addresses for google.com (not scanned): 66.102.7.104
rDNS record for 66.102.7.99: lax04s01-in-f99.1e100.net
This replaces the line
Hostname google.com resolves to 2 IPs. Only scanned 66.102.7.99
- Twisted web server (OS X 10.6.3 Server)
- Apple Filing Protocol (OS X 10.6.3 Server in VMware Fusion)
- Apple Mac OS X Password Server (OS X 10.6.3 Server)
- XAVi XG6546p Wireless Gateway
- Sun GlassFish Communications Server
- Comdasys, SIParator and Glassfish SIP services
Miller reported that an EPROTO was causing Nmap to exit after sending
the Sqlping probe during service scan. The error message was
"Unexpected error in NSE_TYPE_READ callback. Error code: 71 (Protocol
error)". We suspect this was caused by a forged ICMP packet sent by an
active firewall.
$PROGRAMFILES64/WinPcap. Set $INSTDIR to $PROGRAMFILES/WinPcap or
$PROGRAMFILES64/WinPcap depending, but don't modify it if it already has a
value (from /D= on the command line). These changes make /D= work to install a
few files into an alternate directory.
