Yes, 'detail' is included in the accounting section.

Ok, that's not going to log then. It will only log when it gets accounting packets. Look at the 'default' server. In the post-auth section you'll see a reply_log entry that is commented out by default. If you uncomment this, it will start logging entries as per the 'reply_log' line log that is defined in the 'detail.log' module in mods-available. However, note that this will *not* be a single-line entry (which is what's recommended by the eduroam operator in the UK). Look at https://github.com/FreeRADIUS/freeradius-server/blob/v2.x.x/raddb/modules/l inelog for the current linelog for v2.x. If you're on 3.x, go to https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/raddb/mods-avai lable/linelog - This will come in handy when doing what the Confluence page you found says.

Log file enclosed in ZIP format.

Don't do that. Archives are stripped. A simple freeradius -X output capture is useful.

I found this website which may help to enable logging, looks like logging functionality is different between 2.1.10 and 2.1.12. http://confluence.diamond.ac.uk/pages/viewpage.action?pageId=22252353

Ahhh... My history comes back to haunt me... ;-) You may want to set up two of the three line logs defined on that page: eduroam_log and inner_auth_log. To log to the *log* directory, do *not* set 'filename' to 'syslog'. Instead set it to whatever you wanted the filename to be... "${logdir}/linelog" is the default in linelog. Tweak that appropriately for the inner_auth_log (if you want to log authentication of your own users separately). Then, like the page says, call 'eduroam_log' in the post-auth section, or, better yet, in the post-proxy section of your eduroam server, since post-proxy gets hit by an incoming reply from a home organisation before post-auth does (and post-auth also gets hit by your own users after their authentication reply returns from the inner-tunnel server). Also, like the page says, call 'inner_auth_log' from the post-auth section of your inner-tunnel. Stop your server. Start it in debug mode. Then hit it with an authentication request (for your own user). You should with any luck get an entry in your inner-tunnel authentication log. Then, if you have a test subject from another institution, get them to authenticate through eduroam and see what happens. Like Alan and others have pointed out, the module files are liberally commented so that it is easier to understand the operation of the server (and what the options do). Of course, if you strip out all comments for a bare-bones configuration, then yes, it becomes distinctly more difficult (or you spend a lot of time on Github to understand what each file does). :-) Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Networkshop44, University of Manchester. Save the date: 22-24 March, 2016. #NWS44 Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.