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