Reporting from logs - patch

Phil Mayers p.mayers at
Wed Sep 26 11:26:15 CEST 2012

On 26/09/12 00:18, Matthew Newton wrote:
> 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.

Out of curiosity, was there any reason you took this approach rather 
than moving rad_postauth back into rad_authenticate?

The reason I ask is that rad_authenticate already calls the "authorize 
{}" and "authenticate {}" blocks, so symmetry would seem to suggest it 
call the "post-auth {}" block too.

The other thing is that this change moves the execution context for the 
vast majority of post-auth calls (since most auths succeed). That might 
not matter, although I'm not sure about which thread request_finish 
executes in, or if it matters.

More information about the Freeradius-Devel mailing list