Re: FR3 Debugging Switches

2013-10-10 Thread Phil Mayers

On 09/10/13 19:09, Alan DeKok wrote:


   That is *exactly* what the server does for TCP.


...in which case my comment is entirely redundant, please disregard!
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: FR3 Debugging Switches

2013-10-09 Thread Alan DeKok
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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: FR3 Debugging Switches

2013-10-09 Thread A . L . M . Buxey
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: FR3 Debugging Switches

2013-10-09 Thread Arran Cudbard-Bell

On 9 Oct 2013, at 15:22, Adam Bishop adam.bis...@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.cudba...@freeradius.org
FreeRADIUS Development Team

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: FR3 Debugging Switches

2013-10-09 Thread Arran Cudbard-Bell

On 9 Oct 2013, at 15:47, Alan DeKok al...@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.cudba...@freeradius.org
FreeRADIUS Development Team

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: FR3 Debugging Switches

2013-10-09 Thread Phil Mayers

On 09/10/13 16:36, Arran Cudbard-Bell wrote:


On 9 Oct 2013, at 15:47, Alan DeKok al...@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)

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: FR3 Debugging Switches

2013-10-09 Thread 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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: FR3 Debugging Switches

2013-10-09 Thread Alan DeKok
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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html