46

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.

Ram
  • 103
  • 5
Input J
  • 563
  • 1
  • 4
  • 9
  • 9
    "what exactly goes about" is going to be very hard to answer. These days the OS might do 'clever' things, like detecting that the cable is removed. Dropping the routes to that network from the routing table. Activating new routes via wireless, .... All of this gets in the way of a simple universal explanation. – Hennes May 07 '15 at 09:11
  • 5
    Did you look in the bit bucket for your missing packets? – Daniel R Hicks May 07 '15 at 12:19
  • 4
    One thing that can happen for sure is that your current communications are interrupted in the middle of a s – ereOn May 08 '15 at 14:02
  • It depends on OS and its configuration. For MS Windows try to google `windows mediasense`. – Zaboj Campula May 10 '15 at 10:00

1 Answers1

66

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.

DCTLib
  • 103
  • 2
jcbermu
  • 17,278
  • 2
  • 52
  • 60
  • 7
    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. – usr May 07 '15 at 13:00
  • 8
    @usr Why would it be useful to kill every connection just because someone power-cycles the Ethernet switch that my PC is connected to? – user May 07 '15 at 13:17
  • @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. – usr May 07 '15 at 13:20
  • 1
    TCP has an optional feature `keepalive`. When it is turned on, your connections will (almost) be instantly terminated when you unplug the cable. – Siyuan Ren May 07 '15 at 13:20
  • 11
    @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. – user May 07 '15 at 13:21
  • 9
    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 :)) – Luaan May 07 '15 at 13:23
  • @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. – jcbermu May 07 '15 at 13:42
  • 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. – usr May 07 '15 at 13:44
  • On Windows, it dies very fast at the next send() with "no route to host". – Joshua May 07 '15 at 15:46
  • 11
    @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. – Brad May 07 '15 at 16:35
  • @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. – usr May 07 '15 at 16:45
  • @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. – Bob May 07 '15 at 18:18
  • Windows force-kills network connections when the ethernet link dies, Linux does not. Most of the time I prefer the Linux approach. – pjc50 May 07 '15 at 21:50
  • 1
    @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). – Luaan May 08 '15 at 09:16
  • @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 May 08 '15 at 18:56
  • @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. – Barmar May 08 '15 at 18:58
  • @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). – Remy Lebeau Sep 15 '17 at 01:28
  • @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. – Barmar Sep 15 '17 at 01:32
  • @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. – Remy Lebeau Sep 15 '17 at 01:40