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.

  • 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 7, 2015 at 9:11
  • 5
    Did you look in the bit bucket for your missing packets? May 7, 2015 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 8, 2015 at 14:02
  • It depends on OS and its configuration. For MS Windows try to google windows mediasense. May 10, 2015 at 10:00

1 Answer 1


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.

  • 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 7, 2015 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 7, 2015 at 13:17
  • 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 7, 2015 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 7, 2015 at 13:23
  • 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 7, 2015 at 16:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.