Skip to content
Advertisement

What happens to TCP socket when IP address changes?

Is there any error on a socket when writing to it after IP address change?

In my I’m using TCP socket, both read/write (non-passive), no TCP or application keep-alive.

To inspect this case I use socat to connect to a simple echo server on my local network. The connection is OK until I change the client IP address on my router and restart the network interface. At this point, I can write to a socket without any errors despite the IP of the client was changed, but no messages are being delivered anymore. I wait for some minutes and change the IP back. All the ‘stashed’ messages which were unable to be sent are being sent.

As far as I understand, when client IP was changed TCP connection does not exist anymore. Why there are no errors when writing to the socket when IP was changed? Is this specific to a Linux TCP stack or specified by TCP/IP?

Advertisement

Answer

A TCP connection is defined by source IP, source port, destination IP, and destination port. Changing the client’s IP address on your router does not cause the connection on your client and server to cease to exist immediately; however, if you leave the router in this state long enough, the connection will eventually cease to exist after certain amount of retries and timeouts have occurred. The exact amount is determined via configurable kernel parameters both on your client and on your echo server. You can inspect these parameters with sysctl -a | grep tcp

After you’ve changed the client’s IP address on your router, the client is still able to send packets to the server, and the server is also able to receive these packets, but the server’s attempt to reply/acknowledge back to the client is unable to be routed back to the client. This leads to retries up to a certain limit on the client (which is why you saw no errors on the client side). Once you’ve reverted the client’s IP back on your router, the server is able to communicate with the client again as the router is now able to correctly route the server’s packet to the client.

This retry behavior is not specific to the Linux TCP stack. rfc 2988 defines the standard algorithm that senders are required to use to compute and manage their retransmission timer.

Advertisement