Analyzing TCP Connection Queue Overflows Using netstat and Linux Kernel Source

In this technical note, the author revisits the interpretation of netstat -s output for detecting TCP connection queue overflows, correcting common misconceptions about the meaning of the SYN drop counters for both full and half‑connection queues.

Full‑connection queue overflow detection

The kernel increments the MIB counters LINUX_MIB_LISTENOVERFLOWS and LINUX_MIB_LISTENDROPS when the accept queue is full, which appear in SNMP as ListenOverflows and ListenDrops . The relevant source snippets are:

// file: net/ipv4/tcp_ipv4.c
int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb) {
    // ... check half‑connection queue ...
    // check full‑connection queue
    if (sk_acceptq_is_full(sk) && inet_csk_reqsk_queue_young(sk) > 1) {
        NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_LISTENOVERFLOWS);
        goto drop;
    }
    // ...
    drop:
    NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_LISTENDROPS);
    return 0;
}

When the full queue overflows, the ListenOverflows counter increases, and the same counter is also raised during the third‑handshake processing if the queue is still full.

The SNMP table that exposes these counters is defined in net/ipv4/proc.c :

// file: net/ipv4/proc.c
static const struct snmp_mib snmp4_net_list[] = {
    SNMP_MIB_ITEM("ListenDrops", LINUX_MIB_LISTENDROPS),
    SNMP_MIB_ITEM("ListenOverflows", LINUX_MIB_LISTENOVERFLOWS),
    // ...
};

netstat tool source

The netstat -s command reads these SNMP entries. Its implementation (in the net‑tools repository) maps the counters to human‑readable strings:

// file: https://github.com/giftnuss/net-tools/blob/master/statistics.c
struct entry Tcpexttab[] = {
    { "ListenDrops", N_("%u SYNs to LISTEN sockets dropped"), opt_number },
    { "ListenOverflows", N_("%u times the listen queue of a socket overflowed"), opt_number },
    // ...
};

Thus, observing a growing value for “xx times the listen queue of a socket overflowed” reliably indicates a full‑connection queue overflow.

Half‑connection queue overflow detection

When the half‑connection (SYN‑RECV) queue is full, the kernel increments LINUX_MIB_LISTENDROPS , which also appears as ListenDrops . However, this counter is also increased in other situations (e.g., full‑connection overflow or handshake errors), making it unreliable for half‑queue monitoring.

The relevant code path is:

// file: net/ipv4/tcp_ipv4.c
int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb) {
    // check half‑connection queue
    if (inet_csk_reqsk_queue_is_full(sk) && !isn) {
        want_cookie = tcp_syn_flood_action(sk, skb, "TCP");
        if (!want_cookie)
            goto drop;
    }
    // ... check full‑connection queue ...
    drop:
    NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_LISTENDROPS);
    return 0;
}

Because ListenDrops is not exclusive to half‑queue overflow, the author recommends checking the kernel parameter tcp_syncookies . If it is set to 1, half‑queue overflows will not cause packet loss.

When tcp_syncookies is disabled, a practical way to verify half‑queue pressure is to monitor the number of sockets in the SYN_RECV state:

# netstat -antp | grep SYN_RECV

Comparing this count with the calculated half‑queue length (as described in the linked article about why servers must listen first) tells you whether the half‑queue is saturated.

Summary

For full‑connection queues, repeatedly running watch 'netstat -s | grep overflowed' and watching the “times the listen queue of a socket overflowed” metric provides a reliable indication of overflow and packet loss.

For half‑connection queues, ensure tcp_syncookies=1 to prevent loss; otherwise, combine netstat -s with SYN_RECV counts and the calculated queue size to assess overflow.

Additional details on enlarging the half‑connection queue are available in the referenced article “Why server programs must listen first?”.