The Flood Below Tor: TCP Listener Pressure During the DoS
Part 4 of a five-part series on the June–July 2026 circuit-building DoS. 1. The Tor Network’s Circuit-Building DoS Wave in June–July 2026 — the network-wide view from Tor's public data. 2. Anatomy of the Attack — the four periods of elevated signals. 3. What It Actually Costs — the CPU and memory bill, and the public comparisons. 4. The Flood Below Tor (you are here) — TCP listener pressure beneath Tor. 5. Defending Against Circuit-Building DoS — better metrics and the protocol fixes we're asking for.
Correction — October 20, 2026. We previously described ListenDrops as completed connections and used it to calculate connection-loss percentages. Those interpretations were wrong. The charts and event counts below have been recalculated from historical metrics with explicit windows and coverage. This correction adds no October traffic data.
Everything in the earlier posts happened inside Tor — circuits, handshakes, DoS counters, memory. This post is about what was happening underneath it. From June 26 to July 11, the available data from 1AEO's monitored hosts contain an estimated 1.28 billion TCP listener-drop events. These are not unique completed connections: a single attempt can contribute repeated events and later succeed. Tor's own counters do not record traffic discarded before accept().
What Is an Accept Queue? #
The accept queue holds connections waiting for the application to collect them with accept(). If arrivals outrun acceptance, the queue fills. Linux can then discard incoming traffic, including SYNs whose handshake has not completed. ListenOverflows records accept-queue overflow events; ListenDrops also includes other listener drops, such as allocation failures. Retransmitted packets can be counted again. Neither counter counts distinct connections. See the Linux counter definitions.
A Billion Listener-Drop Events #
The recalculated window is June 26, 00:00 UTC to July 11, 00:00 UTC, ending before the maintenance day. Summed over available host data, ListenDrops averaged 985 events per second, with a half-hour peak of 2,576/s and an estimated total of 1.28 billion events. Three to seven of the seven selected hosts contributed to each interval; missing host intervals are not filled. This is a new calculation with stated boundaries, not an exact reproduction of the original 1.3-billion estimate.
Listener pressure was visible on June 21–24, before the June 25, 23:00 UTC circuit-counter onset in the anatomy post, and remained elevated at the end of this chart on July 14. The earlier timing does not establish a separate campaign or a common attacker. The July 11 maintenance day is shown separately because our restarts also generate reconnect activity.
Kernel Events and Tor Connections Measure Different Things #
The old chart treated PassiveOpens as connections accepted by Tor. It is a kernel passive-open counter, not an application accept() count. Adding it to ListenDrops does not measure distinct offered connections, and dividing drops by that sum does not measure a connection-loss percentage. We withdraw the claims of doubled offered load, 35–46% connection loss and half-hour losses above 70%. The replacement chart shows the counters separately.
TCPSynRetrans also increased during this period. It records these hosts' local SYN/SYN-ACK retransmission activity, not retries arriving from remote clients. The counter does not identify unique affected users or prove what they experienced. The former six-to-seven-and-a-half-fold claim used an unrecovered baseline and is not carried into this recalculation.
What It Is — and Isn't #
- SYN flooding is not ruled out. The available
SyncookiesSentrates were zero during June 26–July 11, but not throughout the full June–July chart. Zero cookies does not prove handshake completion: cookie generation depends on kernel configuration and SYN-backlog conditions. The recalculatedListenOverflowsevent total is 99.87% ofListenDropsover the same available intervals, consistent with accept-queue pressure. Both counters can rise for discarded SYNs. - Connection tracking is a separate resource. Our July investigation reported no conntrack exhaustion on the monitored hosts. Listener counters alone cannot establish that conclusion; it depends on the host configuration and conntrack observations at the time.
- Kernel counters are independent of Tor's gauge. Listener events occur below Tor. The connection-gauge accounting problem is separate and does not explain away kernel listener pressure.
- CPU pressure can delay acceptance. Tor accepts sockets on its main loop while workers perform circuit handshakes. Our July investigation observed full accept queues on busy relay processes. That is consistent with arrivals outpacing acceptance under load; aggregate counters do not isolate the cause of every drop. The earlier per-thread scheduling claim and loss-fraction comparison around July 11 are not established by these metrics.
Why Tor's Defenses Can't See This #
Tor's connection defenses act after the kernel hands it a socket. They cannot count listener drops before accept(). Our earlier comparison of a reported 27.6 million Tor rejections with roughly 40 times as many kernel-dropped connections mixed different event populations; we withdraw that comparison. Aggregate counters also do not identify a source-pool size or establish that every source stayed below a per-source limit. The defenses post discusses proposals for controlling aggregate load.
Check Your Own Relays #
Every operator can read these cumulative Linux counters. Compare absolute snapshots over time and check for reboots or network-namespace resets:
# absolute listener-event counters; compare snapshots over time
watch -n5 "nstat -az 2>/dev/null | grep -E 'ListenOverflows|ListenDrops'"
# log a UTC-timestamped series (every 30s) — useful for cross-operator comparison
while :; do echo "$(date -u +%FT%TZ) $(nstat -az 2>/dev/null | awk '/ListenDrops/{print $2}')"; sleep 30; done
# zero SYN cookies does not rule out SYN flooding
nstat -az | grep -Ei 'Listen|Syncookie'Elevated ListenDrops warrants checking listener queues, CPU scheduling, memory and kernel configuration. Similar counters on another network do not by themselves identify the same attack. UTC-timestamped comparisons and maintenance records can help test whether pressure coincides across operators. Get in touch.
How We Measured #
We re-queried the historical node_exporter counters on October 20, 2026. The charts cover June 1, 00:00 through July 14, 00:00 UTC. Each point sums per-host rate(counter[30m]), evaluated every 30 minutes, with at least 15 samples, a last sample less than 180 seconds old, and a successful target scrape. No duplicate host series were present. All 720 half-hour slots in the June 26–July 11 statistics window had data, but only 331 had all seven hosts. The event estimate integrates those available rates; it does not fill missing hosts or reuse the original maintenance mask.
These are network-namespace counters, not per-port Tor measurements. The historical July 1 inventory includes Linux 6.8–6.17 kernel families and node_exporter 1.7.0/1.9.0. The Linux listen path and retransmission path establish the counter meanings. The measurements are aggregate; no packet captures or source-address records were used.