What happens to TCP connections when I remove the ethernet cable?

Question

For a TCP connection, when I remove the cable and reconnect after 30-40 seconds there is no packet loss issues. But when the reconnect time is more than a few minutes all the packets are lost. I know it works with the retransmission timer running out but I want to know what exactly goes about when a network cable is unplugged.

Solution

By definition on a layered model as OSI or TCP/IP each layer works independent and not-aware of the lower layers.

When you remove the cable, it's a physical disruption (layer 1), so almost inmediately ethernet (layer 2) detects a loss of signal (if you're on Windows you will see the very dreaded pop-up informing network disconnected)

IP (layer 3) and TCP (layer 4) won't notice it, so they will try to keep on working.

TCP won't break a established TCP connection during a period of time because when TCP sends data, it expects an ACK in reply and if it doesn't arrive within a period of time, it re-transmits the data.

TCP will re-transmit the data, passing it to IP, who will pass it to Ethernet, who is unable to send it and simply discard it.

TCP will be waiting again and repeating this process until a timeout happens that let it declares that the connection is over. TCP resets the segment sequence number, discard the information that was trying to send and let free the buffer and memory resources that were allocated for that connection.

Plug the cable in before it happens and everything will keep going. This is what makes TCP reliable and at the same time vulnerable to DDos attacks.

If the OS has more than one interface (for example, ethernet and wi-fi), it is possible that when the ethernet goes down, it will try through wifi. It depends how the routing is configured, but in general terms "TCP won't be aware of that".

The basic structure of DDoS attacks is: thousands of clients opening each one a TCP connection every few seconds to a server and then abandoning the connection. Each TCP connection keeps open on the server during a long time (wasting valuable assets as TCP ports, allocated memory, bandwith, etc.) clogging the server resources to attend legitimate users.

Comments

[usr]

That's what the model says but I believe real OSes detect some failures and kill connections immediately. That's just a useful thing to do.

[user]

@usr Why would it be useful to kill every connection just because someone power-cycles the Ethernet switch that my PC is connected to?

[usr]

@MichaelKjörling good point. But that's what happens. I just disabled my NIC using the Window network center and watched all TCP connections instantly die using TcpView.

[Siyuan Ren]

TCP has an optional feature keepalive. When it is turned on, your connections will (almost) be instantly terminated when you unplug the cable.

[user]

@usr Disabling the network card through the OS' administrative interfaces is a completely different operation compared to physically unplugging the cable or otherwise breaking the physical-layer link. Please do not confuse the two.

[Luaan]

Also, if you don't actually send any TCP data while the cable is disconnected, it will never notice. That's why you need to keep sending keep-alive messages - applications that only ever listen will never know if the connection "dies". On the plus side, it also means that if neither side tried to send anything while the cable was unplugged, the connection will work just fine after the cable is plugged back in. TCP is used a lot differently from how it was designed :) Remember the TCP-over-Pigeon-mail experiment :))

[jcbermu]

@usr If you disable the NIC, you are removing layer 1 and layer 2, so upper layers can't exist. It's different than having layer1 and layer 2 in a disconnection state, that the system could consider a transitional state.

[usr]

I just plugged the cable and it did nothing indeed. It could have, though. The OS did detect that the cable was unplugged. The hardware tells that to the OS. Of course not every link interruption can be detected but some can. It depends on the OS what happens then. It is not possible to logically deduce what must happen. It's an implementation choice.

[Joshua]

On Windows, it dies very fast at the next send() with "no route to host".

[Brad]

@usr It's a really bad implementation choice to not follow standards. TCP connections can survive temporary network outages. It's designed to do so. In fact, it used to be that you could even reboot your computer and still have a TCP connection but this wasn't always practical. Your assumption that everyone wants to be disconnected when a cable gets yanked is false, and is not how the systems were designed.

[usr]

@Brad I don't make that assumption any longer. But it is an important addendum to this answer that connections can be killed at the leisure of the OS due to some detectable link failures. The simplistic OSI model is not fully implemented in practice.

[tvdo]

@Luaan IIRC one of the bigger reasons for keep-alives is NAT (and firewalls and anything else with idle detection). If you don't send anything for a while, one of the networking devices between you and the remote host, most often a NAT router these days, will assume the connection no longer exists and simply close the port. The next time you try to use it? Boom.

[Wayne Jhukie]

Windows force-kills network connections when the ethernet link dies, Linux does not. Most of the time I prefer the Linux approach.

[Luaan]

@pjc50 Not true. Windows will only force-kill the connection when you disable the NIC. That's completely different from losing connection (e.g. a restart of a router, unplugging a cable...). The reason is quite simple - when you disable the NIC, it no longer keeps the memory of all the channels, ports, segments to send etc. On the other hand, if you unplug the cable, the NIC is still fine. It just has to wait for a while for the connection to come back on, and it can continue just fine. Unless you're sending data (users don't like 4-minute long timeouts, really).

[Barmar]

@Brad I don't think it has ever been possible for TCP connections to persist across a reboot. A TCB relates a socket tuple to an I/O stream that's open in some processes. When you reboot, all the processes are gone, as are all the I/O streams they had. TCP is even required to assign initial sequence numbers randomly, to minimize the chance that a retransmission from before the reboot will appear to be a valid segment in a new connection that happens to use the same port numbers.

[Barmar]

@SiyuanRen Keepalives practically never detect the failure immediately. In most configurations, keepalives aren't even sent unless a connection has been idle for a long time (I think 2 hours is the default). And once they're sent, they don't detect the failure until you reach the retransmission limit, which can take a couple of minutes. If you want quicker detection of failure, you generally have to implement application-level keepalives.

[Remy Lebeau]

@Barmar: TCP keepalive intervals can be configured on most platforms, either in the OS configuration, or by software on a per-socket basis (ie, setsockopt() with TCP_KEEPCNT/TCP_KEEPIDLE/TCP_KEEPINTVL options on Linux, WSAIoctl(SIO_KEEPALIVE_VALS) on Windows, etc).

[Barmar]

@RemyLebeau True, but it still doesn't detect the failure until the retransmission limit is reached AFTER the keepalive interval. So if you set keepalive to 1 minute, it will still take about 3 minutes to detect the failure.

[Remy Lebeau]

@Barmar: SIO_KEEPALIVE_VALS on Windows lets you set the initial timeout before keepalive kicks in, and the per-keepalive timeout. On Vista+, the probe count is fixed at 10, but on earlier versions it is configurable in the Registry. TCP_KEEPCNT/TCP_KEEPIDLE/TCP_KEEPINTVL on Linux also allow a similar degree of fine-grain control over the keepalive timeouts and probing. So you can set the timeouts accordingly to get close to a desirable total timeout taking retransmissions and probes into account.