How to Trace TCP Socket TCP_INFO tcpi_retrans_synack Drop Rates in Linux Using eBPF

In high-concurrency Linux web servers and load balancers, handshake performance directly dictates connection establishment latency. When SYN-ACK packets dispatched by the server fail to receive an acknowledgment or are dropped in flight by downstream middleboxes, the kernel’s TCP stack retransmits the response, tracking cumulative attempts in tcpi_retrans_synack. By deploying non-invasive extended Berkeley Packet Filter (eBPF) tracing scripts, system administrators can measure SYN-ACK drop rates at wire speed without introducing system call overhead.

Mechanisms of SYN-ACK Retransmission and Drop Counters

Upon receiving a valid SYN packet, the kernel creates an entry in the half-open connection table and issues a SYN-ACK via inet_rtx_syn_ack(). If client acknowledgment does not occur before the exponential backoff timer elapses, the counter increments. High drop rates generally correlate with asymmetric routing changes, packet filter drops, MTU black holes, or transient saturation in internet service provider (ISP) peering points.

Constructing the bpftrace Drop Rate Monitor

The following bpftrace script hooks into inet_rtx_syn_ack to sample drop frequencies, grouping by destination subnet and logging drop percentages across 10-second intervals:

#!/usr/bin/env bpftrace

#include <net/sock.h>
#include <net/inet_connection_sock.h>

BEGIN
{
  printf("Tracing SYN-ACK retransmission drop rates... Hit Ctrl-C to finish.
");
}

kprobe:inet_rtx_syn_ack
{
  $req = (struct request_sock *)arg1;
  $daddr = ntop($req->ir_rmt_addr);
  $retries = $req->num_retrans;

  // Track retry counts per client
  @synack_retries_total = count();
  @synack_by_destination[$daddr] = count();
  
  if ($retries >= 2) {
    @severe_synack_drops[$daddr] = count();
  }
}

interval:s:10
{
  time("%H:%M:%S ");
  printf("--- SYN-ACK Activity (Last 10s) ---
");
  print(@synack_retries_total);
  print(@severe_synack_drops);
  clear(@synack_retries_total);
  clear(@severe_synack_drops);
}

END
{
  clear(@synack_by_destination);
}

Running and Interpreting Kernel Measurements

Execute the tracing probe with root access on the target server:

sudo bpftrace synack_drop_rate.bt

The diagnostic stream periodically outputs accumulated drops:

16:44:10 --- SYN-ACK Activity (Last 10s) ---
@synack_retries_total: 124
@severe_synack_drops[198.51.100.22]: 15
@severe_synack_drops[203.0.113.41]: 8

Remediation and Kernel Tuning Best Practices

To mitigate the impact of persistent SYN-ACK loss on server socket allocation:

• Adjust SYN-ACK Retries: Configure net.ipv4.tcp_synack_retries = 3 to free request sockets earlier when clients fail to respond.
• Verify TCP Timestamps: Ensure net.ipv4.tcp_timestamps = 1 is enabled to support accurate round-trip time calculations and PAWS protection.
• Inspect Firewall State Tables: Verify that intermediate connection-tracking tables (e.g. conntrack) are not dropping state entries prematurely.