[RADIATOR] Radiator Version 4.3 released

[Hugh Irvine]

Hello Heikki -

Thanks for letting us know.

BTW - the new ClientHook can be specified at the global level and/or  
per Client level.

Ie. a single global ClientHook will be executed by all Client clauses.

regards

Hugh


On 11 Feb 2009, at 01:56, Heikki Vatiainen wrote:

> Note: Replying to an old message from July 2008.
>
> We have upgraded the system that uses PreClientHook to fix
> Called-Station-Ids as I described below.
>
> Everything works just fine i.e., just as before the *ClientHooks were
> rearranged.
>
> Thanks!
>
> Mike McCauley wrote:
>> 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!
>>
>
>
> -- 
> Heikki Vatiainen, Arch Red Oy
> +358 44 087 6547
>
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator



NB:

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?
Have you checked the RadiusExpert wiki:
http://www.open.com.au/wiki/index.php/Main_Page

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
Includes support for reliable RADIUS transport (RadSec),
and DIAMETER translation agent.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.