Reporting from logs - patch

Matthew Newton mcn4 at
Wed Sep 26 01:18:10 CEST 2012

On Tue, Sep 25, 2012 at 09:49:53PM +0100, Matthew Newton wrote:
> On Tue, Sep 25, 2012 at 06:08:04PM +0100, Phil Mayers wrote:
> > I did think about this myself; one option is to call rad_postauth
> > manually if rad_authenticate(fake) fails in peap.c - which I guess
> > is the easy/obvious solution you're referring to? Certainly
> > preferable to the current situation IMO.
> Yes. I'm just testing that to see if it behaves as expected - will
> post a patch for discussion if it seems OK.

Righto, finished hacking something together on master - pushed it to

There are three small commits -

1. move rad_postauth (for accept) from the end of the
rad_authenticate function to next to the rad_postauth called for
reject in process.c. This means that rad_authenticate never calls
rad_postauth - it always has to be called explicitly.

2. Add a new function, 'rad_virtual_server', which does everything
needed to run a virtual server. In this case, calling
rad_authenticate, and then rad_postauth. It could be easily
expanded in future to also handle acct packets, although I can't
quite think of a reason to at the moment (maybe for the
rlm_inject idea?...)

3. Update PEAP/EAP_TLS/TTLS to call rad_virtual_server, rather
than rad_authenticate. This means the inner-tunnels get a
post-auth REJECT as well.

I've tested it with successes and failures for PAP, EAP-TLS
(check-eap-tls), PEAP and EAP-TTLS (inner-tunnel), and all work as

The only thing I'm slightly unsure about is (1) - it seems to
behave as expected, and seems the right place to put it, but I'm
not 100%. On why rad_postauth was previously removed from
rad_authenticate for rejects, my guess would be that there are so
many places that rad_authenticate return for a reject, it would be
called from several places. It's just tidier to do an if() and
call it once after rad_authenticate has returned. rad_postauth is
called immediately on failure, so reject_delay doesn't seem the
right reason. But that's just my guess.



Matthew Newton, Ph.D. <mcn4 at>

Systems Architect (UNIX and Networks), Network Services,
I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom

For IT help contact helpdesk extn. 2253, <ithelp at>

More information about the Freeradius-Devel mailing list