RLM Perl cache problem? (was: Freeradius-Users Digest, Vol 19, Issue 71)
david.suarezdelis at telefonica.es
david.suarezdelis at telefonica.es
Wed Nov 22 12:12:03 CET 2006
On Mon, 20 Nov 2006 08:22:33 -0800 Alan DeKok <aland at deployingradius.com>
wrote:
> david.suarezdelis at telefonica.es wrote:
>
> > I have observed that once I have returned a Class attribute, though, it
> > keeps getting sent by FreeRadius even when my authenticate() sub is not
> > assigning to it.
>
> I'd be a little surprised if that happens. There's no cache in the
> server like that.
Then some process must get hooked somehow so it keeps sending the
attribute...
> Can you explain in more detail, like using the output of radiusd -X,
> and two packets?
Yes, here we go:
(some data modified to protect the innocent)
This is the expected behavior, where the perl section authenticate() sub
adds some values (IP, netmask and class):
rad_recv: Access-Request packet from host 10.236.247.4:1366, id=182,
length=91
User-Name = "test1"
User-Password = "testing123"
NAS-Port = 3298
Service-Type = Framed-User
Framed-Protocol = PPP
Tunnel-Client-Endpoint:0 = "127.0.0.5"
NAS-IP-Address = 10.236.247.4
NAS-Port-Type = Virtual
Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 33
modcall[authorize]: module "preprocess" returns ok for request 33
modcall[authorize]: module "chap" returns noop for request 33
modcall[authorize]: module "mschap" returns noop for request 33
rlm_realm: No '@' in User-Name = "test1", looking up realm NULL
rlm_realm: No such realm "NULL"
modcall[authorize]: module "suffix" returns noop for request 33
rlm_eap: No EAP-Message, not doing EAP
modcall[authorize]: module "eap" returns noop for request 33
users: Matched entry DEFAULT at line 216
modcall[authorize]: module "files" returns ok for request 33
modcall: leaving group authorize (returns ok) for request 33
rad_check_password: Found Auth-Type External
auth: type "External"
Processing the authenticate section of radiusd.conf
modcall: entering group External for request 33
perl_pool: item 0x8ded928 asigned new request. Handled so far: 12
found interpetator at address 0x8ded928
rlm_perl: Added pair Class = OU=tme;
rlm_perl: Added pair Framed-IP-Address = 10.236.246.226
rlm_perl: Added pair Framed-IP-Netmask = 255.255.255.255
rlm_perl: Added pair Auth-Type = External
perl_pool total/active/spare [3/0/3]
Unreserve perl at address 0x8ded928
modcall[authenticate]: module "perl" returns ok for request 33
modcall: leaving group External (returns ok) for request 33
Processing the post-auth section of radiusd.conf
modcall: entering group post-auth for request 33
radius_xlat: '/var/log/freeradius/radacct/10.236.247.4
/reply-detail-20061116'
rlm_detail:
/var/log/freeradius/radacct/%{Client-IP-Address}/reply-detail-%Y%m%d
expands to /var/log/freeradius/radacct/10.236.247.4/reply-detail-20061116
modcall[post-auth]: module "reply_log" returns ok for request 33
modcall: leaving group post-auth (returns ok) for request 33
Sending Access-Accept of id 182 to 10.236.247.4 port 1366
Class = 0x4f553d746d653b
Framed-IP-Address = 10.236.246.226
Framed-IP-Netmask = 255.255.255.255
Finished request 33
However, changing test1 user profile on the DB so it doesn't have a class
attribute to send:
The traces show this (Log::Log4perl and Data::Dumper):
2006-11-22 10:49:53,068 viblde01 INFO> LDAP::Group.pm(296) get_class() -
'cn=racc_test, ou=Usuarios, dc=org' no posee información de Class, no se
aplica
2006-11-22 10:49:53,141 viblde01 DEBUG> radius.pl(62) main::authenticate -
$VAR1 = bless( {
[...]
'RESPONSE' => bless( {
'REPLY_TIMEOUT' => 0,
'MODIFICATION_TIME' =>
'1164188986.423663',
'ATTR' => {
'Cisco-AVPair' => [],
'Reply-Message' =>
undef,
'Class' => 'OU=tme;',
'Auth-Type' => undef,
'Framed-IP-Address' =>
'10.235.237.66',
'Framed-IP-Netmask' =>
'255.255.255.255'
},
'REPLY' => 2,
'NAS-IP-Address' => '10.235.236.5',
'CREATION_TIME' =>
'1164188985.191276'
}, 'RADIUS::Reply' ),
[...]
And on freeradius -X:
found interpetator at address 0xa90eee8
rlm_perl: Added pair Class = OU=tme;
rlm_perl: Added pair Framed-IP-Address = 10.235.237.66
rlm_perl: Added pair Framed-IP-Netmask = 255.255.255.255
rlm_perl: Added pair Auth-Type = External
This is, it's remembering (somehow) that it assinged to it before... (The
INFO log entry is in Spanish, it says that that RDN does not have Class
info, so it's not apllied).
The relevant code here is this:
sub get_class
{
my $self = shift;
my $class = $self->{GROUP}->get_value('class');
if ( defined $class and $class ne '*' )
{
return $class;
}
else
{
$logger->info( "'", $self->{RACC}->dn, "' no posee información de
Class, no se aplica" );
return undef;
}
}
And it's used such as in radius.pl:
my $class = $lgroup->get_class;
if ( defined $class )
{
$reply->class($class);
}
where $lgroup is an object representing the LDAP group that hosts the info
(wrapped around by automagically written accessors and mutators) and $reply
is an object representing the RADIUS Reply packet. In LDAP::Reply, the
attributes are initialized to the ones in a 'standard' %RAD_REPLY hash
(reply packet, both for Access Request and Accounting requests)
The $self->{GROUP} is a Net::LDAP::Entry object created when this request
was instantiated, and thus it's returning the 'undef' value as expected.
> > PS- aditionally, is there an updated rlm_perl manual specifying what
> > section it loads is for, and how to use the shared memory to set up db
> > pools and cached results for making things easier before each forking?
> > thanks!
>
> Nope, sorry.
Ack... Anyone who knows willing to provide one example per possibility in
rlm_perl? I can surely offer myself to document things once I have an idea
of how to start with each thingie...
Thanks!
david
___________________________________________________________________________
Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si no es vd. el destinatario
indicado, queda notificado de que la lectura, utilización, divulgación y/o
copia sin autorización está prohibida en virtud de la legislación vigente.
Si ha recibido este mensaje por error, le rogamos que nos lo comunique
inmediatamente por esta misma vía y proceda a su destrucción.
El correo electrónico vía Internet no permite asegurar la confidencialidad
de los mensajes que se transmiten ni su integridad o correcta recepción.
Telefónica no asume ninguna responsabilidad por estas circunstancias.
This message is intended exclusively for its addressee and may contain
information that is CONFIDENTIAL and protected by a professional privilege
or whose disclosure is prohibited by law.If you are not the intended
recipient you are hereby notified that any read, dissemination, copy or
disclosure of this communication is strictly prohibited by law. If this
message has been received in error, please immediately notify us via e-mail
and delete it.
Internet e-mail neither guarantees the confidentiality nor the integrity or
proper receipt of the messages sent. Telefónica does not assume any
liability for those circumstances.
___________________________________________________________________________
More information about the Freeradius-Users
mailing list