[RADIATOR] Radiator Version 4.3 released

[Mike McCauley]

Hello Heikki,

thanks for your note.
After careful consideration, we agree with you. The latest patch set backs out 
this change:

Reverted changes to PreClientHook introduced in 4.3. PreClientHook is now
called before despatch to any Client clause. It will always be called even if
there is no matching Client, but the attributes will not have been
decrypted (as decrypting is done in the context of a particular Client). 
The new parameter ClientHook has been added to the Client clause,
and is called immediately after the attributes have been decrypted by the
Client. 

Please let us know if that works for you.

Cheers.


On Friday 18 July 2008 05:05, Heikki Vatiainen wrote:
> Mike McCauley wrote:
> > Revision 4.3 (2008-07-17) New modules and bug fixes
> >
> > Moved the location of PreClientHook call to the very beginning of the
> > Client handle_request, so that decoded and decrypted attributes are
> > available to PreClientHooks. Now, PreClientHook will _not_ be called if
> > there is no matching Client clause. Also, within PreClientHook, the
> > $->{Client} member will now be set to the Client clause handling the
> > request, which may be helpful in some PreClientHooks.
>
> Could this change be reconsidered? At least it would be very useful to
> have a hook that behaves like pre-4.3 PreClientHook.
>
> The reason I am asking, is that we are identifing Clients by their
> MAC-addresses. These clients come from different manufacturers that have
> different ideas of what Called-Station-Id should look like. Additionally
> WLAN access points often have the network name (SSID) as a suffix after
> the MAC address.
>
> We are currently using PreClientHook to normalise Called-Station-Id so
> that Radiator can find correct Client clauses. This relies on the
> pre-4.3 processing order which runs PreClientHook before Client clause
> is selected.
>
> I would not be surprised if this kind of configuration is used by others
> too.
>
> Is there a possibility that the change in processing in 4.3 is rolled
> back? The new change could then be made available with a new hook
> (ClientHook maybe?).
>
> The rollback and new hook would not break any existing behaviour and the
> new hook would still be there for those, who need the new functionality
> that a hook in the beginning of Client handle_request() could provide.
>
> Also, the pre-4.3 behaviour is consistent with other PreXYZ-hooks that
> run before XYZ is selected.
>
> If the change is permanent, then a new ReallyPreClientHook would be very
> welcome.
>
> Thanks!

-- 
Mike McCauley                               mikem at open.com.au
Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, WWW
9 Bulbul Place Currumbin Waters QLD 4223 Australia   http://www.open.com.au
Phone +61 7 5598-7474                       Fax   +61 7 5598-7070

Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, 
TTLS, PEAP, TNC, WiMAX, RSA, Vasco etc 
on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.