On Mon, 20 Nov 2006 08:22:33 -0800 Alan DeKok <aland@deployingradius.com> wrote:

david.suarezdelis@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. ___________________________________________________________________________