The Linux-specific SO_BINDTODEVICE sockopt causes packets to be sent on
a specific interface, in cases where merely setting the source address
does not uniquely determine the interface.
The exceptions are the calls in ncat/ncat_connect.c and
nping/EchoServer.cc. Ncat doesn't have an option for the interface, and
I think Nping's -e option is only meant to apply to probes, not to the
echo server listener.
This was an old library removed in r2811 and r2812, of which a few
traces remained.
I don't know the purpose of this in nbase_misc.c:
if(sd != 501) // Hack related to WinIP Raw Socket support
ioctlsocket (sd, FIONBIO, &one);
There are some other #ifdefs that are used on other platforms, in which
code intf_name might nto be set but will continue to be an empty string
as before.
This commit fixes two different bugs:
(1) First in some situations Nmap will only see routes that are attached
to the device that handles the default route.
(2) On boxes without a default route, Nmap will not see any route.
These two bugs are caused by sysroutes_dnet_find_interfaces() logic
which will use only the geteway to match interface addresses.
To fix this, first check the current route and see if the gateway was set
otherwise use the destination address to match the address of an
interface.
This is set to an empty string in all functions yielding routes,
particularly route_loop. The code to get the interface pertaining to a
route is different on different platforms, so must be added one by one.
The code setting the intf_name to an empty string is only tested on
Linux.
of them had the type ARPHDR_INFINIBAND; this was the case for
IP-over-InfiniBand interfaces. However, This support is not complete
since IPoIB interfaces use 20 bytes for the hardware address, and
currently we only report and handle 6 bytes.
Nmap IP level scans should work without any problem, please refer to
the '--send-ip' switch and to the following thread:
http://seclists.org/nmap-dev/2012/q3/642
This bug was reported by starlight.2012q3.
of them had the type ARPHDR_IEEE80211; this was the case for wireless
interfaces operating in access point mode. This bug was reported by
Sebastiaan Vileijn.
http://seclists.org/nmap-dev/2012/q3/986
For some reason (probably by imitation of nmap_getservbyport), protocol
numbers, which are byte values 0–255, had htons called on them after
being read from nmap-protocols. On little-endian platforms, this turned
them into integers 0x0100, 0x0200, 0x0300, etc.
protocol_table is supposed to be an array of 256 linked lists, linking
all the protocol names of the same number. Because of the above htons
conversion, all protocols mapped to bucket 0 on lookup instead. Perhaps
in an attempt to work around this broken lookup, all protocols were
inserted into bucket 0 on init; all other buckets were empty. This
worked on little-endian platforms, but on big-endian platforms where
htons is a no-op, all protocol numbers but 0 mapped to an empty linked
list.
Remove all the htons stuff and just look things up by integers. Use the
same mapping on initial insertion and on lookup, so that the buckets are
acutally populated.
This was noticed by hejianet.
http://seclists.org/nmap-dev/2012/q3/1005
