force connect to work

Question

I run the following line in bash, on a VM running red hat 5:

    for i in {1..100000};
        do telnet 10.10.10.105 41941;
    done

At some point, telnet connects to the port even though there is no one listening on it. It seems o be connecting to its self? The same issue appears when i start the client side of an application, without starting the server - the client successfully connects to the ip:port. The client looks something like this:

    addr.sin_family = AF_INET;
    addr.sin_port = htons(atoi(port));
    addr.sin_addr.s_addr = inet_addr(hostname);

    some_while_loop
    {
        status = ::connect(sock, (sockaddr *)&addr, sizeof(addr));
        if (status == -1)
        {
            shutdown(sock, 2);
            close(sock);
            return false;
        }
   }

I found this article: http://web.deu.edu.tr/doc/soket/ which states in 6.2 that the connection will succeed if you to the same machine you're running on. My question is, why is this happening? Is it a hardware issue or is it a fail-safe red-hat kernel is using, or maby it's because of the port i'm using (for 1025 for example, i don't have this issue)... ?

Answer 1

It is correlated to the port. When initiiating a TCP connection, for the client, a random unused port in the upper range of the ports (32786+) is picked. Then the usual TCP handshake is done, only with a special case called simultanous initiiation. Here it is assumed that both sides of the connection want to establish a connection at the same time, see below for a figure from the RFC.

You can enforce that behaviour using ncat:

ncat -p 50000 127.0.0.1 50000

This will make ncat connect to 127.0.0.1:50000, while using the source port 50000. You get a valid connection immediately, without having to listen for incoming connections beforehand.

---

Despite what commenters said, the case happening here is called simultanous initiiation and is well specified in RFC 793, Section 3.4, where it says:

Simultaneous initiation is only slightly more complex, as is shown in figure 8. Each TCP cycles from CLOSED to SYN-SENT to SYN-RECEIVED to ESTABLISHED.

      TCP A                                            TCP B

  1.  CLOSED                                           CLOSED

  2.  SYN-SENT     --> <SEQ=100><CTL=SYN>              ...

  3.  SYN-RECEIVED <-- <SEQ=300><CTL=SYN>              <-- SYN-SENT

  4.               ... <SEQ=100><CTL=SYN>              --> SYN-RECEIVED

  5.  SYN-RECEIVED --> <SEQ=100><ACK=301><CTL=SYN,ACK> ...

  6.  ESTABLISHED  <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED

  7.               ... <SEQ=101><ACK=301><CTL=ACK>     --> ESTABLISHED

                Simultaneous Connection Synchronization

                               Figure 8.

I also corrected the first paragraph to be more clear and precise.