Connecting to yourself (and hogging a port number) - linux

Question

We ran across a situation where an application apparently "half-connects" to itself through an system assigned port number and "gets stuck" on Linux (Centos 6.4 in particular).
The situation is as follows:
A (python) app is trying to connect to some service, let's say at IP address 192.168.1.201:8081. For some reason, the assigned outgoing port is 8081. The connect succeeds but no further activity occurs on the socket because it is not really connected but sort of half-way connected (My guess is that only half the handshake is completed and Linux is doing the rest in the background to improve parallelism). A read statement on the socket hangs waiting for the rest of the connect to complete.
Here is a simple C++ program that replicates the problem. Run it with the IP address of the host you are running on. It is peculiar because we are binding the connecting socket to a port (which is legal), and then connecting to the same address and port without an error message being generated, without a "listen," and with the read hanging.
./foo 192.168.1.201
Connected...going to read...'
ss -na
ESTAB 0 0 192.168.1.201:8081 192.168.1.201:8081
If you kill the program, the socket goes into Time-Wait:
TIME-WAIT 0 0 192.168.1.201:8081 192.168.1.201:8081
The question is: Can this happen with system assigned ports? Can you get into a state where somehow the outbound address/port ends up matching the destination address/port and the system deadlocks? That appears to be what we are seeing.
Thanks,
-- Mike
Program:
#include <assert.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <netdb.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <arpa/inet.h>
int main(int argc, char *argv[])
{
int ret;
int sockfd = 0, n = 0;
char recvBuff[1024];
struct sockaddr_in serv_addr;
struct sockaddr_in sa_loc;
if(argc != 2)
{
printf("\n Usage: %s <ip of server> \n",argv[0]);
return 1;
}
memset(recvBuff, '0',sizeof(recvBuff));
if((sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0)
{
printf("\n Error : Could not create socket \n");
return 1;
}
memset(&sa_loc, 0, sizeof(struct sockaddr_in));
sa_loc.sin_family = AF_INET;
sa_loc.sin_port = htons(8081);
sa_loc.sin_addr.s_addr = inet_addr(argv[1]);
ret = bind(sockfd, (struct sockaddr *)&sa_loc, sizeof(struct sockaddr));
if (ret != 0) {
perror("bind");
exit(1);
}
memset(&serv_addr, '0', sizeof(serv_addr));
serv_addr.sin_family = AF_INET;
serv_addr.sin_port = htons(8081);
if(inet_pton(AF_INET, argv[1], &serv_addr.sin_addr)<=0)
{
printf("\n inet_pton error occured\n");
return 1;
}
ret = connect(sockfd, (struct sockaddr *)&serv_addr, sizeof(serv_addr));
if (ret != 0) {
perror("connect");
exit(1);
}
printf("Connected...going to read...\n"); fflush(stdout);
while ( (n = read(sockfd, recvBuff, sizeof(recvBuff)-1)) > 0) {
recvBuff[n] = 0;
printf("%s", recvBuff); fflush(stdout);
}
if(n <= 0) {
perror("read");
exit(1);
}
return 0;
}

Answer 1

By binding the socket to a port and then connecting to the very same port, you established a kind of loopback connection of the socket to itself.
Can this happen with system assigned ports?
No, it can't, because connect(3) promises:
If the socket has not already been bound to a local address,
connect() shall bind it to an address which, unless the
socket's address family is AF_UNIX, is an unused local address.
This unused local address is never the same as the one a running server's socket is bound to. Plus, the bind() in your client wouldn't have succeeded if a server for that port ran already.
Can you get into a state where somehow the outbound address/port ends
up matching the destination address/port and the system deadlocks?
We can only get into the observed state if we explicitly program that way, by binding to the very same port we're then connecting to. Also, the system doesn't deadlock, only the application blocks, quite simply because it calls read(), waiting for data which is never written.