Tcp State Diagram - Learning Module

Loading content...

0/228

SYN_SENT and SYN_RECEIVED: The Handshake in Progress

The Critical Moments of Connection Establishment

The TCP three-way handshake is one of the most important sequences in network communication. During this brief but critical exchange, two endpoints negotiate parameters, synchronize sequence numbers, and establish the shared state necessary for reliable data transfer. The SYN_SENT and SYN_RECEIVED states represent the intermediate phases of this handshake—moments where the connection exists in a partially-formed, vulnerable state.

These transitional states are where connections are most susceptible to failures, timeouts, and attacks. A packet lost here means connection failure. A malicious actor flooding SYN packets exploits these states. Network latency during this phase directly impacts perceived application responsiveness. Understanding SYN_SENT and SYN_RECEIVED deeply means understanding not just the protocol mechanics, but the performance characteristics, failure modes, and security implications that arise during connection establishment.

This page explores both states comprehensively—examining the client's perspective (SYN_SENT), the server's perspective (SYN_RECEIVED), the unusual simultaneous open case, and the practical implications for real-world systems.

Learning Objectives

By the end of this page, you will understand: (1) How clients enter and exit SYN_SENT state, (2) How servers enter and exit SYN_RECEIVED state, (3) The timeout and retransmission mechanisms during handshake, (4) TCP simultaneous open and the four-way handshake, (5) Security considerations during the partially-open states, and (6) Practical debugging of connection establishment issues.

SYN_SENT: The Client's Active Open

When a client application calls connect() on a TCP socket, it initiates an active open—actively reaching out to establish a connection with a remote server. The socket immediately transitions from CLOSED to SYN_SENT, and the kernel transmits a SYN segment to the target address.

The SYN_SENT State Mechanics

Entry Condition:

Application calls connect()
Kernel generates and sends SYN segment
Socket transitions: CLOSED → SYN_SENT

What the SYN Contains:

The initial SYN segment carries crucial information for connection establishment:

Field	Purpose	Example Value
Sequence Number	Client's Initial Sequence Number (ISN)	1234567890
SYN flag	Indicates synchronization request	Set (1)
ACK flag	Not acknowledging anything yet	Clear (0)
Window Size	Client's initial receive window	65535
MSS Option	Maximum Segment Size	1460 bytes
Window Scale Option	Window size multiplier	7 (×128)
SACK Permitted Option	Selective acknowledgments allowed	Present
Timestamps Option	For RTT measurement and PAWS	Present

The ISN Generation Problem

The Initial Sequence Number (ISN) selection is security-critical. Early TCP implementations used predictable ISNs (incrementing clocks), enabling devastating attacks:

The ISN Prediction Attack (Historical):

Attacker observes ISN patterns from legitimate connections
Attacker predicts the server's ISN for a spoofed connection
Attacker sends spoofed SYN with fake source IP
Attacker predicts and sends correct ACK (acknowledging predicted ISN+1)
Connection established with attacker impersonating trusted source

Modern systems use cryptographically random ISNs:

ISN = hash(source_ip, source_port, dest_ip, dest_port, secret_key, timestamp)

This makes prediction virtually impossible while still ensuring ISNs don't repeat during the Maximum Segment Lifetime (MSL).

Converting Mermaid diagram...

Exit Conditions from SYN_SENT

Normal Success Path:

Receive SYN+ACK from server
Validate that ACK acknowledges our SYN (ack = our_ISN + 1)
Send ACK for server's SYN (our ack = server_ISN + 1)
Transition to ESTABLISHED state
Unblock the connect() call (return success to application)

Timeout Path:

No SYN+ACK received within timeout period
Retransmit SYN (exponential backoff: 1s, 2s, 4s, 8s, ...)
After tcp_syn_retries attempts (default: 6), give up
Transition to CLOSED
Return error to application (ETIMEDOUT)

Reset Path:

Receive RST from server (port not listening, connection refused)
Immediately transition to CLOSED
Return error to application (ECONNREFUSED)

Simultaneous Open Path (Rare):

Receive SYN (without ACK) from the peer
Both sides sent SYN at approximately the same time
Transition to SYN_RECEIVED (will discuss later)

syn_sent_timing.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
/**
 * Understanding SYN_SENT behavior in practice
 * Demonstrates timeouts and connection failure scenarios
 */
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <stdio.h>
#include <errno.h>
#include <time.h>
#include <unistd.h>
 
int main() {
    int sockfd;
    struct sockaddr_in server_addr;
    time_t start, end;
 
    sockfd = socket(AF_INET, SOCK_STREAM, 0);
    
    // Connect to a non-existent or firewalled host
    // This will demonstrate SYN_SENT timeout behavior
    server_addr.sin_family = AF_INET;
    server_addr.sin_port = htons(12345);
    inet_pton(AF_INET, "192.0.2.1", &server_addr.sin_addr);  // TEST-NET-1
 
    printf("Attempting connection (socket enters SYN_SENT)...\n");
    start = time(NULL);
 
    int result = connect(sockfd, 
                         (struct sockaddr *)&server_addr, 
                         sizeof(server_addr));
 
    end = time(NULL);
 
    if (result < 0) {
        printf("Connection failed after %ld seconds\n", end - start);
        
        switch (errno) {
            case ETIMEDOUT:
                printf("Error: ETIMEDOUT - SYN retries exhausted\n");
                printf("(No SYN+ACK received; host may be unreachable)\n");
                break;
            case ECONNREFUSED:
                printf("Error: ECONNREFUSED - Received RST\n");
                printf("(Server not listening on that port)\n");
                break;
            case ENETUNREACH:
                printf("Error: ENETUNREACH - Network unreachable\n");
                printf("(No route to destination)\n");
                break;
            case EHOSTUNREACH:
                printf("Error: EHOSTUNREACH - Host unreachable\n");
                printf("(ICMP host unreachable received)\n");
                break;
            default:
                perror("connect");
        }
    } else {
        printf("Connection established in %ld seconds\n", end - start);
    }
 
    close(sockfd);
    return 0;
}

Reducing Connection Timeout Delay

The default SYN retry behavior (6 retries with exponential backoff) can result in 127+ second timeouts. For latency-sensitive applications, reduce tcp_syn_retries or implement application-level timeouts using non-blocking sockets with select()/poll()/epoll(). Cloud environments often use aggressive retry settings (2-3 retries).

SYN_RECEIVED: The Server's Response

When a server in LISTEN state receives a valid SYN packet, it creates a new connection record (or request socket) and transitions that connection into the SYN_RECEIVED state. Note carefully: the listening socket itself stays in LISTEN—SYN_RECEIVED applies to the embryonic connection being established.

The SYN_RECEIVED State Mechanics

Entry Conditions:

From State	Trigger	Action
LISTEN	Receive valid SYN	Create request_sock, send SYN+ACK
SYN_SENT	Receive SYN (no ACK)	Simultaneous open; send SYN+ACK

What the SYN+ACK Contains:

The server's response acknowledges the client's SYN and sends its own:

Field	Value	Purpose
Sequence Number	Server's ISN	Initiating server's sequence space
ACK Number	Client's ISN + 1	Acknowledging client's SYN
SYN flag	Set	Synchronizing server's sequence
ACK flag	Set	Acknowledging client's SYN
MSS Option	Server's MSS	May differ from client's
Window Scale	Server's value	If client offered it
SACK Permitted	Present	If client offered it

The Request Socket (Mini-Socket)

In modern implementations (Linux, Windows), the server doesn't create a full socket for each SYN. Instead, it creates a lightweight request socket (or connection request block):

// Simplified Linux request_sock structure
struct request_sock {
    struct sock_common          __req_common;
    struct request_sock         *dl_next;      // Queue linkage
    
    u32                         rcv_isn;       // Client's ISN
    u32                         snt_isn;       // Our ISN
    u16                         mss;           // Negotiated MSS
    u8                          num_retrans;   // SYN+ACK retries
    u8                          syncookie:1;   // Created via SYN cookie?
    
    struct timer_list           rsk_timer;     // Retransmission timer
};

This design minimizes memory consumption for half-open connections, which is crucial during SYN floods. A full socket (struct sock_common, struct inet_sock, etc.) may consume 1-2 KB, while a request socket uses only ~100-200 bytes.

The SYN_RECEIVED State Timeline

                     Time
                       │
    Server receives    │
    SYN from client    ▼
    ─────────────────────
                       │
    Create request_sock│
    Send SYN+ACK       │
    Start timer        │────────────────────────┐
    (Enter SYN_RCVD)   │                        │
                       │                        │
                       │  Timer expires?        │ Waiting for
                       │  Resend SYN+ACK        │ client's ACK
                       ├────────────────────────┤
                       │  Timer expires again?  │
                       │  Resend SYN+ACK        │
                       ├────────────────────────┤
                       │                        │
    Receive ACK ─────▶ │  Validate ACK          │
                       │  Create full socket    │
                       │  Move to accept queue  │
                       │  (Enter ESTABLISHED)   │
    ─────────────────────
                       │
    App calls accept() │
    Returns new fd     ▼

Exit Conditions from SYN_RECEIVED

Normal Success Path:

Receive valid ACK from client (ack = our_ISN + 1)
Promote request_sock to full socket
Move to accept queue
Transition to ESTABLISHED

Timeout Path:

No ACK received within timeout
Retransmit SYN+ACK (up to tcp_synack_retries times)
After exhausting retries, destroy request_sock
Connection attempt silently dropped

Reset Path:

Receive RST from client
Destroy request_sock immediately
Log event (depending on configuration)

SYN_RECEIVED is Inherently Vulnerable

The server commits resources when creating a request_sock, but the client hasn't proven its legitimacy (the source IP could be spoofed). This asymmetry—server commits resources based on unauthenticated SYN—is the fundamental vulnerability exploited by SYN floods. SYN cookies address this by deferring resource allocation until the final ACK proves the client's legitimacy.

SYN Queue vs Accept Queue
Aspect	SYN Queue	Accept Queue
Contains	Connections in SYN_RECEIVED	Connections in ESTABLISHED
Data structure	Hash table or list	Queue (FIFO)
Entry size	~100-200 bytes (request_sock)	~1-2 KB (full socket)
Controlled by	tcp_max_syn_backlog sysctl	backlog parameter + somaxconn
Overflow action	Drop SYN or use SYN cookies	Drop completed connection
Attacker target	SYN flood attack	slowloris/accept exhaustion

Retransmission During Handshake

The three-way handshake operates over an unreliable network layer—packets can be lost, delayed, or corrupted. TCP handles this through retransmission with exponential backoff, but the behavior during handshake differs from established connection retransmission.

SYN Retransmission (Client Side)

When a client sends a SYN and receives no SYN+ACK:

Attempt  │  Delay    │  Cumulative
─────────┼───────────┼─────────────
   1     │   0s      │    0s        (initial SYN)
   2     │   1s      │    1s        (1st retry)
   3     │   2s      │    3s        (2nd retry)
   4     │   4s      │    7s        (3rd retry)
   5     │   8s      │   15s        (4th retry)
   6     │  16s      │   31s        (5th retry)
   7     │  32s      │   63s        (6th retry)
  Fail   │  64s      │  127s        (give up)

Controlled by: net.ipv4.tcp_syn_retries (default: 6)

Total timeout ≈ 127 seconds before the connect() call returns ETIMEDOUT.

SYN+ACK Retransmission (Server Side)

When a server sends SYN+ACK and receives no ACK:

Attempt  │  Delay    │  Cumulative
─────────┼───────────┼─────────────
   1     │   0s      │    0s        (initial SYN+ACK)
   2     │   1s      │    1s        (1st retry)
   3     │   2s      │    3s        (2nd retry)
   4     │   4s      │    7s        (3rd retry)
   5     │   8s      │   15s        (4th retry)
   6     │  16s      │   31s        (5th retry)
  Drop   │           │   ~63s       (destroy request_sock)

Controlled by: net.ipv4.tcp_synack_retries (default: 5)

The request_sock is destroyed after approximately 63 seconds of no response.

tune_handshake_retries.sh
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
#!/bin/bash
# Tuning TCP handshake retransmission parameters
 
# View current settings
echo "Current SYN retry settings:"
sysctl net.ipv4.tcp_syn_retries
sysctl net.ipv4.tcp_synack_retries
 
# For faster failure detection (client side)
# Reduce SYN retries from default 6 to 2
# Total timeout: ~7 seconds (1 + 2 + 4)
sudo sysctl -w net.ipv4.tcp_syn_retries=2
 
# For faster cleanup of dead connections (server side)
# Reduce SYN+ACK retries from default 5 to 2
# Dead connections cleaned up in ~7 seconds
sudo sysctl -w net.ipv4.tcp_synack_retries=2
 
# ⚠️ Warning: Lower values mean faster failure detection
#    but also less tolerance for packet loss and latency.
#    For high-latency networks (satellite, intercontinental),
#    keep defaults or even increase.
 
# Make changes persistent
echo "net.ipv4.tcp_syn_retries = 2" >> /etc/sysctl.d/99-tcp-tuning.conf
echo "net.ipv4.tcp_synack_retries = 2" >> /etc/sysctl.d/99-tcp-tuning.conf

Why Exponential Backoff?

The exponential backoff pattern (1s, 2s, 4s, 8s, ...) serves multiple purposes:

Congestion Control: If packets are being lost due to network congestion, aggressive retransmission would worsen the congestion. Backing off gives the network time to recover.
Resource Conservation: Constant retransmission wastes CPU and bandwidth on both endpoints.
Diverse Network Conditions: The increasing delays accommodate networks with vastly different characteristics—from local networks (ms latency) to satellite links (600ms+ RTT).
Attack Mitigation: Rapid retransmission would amplify DDoS attack traffic.

Packet Loss Scenarios

Lost Packet	Effect	Recovery
Initial SYN	Client retransmits	1s delay minimum
SYN+ACK	Server retransmits	1s delay minimum
Final ACK	Server retransmits SYN+ACK	1s delay; client re-ACKs
Initial SYN (to wrong port)	Immediate RST	No delay (ECONNREFUSED)
Initial SYN (firewalled)	No response	Full timeout (127s default)

The "Connection Timeout" Hierarchy

Applications may implement multiple timeout layers:

Layer           │ Typical Value    │ Control
────────────────┼──────────────────┼─────────────────────
Kernel SYN      │ 127 seconds      │ tcp_syn_retries
Socket timeout  │ 30 seconds       │ SO_SNDTIMEO / alarm()
Application     │ 5-10 seconds     │ Application logic
User interface  │ 3-5 seconds      │ UX design

Best practice: Set application-level timeouts shorter than kernel timeouts to maintain responsiveness.

Non-Blocking Connect for Fast Timeouts

For sub-second connection timeouts, use non-blocking sockets: (1) Set socket non-blocking, (2) Call connect() (returns immediately with EINPROGRESS), (3) Use select()/poll()/epoll() with your desired timeout, (4) Check socket error status with getsockopt(SO_ERROR). This bypasses kernel SYN retry behavior.

Simultaneous Open: The Four-Way Handshake

TCP's state machine includes a rarely-encountered but fascinating scenario: simultaneous open, where both endpoints initiate connection at approximately the same time. Neither endpoint is purely a client or server—both perform active opens.

How Simultaneous Open Occurs

For simultaneous open to occur, the following must happen:

Both endpoints have sockets bound to known ports
Both endpoints call connect() at approximately the same time
Each endpoint's SYN reaches the other before its own SYN+ACK is sent

    Host A                           Host B
      │                                │
      │  connect() called              │  connect() called
      │  Send SYN (seq=100)            │  Send SYN (seq=300)
      │═════════════════════════════▶  │
      │  ◀═════════════════════════════│
      │                                │
  SYN crosses SYN in transit           │
      │                                │
  Receive SYN        Receive SYN       │
  (no ACK bit)       (no ACK bit)      │
      │                                │
  Enter SYN_RECEIVED                   │  Enter SYN_RECEIVED
  Send SYN+ACK       Send SYN+ACK      │
      │═════════════════════════════▶  │
      │  ◀═════════════════════════════│
      │                                │
  Receive SYN+ACK    Receive SYN+ACK   │
  Enter ESTABLISHED  Enter ESTABLISHED │

The State Transitions

In simultaneous open, both endpoints follow this path:

CLOSED → SYN_SENT → SYN_RECEIVED → ESTABLISHED

This is unlike normal connection where:

Client: CLOSED → SYN_SENT → ESTABLISHED
Server: LISTEN → SYN_RECEIVED → ESTABLISHED

The key insight: when a socket in SYN_SENT receives a SYN (without ACK), it knows a simultaneous open is occurring and transitions to SYN_RECEIVED rather than ESTABLISHED.

Converting Mermaid diagram...

Practical Occurrence

Simultaneous open is rare in practice because:

Asymmetric design: Most applications use client-server model where one side listens and one connects.
Timing requirements: Both SYNs must be in flight simultaneously, which requires very precise timing or high latency.
Known ports: Both sides must know each other's port in advance to connect().

However, simultaneous open can occur in:

Peer-to-peer applications: Where both peers try to initiate connection
NAT traversal techniques: UDP hole punching adapted for TCP
Testing/debugging scenarios: Intentionally triggering the behavior

Why TCP Supports This

TCP was designed to handle any combination of opens and closes. The state machine's completeness ensures that even unusual sequences work correctly. RFC 793 explicitly specifies simultaneous open behavior, and all conforming implementations must support it.

Verification Code

simultaneous_open_test.py
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
"""
Demonstrating TCP simultaneous open
Requires precise timing and works best on local machine
 
Run two instances of this script with opposite port assignments:
  Instance 1: MY_PORT=50000, PEER_PORT=50001
  Instance 2: MY_PORT=50001, PEER_PORT=50000
 
Both will connect() to each other simultaneously.
"""
 
import socket
import time
import threading
 
MY_PORT = 50000
PEER_PORT = 50001
PEER_IP = "127.0.0.1"
 
def attempt_simultaneous_open():
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    
    # Must bind to known port so peer can connect to us
    sock.bind(('', MY_PORT))
    
    # Wait for synchronization (in real scenario, use external sync)
    time.sleep(1)
    print(f"Attempting simultaneous open to {PEER_IP}:{PEER_PORT}")
    
    # Note: Normal connect() on bound socket
    # If peer also Connect()s at same time, simultaneous open occurs
    try:
        sock.connect((PEER_IP, PEER_PORT))
        print("Connection established via simultaneous open!")
        
        # Verify we're connected
        local = sock.getsockname()
        remote = sock.getpeername()
        print(f"Local: {local}, Remote: {remote}")
        
    except socket.timeout:
        print("Connection timed out (peer may not have connected)")
    except Exception as e:
        print(f"Error: {e}")
    finally:
        sock.close()
 
if __name__ == "__main__":
    attempt_simultaneous_open()

Historical Significance

Simultaneous open was more relevant in early ARPAnet days when the network was smaller and peer relationships were common. Modern networks are highly asymmetric, making this a curiosity rather than a common occurrence. However, understanding it illuminates the completeness of TCP's design.

Security Considerations During Handshake

The SYN_SENT and SYN_RECEIVED states represent a window of vulnerability. The connection exists but is not yet validated—creating opportunities for attacks, reconnaissance, and denial of service.

Attack Vectors Targeting Handshake States

1. SYN Flood Attack

Target: SYN_RECEIVED state on servers

Attacker sends massive volume of SYN packets
Each SYN creates a request_sock entry
Spoofed source IPs prevent ACK completion
Server's SYN queue fills up
Legitimate connections denied

Mitigations:

SYN cookies (eliminate state for half-open connections)
Increase SYN queue size
Reduce SYN+ACK retries
Firewall rate limiting
Cloud DDoS protection

2. ACK Flood Attack

Target: Processing overhead for spurious ACKs

Attacker sends ACK packets with random sequence numbers
Server must look up and validate each ACK
CPU resources consumed even though ACKs are rejected

Mitigations:

SYN cookies (ACKs only valid if cookie matches)
Rate limiting ACKs to non-existent connections
Hardware offload for packet filtering

3. Port Scanning / Reconnaissance

Target: Discovery of listening services

SYN scan: Send SYN, look for SYN+ACK (open) or RST (closed)
Half-open scan: Don't complete handshake (harder to log)
Connect scan: Complete handshake, then close

Mitigations:

Firewall rules restricting port access
Connection logging (even half-open)
Intrusion detection systems (IDS)
Port knocking

4. RST Injection Attack

Target: Disrupting connections during establishment

Attacker guesses sequence numbers
Sends spoofed RST to terminate connections
Easier during handshake (fewer valid sequence numbers)

Mitigations:

TCP timestamps (adds entropy to validation)
Sequence number randomization
TCP-AO (Authentication Option) for critical connections

Handshake Attack Summary
Attack	Target State	Goal	Defense
SYN Flood	SYN_RECEIVED	Exhaust server resources	SYN cookies, queue tuning
ACK Flood	N/A (fake ACKs)	CPU exhaustion	SYN cookies, rate limiting
Port Scan	LISTEN	Reconnaissance	Firewalls, IDS
RST Injection	SYN_SENT/SYN_RECEIVED	Connection termination	Sequence randomization, timestamps
ISN Prediction	SYN_SENT	Session hijacking	Cryptographic ISN

Detecting Handshake Anomalies

Monitoring tools can identify attacks and anomalies:

# Check for SYN flood indicators
netstat -s | grep -i syn

# Example output during attack:
#   23451 SYNs to LISTEN sockets dropped
#   18234 times the listen queue of a socket overflowed
#   521432 SYN cookies sent
#   512891 SYN cookies received

# Monitor in real-time
watch -n1 'ss -tn state syn-recv | wc -l'

# Alert if SYN_RECEIVED count exceeds threshold
SYN_RECV_COUNT=$(ss -tn state syn-recv | wc -l)
if [ $SYN_RECV_COUNT -gt 1000 ]; then
    echo "ALERT: High SYN_RECEIVED count ($SYN_RECV_COUNT)"
fi

Firewall Rules for Handshake Protection

# iptables rules for SYN flood protection

# Limit new connections per source IP
iptables -A INPUT -p tcp --syn -m connlimit \
    --connlimit-above 100 --connlimit-mask 32 \
    -j DROP

# Rate limit SYN packets overall
iptables -A INPUT -p tcp --syn -m limit \
    --limit 100/s --limit-burst 200 \
    -j ACCEPT

# Drop invalid packets (bad flags, wrong sequence)
iptables -A INPUT -m state --state INVALID -j DROP

# Log potential scans
iptables -A INPUT -p tcp --syn -m recent --name portscan \
    --update --seconds 60 --hitcount 10 -j LOG \
    --log-prefix "PORT SCAN DETECTED: "

Defense in Depth

No single defense is sufficient against handshake attacks. Modern protection combines multiple layers: network-level filtering, OS kernel hardening (SYN cookies, queue tuning), application-level rate limiting, and cloud-based DDoS mitigation. The handshake is inherently vulnerable by design, so mitigation is about raising the cost of attack rather than eliminating it.

Debugging Connection Establishment Issues

Connection establishment problems manifest in various ways: timeouts, refused connections, slow startups. Understanding the handshake states helps pinpoint the cause.

Diagnostic Approach

Step 1: Identify the Symptom

Symptom	Likely Cause	Check
ECONNREFUSED	RST received	Server not listening
ETIMEDOUT	No SYN+ACK	Firewall, routing, server down
Slow connect	Handshake completing slowly	Latency, packet loss, misconfiguration
Intermittent failure	Overloaded queues	Server queue depths

Step 2: Verify Server is Listening

# On the server
ss -tlnp | grep PORT
lsof -i :PORT

# Expected: LISTEN state socket with correct program

Step 3: Check Network Path

# Can we reach the server?
ping server_ip

# Can we reach the port?
nmap -p PORT server_ip

# Or without nmap:
nc -zv server_ip PORT

Step 4: Capture the Handshake

# Capture TCP handshake packets
tcpdump -i any host server_ip and port PORT -nn

# Expected successful handshake:
# 1. Client → Server: SYN
# 2. Server → Client: SYN+ACK
# 3. Client → Server: ACK

diagnose_connection.sh
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
#!/bin/bash
# Comprehensive TCP connection diagnostic script
 
if [ $# -ne 2 ]; then
    echo "Usage: $0 <host> <port>"
    exit 1
fi
 
HOST=$1
PORT=$2
 
echo "=== TCP Connection Diagnostics ==="
echo "Target: $HOST:$PORT"
echo "Time: $(date)"
echo ""
 
# Test 1: DNS resolution
echo "--- DNS Resolution ---"
if host $HOST > /dev/null 2>&1; then
    echo "✓ DNS resolves: $(host $HOST | head -1)"
else
    echo "✗ DNS resolution failed"
fi
echo ""
 
# Test 2: ICMP connectivity
echo "--- ICMP Connectivity ---"
if ping -c 1 -W 2 $HOST > /dev/null 2>&1; then
    echo "✓ Host responds to ping"
else
    echo "✗ No ping response (may be firewalled)"
fi
echo ""
 
# Test 3: TCP port reachability
echo "--- TCP Port Check ---"
timeout 5 bash -c "echo > /dev/tcp/$HOST/$PORT" 2>/dev/null
if [ $? -eq 0 ]; then
    echo "✓ Port $PORT is reachable"
else
    echo "✗ Port $PORT is not reachable"
fi
echo ""
 
# Test 4: Connection timing
echo "--- Connection Timing ---"
START=$(date +%s.%N)
nc -zvw 10 $HOST $PORT 2>&1
END=$(date +%s.%N)
DURATION=$(echo "$END - $START" | bc)
echo "Connection attempt took: ${DURATION}s"
echo ""
 
# Test 5: Capture analysis hint
echo "--- For deeper analysis, run: ---"
echo "sudo tcpdump -i any host $HOST and port $PORT -nn -c 10"
echo ""
echo "--- Expected packets: ---"
echo "  Client → Server: Flags [S] (SYN)"
echo "  Server → Client: Flags [S.] (SYN+ACK)"
echo "  Client → Server: Flags [.] (ACK)"

Common Issues and Solutions

Issue: Connection Refused Immediately

connect(): Connection refused (ECONNREFUSED)

Cause: Server's kernel sent RST because nothing is listening
Verify: ss -tlnp | grep PORT shows nothing
Solution: Start the server application

Issue: Connection Timeout (Long Delay)

connect(): Connection timed out (ETIMEDOUT)

Cause: SYN packets not receiving response
Possibilities:
- Firewall dropping SYN packets
- Wrong IP address
- Server host down
- SYN queue full (with SYN cookies disabled)
Verify: tcpdump shows SYN sent, no SYN+ACK
Solution: Check firewall rules, verify server state

Issue: Slow Connection (Several Seconds)

Cause A: Packet loss requiring retransmission
- Check: tcpdump shows SYN, delay, SYN retransmit
- Solution: Investigate network path quality
Cause B: High latency path
- Check: ping shows high RTT
- Solution: Normal for distant servers
Cause C: DNS delay before connect()
- Check: strace shows slow gethostbyname()
- Solution: Use IP addresses for testing; fix DNS

Issue: Sporadic Connection Failures

Cause A: Server queue overloaded
- Check: Server's netstat -s shows overflow counters increasing
- Solution: Increase backlog, add SYN cookies, scale server
Cause B: Intermittent network issues
- Check: mtr or traceroute shows packet loss at specific hop
- Solution: Network-level remediation

The tcpdump Revelation

When troubleshooting connection issues, tcpdump is your best friend. Capture on both endpoints if possible. A missing SYN+ACK reveals a server-side or network-side issue. A missing final ACK reveals a client-side issue. Seeing RST reveals a refusal. Seeing nothing reveals a firewall or routing problem.

Summary: SYN_SENT and SYN_RECEIVED States

We've explored the two transitional states of TCP connection establishment—the critical moments where connections are formed but not yet validated.

Key Takeaways

Core Concepts

•SYN_SENT is the client's active open state — Entered when connect() is called, waiting for SYN+ACK.
•SYN_RECEIVED is the server's response state — Entered when a SYN arrives at a listening socket.
•Initial Sequence Numbers must be unpredictable — Cryptographic ISNs prevent session hijacking.
•Retransmission uses exponential backoff — Default ~127 seconds for SYN, ~63 seconds for SYN+ACK.
•Simultaneous open is rare but supported — Both sides can transition through SYN_SENT → SYN_RECEIVED → ESTABLISHED.
•Handshake states are vulnerable — SYN floods target SYN_RECEIVED; reconnaissance targets initial handshake response.
•Debugging requires packet captures — tcpdump reveals exactly where handshake fails.

What's Next

Once the three-way handshake completes successfully, the connection enters the ESTABLISHED state—the stable, data-transfer phase that most developers think of when they think of TCP connections. In the next page, we'll explore what ESTABLISHED means, how data transfer occurs, and the mechanisms that maintain connection health during this phase.

Page Complete

You now understand the SYN_SENT and SYN_RECEIVED states in depth—from the socket API operations that trigger them, through the kernel mechanics of retransmission, to the security implications of these vulnerable transitional states. This knowledge is essential for debugging connection establishment issues and understanding TCP's reliability guarantees.

SYN_SENT and SYN_RECEIVED: The Handshake in Progress

The Critical Moments of Connection Establishment

Learning Objectives

SYN_SENT: The Client's Active Open

The SYN_SENT State Mechanics

Entry Condition:

Application calls connect()
Kernel generates and sends SYN segment
Socket transitions: CLOSED → SYN_SENT

What the SYN Contains:

The initial SYN segment carries crucial information for connection establishment:

Field	Purpose	Example Value
Sequence Number	Client's Initial Sequence Number (ISN)	1234567890
SYN flag	Indicates synchronization request	Set (1)
ACK flag	Not acknowledging anything yet	Clear (0)
Window Size	Client's initial receive window	65535
MSS Option	Maximum Segment Size	1460 bytes
Window Scale Option	Window size multiplier	7 (×128)
SACK Permitted Option	Selective acknowledgments allowed	Present
Timestamps Option	For RTT measurement and PAWS	Present

The ISN Generation Problem

The Initial Sequence Number (ISN) selection is security-critical. Early TCP implementations used predictable ISNs (incrementing clocks), enabling devastating attacks:

The ISN Prediction Attack (Historical):

Attacker observes ISN patterns from legitimate connections
Attacker predicts the server's ISN for a spoofed connection
Attacker sends spoofed SYN with fake source IP
Attacker predicts and sends correct ACK (acknowledging predicted ISN+1)
Connection established with attacker impersonating trusted source

Modern systems use cryptographically random ISNs:

ISN = hash(source_ip, source_port, dest_ip, dest_port, secret_key, timestamp)

This makes prediction virtually impossible while still ensuring ISNs don't repeat during the Maximum Segment Lifetime (MSL).

Converting Mermaid diagram...

Exit Conditions from SYN_SENT

Normal Success Path:

Receive SYN+ACK from server
Validate that ACK acknowledges our SYN (ack = our_ISN + 1)
Send ACK for server's SYN (our ack = server_ISN + 1)
Transition to ESTABLISHED state
Unblock the connect() call (return success to application)

Timeout Path:

No SYN+ACK received within timeout period
Retransmit SYN (exponential backoff: 1s, 2s, 4s, 8s, ...)
After tcp_syn_retries attempts (default: 6), give up
Transition to CLOSED
Return error to application (ETIMEDOUT)

Reset Path:

Receive RST from server (port not listening, connection refused)
Immediately transition to CLOSED
Return error to application (ECONNREFUSED)

Simultaneous Open Path (Rare):

Receive SYN (without ACK) from the peer
Both sides sent SYN at approximately the same time
Transition to SYN_RECEIVED (will discuss later)

syn_sent_timing.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
/**
 * Understanding SYN_SENT behavior in practice
 * Demonstrates timeouts and connection failure scenarios
 */
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <stdio.h>
#include <errno.h>
#include <time.h>
#include <unistd.h>
 
int main() {
    int sockfd;
    struct sockaddr_in server_addr;
    time_t start, end;
 
    sockfd = socket(AF_INET, SOCK_STREAM, 0);
    
    // Connect to a non-existent or firewalled host
    // This will demonstrate SYN_SENT timeout behavior
    server_addr.sin_family = AF_INET;
    server_addr.sin_port = htons(12345);
    inet_pton(AF_INET, "192.0.2.1", &server_addr.sin_addr);  // TEST-NET-1
 
    printf("Attempting connection (socket enters SYN_SENT)...\n");
    start = time(NULL);
 
    int result = connect(sockfd, 
                         (struct sockaddr *)&server_addr, 
                         sizeof(server_addr));
 
    end = time(NULL);
 
    if (result < 0) {
        printf("Connection failed after %ld seconds\n", end - start);
        
        switch (errno) {
            case ETIMEDOUT:
                printf("Error: ETIMEDOUT - SYN retries exhausted\n");
                printf("(No SYN+ACK received; host may be unreachable)\n");
                break;
            case ECONNREFUSED:
                printf("Error: ECONNREFUSED - Received RST\n");
                printf("(Server not listening on that port)\n");
                break;
            case ENETUNREACH:
                printf("Error: ENETUNREACH - Network unreachable\n");
                printf("(No route to destination)\n");
                break;
            case EHOSTUNREACH:
                printf("Error: EHOSTUNREACH - Host unreachable\n");
                printf("(ICMP host unreachable received)\n");
                break;
            default:
                perror("connect");
        }
    } else {
        printf("Connection established in %ld seconds\n", end - start);
    }
 
    close(sockfd);
    return 0;
}

Reducing Connection Timeout Delay

SYN_RECEIVED: The Server's Response

The SYN_RECEIVED State Mechanics

Entry Conditions:

From State	Trigger	Action
LISTEN	Receive valid SYN	Create request_sock, send SYN+ACK
SYN_SENT	Receive SYN (no ACK)	Simultaneous open; send SYN+ACK

What the SYN+ACK Contains:

The server's response acknowledges the client's SYN and sends its own:

Field	Value	Purpose
Sequence Number	Server's ISN	Initiating server's sequence space
ACK Number	Client's ISN + 1	Acknowledging client's SYN
SYN flag	Set	Synchronizing server's sequence
ACK flag	Set	Acknowledging client's SYN
MSS Option	Server's MSS	May differ from client's
Window Scale	Server's value	If client offered it
SACK Permitted	Present	If client offered it

The Request Socket (Mini-Socket)

In modern implementations (Linux, Windows), the server doesn't create a full socket for each SYN. Instead, it creates a lightweight request socket (or connection request block):

// Simplified Linux request_sock structure
struct request_sock {
    struct sock_common          __req_common;
    struct request_sock         *dl_next;      // Queue linkage
    
    u32                         rcv_isn;       // Client's ISN
    u32                         snt_isn;       // Our ISN
    u16                         mss;           // Negotiated MSS
    u8                          num_retrans;   // SYN+ACK retries
    u8                          syncookie:1;   // Created via SYN cookie?
    
    struct timer_list           rsk_timer;     // Retransmission timer
};

The SYN_RECEIVED State Timeline

                     Time
                       │
    Server receives    │
    SYN from client    ▼
    ─────────────────────
                       │
    Create request_sock│
    Send SYN+ACK       │
    Start timer        │────────────────────────┐
    (Enter SYN_RCVD)   │                        │
                       │                        │
                       │  Timer expires?        │ Waiting for
                       │  Resend SYN+ACK        │ client's ACK
                       ├────────────────────────┤
                       │  Timer expires again?  │
                       │  Resend SYN+ACK        │
                       ├────────────────────────┤
                       │                        │
    Receive ACK ─────▶ │  Validate ACK          │
                       │  Create full socket    │
                       │  Move to accept queue  │
                       │  (Enter ESTABLISHED)   │
    ─────────────────────
                       │
    App calls accept() │
    Returns new fd     ▼

Exit Conditions from SYN_RECEIVED

Normal Success Path:

Receive valid ACK from client (ack = our_ISN + 1)
Promote request_sock to full socket
Move to accept queue
Transition to ESTABLISHED

Timeout Path:

No ACK received within timeout
Retransmit SYN+ACK (up to tcp_synack_retries times)
After exhausting retries, destroy request_sock
Connection attempt silently dropped

Reset Path:

Receive RST from client
Destroy request_sock immediately
Log event (depending on configuration)

SYN_RECEIVED is Inherently Vulnerable

SYN Queue vs Accept Queue
Aspect	SYN Queue	Accept Queue
Contains	Connections in SYN_RECEIVED	Connections in ESTABLISHED
Data structure	Hash table or list	Queue (FIFO)
Entry size	~100-200 bytes (request_sock)	~1-2 KB (full socket)
Controlled by	tcp_max_syn_backlog sysctl	backlog parameter + somaxconn
Overflow action	Drop SYN or use SYN cookies	Drop completed connection
Attacker target	SYN flood attack	slowloris/accept exhaustion

Retransmission During Handshake

SYN Retransmission (Client Side)

When a client sends a SYN and receives no SYN+ACK:

Attempt  │  Delay    │  Cumulative
─────────┼───────────┼─────────────
   1     │   0s      │    0s        (initial SYN)
   2     │   1s      │    1s        (1st retry)
   3     │   2s      │    3s        (2nd retry)
   4     │   4s      │    7s        (3rd retry)
   5     │   8s      │   15s        (4th retry)
   6     │  16s      │   31s        (5th retry)
   7     │  32s      │   63s        (6th retry)
  Fail   │  64s      │  127s        (give up)

Controlled by: net.ipv4.tcp_syn_retries (default: 6)

Total timeout ≈ 127 seconds before the connect() call returns ETIMEDOUT.

SYN+ACK Retransmission (Server Side)

When a server sends SYN+ACK and receives no ACK:

Attempt  │  Delay    │  Cumulative
─────────┼───────────┼─────────────
   1     │   0s      │    0s        (initial SYN+ACK)
   2     │   1s      │    1s        (1st retry)
   3     │   2s      │    3s        (2nd retry)
   4     │   4s      │    7s        (3rd retry)
   5     │   8s      │   15s        (4th retry)
   6     │  16s      │   31s        (5th retry)
  Drop   │           │   ~63s       (destroy request_sock)

Controlled by: net.ipv4.tcp_synack_retries (default: 5)

The request_sock is destroyed after approximately 63 seconds of no response.

tune_handshake_retries.sh
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
#!/bin/bash
# Tuning TCP handshake retransmission parameters
 
# View current settings
echo "Current SYN retry settings:"
sysctl net.ipv4.tcp_syn_retries
sysctl net.ipv4.tcp_synack_retries
 
# For faster failure detection (client side)
# Reduce SYN retries from default 6 to 2
# Total timeout: ~7 seconds (1 + 2 + 4)
sudo sysctl -w net.ipv4.tcp_syn_retries=2
 
# For faster cleanup of dead connections (server side)
# Reduce SYN+ACK retries from default 5 to 2
# Dead connections cleaned up in ~7 seconds
sudo sysctl -w net.ipv4.tcp_synack_retries=2
 
# ⚠️ Warning: Lower values mean faster failure detection
#    but also less tolerance for packet loss and latency.
#    For high-latency networks (satellite, intercontinental),
#    keep defaults or even increase.
 
# Make changes persistent
echo "net.ipv4.tcp_syn_retries = 2" >> /etc/sysctl.d/99-tcp-tuning.conf
echo "net.ipv4.tcp_synack_retries = 2" >> /etc/sysctl.d/99-tcp-tuning.conf

Why Exponential Backoff?

The exponential backoff pattern (1s, 2s, 4s, 8s, ...) serves multiple purposes:

Congestion Control: If packets are being lost due to network congestion, aggressive retransmission would worsen the congestion. Backing off gives the network time to recover.
Resource Conservation: Constant retransmission wastes CPU and bandwidth on both endpoints.
Diverse Network Conditions: The increasing delays accommodate networks with vastly different characteristics—from local networks (ms latency) to satellite links (600ms+ RTT).
Attack Mitigation: Rapid retransmission would amplify DDoS attack traffic.

Packet Loss Scenarios

Lost Packet	Effect	Recovery
Initial SYN	Client retransmits	1s delay minimum
SYN+ACK	Server retransmits	1s delay minimum
Final ACK	Server retransmits SYN+ACK	1s delay; client re-ACKs
Initial SYN (to wrong port)	Immediate RST	No delay (ECONNREFUSED)
Initial SYN (firewalled)	No response	Full timeout (127s default)

The "Connection Timeout" Hierarchy

Applications may implement multiple timeout layers:

Layer           │ Typical Value    │ Control
────────────────┼──────────────────┼─────────────────────
Kernel SYN      │ 127 seconds      │ tcp_syn_retries
Socket timeout  │ 30 seconds       │ SO_SNDTIMEO / alarm()
Application     │ 5-10 seconds     │ Application logic
User interface  │ 3-5 seconds      │ UX design

Best practice: Set application-level timeouts shorter than kernel timeouts to maintain responsiveness.

Non-Blocking Connect for Fast Timeouts

Simultaneous Open: The Four-Way Handshake

How Simultaneous Open Occurs

For simultaneous open to occur, the following must happen:

Both endpoints have sockets bound to known ports
Both endpoints call connect() at approximately the same time
Each endpoint's SYN reaches the other before its own SYN+ACK is sent

    Host A                           Host B
      │                                │
      │  connect() called              │  connect() called
      │  Send SYN (seq=100)            │  Send SYN (seq=300)
      │═════════════════════════════▶  │
      │  ◀═════════════════════════════│
      │                                │
  SYN crosses SYN in transit           │
      │                                │
  Receive SYN        Receive SYN       │
  (no ACK bit)       (no ACK bit)      │
      │                                │
  Enter SYN_RECEIVED                   │  Enter SYN_RECEIVED
  Send SYN+ACK       Send SYN+ACK      │
      │═════════════════════════════▶  │
      │  ◀═════════════════════════════│
      │                                │
  Receive SYN+ACK    Receive SYN+ACK   │
  Enter ESTABLISHED  Enter ESTABLISHED │

The State Transitions

In simultaneous open, both endpoints follow this path:

CLOSED → SYN_SENT → SYN_RECEIVED → ESTABLISHED

This is unlike normal connection where:

Client: CLOSED → SYN_SENT → ESTABLISHED
Server: LISTEN → SYN_RECEIVED → ESTABLISHED

The key insight: when a socket in SYN_SENT receives a SYN (without ACK), it knows a simultaneous open is occurring and transitions to SYN_RECEIVED rather than ESTABLISHED.

Converting Mermaid diagram...

Practical Occurrence

Simultaneous open is rare in practice because:

Asymmetric design: Most applications use client-server model where one side listens and one connects.
Timing requirements: Both SYNs must be in flight simultaneously, which requires very precise timing or high latency.
Known ports: Both sides must know each other's port in advance to connect().

However, simultaneous open can occur in:

Peer-to-peer applications: Where both peers try to initiate connection
NAT traversal techniques: UDP hole punching adapted for TCP
Testing/debugging scenarios: Intentionally triggering the behavior

Why TCP Supports This

Verification Code

simultaneous_open_test.py
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
"""
Demonstrating TCP simultaneous open
Requires precise timing and works best on local machine
 
Run two instances of this script with opposite port assignments:
  Instance 1: MY_PORT=50000, PEER_PORT=50001
  Instance 2: MY_PORT=50001, PEER_PORT=50000
 
Both will connect() to each other simultaneously.
"""
 
import socket
import time
import threading
 
MY_PORT = 50000
PEER_PORT = 50001
PEER_IP = "127.0.0.1"
 
def attempt_simultaneous_open():
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    
    # Must bind to known port so peer can connect to us
    sock.bind(('', MY_PORT))
    
    # Wait for synchronization (in real scenario, use external sync)
    time.sleep(1)
    print(f"Attempting simultaneous open to {PEER_IP}:{PEER_PORT}")
    
    # Note: Normal connect() on bound socket
    # If peer also Connect()s at same time, simultaneous open occurs
    try:
        sock.connect((PEER_IP, PEER_PORT))
        print("Connection established via simultaneous open!")
        
        # Verify we're connected
        local = sock.getsockname()
        remote = sock.getpeername()
        print(f"Local: {local}, Remote: {remote}")
        
    except socket.timeout:
        print("Connection timed out (peer may not have connected)")
    except Exception as e:
        print(f"Error: {e}")
    finally:
        sock.close()
 
if __name__ == "__main__":
    attempt_simultaneous_open()

Historical Significance

Security Considerations During Handshake

The SYN_SENT and SYN_RECEIVED states represent a window of vulnerability. The connection exists but is not yet validated—creating opportunities for attacks, reconnaissance, and denial of service.

Attack Vectors Targeting Handshake States

1. SYN Flood Attack

Target: SYN_RECEIVED state on servers

Attacker sends massive volume of SYN packets
Each SYN creates a request_sock entry
Spoofed source IPs prevent ACK completion
Server's SYN queue fills up
Legitimate connections denied

Mitigations:

SYN cookies (eliminate state for half-open connections)
Increase SYN queue size
Reduce SYN+ACK retries
Firewall rate limiting
Cloud DDoS protection

2. ACK Flood Attack

Target: Processing overhead for spurious ACKs

Attacker sends ACK packets with random sequence numbers
Server must look up and validate each ACK
CPU resources consumed even though ACKs are rejected

Mitigations:

SYN cookies (ACKs only valid if cookie matches)
Rate limiting ACKs to non-existent connections
Hardware offload for packet filtering

3. Port Scanning / Reconnaissance

Target: Discovery of listening services

SYN scan: Send SYN, look for SYN+ACK (open) or RST (closed)
Half-open scan: Don't complete handshake (harder to log)
Connect scan: Complete handshake, then close

Mitigations:

Firewall rules restricting port access
Connection logging (even half-open)
Intrusion detection systems (IDS)
Port knocking

4. RST Injection Attack

Target: Disrupting connections during establishment

Attacker guesses sequence numbers
Sends spoofed RST to terminate connections
Easier during handshake (fewer valid sequence numbers)

Mitigations:

TCP timestamps (adds entropy to validation)
Sequence number randomization
TCP-AO (Authentication Option) for critical connections

Handshake Attack Summary
Attack	Target State	Goal	Defense
SYN Flood	SYN_RECEIVED	Exhaust server resources	SYN cookies, queue tuning
ACK Flood	N/A (fake ACKs)	CPU exhaustion	SYN cookies, rate limiting
Port Scan	LISTEN	Reconnaissance	Firewalls, IDS
RST Injection	SYN_SENT/SYN_RECEIVED	Connection termination	Sequence randomization, timestamps
ISN Prediction	SYN_SENT	Session hijacking	Cryptographic ISN

Detecting Handshake Anomalies

Monitoring tools can identify attacks and anomalies:

# Check for SYN flood indicators
netstat -s | grep -i syn

# Example output during attack:
#   23451 SYNs to LISTEN sockets dropped
#   18234 times the listen queue of a socket overflowed
#   521432 SYN cookies sent
#   512891 SYN cookies received

# Monitor in real-time
watch -n1 'ss -tn state syn-recv | wc -l'

# Alert if SYN_RECEIVED count exceeds threshold
SYN_RECV_COUNT=$(ss -tn state syn-recv | wc -l)
if [ $SYN_RECV_COUNT -gt 1000 ]; then
    echo "ALERT: High SYN_RECEIVED count ($SYN_RECV_COUNT)"
fi

Firewall Rules for Handshake Protection

# iptables rules for SYN flood protection

# Limit new connections per source IP
iptables -A INPUT -p tcp --syn -m connlimit \
    --connlimit-above 100 --connlimit-mask 32 \
    -j DROP

# Rate limit SYN packets overall
iptables -A INPUT -p tcp --syn -m limit \
    --limit 100/s --limit-burst 200 \
    -j ACCEPT

# Drop invalid packets (bad flags, wrong sequence)
iptables -A INPUT -m state --state INVALID -j DROP

# Log potential scans
iptables -A INPUT -p tcp --syn -m recent --name portscan \
    --update --seconds 60 --hitcount 10 -j LOG \
    --log-prefix "PORT SCAN DETECTED: "

Defense in Depth

Debugging Connection Establishment Issues

Connection establishment problems manifest in various ways: timeouts, refused connections, slow startups. Understanding the handshake states helps pinpoint the cause.

Diagnostic Approach

Step 1: Identify the Symptom

Symptom	Likely Cause	Check
ECONNREFUSED	RST received	Server not listening
ETIMEDOUT	No SYN+ACK	Firewall, routing, server down
Slow connect	Handshake completing slowly	Latency, packet loss, misconfiguration
Intermittent failure	Overloaded queues	Server queue depths

Step 2: Verify Server is Listening

# On the server
ss -tlnp | grep PORT
lsof -i :PORT

# Expected: LISTEN state socket with correct program

Step 3: Check Network Path

# Can we reach the server?
ping server_ip

# Can we reach the port?
nmap -p PORT server_ip

# Or without nmap:
nc -zv server_ip PORT

Step 4: Capture the Handshake

# Capture TCP handshake packets
tcpdump -i any host server_ip and port PORT -nn

# Expected successful handshake:
# 1. Client → Server: SYN
# 2. Server → Client: SYN+ACK
# 3. Client → Server: ACK

diagnose_connection.sh
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
#!/bin/bash
# Comprehensive TCP connection diagnostic script
 
if [ $# -ne 2 ]; then
    echo "Usage: $0 <host> <port>"
    exit 1
fi
 
HOST=$1
PORT=$2
 
echo "=== TCP Connection Diagnostics ==="
echo "Target: $HOST:$PORT"
echo "Time: $(date)"
echo ""
 
# Test 1: DNS resolution
echo "--- DNS Resolution ---"
if host $HOST > /dev/null 2>&1; then
    echo "✓ DNS resolves: $(host $HOST | head -1)"
else
    echo "✗ DNS resolution failed"
fi
echo ""
 
# Test 2: ICMP connectivity
echo "--- ICMP Connectivity ---"
if ping -c 1 -W 2 $HOST > /dev/null 2>&1; then
    echo "✓ Host responds to ping"
else
    echo "✗ No ping response (may be firewalled)"
fi
echo ""
 
# Test 3: TCP port reachability
echo "--- TCP Port Check ---"
timeout 5 bash -c "echo > /dev/tcp/$HOST/$PORT" 2>/dev/null
if [ $? -eq 0 ]; then
    echo "✓ Port $PORT is reachable"
else
    echo "✗ Port $PORT is not reachable"
fi
echo ""
 
# Test 4: Connection timing
echo "--- Connection Timing ---"
START=$(date +%s.%N)
nc -zvw 10 $HOST $PORT 2>&1
END=$(date +%s.%N)
DURATION=$(echo "$END - $START" | bc)
echo "Connection attempt took: ${DURATION}s"
echo ""
 
# Test 5: Capture analysis hint
echo "--- For deeper analysis, run: ---"
echo "sudo tcpdump -i any host $HOST and port $PORT -nn -c 10"
echo ""
echo "--- Expected packets: ---"
echo "  Client → Server: Flags [S] (SYN)"
echo "  Server → Client: Flags [S.] (SYN+ACK)"
echo "  Client → Server: Flags [.] (ACK)"

Common Issues and Solutions

Issue: Connection Refused Immediately

connect(): Connection refused (ECONNREFUSED)

Cause: Server's kernel sent RST because nothing is listening
Verify: ss -tlnp | grep PORT shows nothing
Solution: Start the server application

Issue: Connection Timeout (Long Delay)

connect(): Connection timed out (ETIMEDOUT)

Cause: SYN packets not receiving response
Possibilities:
- Firewall dropping SYN packets
- Wrong IP address
- Server host down
- SYN queue full (with SYN cookies disabled)
Verify: tcpdump shows SYN sent, no SYN+ACK
Solution: Check firewall rules, verify server state

Issue: Slow Connection (Several Seconds)

Cause A: Packet loss requiring retransmission
- Check: tcpdump shows SYN, delay, SYN retransmit
- Solution: Investigate network path quality
Cause B: High latency path
- Check: ping shows high RTT
- Solution: Normal for distant servers
Cause C: DNS delay before connect()
- Check: strace shows slow gethostbyname()
- Solution: Use IP addresses for testing; fix DNS

Issue: Sporadic Connection Failures

Cause A: Server queue overloaded
- Check: Server's netstat -s shows overflow counters increasing
- Solution: Increase backlog, add SYN cookies, scale server
Cause B: Intermittent network issues
- Check: mtr or traceroute shows packet loss at specific hop
- Solution: Network-level remediation

The tcpdump Revelation

Summary: SYN_SENT and SYN_RECEIVED States

We've explored the two transitional states of TCP connection establishment—the critical moments where connections are formed but not yet validated.

Key Takeaways

Core Concepts

•SYN_SENT is the client's active open state — Entered when connect() is called, waiting for SYN+ACK.
•SYN_RECEIVED is the server's response state — Entered when a SYN arrives at a listening socket.
•Initial Sequence Numbers must be unpredictable — Cryptographic ISNs prevent session hijacking.
•Retransmission uses exponential backoff — Default ~127 seconds for SYN, ~63 seconds for SYN+ACK.
•Simultaneous open is rare but supported — Both sides can transition through SYN_SENT → SYN_RECEIVED → ESTABLISHED.
•Handshake states are vulnerable — SYN floods target SYN_RECEIVED; reconnaissance targets initial handshake response.
•Debugging requires packet captures — tcpdump reveals exactly where handshake fails.

What's Next

Page Complete