[RADIATOR] missing documentation for VsaTranslationHook and more

Tuure Vartiainen vartiait at open.com.au
Wed Sep 6 12:25:48 UTC 2017


> On 5 Sep 2017, at 16.24, Karl Gaissmaier <karl.gaissmaier at uni-ulm.de> wrote:
> the documentation for VsaTranslationHook is missing, also the documentation for VSA translation in AuthRADIUS.

yes, during two past years we have been adding multiple new features and unfortunately updating documentation is a bit behind, 
we will try to improve the situation and get it in sync with the code.

However, goodies/vsa-translate.cfg config has some examples.

> ---------
> I'd like to solve the problem of different MAC address representations in the Calling-Station-Id attribute (and also other radius attributes), coming from different sources from all over the world via RADSEC in the eduroam federation.
> This makes searching in loggs difficult, sigh.
> I can't use VSA vendor and type translations since via the RADSEC clause a lot of different Client vendors are proxied to me as IdP. Btw, VSA Translation is not (yet) implermented for RADSEC.
> I need a generic rewrite ruleset for the different MAC address representations and that's what regexps are for, like:
>    # strip delimiters
>    s/[^a-f0-9]+//ig
>    # insert colons
>    s/(..)(..)(..)(..)(..)(..)/$1:$2:$3:$4:$5:$6/
> similar to RewriteUser.
> Bingo, I found VsaTranslationHook, but only in the sources of Client.pm and AuthRADIUS.pm and not in the corresponding RADSEC modules, AuthRADSEC.pm and ServerRADSEC.pm and also in ServerRADIUS.pm.
> You know, AuthRadius.pm and AuthRADSEC.pm are used for forwarding packets, Client.pm, ServerRADIUS.pm and ServerRADSEC.pm are all receiving clients.

RadSec does not currently have VSA translation implemented, but I created a feature request for it.

> ----------------
> Btw, the Hook in AuthRADIUS.pm is bound to the condition that VsaTranslate is defined, that means I can't use just the Hook alone, that's not good.
> AuthRADIUS.pm
> =============
>    if ($host->{VsaTranslateIn})
>    {
>        Radius::Nas::translateVSAsIn($host->{VsaVendor}, $host->{VsaType}, $host->{VsaTranslateIn}, $p);
>        $host->runHook('Transplantation', $p, $p, 0) if $host->{VsaTranslationHook};
>    }
> In Client.pm the Hook is called just if it is defined, fine!
> Client.pm:
> ==========
>    $self->translateVSAsIn($p) if $self->{VsaTranslateIn};
>    $self->runHook('VsaTranslationHook', $p, $p, 0) if $self->{VsaTranslationHook};
> Please make this logic comparable.

I created a bug ticket for this. An orignal idea was VsaTranslationHook to be additional to VsaTranslateIn, 
but of course it can be used also without.

> Do you have any other suggestion for the problem of different attribute representations coming from the same input channel?

If you can’t differentiate a vendor based on a source, then the strategy should be 
either to unify received values systematically or try to identify the vendor based on 
other received (vendor specific) attributes and select a business logic based on that.

E.g. different formats for Called-Station-Id and Calling-Station-Id:


Called-Station-Id can also contain WLAN SSID:


VSA translation feature was added originally to help unifying vendor specific attributes, 
as in some (broadband) cases a wanted value is in different attributes, 
e.g. (Juniper) Unisphere-Pppoe-Description="pppoe 11:22:33:aa:bb:cc” or 
(Cisco) cisco-avpair = "client-mac-address=1122.33aa.bbcc”, and a hook was needed before 
to do the mangling.

Tuure Vartiainen <vartiait at open.com.au>

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,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.

More information about the radiator mailing list