I've just committed some fixes to debugging output. It now prints the section names as it's parsing them: foo { bar = stuff } Which is a lot cleaner than what was there before. Also, the lines with brackets are indented one space for every section nesting, which makes it easier to track sections && subsections. The rest of the messages printed out during server initialization have been normalized to a more standard form. The debug output for handling packets has changed. There's less text on the screen, which makes it easier to read (for the people who actually read it.) It also shows some limited nesting via "+". After some back and forth, I decided it was clearer to use "+" rather than anything else. e.g. +- entering group authorize ++[foo] returns ok ++[bar] returns noop ... +- group authorize returns ok The individual module debug output is still indented with spaces, which makes it easier to tell the difference between server messages && module messages. All told, it's very different from 1.x, and I hope much easier to understand. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan DeKok wrote:
I've just committed some fixes to debugging output. It now prints the section names as it's parsing them:
foo { bar = stuff }
Which is a lot cleaner than what was there before. Also, the lines with brackets are indented one space for every section nesting, which makes it easier to track sections && subsections.
The rest of the messages printed out during server initialization have been normalized to a more standard form.
The debug output for handling packets has changed. There's less text on the screen, which makes it easier to read (for the people who actually read it.) It also shows some limited nesting via "+". After some back and forth, I decided it was clearer to use "+" rather than anything else. e.g.
+- entering group authorize ++[foo] returns ok ++[bar] returns noop ... +- group authorize returns ok
The individual module debug output is still indented with spaces, which makes it easier to tell the difference between server messages && module messages.
All told, it's very different from 1.x, and I hope much easier to understand.
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
It is , far far far easier to understand, especially when loading the config files... as the text scrolling down the screen actually resembles the config file you've just been editing. Just to clarify with EAP updated -> I need to do db lookups to get password hashes etc ok -> I'm processing an eap conversation , so don't bother with the other modules. noop -> Theres no eap message so i'm not going to do anything. -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900
Arran Cudbard-Bell wrote:
It is , far far far easier to understand, especially when loading the config files... as the text scrolling down the screen actually resembles the config file you've just been editing.
Thanks. That's what the intention was.
Just to clarify with EAP
updated -> I need to do db lookups to get password hashes etc ok -> I'm processing an eap conversation , so don't bother with the other modules. noop -> Theres no eap message so i'm not going to do anything.
Yes. See the comments around "eap" in the "authorize" section of "radiusd.conf" in the latest CVS. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
It is , far far far easier to understand, especially when loading the config files... as the text scrolling down the screen actually resembles the config file you've just been editing.
Thanks. That's what the intention was.
Just to clarify with EAP
updated -> I need to do db lookups to get password hashes etc ok -> I'm processing an eap conversation , so don't bother with the other modules. noop -> Theres no eap message so i'm not going to do anything.
Yes. See the comments around "eap" in the "authorize" section of "radiusd.conf" in the latest CVS.
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Ok so in a EAP conversation EAP will return updated on the start of the conversation To save establishing the TLS connection for a user which can never be authenticated ? --- On inner encryption start , so the initial challenge if your using mschap/chap. Possibly to calculate the challenge (I don't know the inner workings of mschap). --- When the response from the challenge is recieved. Obviously needed to check the response is correct. --- And then finally, when the user has to be authorised. So you've halved the load on the db for EAP-PEAP :) And now theres no need to mess about with Authz-Types ... So no need to put the original source ip in internally forwarded packets. Ok well, thats fixed just about all the issues I had with freeRADIUS. Hows that book coming ? :) -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900
Arran Cudbard-Bell wrote:
So you've halved the load on the db for EAP-PEAP :)
More than that, probably. If you configure it as: authorize { ... eap { handled = return ok = return } ... } Then the EAP Identity packet won't cause it to hit the DB, either.
And now theres no need to mess about with Authz-Types ...
So no need to put the original source ip in internally forwarded packets.
It's still a useful feature.
Ok well, thats fixed just about all the issues I had with freeRADIUS.
The two things left for 2.0 are: - HUP handling - integration of detail file reading into the server core (partially done) The detail logic will allow some cool features: NAS ----+--> proxy ------> home server | | | | if home server is down | v \--- detail file i.e. "proxy requests to the home server. If it's down, log them to the detail file. If there's stuff in the detail file, read it back, and handle it again, just like it was a new request."
Hows that book coming ? :)
Slowly, unfortunately. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
O/H Alan DeKok έγραψε:
Arran Cudbard-Bell wrote:
So you've halved the load on the db for EAP-PEAP :)
More than that, probably. If you configure it as:
authorize { ... eap { handled = return ok = return } ... }
Then the EAP Identity packet won't cause it to hit the DB, either.
And now theres no need to mess about with Authz-Types ...
So no need to put the original source ip in internally forwarded packets.
It's still a useful feature.
Ok well, thats fixed just about all the issues I had with freeRADIUS.
The two things left for 2.0 are:
- HUP handling - integration of detail file reading into the server core (partially done)
And removing the xlat input string limit, probably by using preallocated buffers which will increase performance...
The detail logic will allow some cool features:
NAS ----+--> proxy ------> home server | | | | if home server is down | v \--- detail file
i.e. "proxy requests to the home server. If it's down, log them to the detail file. If there's stuff in the detail file, read it back, and handle it again, just like it was a new request."
Hows that book coming ? :)
Slowly, unfortunately.
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
-- Kostas Kalevras - Network Operations Center National Technical University of Athens http://kkalev.wordpress.com
Kostas Kalevras wrote:
The two things left for 2.0 are:
- HUP handling - integration of detail file reading into the server core (partially done)
And removing the xlat input string limit, probably by using preallocated buffers which will increase performance...
While I'd like that to go in, it's less of a priority than HUP handling. Changing the VALUE_PAIR to handle arbitrary sized strings involves changing everything in the server that looks at or modifies a VALUE_PAIR. There are big security concerns, too. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Kostas Kalevras