Socket getting created with same IP and port on local host

I am seeing weird behavior on Linux where I am seeing that remote end and local end are both showing same IP and port combination. Following is the netstat output

netstat -anp | grep 6102

tcp 0 0 139.185.44.123:61020 0.0.0.0:* LISTEN 3361/a.out

tcp 0 0 139.185.44.123:61021 139.185.44.123:61021 ESTABLISHED 3361/a.out

开发者_高级运维

Can anyone tell me if this is even possible ? If yes, then what could be the scenario ?

---

A connection is identified by a 4-tuple ((source ip, source port), (target ip, target port)), and the source and target ports could conceivably be the same without any issues. This connection could even be established by one process, which would lead to the output you're seeing.

However, I just got bitten by a nasty bug, where a client socket would try to connect to a server socket with a port number in the ephemeral port range on the same machine. The connection operation would be retried operation until it succeeded.

The retry feature was the issue: if the server application wasn't running AND the source port that got picked at random was the same as the target port (which is possible because the target port was in the ephemeral range), the client socket would CONNECT TO ITSELF (which was wreaking havoc on the internal logic of the client application, you can imagine).

Since the client was performing retries as quickly as possible, the 1 in 30.000 odds that this can happen were hit quickly enough.

The following Python script reproduces it:

import socket

host = 'localhost'
port = 35911

ctr = 0
while True:
    try:
        s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        s.settimeout(5)
        ctr += 1
        s.connect((host, port))
        print "Connected to self after", ctr, "tries"
        break
    except socket.error, e:
        print e
        # Retry

---

Here is an imaginable scenario. The caller of connect could call bind before calling connect. The caller of connect could cooperate with the caller of listen, and intentionally bind to a port number 1 higher than the listening port number.

If the kernel proceeds to reuse the socket number for the listener, I'd call that a kernel bug.

---

When multi-threaded server software accepts connection, it usually creates another socket, which communicates with newly connected client in separate thread, while original server socket is still listening for new clients in original thread. In such cases ports of both sockets are equal. So, there's no any problem.

---

It's a slightly odd case, called a TCP "active/active open". A socket has been opened, bound to a local port and then connected to itself, by using connect() with its own address as the destination.

---

Nothing weird about that. It has a 1 in 63k chance of happening. What you won't see is * two* such ESTABLISHED* connections: that's impossible by the rules of TCP.