Strange read error from <ip>: Transport endpoint is not connected

["Corentin Delorme" <codelorme () gmail com>]

Hi all,

If you try to run nmap with an ip of the form w.x.y.z with w between
240 and 255, you will get your console flooded with the following
message:

      Strange read error from <ip>: Transport endpoint is not connected

I'm running nmap v4.01 on a gentoo box with a 2.6 kernel, and this bug
apparently exists since at least nmap v2.53  as stated by the followig
link:

               http://seclists.org/lists/nmap-dev/2003/Jan-Mar/0021.html

So we will try to solve it. When I found the bug I first though it was
due to some wizard hacker defense against nmap, but after trying to
sniff my traffic I realized that not even one packet was sent out. So
I resigned myself to use strace and found that a connect call was
returning -1 with an invalid parameter error (EINVAL).

In fact, a lot of (network) programs have problems to handle these IPs
as shown here:

    $ nc 245.56.43.13 22
    (UNKNOWN) [245.56.43.13] 22 (ssh) : Invalid argument

    $ telnet 250.87.54.90 80
    Trying 250.87.54.90...
    telnet: Unable to connect to remote host: Invalid argument

    $ tracepath 247.12.32.87
     1:  send failed
         Resume: pmtu 65535

    $ traceroute 243.67.78.45
    traceroute to 243.67.78.45 (243.67.78.45), 30 hops max, 40 byte packets
    traceroute: sendto: Invalid argument
     1 traceroute: wrote 243.67.78.45 40 chars, ret=-1
    traceroute: sendto: Invalid argument
     2 traceroute: wrote 243.67.78.45 40 chars, ret=-1

I can see only 2 possibilities (maybe there is more but I can't figure
them out):
     - a bug in the connect call
     - the connect call is programmed to not connect on these special
(reserved) IPs (this would be strange because how can the IANA
administer their networks if they can't connect to their boxes ? They
would have to do all in local network, or have some special rewritten
OSes)

(If you know the answer you are welcome to send me an email ; )

But let' go back to nmap. In file targets.cc after the connect call in
function sendconnecttcpquery, the value of errno is not tested, so the
execution continue even if the connection was not successful. Then the
return value of the recv call in function get_connecttcpscan_results
is tested, and if it is -1 we enter in a switch statement on the
result of the socket_errno call:

    ...
    foundsomething = 0;
    res2 = recv(tqi->sockets[p][seq], buf, sizeof(buf) - 1, 0);
    if (res2 == -1) {
        int sock_err = socket_errno();
        switch(sock_err) {
        case ECONNREFUSED:
         ...

 As the error ENOTCONN (socket not connected) is not caught, the
default case is executed, which is responsible for printing our
"strange read error" message. Then a break is issued. this lead us to
a if satement which test the value of the variable foundsomething, and
if it is non-zero then the scan is launched.

    ...
    if (foundsomething) {
        hostupdate(hostbatch, hostbatch[hostindex], newstate, 1, trynum,
                        to,  &time[seq], NULL, pt, tqi, pingstyle_connecttcp);
        /*              break;*/
    }
    ...

But in our case this variable is 0, thus skipping the if body. This
leads us at the end of the while block, so it reiterate on and on
through it, printing each time our message.

I think the better way to address this bug is to do as the others
programs do, i.e. to test the result of the connect call and exit if
it wasn't successful. Here is a diff on the file targets.cc:

$ diff -u nmap-4.01/targets.cc nmap-4.01+/targets.cc
--- nmap-4.01/targets.cc        2006-02-07 08:15:37.000000000 +0100
+++ nmap-4.01+/targets.cc       2006-04-12 00:48:16.000000000 +0200
@@ -796,8 +796,12 @@
 #endif //HAVE_IPV6

   res = connect(tqi->sockets[probe_port_num][seq],(struct sockaddr
*)&sock, socklen);
+  if (errno == EINVAL) {
+       perror("sendconnecttcpquery: connect");
+       exit(-1);
+  }
   sock_err = socket_errno();
-
+
   if ((res != -1 || sock_err == ECONNREFUSED)) {
     /* This can happen on localhost, successful/failing connection immediately
        in non-blocking mode */

After recompiling, we get the following when running nmap with our
reserved IPs which is better than getting your terminal flooded, and
more like the behavior of the others programs:

    $ nmap 242.54.76.78

Starting Nmap 4.01 ( http://www.insecure.org/nmap/ ) at 2006-04-12 01:55 CEST
sendconnecttcpquery: connect: Invalid argument

I don't know if it is an acceptable solution so I'm refering to the
nmap hackers community. Personnaly I don't really like it (not the
community, the solution ; ) and it would be better to understand  why
the connect call is failing. Again if you know why, please send me an
email.

Any comments and questions will be appreciated.

Corentin

PS: please forgive my frenchy english.


_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev