Hi all, We're running FreeRADIUS 3.x as a RadSec terminator (TLS/TCP on port 2083) in a Linux container, and we hit a hard ceiling at ~505 concurrent TLS connections. Looking for guidance on the recommended path forward. *Symptom (full logs attached):* Every new connection above ~505 is rejected. *Root cause: *The #ifndef HAVE_KQUEUE branch in event.c uses select() + fd_set. On glibc, FD_SETSIZE and __FD_SETSIZE are hard-coded to 1024 in <bits/typesizes.h>, and sizeof(fd_set) is 128 bytes (1024 bits). Since each RadSec peer holds a persistent TCP FD, we run out at ~1000. *What we tried (none of it gets past 1024):* 1. Raised FR_EV_MAX_FDS 512 → 2048 (event.c) 2. Raised MAX_SOCKETS 1024 → 2048 (packet.c) 3. Added -DFD_SETSIZE=65536 to CFLAGS — verified as a no-op: glibc redefines 4. FD_SETSIZE back to 1024 in <sys/select.h>, and sizeof(fd_set) stays 128 bytes 5. Raised ulimit -n / LimitNOFILE to 65536 6. Raised max_connections on the listener and per client *Questions:* 1. Is there any supported way on v3.x to use an event backend other than select() on Linux? I see the kqueue branch but no epoll branch. 2. Does upgrading to v4 solve this — i.e., can v4 handle 5k–10k concurrent RadSec sessions on Linux out of the box? 3. Would an epoll backend patch for v3 (new #elif defined(HAVE_EPOLL) branch in event.c, replacing fd_set with an fd-indexed array) be of interest upstream, or is that out of scope for v3 maintenance? 4. Any deployment patterns people use to stretch v3 further, beyond tight idle_timeout / lifetime / cleanup_delay and sharding across multiple FR instances? *Environment:* - FreeRADIUS 3.x (event.c commit 92ab704b) - Linux, glibc (Debian-based container), Kubernetes - Single radiusd process, multi-threaded - TLS listener on 0.0.0.0:2083, virtual-server=radius-tls - ~1000 long-lived RadSec sessions at steady state - Container confirms __FD_SETSIZE=1024, sizeof(fd_set)=128 Logs attached. Any pointers appreciated. Thanks, Tayyab Elahi