On 12/18/2013 11:43 PM, Michael wrote: > I've gotten closer using an AuthBy GROUP around AuthBy RADIUS, but it > seem to: > > 1. receive the auth request > 2. proxy it to the host > 3. check the session db before the reply comes back and reject if need be. > 4. send the reject to the lns device. > 5. send the accept from the proxy to the lns device.
This comes from AuthBy GROUP first evaluating all its AuthBys and then doing DefaultSimultaneousUse check. When the check is done the request has already been proxied to the next hop. You could consider a ReplyHook that does the check. I'd think something like below should work. sub { my $p = ${$_[0]}; # proxy reply packet my $rp = ${$_[1]}; # reply packet to NAS my $op = ${$_[2]}; # original request packet my $sp = ${$_[3]}; # packet sent to proxy return unless $p->code eq 'Access-Accept'; my $limit = $sp->{ThisAuth}->{DefaultSimultaneousUse}; if (Radius::SessGeneric::find($op->{Handler}->{SessionDatabase})->exceeded( $limit, $op->{OriginalUserName}, $op)) { $op->{RadiusResult} = $main::REJECT; } } Please let us know how it works. Thanks, Heikki -- Heikki Vatiainen <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 etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator