TCP socket received from wrong port

I have a problem with TCP sockets receiving messages with the wrong destination address.

The OS is Ubuntu Linux 10.10 and the kernel version is 2.6.31-11-rt, but this happens with other kernels as well. A C / C ++ program with this problem does the following:

  • The TCP server connector is listening for connections on INADDR_ANY on port 9000.

  • Messages are received with the recv (2) TCP message sink stream. After reading the message, the connection is not closed, but the stream continues to read from the same connection forever.

  • Error: also messages for ports other than 9000 are received by the TCP message receiver. For example, when a remote SFTP client connects to a PC that is listening on a TCP receiver, it causes the TCP receiver to receive SFTP messages as well. How is this possible? How can TCP ports "leak" in this way? I think SFTP should use port 22, right? Then how is it possible these messages are visible on port 9000?

Additional Information:

  • At the same time, there is a raw socket listening on another network interface and the interface is in promiscuous mode. Could this have an effect?

  • TCP connection is not closed between messages received. The message listener simply reads data from the socket. Is this really the correct way to implement a TCP message sink?

Has anyone seen a problem like this? Thanks in advance.

EDIT:

Ok, here's some code. The code looks all right, so the main weird thing is: How can a TCP socket ever receive data sent to a different port?

/// Create TCP socket and make it listen to defined port
TcpSocket::listen() {
    m_listenFd = socket(AF_INET, SOCK_STREAM, 0)
    ...
    bzero(&m_servaddr, sizeof(sockaddr_in));
    m_servaddr.sin_family = AF_INET;
    m_servaddr.sin_addr.s_addr = htonl(INADDR_ANY);
    m_servaddr.sin_port = htons(9000);
    bind(m_listenFd, (struct sockaddr *)&m_servaddr, sizeof(sockaddr_in);
    ...
    listen(m_listenFd, 1024);
    ...
    m_connectFd = accept(m_listenFd, NULL, NULL);
}

/// Receive message from TCP socket.
TcpSocket::receiveMessage() {
    Uint16 receivedBytes = 0;
    // get the common fixed-size message header (this is an own message structure)
    Uint16 numBytes = recv(m_connectFd, msgPtr + receivedBytes, sizeof(SCommonTcpMSGHeader), MSG_WAITALL);
    ...
    receivedBytes = numBytes;
    expectedMsgLength = commonMsgHeader->m_msgLength;   // commonMsgHeader is mapped to received header bytes
    ...
    // ok to get message body
    numBytes = recv(m_connectFd, msgPtr + receivedBytes, expectedMsgLength - receivedBytes, MSG_WAITALL);
}

      

+3


source to share


2 answers


The TCP connection is not closed between messages received. the message listener just reads data from the socket. Is this really the correct way to implement a TCP message sink?

Yes, but it should close the socket and exit when it receives an EOS indication (recv () returns zero).



I think ten to one of your raw socket and FD TCP sockets is confusing somewhere.

0


source


Umm ... It looks like it was a raw socket after which he received messages. You can see from the log that the raw message handler is printing messages, not the TCP message handler. Duh ...!: S Sorry. So it looks like binding a raw socket to a different network interface is not working correctly. You need to fix this. Funny, although sometimes it works with SSH / SFTP, sometimes it doesn't.



0


source







All Articles