It appears the debugging switches don't work quite as I'd expect in FreeRADIUS 3 when RadSec is configured. # radiusd -fxx -l stdout Works as expected (threaded debugging with no timestamps), however: # radiusd -fXx -l stdout <snip> Wed Oct 9 14:44:18 2013 : Error: /opt/freeradiuss/etc/raddb/sites-enabled/tls[7]: Threading must be enabled for TLS sockets to function properly. Wed Oct 9 14:44:18 2013 : Error: /opt/freeradiuss/etc/raddb/sites-enabled/tls[7]: You probably need to do 'radiusd -fxx -l stdout' for debugging '-fXxx -l stdout' reacts in the same way, but '-fxxx -l stdout' does run and produce timestamps, so I think this one is just a documentation issue - I can't find anything doc/ that says xxx is a valid combination. radiusd --help also indicates that -fXx should still be valid. Similarly, when doing a config check: # ./sbin/radiusd -Cfxx -l stdout <snip> /opt/freeradiuss/etc/raddb/sites-enabled/tls[7]: Threading must be enabled for TLS sockets to function properly. /opt/freeradiuss/etc/raddb/sites-enabled/tls[7]: You probably need to do 'radiusd -fxx -l stdout' for debugging The init scripts for debian (possibly RHEL too) trigger the latter one, as it runs a config check on restart (which bails out due to the error above). Regards, Adam Bishop gpg: 0x6609D460 Janet, the UK's research and education network. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238
Adam Bishop wrote:
It appears the debugging switches don't work quite as I'd expect in FreeRADIUS 3 when RadSec is configured.
Yes. Because of OpenSSL limitations, the server MUST have multiple threads when using radsec.
# radiusd -fxx -l stdout
Works as expected (threaded debugging with no timestamps), however:
# radiusd -fXx -l stdout <snip> Wed Oct 9 14:44:18 2013 : Error: /opt/freeradiuss/etc/raddb/sites-enabled/tls[7]: Threading must be enabled for TLS sockets to function properly. Wed Oct 9 14:44:18 2013 : Error: /opt/freeradiuss/etc/raddb/sites-enabled/tls[7]: You probably need to do 'radiusd -fxx -l stdout' for debugging
So... what's wrong with following that documentation?
'-fXxx -l stdout' reacts in the same way,
Because the "-X" means "-f", which is invalid for radsec.
but '-fxxx -l stdout' does run and produce timestamps,
Which is what the error message says to use. What's wrong with that?
so I think this one is just a documentation issue - I can't find anything doc/ that says xxx is a valid combination. radiusd --help also indicates that -fXx should still be valid.
Similarly, when doing a config check:
# ./sbin/radiusd -Cfxx -l stdout <snip> /opt/freeradiuss/etc/raddb/sites-enabled/tls[7]: Threading must be enabled for TLS sockets to function properly. /opt/freeradiuss/etc/raddb/sites-enabled/tls[7]: You probably need to do 'radiusd -fxx -l stdout' for debugging
The init scripts for debian (possibly RHEL too) trigger the latter one, as it runs a config check on restart (which bails out due to the error above).
The "-C" code should be changed to remove it's setting of "-f". We'll fix that for 3.0.1. Alan DeKok.
On 9 Oct 2013, at 15:47, Alan DeKok <aland@deployingradius.com> wrote:
Adam Bishop wrote:
It appears the debugging switches don't work quite as I'd expect in FreeRADIUS 3 when RadSec is configured.
Yes. Because of OpenSSL limitations, the server MUST have multiple threads when using radsec.
Isn't it required for doing any RADIUS over TCP? Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
On 09/10/13 16:36, Arran Cudbard-Bell wrote:
On 9 Oct 2013, at 15:47, Alan DeKok <aland@deployingradius.com> wrote:
Adam Bishop wrote:
It appears the debugging switches don't work quite as I'd expect in FreeRADIUS 3 when RadSec is configured.
Yes. Because of OpenSSL limitations, the server MUST have multiple threads when using radsec.
Isn't it required for doing any RADIUS over TCP?
Perhaps architecturally, but not inherently; you could, at least in theory: 1. Receive 4-byte length 2. Sanity-check the length 3. Allocate buffer 4. Read on TCP socket non-blocking in normal select loop until you've filled the buffer 5. Parse packet from buffer, dispatch packet SSL presents the slight (ahem) complication of having to route the read/write via a memory BIO and check for the "want read" / "want write" state (same way EAP does). So... it's almost certainly *easier* and more sanity-preserving from a development PoV to use threads ;o)
Phil Mayers wrote:
Perhaps architecturally, but not inherently; you could, at least in theory:
1. Receive 4-byte length 2. Sanity-check the length 3. Allocate buffer 4. Read on TCP socket non-blocking in normal select loop until you've filled the buffer 5. Parse packet from buffer, dispatch packet
That is *exactly* what the server does for TCP. Alan DeKok.
Arran Cudbard-Bell wrote:
Isn't it required for doing any RADIUS over TCP?
Nope. Only SSL. The reason is that sometimes reading from an SSL socket requires SSL writing data to the other end. So you end up with both ends waiting for something. And that knowledge is buried inside of OpenSSL. Having threads means that each thread can wait without blocking anything else. It can probably be fixed, but it's hard. Alan DeKok.
Hi,
It appears the debugging switches don't work quite as I'd expect in FreeRADIUS 3 when RadSec is configured.
# radiusd -fxx -l stdout
yep. if you try 'radiusd -X' it will tell you to run it like that.
# radiusd -fXx -l stdout # ./sbin/radiusd -Cfxx -l stdout
single thread methods wont work with RADSEC being present. the docs probably need a slight update with the presence of TLS alan
On 9 Oct 2013, at 15:22, Adam Bishop <Adam.Bishop@JA.NET> wrote:
It appears the debugging switches don't work quite as I'd expect in FreeRADIUS 3 when RadSec is configured.
# radiusd -fxx -l stdout
Works as expected (threaded debugging with no timestamps), however:
# radiusd -fXx -l stdout <snip> Wed Oct 9 14:44:18 2013 : Error: /opt/freeradiuss/etc/raddb/sites-enabled/tls[7]: Threading must be enabled for TLS sockets to function properly. Wed Oct 9 14:44:18 2013 : Error: /opt/freeradiuss/etc/raddb/sites-enabled/tls[7]: You probably need to do 'radiusd -fxx -l stdout' for debugging
'-fXxx -l stdout' reacts in the same way, but '-fxxx -l stdout' does run and produce timestamps, so I think this one is just a documentation issue - I can't find anything doc/ that says xxx is a valid combination. radiusd --help also indicates that -fXx should still be valid.
man radiusd -x Finer-grained debug mode. In this mode the server will print details of every request on it's stdout output. You can specify this option multiple times (-x -x or -xx) to get more detailed output. -X will FORCE the server into single threaded mode, -f -x != -X, and so the server will refuse to start when TCP is required.
Similarly, when doing a config check:
# ./sbin/radiusd -Cfxx -l stdout <snip> /opt/freeradiuss/etc/raddb/sites-enabled/tls[7]: Threading must be enabled for TLS sockets to function properly. /opt/freeradiuss/etc/raddb/sites-enabled/tls[7]: You probably need to do 'radiusd -fxx -l stdout' for debugging
The init scripts for debian (possibly RHEL too) trigger the latter one, as it runs a config check on restart (which bails out due to the error above).
Ok that's a legitimate issue and should be fixed. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
participants (5)
-
A.L.M.Buxey＠lboro.ac.uk -
Adam Bishop -
Alan DeKok -
Arran Cudbard-Bell -
Phil Mayers