Fundamentals 10 min read

Does a TCP Connection Persist After Unplugging the Network Cable?

Unplugging a network cable does not immediately terminate a TCP connection; the kernel’s socket state remains ESTABLISHED, and the connection’s fate depends on data transmission, retransmission limits, TCP keepalive settings, and whether either side detects a failure.

IT Services Circle
IT Services Circle
IT Services Circle
Does a TCP Connection Persist After Unplugging the Network Cable?

Today we discuss an interesting question: Does a TCP connection still exist after the network cable is unplugged for a few seconds and then plugged back in?

Many assume that removing the cable breaks the physical layer, which should also break the transport layer, causing the TCP connection to disappear, similar to a wired telephone call ending when the line is cut. However, this reasoning is flawed because unplugging the cable does not affect the transport layer.

In the Linux kernel, a TCP connection is represented by a struct socket structure that holds the connection’s state. When the cable is unplugged, the OS does not modify this structure, so the TCP state remains unchanged.

In an experiment, I connected to a cloud server via SSH, disabled Wi‑Fi to simulate unplugging the cable, and observed that the TCP connection stayed in the ESTABLISHED state.

From this we know that unplugging the cable alone does not change the TCP connection state. What matters next is what actions each side takes after the cable is removed.

When Data Is Transmitted After Unplugging

If the server sends data while the client’s cable is unplugged, the client cannot acknowledge the packets, so the server eventually triggers the timeout‑retransmission mechanism.

If the client reinstalls the cable before the server reaches the maximum retransmission count, the connection is still alive and the client can acknowledge the data normally.

However, if the server exhausts its retransmission attempts (controlled by tcp_retries2 ) before the client reconnects, the kernel marks the connection as faulty and closes it. When the client later reconnects and sends data, the server, having already discarded the original four‑tuple, replies with an RST, causing the client to close the connection as well.

When No Data Is Transmitted After Unplugging

If neither side sends data, the outcome depends on whether TCP keepalive is enabled.

If keepalive is disabled , the connection remains in the ESTABLISHED state indefinitely, even if the client never restores the cable.

If keepalive is enabled , the kernel periodically sends probe packets. If the remote side does not respond after a configurable number of probes, the connection is considered dead and is closed.

The keepalive parameters on Linux are:

net.ipv4.tcp_keepalive_time=7200
net.ipv4.tcp_keepalive_intvl=75
net.ipv4.tcp_keepalive_probes=9

This means the system waits 2 hours of inactivity before starting keepalive probes, sends a probe every 75 seconds, and gives up after 9 unanswered probes (totaling about 2 hours 11 minutes 15 seconds) before declaring the connection dead.

Applications must enable keepalive by setting the SO_KEEPALIVE socket option; otherwise the mechanism is inactive.

Summary

Unplugging the network cable does not directly affect the TCP connection state. Whether the connection persists depends on subsequent data transmission, retransmission limits, and keepalive configuration. With data transmission, the connection can survive if the client reconnects before the server’s retransmission limit is reached; without data, the connection stays alive only if keepalive is disabled, otherwise it will eventually be closed after probes fail.

networkTCPlinuxSocketkeepaliveRetransmission
IT Services Circle
Written by

IT Services Circle

Delivering cutting-edge internet insights and practical learning resources. We're a passionate and principled IT media platform.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.