Hi Jose - Right - understood.
In this case I would probably use separate Radiator processes as intermediates between your main server and the targets that require special AVpair processing. You would forward the original request unchanged and then deal with whatever changes are required on the intermediate Radiator instances. I tend to use this architecture quite often as it makes each individual piece much simpler and cleaner. Something like this: ….. <Handler Client-Identifier=PGW, Acct-Status-Type=Start> Identifier PGW_START AccountingHandled <AuthBy GROUP> AuthByPolicy ContinueAlways <AuthBy RADIUS> # Forward to intermediate instance Host localhost AcctPort 11812 Secret secret2 IgnoreAccountingResponse </AuthBy> <AuthBy RADIUS> # Forward to intermediate instance Host localhost AcctPort 11813 Secret secret3 IgnoreAccountingResponse </AuthBy> <AuthBy RADIUS> # Forward to intermediate instance Host localhost AcctPort 11814 Secret secret4 IgnoreAccountingResponse </AuthBy> <AuthBy RADIUS> Host 192.168.1.5 Secret secret5 IgnoreAccountingResponse </AuthBy> <AuthBy RADIUS> Host 192.168.1.6 Secret secret6 IgnoreAccountingResponse </AuthBy> </AuthBy> MaxSessions 0 </Handler> BTW - I agree with you that a RequestHook would be a useful addition in any case. regards Hugh > On 25 Apr 2015, at 00:35, Jose Borges Ferreira <undersp...@gmail.com> wrote: > > Hi, > > > I have somthing similar to this: > > <Handler Client-Identifier=PGW, Acct-Status-Type=Start> > Identifier PGW_START > AccountingHandled > > <AuthBy GROUP> > AuthByPolicy ContinueUntilReject > <AuthBy RADIUS> > Host 192.168.1.2 > Secret secret2 > StripFromRequest AVP1__2,AVP2__2 > AllowInRequest 3GPP-IMSI, > Acct-Session-Id, NAS-Port-Type\ > Acct-Status-Type, > Called-Station-Id, Calling-Station-Id, Event-Timestamp, > Framed-IP-Address, User-Name > </AuthBy> > <AuthBy RADIUS> > Host 192.168.1.3 > Secret secret3 > > RequestHook sub {\ > my $p = ${$_[0]};\ > my $fp = ${$_[1]};\ > my $imsi = $p->get_attr('3GPP-IMSI');\ > if ($imsi =~ /^1234/) { \ > > $fp->change_attr('3GPP-RAT-Type,', 'UMTS');\ > > }\ > } > > AllowInRequest 3GPP-IMSI, > 3GPP-PDP-Type, 3GPP-RAT-Type, 3GPP-User-Location-Info, > Acct-Session-Id,NAS-Port-Type \ > Acct-Status-Type, > Called-Station-Id, Calling-Station-Id, Event-Timestamp, > Framed-IP-Address, User-Name > > </AuthBy> > <AuthBy RADIUS> > Host 192.168.1.4 > Secret secret3 > AllowInRequest 3GPP-RAT-Type, > 3GPP-User-Location-Info, Acct-Session-Id, NAS-Port-Type\ > Acct-Status-Type, > Called-Station-Id, Calling-Station-Id, Event-Timestamp, > Framed-IP-Address, User-Name > </AuthBy> > > <AuthBy RADIUS> > Host 192.168.1.5 > Secret secret4 > </AuthBy> > > <AuthBy RADIUS> > Host 192.168.1.6 > Secret secret5 > </AuthBy> > </AuthBy> > > > MaxSessions 0 > </Handler> > > > ( not exactly this but similar enough) > > > I want o achieve the following: > > 1.Broadcast accounting to all servers. > 2.Have a different set of AVPs for each destination server. > 3.To one server ( and only to that one) want to have a more complex > logic and be able to add,remove or change AVPs > > In other setups I found that changing avps on one clause it will send > AVP changes to the following servers, which was not intended > > I achieved the intended behaviour by enclosing a AuthBy RADIUS in a > GROUP between a couple of INTERNALs. The first one to change the AVP > and a final one to restore from original packet. > > I found a RequestHook very useful and more clean approach. It is the > counterpart of the Reply/NoReplyHook . > I thought it could be useful for other and, eventually, included in > next versions. > > Thanks anyway, > > Best regards, > > José Borges Ferreira > > > > > > > > > > > > On Wed, Apr 22, 2015 at 7:21 AM, Hugh Irvine <h...@open.com.au> wrote: >> >> Hello Jose - >> >> One way to do this is with multiple Handler clauses and an AuthBy HANDLER >> clause in the first one. >> >> See the example in “goodies/authhandler.cfg”. >> >> See also section 5.76 AuthBy HANDLER in the manual (“doc/ref.pdf”). >> >> You can have a different PreAuthHook in each target Handler clause, and the >> overall configuration will be much simpler. >> >> I would also have separate configuration files for authentication and >> accounting (each listening only on the corresponding ports). >> >> hope that helps >> >> regards >> >> Hugh >> >> >> >>> On 22 Apr 2015, at 01:26, Jose Borges Ferreira <undersp...@gmail.com> wrote: >>> >>> Hi all, >>> >>> I have a setup that forwards some accounting to several servers. I >>> need to mangle some attributes before a forward to the remote >>> server.One requirement is to have different mangling per host. >>> I couldn't found a way to change hook some code at AuthBy RADIUS, so I >>> implemented the attached patch. >>> >>> So , my question is : >>> >>> Is there a way to achieve what I want ? >>> >>> Does the patch makes sense ? >>> >>> Thanks in advanced, >>> >>> José Borges Ferreira >>> <RequestHook.patch>_______________________________________________ >>> radiator mailing list >>> radiator@open.com.au >>> http://www.open.com.au/mailman/listinfo/radiator >> >> >> -- >> >> Hugh Irvine >> h...@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, >> TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, >> DIAMETER, SIM, etc. >> Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc. >> -- Hugh Irvine h...@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, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER, SIM, etc. Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc. _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator