Apparently SCTP can't have the same kind of half-open sockets that TCP
has. When one direction is closed, we can't do anything further with the
socket.
http://seclists.org/nmap-dev/2013/q1/227
This eliminates the ambiguity that could exist when, say, both o.udp and
o.sctp were both set. The code would use whichever it happened to test
first. This also makes TCP mode explicit with IPPROTO_TCP.
At high scan rates, there was nothing to prevent trying to set or clear
socket descriptors above FD_SETSIZE, which is usually around 1024. I got
a reliable assertion failures with the command
nmap -sT -p- --min-rate 100000 scanme.nmap.org
The problem only affected -sT scans. A similar protection was added to
Nsock in r15808.
Fixed a bug that prevented Nmap from finding any interfaces when one
of them had the type ARP_HDR_APPLETALK; this was the case for
AppleTalk interfaces. However, This support is not complete
since AppleTalk interfaces use different size hardware addresses
than Ethernet. 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/2013/q1/214
This bug was reported by Steven Gregory Johnson on IRC.
Compare to this similar test in Nmap's scan_engine.cc:
if (scantype != CONNECT_SCAN && Targets[0]->ifType() == devt_loopback) {
log_write(LOG_STDOUT, "Skipping %s against %s because Windows does not support scanning your own machine (localhost) this way.\n", scantype2str(scantype), Targets[0]->NameIP());
return;
}
rndbit made a report--unfortunately we con't fix it, but we can make the
error message clearer.
http://seclists.org/nmap-dev/2013/q1/187
Nping calls route_dst at least twice: once with a NULL device, and again
with the device learned from the first time. This interfered with the
code that automatically chooses a loopback interface for dests that are
the same as an interface address. For example, if you are 192.168.0.1,
and you are scanning 192.168.0.1, route_dst will tell you to use
interface "lo0" even though the interface of 192.168.0.1 may be "eth0".
route_dst was returning failure because the device name check was being
done before "eth0" got changed to "lo0".
This problem didn't show up on Linux because Linux uses
route_dst_netlink, which delegates the work to the kernel. But I could
reproduce on Linux by forcing the use of route_dst_generic.
The existing tests here didn't make much sense, and didn't cover all the
situations we care about. The 8 tests now check each of
client !--send-only EOF on stdin
client --send-only EOF on stdin
server !--send-only EOF on stdin
server --send-only EOF on stdin
client !--recv-only EOF on socket
client --recv-only EOF on socket
server !--recv-only EOF on socket
server --recv-only EOF on socket
The other thing we care about is whether the client/server keeps running
after the EOF. That is now checked in each of the tests too.
RFC 3986 section 3.1:
Although schemes are case-insensitive, the canonical form is lowercase
and documents that specify schemes must do so with lowercase letters.
An implementation should accept uppercase letters as equivalent to
lowercase in scheme names (e.g., allow "HTTP" as well as "http") for the
sake of robustness but should only produce lowercase scheme names for
consistency.
RFC 3986 says that these URLs are equivalent:
http://example.com/http://example.com:/
url.parse was returning port="" for the latter. Make it instead return
port=nil like the former.
To me, this is a relative URL with a path of "". I.e., it refers to the
same document as wherever the URL appeared, like when people do
<form action="" enctype="multipart/form-data" method="POST">
This code was quite old (dating from r854 in 2000) and may not serve a
purpose anymore. Let's try removing it.
Apart from being obsolete, the code had a race condition where the
connection could be closed with a RST before getpeername was called,
leading to a fatal error message.
