How to Trace TCP Socket TCP_INFO tcpi_retrans_synack Path MTU Discovery Black Hole Drops in Linux Using eBPF

In modern enterprise networks and cloud transit gateways, Path MTU Discovery (PMTU) black holes present severe diagnostic challenges. When middleboxes or security appliances drop ICMP Fragmentation Needed packets (Type 3, Code 4) without forwarding them to the server, oversized packets cannot traverse downstream links. During TCP handshake completion, if options headers or initial window payloads exceed path MTU limits without receiving ICMP notifications, the server experiences repeated SYN-ACK timeouts, tracked inside tcpi_retrans_synack. Extended Berkeley Packet Filter (eBPF) provides kernel-level visibility into these silent drop conditions.

Understanding Path MTU Black Holes During Connection Handshakes

When a client initiates a connection, the server selects an initial maximum segment size (MSS) based on local interface MTU and client advertised MSS. If an intermediate tunnel or carrier network enforces a lower MTU (such as 1420 bytes on GRE or IPsec overlays) and drops oversized segments while suppressing ICMP unreachable signals, the handshake stalls. The kernel continues retransmitting SYN-ACK packets via inet_rtx_syn_ack(). Tracing kernel MTU clamping decisions alongside socket retransmissions uncovers black hole paths directly.

Constructing the bpftrace PMTU Black Hole Monitor

The following bpftrace script captures SYN-ACK retransmission attempts and checks the socket route MTU metrics:

#!/usr/bin/env bpftrace

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

BEGIN
{
  printf("Tracing PMTU black hole handshake drops... Hit Ctrl-C to finish.
");
}

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

  if ($retries >= 2) {
    printf("[%s] Persistent SYN-ACK RTX (Potential PMTU Black Hole) -> %s:%d [Attempts: %d]
",
      strftime("%H:%M:%S", nsecs), $daddr, $dport, $retries);
    @pmtu_suspect_hosts[$daddr] = count();
  }
}

interval:s:15
{
  time("%H:%M:%S ");
  printf("--- Suspected PMTU Black Hole Destinations ---
");
  print(@pmtu_suspect_hosts);
  clear(@pmtu_suspect_hosts);
}

END
{
  clear(@pmtu_suspect_hosts);
}

Running and Interpreting Kernel Diagnostics

Run the script on the target Linux host with administrative privileges:

sudo bpftrace synack_pmtu_drops.bt

When MTU black holes impede completion, the diagnostic console prints suspected destinations:

[17:02:10] Persistent SYN-ACK RTX (Potential PMTU Black Hole) -> 203.0.113.118:49210 [Attempts: 2]
17:02:25 --- Suspected PMTU Black Hole Destinations ---
@pmtu_suspect_hosts[203.0.113.118]: 7

Remediation Strategies and Configuration Auditing

To resolve and bypass Path MTU Discovery black holes in Linux:

• Enable TCP MTU Probing: Configure net.ipv4.tcp_mtu_probing = 1 or 2 in /etc/sysctl.conf to automatically step down packet sizing upon persistent loss.
• MSS Clamping at Border: Implement iptables or nftables MSS clamping: iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu.
• Audit Intermediate Firewalls: Ensure security middleboxes do not drop ICMP Type 3 Code 4 datagrams.