[RADIATOR] Radiator Version 4.3 released

[Heikki Vatiainen]

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!

-- 
Heikki Vatiainen, Arch Red Oy, Finland
+358 44 087 6547