On Apr 22, 2026, at 6:37 AM, Tayyab Elahi <tayyab.elahi@emumba.com> wrote:
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.
For one, please don't send 600Kb logs to the list. No one is going to read all of that. The debug output is supposed to be used to debug policies for a few packets. It's not supposed to be used to show "here's 1000 packets, all showing exactly the same problem"
*Symptom (full logs attached):* Every new connection above ~505 is rejected.
You don't need to show 500 connection attempts in the logs.
*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.
Yes.
*What we tried (none of it gets past 1024):*
The 1024 limit is imposed by glibc. You can't work around it by changing FreeRADIUS.
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.
You can install libkqueue for Linux, and use that: http://packages.networkradius.com/extras/ubuntu/noble Or, supply patches to use epoll().
2. Does upgrading to v4 solve this — i.e., can v4 handle 5k–10k concurrent RadSec sessions on Linux out of the box?
v4 requires libkqueue. Among other things, it's API is a lot simpler than epoll.
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?
If the patch is small, we'll take it seriously. If it deletes existing code or makes massive changes, it's a lot harder to integrate. i.e. we can't break peoples existing networks in order to add a feature that other people want.
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
You likely want to close connections which aren't used. That will help a little bit. Alan DeKok.