Understanding debugging logs
Hi, Is there any advised technique or tools out there to help understanding FreeRADIUS debugging output generated by radmin/raddebug? A lot of information is generated, but a method of cutting out repeated information or quickly highlighting issues in a debug session would be handy. If not, is the best method working backwards, checking for errors in each packet log? I am already filtering by MAC or User-Name to make sure I just have output from the session I want. This is not a complaint. We are currently moving from NPS so having useful debugging is brilliant and a whole new world where problems seem solvable! I'm always interested in anything that will make life easier though :) Dave Hartburn
Hi Dave, I find that the easiest way to read the logs is to start with the request, and trace it down from there. Some things I check for: - Determine if all of the attributes that you expect to see are atually present - Determine if the request follows the path you expect - Does "suffix" do anything? - Is there a DEFAULT from the users file that gets matched? - Is the request proxied externally, or to a local virtual server? - Determine if authorize is setting the Auth-Type you expect - Determine if authenticate is able to authenticate the user - Is an Access-Accept or Access-Reject returned? - If there is an Access-Accept, but the NAS still isn't letting you in - Is there a Reply-Attribute that is missing? If you're looking for something more specific than that, you will have to explain the specific problem you are having and provide some debug output (don't forget to sanitize IPs and passwords if you need to). -- Also Dave -----Original Message----- From: David Hartburn <D.J.Hartburn@kent.ac.uk> Reply-to: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> To: freeradius-users@lists.freeradius.org Subject: Understanding debugging logs Date: Fri, 23 Oct 2015 16:15:59 +0100 Hi, Is there any advised technique or tools out there to help understanding FreeRADIUS debugging output generated by radmin/raddebug? A lot of information is generated, but a method of cutting out repeated information or quickly highlighting issues in a debug session would be handy. If not, is the best method working backwards, checking for errors in each packet log? I am already filtering by MAC or User-Name to make sure I just have output from the session I want. This is not a complaint. We are currently moving from NPS so having useful debugging is brilliant and a whole new world where problems seem solvable! I'm always interested in anything that will make life easier though :) Dave Hartburn - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Fri, Oct 23, 2015 at 04:15:59PM +0100, David Hartburn wrote:
Is there any advised technique or tools out there to help understanding FreeRADIUS debugging output generated by radmin/raddebug?
Eyes :)
If not, is the best method working backwards, checking for errors in each packet log? I am already filtering by MAC or User-Name to make sure I just have output from the session I want.
I start at the bottom and work up. Find the error, then look back to find why that error occurred. After a few times doing this you'll work out the bits to skip pretty quickly.
This is not a complaint. We are currently moving from NPS so having useful debugging is brilliant and a whole new world where problems seem solvable! I'm always interested in anything that will make life easier though :)
Experience helps, but I admit the volume of debugs does look daunting to begin with. But it's pretty much all relevant. Which is why most questions to this list without debug output result in "provide the debug output", and few questions that include the debug output result in requests for further information. Network RADIUS provide a debug highlighter if that's your thing. http://networkradius.com/freeradius-debugging/ Cheers, Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On Fri, Oct 23, 2015 at 03:35:16PM +0000, David Aldwinckle wrote:
I find that the easiest way to read the logs is to start with the request, and trace it down from there. Some things I check for:
On Fri, Oct 23, 2015 at 04:40:20PM +0100, Matthew Newton wrote:
I start at the bottom and work up.
There you go - you've got both options now! Start a new trend. Look at a packet somewhere in the middle and work out from there. Matthew p.s. Confession: I occasionally start at the top. -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Thanks for all the advice. Is that a device and conquer approach? All you need to know is if the error is in the top or bottom half then you can throw half away ;) I do have an auth problem at the moment, so I'll generate lots of debug and see where I can get. Thanks again Dave On 23/10/15 16:43, Matthew Newton wrote:
On Fri, Oct 23, 2015 at 03:35:16PM +0000, David Aldwinckle wrote:
I find that the easiest way to read the logs is to start with the request, and trace it down from there. Some things I check for:
On Fri, Oct 23, 2015 at 04:40:20PM +0100, Matthew Newton wrote:
I start at the bottom and work up.
There you go - you've got both options now!
Start a new trend. Look at a packet somewhere in the middle and work out from there.
Matthew
p.s. Confession: I occasionally start at the top.
On 29 Oct 2015, at 12:37, David Hartburn <D.J.Hartburn@kent.ac.uk> wrote:
Thanks for all the advice. Is that a device and conquer approach? All you need to know is if the error is in the top or bottom half then you can throw half away ;)
I do have an auth problem at the moment, so I'll generate lots of debug and see where I can get.
Use FreeRADIUS >= v3, log to stdout -X, look for red and yellow things. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
David Hartburn [D.J.Hartburn@kent.ac.uk] wrote:
If not, is the best method working backwards, checking for errors in each packet log? I am already filtering by MAC or User-Name to make sure I just have output from the session I want.
Getting radmin working so you could do that was a very good first step. Yes, these can be cognitively overloading sometimes. You rarely actually need timestamps so first try without -Xx Using a very wide terminal also helps :-) I would suggest once you have things working satisfactorily, stash some "normal" transactions in a safe place. Someday I do mean to get around to scripting something that can strip all the less interesting transients like EAP messages, MACs, and packet IDs out, but even without that, doing a diff between a "was working" trace and a "broken" one can often help locate where things start to go off the rails.
On Oct 23, 2015, at 11:15 AM, David Hartburn <D.J.Hartburn@kent.ac.uk> wrote:
Is there any advised technique or tools out there to help understanding FreeRADIUS debugging output generated by radmin/raddebug?
In v3, look for yellow or red text in the debug output. But that's only in "radiusd -X". For radmin / raddebut, look for WARNING or ERROR.
A lot of information is generated, but a method of cutting out repeated information or quickly highlighting issues in a debug session would be handy.
Look for keywords. If you want to know what's going on with SQL.... look for "sql", and ignore everything else. The information is printed because it's *needed* by someone. It's up to you to filter through it for the information you want.
If not, is the best method working backwards, checking for errors in each packet log? I am already filtering by MAC or User-Name to make sure I just have output from the session I want.
This is not a complaint. We are currently moving from NPS so having useful debugging is brilliant and a whole new world where problems seem solvable! I'm always interested in anything that will make life easier though :)
Yes. Having debugging output is infinitely better than having no debug output. :( Alan DeKok.
participants (6)
-
Alan DeKok -
Arran Cudbard-Bell -
Brian Julin -
David Aldwinckle -
David Hartburn -
Matthew Newton