From 33092ffe8ee5fb5f7c080a44831e5557b63deb63 Mon Sep 17 00:00:00 2001 From: bitflash Date: Tue, 18 Aug 2026 10:24:01 -0300 Subject: net: exempt loopback from the per-IP connection cap Review follow-up. A managed-Tor node receives every inbound onion peer over its local hidden-service listener, so they all accept as 127.0.0.1. Capping loopback would cap onion peers as one group and refuse the 33rd legitimate onion peer -- the wrong limit for a network moving toward onion-only. Exempt loopback (127.0.0.0/8): the global MAX_CONNECTIONS still bounds the total, and the direct-IP flood this defends against never arrives over loopback. Bench: a 40-connection flood from 127.0.0.1 is now held in full (no per-IP refusal), while a flood from the machine's LAN address still caps at exactly 32. --- src/net.h | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'src/net.h') diff --git a/src/net.h b/src/net.h index 4fdd1b3..e3d4a93 100644 --- a/src/net.h +++ b/src/net.h @@ -119,6 +119,14 @@ static const unsigned int MAX_CONNECTIONS = 125; // needs only a handful; 32 leaves generous room while denying any one address // more than a quarter of the table. The firewall connlimit on the relays does // the same thing a layer lower; this makes every build carry the defense. +// +// Loopback (127.0.0.0/8) is exempt in the accept path. A managed-Tor node +// receives every inbound onion peer over its local hidden-service listener, so +// they all appear as 127.0.0.1 -- capping loopback would cap onion peers as a +// group, which is exactly wrong for a network moving toward onion-only. The +// global MAX_CONNECTIONS still bounds the total; a per-onion-identity limit, +// applied once identity is known after accept(), is the right future tool for +// onion floods. static const unsigned int MAX_CONNECTIONS_PER_IP = 32; // A node marked for disconnect is normally held until its buffers drain, so -- cgit v1.2.3