rlm_perl and accounting
I'm running freeradius v. 1.1.0 and am trying to use rlm_perl to rewrite accounting attributes before they are written to log with detail and then replicated with radrelay. Here is the version of example.pl that I'm using (I've only added a single statement to the preacct function): use strict; # use ... # This is very important ! Without this script will not get the filled hashesh from main. use vars qw(%RAD_REQUEST %RAD_REPLY %RAD_CHECK); #use Data::Dumper; # This is hash wich hold original request from radius #my %RAD_REQUEST; # In this hash you add values that will be returned to NAS. #my %RAD_REPLY; #This is for check items #my %RAD_CHECK; # # This the remapping of return values # use constant RLM_MODULE_REJECT=> 0;# /* immediately reject the request */ use constant RLM_MODULE_FAIL=> 1;# /* module failed, don't reply */ use constant RLM_MODULE_OK=> 2;# /* the module is OK, continue */ use constant RLM_MODULE_HANDLED=> 3;# /* the module handled the request, so stop. */ use constant RLM_MODULE_INVALID=> 4;# /* the module considers the request invalid. */ use constant RLM_MODULE_USERLOCK=> 5;# /* reject the request (user is locked out) */ use constant RLM_MODULE_NOTFOUND=> 6;# /* user not found */ use constant RLM_MODULE_NOOP=> 7;# /* module succeeded without doing anything */ use constant RLM_MODULE_UPDATED=> 8;# /* OK (pairs modified) */ use constant RLM_MODULE_NUMCODES=> 9;# /* How many return codes there are */ # Function to handle authorize sub authorize { # For debugging purposes only # &log_request_attributes; # Here's where your authorization code comes # You can call another function from here: &test_call; return RLM_MODULE_OK; } # Function to handle authenticate sub authenticate { # For debugging purposes only # &log_request_attributes; if ($RAD_REQUEST{'User-Name'} =~ /^baduser/i) { # Reject user and tell him why $RAD_REPLY{'Reply-Message'} = "Denied access by rlm_perl function"; return RLM_MODULE_REJECT; } else { # Accept user and set some attribute $RAD_REPLY{'h323-credit-amount'} = "100"; return RLM_MODULE_OK; } } # Function to handle preacct sub preacct { # For debugging purposes only #&log_request_attributes; $RAD_REPLY{'Acct-Session-Id'} = "new-session-value"; return RLM_MODULE_OK; } # Function to handle accounting sub accounting { # For debugging purposes only # &log_request_attributes; # You can call another subroutine from here #&test_call; return RLM_MODULE_OK; } # Function to handle checksimul sub checksimul { # For debugging purposes only # &log_request_attributes; return RLM_MODULE_OK; } # Function to handle pre_proxy sub pre_proxy { # For debugging purposes only # &log_request_attributes; return RLM_MODULE_OK; } # Function to handle post_proxy sub post_proxy { # For debugging purposes only # &log_request_attributes; return RLM_MODULE_OK; } # Function to handle post_auth sub post_auth { # For debugging purposes only # &log_request_attributes; return RLM_MODULE_OK; } # Function to handle xlat sub xlat { # For debugging purposes only # &log_request_attributes; # Loads some external perl and evaluate it my ($filename,$a,$b,$c,$d) = @_; &radiusd::radlog(1, "From xlat $filename "); &radiusd::radlog(1,"From xlat $a $b $c $d "); local *FH; open FH, $filename or die "open '$filename' $!"; local($/) = undef; my $sub = <FH>; close FH; my $eval = qq{ sub handler{ $sub;} }; eval $eval; eval {main->handler;}; } # Function to handle detach sub detach { # For debugging purposes only # &log_request_attributes; # Do some logging. &radiusd::radlog(0,"rlm_perl::Detaching. Reloading. Done."); } # # Some functions that can be called from other functions # sub test_call { # Some code goes here } sub log_request_attributes { # This shouldn't be done in production environments! # This is only meant for debugging! for (keys %RAD_REQUEST) { &radiusd::radlog(1, "RAD_REQUEST: $_ = $RAD_REQUEST{$_}"); } } Here's the output of freeradius -X: root@black-pearl:/etc/freeradius# freeradius -X ... Module: Loaded perl perl: module = "/home/jcc/scripts/example.pl" perl: func_authorize = "authorize" perl: func_authenticate = "authenticate" perl: func_accounting = "accounting" perl: func_preacct = "preacct" perl: func_checksimul = "checksimul" perl: func_detach = "detach" perl: func_xlat = "xlat" perl: func_pre_proxy = "pre_proxy" perl: func_post_proxy = "post_proxy" perl: func_post_auth = "post_auth" perl: perl_flags = "(null)" perl: func_start_accounting = "(null)" perl: func_stop_accounting = "(null)" perl: max_clones = 32 perl: start_clones = 5 perl: min_spare_clones = 3 perl: max_spare_clones = 3 perl: cleanup_delay = 5 perl: max_request_per_clone = 0 Module: Instantiated perl (perl) ... Here's my radiusd.conf: ... modules { perl { module = /home/jcc/scripts/example.pl max_clones = 32 start_clones = 5 min_spare_clones = 3 max_spare_clones = 3 cleanup_delay = 5 max_request_per_clone = 0 } } ... preacct { preprocess acct_unique perl suffix files } accounting { local-detail radrelay-detail unix radutmp } ... Notice from my example.pl that I'm trying to rewrite the value for Acct-Session-Id. The freeradius -X output shows that I've added a new pair, Acct-Session-Id = new-session-value, but only the original value shows up in the radacct log, not the new value: rad_recv: Accounting-Request packet from host 127.0.0.1:32819, id=89, length=65 User-Name = "jcc" NAS-Port = 1 Acct-Session-Id = "accounting-session-1" Sip-Transport-Protocol = TCP Processing the preacct section of radiusd.conf modcall: entering group preacct for request 0 modcall[preacct]: module "preprocess" returns noop for request 0 rlm_acct_unique: Hashing 'NAS-Port = 1,Client-IP-Address = 127.0.0.1,NAS-IP-Address = 127.0.0.1,Acct-Session-Id = "accounting-session-1",User-Name = "jcc"' rlm_acct_unique: Acct-Unique-Session-ID = "4f08f8eb92e050ff". modcall[preacct]: module "acct_unique" returns ok for request 0 perl_pool: item 0x8168260 asigned new request. Handled so far: 1 found interpetator at address 0x8168260 rlm_perl: Added pair Acct-Session-Id = new-session-value perl_pool total/active/spare [5/0/5] Could not get @DynaLoader::dl_librefs for unloading. Unreserve perl at address 0x8168260 modcall[preacct]: module "perl" returns ok for request 0 rlm_realm: No '@' in User-Name = "jcc", looking up realm NULL rlm_realm: No such realm "NULL" modcall[preacct]: module "suffix" returns noop for request 0 modcall[preacct]: module "files" returns noop for request 0 modcall: leaving group preacct (returns ok) for request 0 Processing the accounting section of radiusd.conf modcall: entering group accounting for request 0 radius_xlat: '/var/log/freeradius/radacct/127.0.0.1/detail-20060822' rlm_detail: /var/log/freeradius/radacct/%{Client-IP-Address}/detail-%Y%m%d expands to /var/log/freeradius/radacct/127.0.0.1/detail-20060822 modcall[accounting]: module "local-detail" returns ok for request 0 radius_xlat: '/var/log/freeradius/radacct/radrelay-detail' rlm_detail: /var/log/freeradius/radacct/radrelay-detail expands to /var/log/freeradius/radacct/radrelay-detail rlm_detail: Acquired filelock, tried 1 time(s) rlm_detail: Released filelock modcall[accounting]: module "radrelay-detail" returns ok for request 0 rlm_unix: no Accounting-Status-Type attribute in request. modcall[accounting]: module "unix" returns noop for request 0 rlm_radutmp: No Accounting-Status-Type record. modcall[accounting]: module "radutmp" returns noop for request 0 modcall: leaving group accounting (returns ok) for request 0 Sending Accounting-Response of id 89 to 127.0.0.1 port 32819 Finished request 0 Going to the next request --- Walking the entire request list --- Cleaning up request 0 ID 89 with timestamp 44eb308c Nothing to do. Sleeping until we see a request. radrelay-detail log: Tue Aug 22 12:27:56 2006 User-Name = "jcc" NAS-Port = 1 Acct-Session-Id = "accounting-session-1" Sip-Transport-Protocol = TCP NAS-IP-Address = 127.0.0.1 Client-IP-Address = 127.0.0.1 Acct-Unique-Session-Id = "4f08f8eb92e050ff" Timestamp = 1156264076 What am I missing? Thanks. -jc
Yes, this is due to the way rlm_perl works by default (new pairs can be added but existing ones not changed). Look back a week or so in the mailing list archives to the problem I was having. There is a patch on the list that will allegedly make it into HEAD. The patch works nicely for me. Alex On 22/08/06, Justin Church <jcc@unc.edu> wrote:
I'm running freeradius v. 1.1.0 and am trying to use rlm_perl to rewrite accounting attributes before they are written to log with detail and then replicated with radrelay. Here is the version of example.pl that I'm using (I've only added a single statement to the preacct function):
I see the patch you're referring to, but after rethinking my question, I think what I'm really trying to do is rewrite $RAD_REQUEST, not $RAD_REPLY, and it does not appear that I can alter $RAD_REQUEST in any way - either change or add. If I understand correctly, $RAD_REPLY is the hash of attributes that the server will send back to the NAS, and $RAD_REQUEST is the hash of attributes that is actually written when the detail module is called. My goal is to inspect the received attributes using rlm_perl in the preacct{} phase before they are written to log in the accounting{} phase and possibly remove/rewrite/add attributes before they are logged. Is this possible with rlm_perl? Also, I've observed that the freeradius will not start when my example.pl script contains use Data::Dumper; It looks as if others have had this problem when their perl was not compiled with ITHREADS support, but my perl does have ITHREADS support, and neither perl -c -MData::Dumper nor perl example.pl returns an error. jcc@black-pearl:~/scripts$ perl -v This is perl, v5.8.7 built for i486-linux-gnu-thread-multi jcc@black-pearl:~/scripts$ perl -V | grep ITHREADS Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES Thanks. -jc Alex French wrote:
Yes, this is due to the way rlm_perl works by default (new pairs can be added but existing ones not changed). Look back a week or so in the mailing list archives to the problem I was having. There is a patch on the list that will allegedly make it into HEAD. The patch works nicely for me.
Alex
On 22/08/06, *Justin Church* <jcc@unc.edu <mailto:jcc@unc.edu>> wrote:
I'm running freeradius v. 1.1.0 and am trying to use rlm_perl to rewrite accounting attributes before they are written to log with detail and then replicated with radrelay. Here is the version of example.pl that I'm using (I've only added a single statement to the preacct function):
------------------------------------------------------------------------
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Justin Church <jcc@unc.edu> wrote:
I see the patch you're referring to, but after rethinking my question, I think what I'm really trying to do is rewrite $RAD_REQUEST, not $RAD_REPLY, and it does not appear that I can alter $RAD_REQUEST in any way - either change or add.
Yeah, I just ran into this today, too. I think it's useful to be able to modify RAD_REQUEST. The patch included below should help. Unless there are serious objections, I'll add it to 1.1.3, too. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog Index: src/modules/rlm_perl/rlm_perl.c =================================================================== RCS file: /source/radiusd/src/modules/rlm_perl/rlm_perl.c,v retrieving revision 1.13.4.7 diff -u -r1.13.4.7 rlm_perl.c --- src/modules/rlm_perl/rlm_perl.c 27 Apr 2006 17:35:44 -0000 1.13.4.7 +++ src/modules/rlm_perl/rlm_perl.c 22 Aug 2006 22:08:00 -0000 @@ -1050,6 +1050,11 @@ LEAVE; + if ((get_hv_content(rad_request_hv, &vp)) > 0 ) { + pairmove(&request->packet->vps, &vp); + pairfree(&vp); + } + if ((get_hv_content(rad_reply_hv, &vp)) > 0 ) { pairmove(&request->reply->vps, &vp); pairfree(&vp); @@ -1060,6 +1065,12 @@ pairfree(&vp); } + if ((get_hv_content(rad_request_proxy_hv, &vp)) > 0 && request->proxy != NULL) { + pairfree(&request->proxy->vps); + pairmove(&request->proxy->vps, &vp); + pairfree(&vp); + } + if ((get_hv_content(rad_request_proxy_reply_hv, &vp)) > 0 && request->proxy_reply != NULL) { pairfree(&request->proxy_reply->vps); pairmove(&request->proxy_reply->vps, &vp);
I see the patch you're referring to, but after rethinking my question, I think what I'm really trying to do is rewrite $RAD_REQUEST, not $RAD_REPLY, and it does not appear that I can alter $RAD_REQUEST in any way - either change or add.
Hmm... looking into it in a little more detail, I think it would be even easier to do it another way. The code in CVS head has been updated to allow for ":=", to over-write existing attributes. But I think it might be even easier to simply use the hashes as-is, and replace the existing attribute lists. i.e. put the attributes into perl hashes, and then make those perl hashes definitive for the new values of the attributes. This would involve throwing away the previous attributes entirely. So you would have to be *very* careful about modifying the hashes, but you would have complete flexibility. Comments? I don't think this will go into 1.1.3, though... Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On 8/23/06, Alan DeKok <aland@deployingradius.com> wrote:
I see the patch you're referring to, but after rethinking my question, I think what I'm really trying to do is rewrite $RAD_REQUEST, not $RAD_REPLY, and it does not appear that I can alter $RAD_REQUEST in any way - either change or add.
Hmm... looking into it in a little more detail, I think it would be even easier to do it another way. The code in CVS head has been updated to allow for ":=", to over-write existing attributes. But I think it might be even easier to simply use the hashes as-is, and replace the existing attribute lists.
i.e. put the attributes into perl hashes, and then make those perl hashes definitive for the new values of the attributes. This would involve throwing away the previous attributes entirely. So you would have to be *very* careful about modifying the hashes, but you would have complete flexibility.
Comments? I don't think this will go into 1.1.3, though...
In my opinion - brilliant. This is exactly what we need (for both requests and replies). Even if it was just in cvs would save us a lot of hastle. Simply a great feature :-) regards pshemko
Alan DeKok wrote:
I see the patch you're referring to, but after rethinking my question, I think what I'm really trying to do is rewrite $RAD_REQUEST, not $RAD_REPLY, and it does not appear that I can alter $RAD_REQUEST in any way - either change or add.
Hmm... looking into it in a little more detail, I think it would be even easier to do it another way. The code in CVS head has been updated to allow for ":=", to over-write existing attributes. But I think it might be even easier to simply use the hashes as-is, and replace the existing attribute lists.
i.e. put the attributes into perl hashes, and then make those perl hashes definitive for the new values of the attributes. This would involve throwing away the previous attributes entirely. So you would have to be *very* careful about modifying the hashes, but you would have complete flexibility.
Comments? I don't think this will go into 1.1.3, though...
That's exactly what I'm looking for.
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Wed 23 Aug 2006 01:49, Alan DeKok wrote:
I see the patch you're referring to, but after rethinking my question, I think what I'm really trying to do is rewrite $RAD_REQUEST, not $RAD_REPLY, and it does not appear that I can alter $RAD_REQUEST in any way - either change or add.
Hmm... looking into it in a little more detail, I think it would be even easier to do it another way. The code in CVS head has been updated to allow for ":=", to over-write existing attributes. But I think it might be even easier to simply use the hashes as-is, and replace the existing attribute lists.
i.e. put the attributes into perl hashes, and then make those perl hashes definitive for the new values of the attributes. This would involve throwing away the previous attributes entirely. So you would have to be *very* careful about modifying the hashes, but you would have complete flexibility.
That would seem like th logical way to do it, and would certainly make the perl code clearer.. -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Peter Nixon <listuser@peternixon.net> wrote:
That would seem like th logical way to do it, and would certainly make the perl code clearer..
Ok. Unless Boian Jordanov has concerns, I'll commit a patch in a few days. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Wednesday 23 August 2006 20:25, Alan DeKok wrote:
Peter Nixon <listuser@peternixon.net> wrote:
That would seem like th logical way to do it, and would certainly make the perl code clearer..
Ok. Unless Boian Jordanov has concerns, I'll commit a patch in a few days.
Please i have no concerns :-) -- Best Regards, Boian Jordanov SNE Orbitel - Next Generation Telecom tel. +359 2 4004 723 tel. +359 2 4004 002
Hi I've noticed this comment in the cvs log (for rlm_perl.c): Over-write existing vp's with new ones. This means that the Perl module works more like the other modules, which have absolute power over the VP's, and less like the "users" file, which updates the VP's via operators, etc So I've compiled the source and gave it a try, but it behaved exactly as the stable version - didn't replace nor removed any attributes. Is this supposed to work? I tested the pre and post proxy methods: rad_recv: Access-Request packet from host 127.0.0.1 port 32785, id=96, length=62 User-Password = "test" User-Name = "test" Service-Type = Framed-User Framed-Protocol = PPP NAS-IP-Address = a.b.c.d Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 rlm_realm: No '@' in User-Name = "test", looking up realm NULL rlm_realm: No such realm "NULL" perl_pool: item 0x82013e0 asigned new request. Handled so far: 1 found interpetator at address 0x82013e0 rlm_perl: Added pair Framed-Protocol = PPP rlm_perl: Added pair User-Name = test rlm_perl: Added pair User-Password = test rlm_perl: Added pair Service-Type = Framed-User rlm_perl: Added pair NAS-IP-Address = a.b.c.d rlm_perl: Added pair Proxy-To-Realm = quik rlm_perl: Added pair Stripped-User-Name = test perl_pool total/active/spare [32/0/32] Unreserve perl at address 0x82013e0 modcall: group authorize returns ok for request 0 Processing the pre-proxy section of radiusd.conf modcall: entering group pre-proxy for request 0 perl_pool: item 0x840f4e0 asigned new request. Handled so far: 1 found interpetator at address 0x840f4e0 rlm_perl: entering pre-proxy rlm_perl: Added pair Framed-Protocol = PPP rlm_perl: Added pair User-Name = testuser rlm_perl: Added pair User-Password = test rlm_perl: Added pair Service-Type = Framed-User rlm_perl: Added pair Realm = quik rlm_perl: Added pair NAS-IP-Address = a.b.c.d rlm_perl: Added pair Stripped-User-Name = test rlm_perl: Added pair Proxy-To-Realm = quik rlm_perl: Added pair Framed-Protocol = PPP rlm_perl: Added pair User-Name = test rlm_perl: Added pair User-Password = test rlm_perl: Added pair Proxy-State = 0x3936 rlm_perl: Added pair Service-Type = Framed-User rlm_perl: Added pair Realm = quik rlm_perl: Added pair NAS-IP-Address = a.b.c.d perl_pool total/active/spare [32/0/32] Unreserve perl at address 0x840f4e0 modcall: group pre-proxy returns updated for request 0 Sending Access-Request of id 197 to x.y.z.103 port 1812 Framed-Protocol = PPP User-Name = "test" User-Password = "test" Proxy-State = 0x3936 Service-Type = Framed-User NAS-IP-Address = a.b.c.d --- Walking the entire request list --- Waking up in 1 seconds... rad_recv: Access-Accept packet from host x.y.z.103 port 1812, id=197, length=30 Framed-IP-Address = 192.168.1.65 Proxy-State = 0x3936 Processing the post-proxy section of radiusd.conf modcall: entering group post-proxy for request 0 perl_pool: item 0x85f6b88 asigned new request. Handled so far: 1 found interpetator at address 0x85f6b88 rlm_perl: entering post-proxy rlm_perl: Added pair Framed-Protocol = PPP rlm_perl: Added pair User-Name = testuser rlm_perl: Added pair User-Password = test rlm_perl: Added pair Service-Type = Framed-User rlm_perl: Added pair Realm = quik rlm_perl: Added pair NAS-IP-Address = a.b.c.d rlm_perl: Added pair Framed-IP-Address = 10.10.1.1 rlm_perl: Added pair Proxy-To-Realm = quik rlm_perl: Added pair Stripped-User-Name = test rlm_perl: Added pair Framed-Protocol = PPP rlm_perl: Added pair User-Name = test rlm_perl: Added pair User-Password = test rlm_perl: Added pair Service-Type = Framed-User rlm_perl: Added pair Proxy-State = 0x3936 rlm_perl: Added pair Realm = quik rlm_perl: Added pair NAS-IP-Address = a.b.c.d rlm_perl: Added pair Proxy-State = 0x3936 rlm_perl: Added pair Framed-IP-Address = 192.168.1.65 perl_pool total/active/spare [32/0/32] Unreserve perl at address 0x85f6b88 modcall: group post-proxy returns updated for request 0 authorize: Skipping authorize in post-proxy stage rad_check_password: Found Auth-Type rad_check_password: Auth-Type = Accept, accepting the user Sending Access-Accept of id 96 to 127.0.0.1 port 32785 Framed-IP-Address = 10.10.1.1 Framed-IP-Address = 192.168.1.65 Finished request 0 Going to the next request Waking up in 1 seconds... It looks like the content of the original hashes is still being kept. perl code: #add attributes to the request sub sanitise { my ($login,$realm) = split(/\@/, $RAD_REQUEST{'User-Name'}); $RAD_CHECK{'REALM'} = $realm; $RAD_CHECK{'Stripped-User-Name'} = $login; } # Function to handle pre_proxy sub pre_proxy { &radiusd::radlog(1, "entering pre-proxy"); $RAD_REQUEST{'User-Name'} = 'testuser'; return RLM_MODULE_OK; } # Function to handle post_proxy sub post_proxy { &radiusd::radlog(1, "entering post-proxy"); $RAD_REPLY{'Framed-IP-Address'} = '10.10.1.1'; return RLM_MODULE_OK; } # Function to handle authorize sub authorize { #pre-process the packet &sanitise(); if ($RAD_CHECK{'Realm'} == 'adsl.com'){ $RAD_CHECK{'Proxy-To-Realm'} = 'quik'; } return RLM_MODULE_OK; } regards pshemko
"Pshem Kowalczyk" <pshem.k@gmail.com> wrote:
So I've compiled the source and gave it a try, but it behaved exactly as the stable version - didn't replace nor removed any attributes. Is this supposed to work? I tested the pre and post proxy methods: ... # Function to handle pre_proxy sub pre_proxy {
&radiusd::radlog(1, "entering pre-proxy");
$RAD_REQUEST{'User-Name'} = 'testuser';
You're re-writing the request packet (i.e. the one from the NAS), not the packet that's about to be sent to the home server. Try: $RAD_PROXY_REQUEST{'User-Name'} = 'testuser';
# Function to handle post_proxy sub post_proxy {
&radiusd::radlog(1, "entering post-proxy"); $RAD_REPLY{'Framed-IP-Address'} = '10.10.1.1';
That works. The debug log you posted shows that in the reply. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On 8/29/06, Alan DeKok <aland@deployingradius.com> wrote:
"Pshem Kowalczyk" <pshem.k@gmail.com> wrote:
So I've compiled the source and gave it a try, but it behaved exactly as the stable version - didn't replace nor removed any attributes. Is this supposed to work? I tested the pre and post proxy methods: ... # Function to handle pre_proxy sub pre_proxy {
&radiusd::radlog(1, "entering pre-proxy");
$RAD_REQUEST{'User-Name'} = 'testuser';
You're re-writing the request packet (i.e. the one from the NAS), not the packet that's about to be sent to the home server.
Try: $RAD_PROXY_REQUEST{'User-Name'} = 'testuser';
I added: use vars qw(%RAD_REQUEST %RAD_REPLY %RAD_CHECK %RAD_PROXY_REQUEST); and it didn't work, change resulted in the following debug: rad_recv: Access-Request packet from host 127.0.0.1 port 32787, id=15, length=62 User-Password = "test" User-Name = "test" Service-Type = Framed-User Framed-Protocol = PPP NAS-IP-Address = a.b.c.d Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 rlm_realm: No '@' in User-Name = "test", looking up realm NULL rlm_realm: No such realm "NULL" perl_pool: item 0x8201620 asigned new request. Handled so far: 1 found interpetator at address 0x8201620 rlm_perl: Added pair Framed-Protocol = PPP rlm_perl: Added pair User-Name = test rlm_perl: Added pair User-Password = test rlm_perl: Added pair Service-Type = Framed-User rlm_perl: Added pair NAS-IP-Address = a.b.c.d rlm_perl: Added pair Proxy-To-Realm = quik rlm_perl: Added pair Stripped-User-Name = test perl_pool total/active/spare [2/0/2] Unreserve perl at address 0x8201620 modcall: group authorize returns ok for request 0 Processing the pre-proxy section of radiusd.conf modcall: entering group pre-proxy for request 0 perl_pool: item 0x840f8c8 asigned new request. Handled so far: 1 found interpetator at address 0x840f8c8 rlm_perl: entering pre-proxy rlm_perl: Added pair Framed-Protocol = PPP rlm_perl: Added pair User-Name = test rlm_perl: Added pair User-Password = test rlm_perl: Added pair Service-Type = Framed-User rlm_perl: Added pair Realm = quik rlm_perl: Added pair NAS-IP-Address = a.b.c.d rlm_perl: Added pair Stripped-User-Name = test rlm_perl: Added pair Proxy-To-Realm = quik rlm_perl: Added pair Framed-Protocol = PPP rlm_perl: Added pair User-Name = test rlm_perl: Added pair User-Password = test rlm_perl: Added pair Proxy-State = 0x3135 rlm_perl: Added pair Service-Type = Framed-User rlm_perl: Added pair Realm = quik rlm_perl: Added pair NAS-IP-Address = a.b.c.d perl_pool total/active/spare [2/0/2] Unreserve perl at address 0x840f8c8 modcall: group pre-proxy returns ok for request 0 Sending Access-Request of id 22 to x.y.z.103 port 1812 Framed-Protocol = PPP User-Name = "test" User-Password = "test" Proxy-State = 0x3135 Service-Type = Framed-User NAS-IP-Address = a.b.c.d So this time the new value of User-Name ('testuser') doesn't even show in the debug.
# Function to handle post_proxy sub post_proxy {
&radiusd::radlog(1, "entering post-proxy"); $RAD_REPLY{'Framed-IP-Address'} = '10.10.1.1';
That works. The debug log you posted shows that in the reply.
Well, yes it works, but it didn't replace the original value: Sending Access-Accept of id 96 to 127.0.0.1 port 32785 Framed-IP-Address = 10.10.1.1 Framed-IP-Address = 192.168.1.65 So now I have two, which confuses the NAS. I tried to remove whole key from the hash using the 'delete' function and add it afterwards, but it didn't seem to work. It looks like the original attributes are added anyway after the results from rlm_perl (version 1.37) In our situation we have to have control over the IPs send to the NASes. Thx for all the hints pshemko
"Pshem Kowalczyk" <pshem.k@gmail.com> wrote:
$RAD_REQUEST{'User-Name'} = 'testuser';
You're re-writing the request packet (i.e. the one from the NAS), not the packet that's about to be sent to the home server.
Try: $RAD_PROXY_REQUEST{'User-Name'} = 'testuser';
I added: use vars qw(%RAD_REQUEST %RAD_REPLY %RAD_CHECK %RAD_PROXY_REQUEST);
and it didn't work, change resulted in the following debug:
That isn't what I said to do. Are you going to follow my recommendations? Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On 8/30/06, Alan DeKok <aland@deployingradius.com> wrote:
"Pshem Kowalczyk" <pshem.k@gmail.com> wrote:
$RAD_REQUEST{'User-Name'} = 'testuser';
You're re-writing the request packet (i.e. the one from the NAS), not the packet that's about to be sent to the home server.
Try: $RAD_PROXY_REQUEST{'User-Name'} = 'testuser';
I added: use vars qw(%RAD_REQUEST %RAD_REPLY %RAD_CHECK %RAD_PROXY_REQUEST);
and it didn't work, change resulted in the following debug:
That isn't what I said to do.
Are you going to follow my recommendations?
You're right, that what happens when I do to many things at once. Regarding the post-proxy - I checked the rlm_perl code and the post-proxy packet should be referenced as RAD_REQUEST_PROXY_REPLY not simply RAD_REPLY, after discovering that - everything works flawlessly Sorry for the trouble and thx for the great work :-) kind regards pshemko
Is this in the CVS head, yet? -jc Alan DeKok wrote:
Peter Nixon <listuser@peternixon.net> wrote:
That would seem like th logical way to do it, and would certainly make the perl code clearer..
Ok. Unless Boian Jordanov has concerns, I'll commit a patch in a few days.
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Justin Church <jcc@unc.edu> wrote:
Is this in the CVS head, yet?
Yes. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Thanks for the great work, Alan. I've built the latest CVS head and am able to manipulate the attributes in %RAD_REQUEST with rlm_perl. However, I notice that radrelay has been deprecated and the functionality moved into radiusd. How am I to run simultaneous instances of radiusd on the same host - 1 to listen to type 'acct' and 1 to listen to type 'detail'? I apologize if I'm missing something simple. Also, when I try to run 'radiusd -n radrelay', I get an Abort with the following radius.log entries: Wed Sep 6 11:31:19 2006 : Info: FreeRADIUS Version 2.0.0-pre0, for host i686-pc-linux-gnu, built on Sep 6 2006 at 10:15:27 Wed Sep 6 11:31:19 2006 : Info: Starting - reading configuration files ... Wed Sep 6 11:31:19 2006 : Error: Assertion failed in listen.c, line 1996 root@rtc306:/usr/local/var/log/radius# radiusd -v radiusd: FreeRADIUS Version 2.0.0-pre0, for host i686-pc-linux-gnu, built on Sep 6 2006 at 10:15:27 Thanks. -jc Alan DeKok wrote:
Justin Church <jcc@unc.edu> wrote:
Is this in the CVS head, yet?
Yes.
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Justin Church <jcc@unc.edu> wrote:
However, I notice that radrelay has been deprecated and the functionality moved into radiusd. How am I to run simultaneous instances of radiusd on the same host - 1 to listen to type 'acct' and 1 to listen to type 'detail'? I apologize if I'm missing something simple.
Yes. See raddb/radrelay.conf
Wed Sep 6 11:31:19 2006 : Info: FreeRADIUS Version 2.0.0-pre0, for host i686-pc-linux-gnu, built on Sep 6 2006 at 10:15:27 Wed Sep 6 11:31:19 2006 : Info: Starting - reading configuration files ... Wed Sep 6 11:31:19 2006 : Error: Assertion failed in listen.c, line 1996
That's a bug. I've just committed a fix. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
OK. The patch worked, since I can now run radiusd -n radrelay w/o the Abort, but I still am not seeing a way to replicate to multiple accounting servers with radiusd -n radrelay. I need to take accounting requests that arrive at "main-radius" in "radrelay-detail" and replicate them to "remote-radius1", "remote-radius2", "remote-radius3" in parallel. It appears as if my only two options in radrelay.conf are to store accounting data in sql or proxy to other servers. Proxy is closer to what I want, but from looking at proxy.conf, it seems I can only proxy each accounting request received to a single remote-radius server either in failover or round-robin mode. With the old radrelay, I believe I could have just run #radrelay -r remote-radius1 radrelay-detail; radrelay -r remote-radius2 radrelay-detail; radrelay -r remote-radius3 radrelay-detail. Am I missing something, and is this still possible with radiusd -n radrelay? Thanks. -jc Alan DeKok wrote:
Justin Church <jcc@unc.edu> wrote:
However, I notice that radrelay has been deprecated and the functionality moved into radiusd. How am I to run simultaneous instances of radiusd on the same host - 1 to listen to type 'acct' and 1 to listen to type 'detail'? I apologize if I'm missing something simple.
Yes. See raddb/radrelay.conf
Wed Sep 6 11:31:19 2006 : Info: FreeRADIUS Version 2.0.0-pre0, for host i686-pc-linux-gnu, built on Sep 6 2006 at 10:15:27 Wed Sep 6 11:31:19 2006 : Info: Starting - reading configuration files ... Wed Sep 6 11:31:19 2006 : Error: Assertion failed in listen.c, line 1996
That's a bug. I've just committed a fix.
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Justin Church <jcc@unc.edu> wrote:
OK. The patch worked, since I can now run radiusd -n radrelay w/o the Abort, but I still am not seeing a way to replicate to multiple accounting servers with radiusd -n radrelay.
Unfortunately, it doesn't yet do that. The issue is that the server core is really designed to forward packets, not to clone them. I think it's possible to clone the packets, it just requires additional work in the server core.
I need to take accounting requests that arrive at "main-radius" in "radrelay-detail" and replicate them to "remote-radius1", "remote-radius2", "remote-radius3" in parallel. It appears as if my only two options in radrelay.conf are to store accounting data in sql or proxy to other servers.
You can do more than that. Pretty much anything the server can do is valid in radrelay, it's just that the example config is simpler.
With the old radrelay, I believe I could have just run #radrelay -r remote-radius1 radrelay-detail; radrelay -r remote-radius2 radrelay-detail; radrelay -r remote-radius3 radrelay-detail.
i.e. one radrelay per detail file. You can still do this with the new code, you just have to create "radrelay1.conf", radrelay2.conf", etc. It's a big pain, and something that should be fixed before 2.0.
Am I missing something, and is this still possible with radiusd -n radrelay?
Yes, it is. But it's more work. And looking at the conf files, I think the main "libdir", "raddbdir", etc. stuff at the top should be moved into a separate "directories.conf" file. That way all of the other "radiusd.conf" and "radrelay.conf" files can just $INCLUDE it, which gives a central point for storing all changes. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Wed, 6 Sep 2006, Alan DeKok wrote:
Justin Church <jcc@unc.edu> wrote:
OK. The patch worked, since I can now run radiusd -n radrelay w/o the Abort, but I still am not seeing a way to replicate to multiple accounting servers with radiusd -n radrelay.
Unfortunately, it doesn't yet do that. The issue is that the server core is really designed to forward packets, not to clone them.
I think it's possible to clone the packets, it just requires additional work in the server core.
Just a side note on the clone packets issue i ve come across it in another situation. We act as a proxy for various ISPs and we need to have a way to replicate accounting-on/off packets (which obviously don't carry a username@realm attribute) to all ISPs. But currently this is not possible since we have a server logic of one request,one thread. Being able to use multiple Proxy-To-Realm attributes would be great.
I need to take accounting requests that arrive at "main-radius" in "radrelay-detail" and replicate them to "remote-radius1", "remote-radius2", "remote-radius3" in parallel. It appears as if my only two options in radrelay.conf are to store accounting data in sql or proxy to other servers.
You can do more than that. Pretty much anything the server can do is valid in radrelay, it's just that the example config is simpler.
With the old radrelay, I believe I could have just run #radrelay -r remote-radius1 radrelay-detail; radrelay -r remote-radius2 radrelay-detail; radrelay -r remote-radius3 radrelay-detail.
i.e. one radrelay per detail file.
You can still do this with the new code, you just have to create "radrelay1.conf", radrelay2.conf", etc. It's a big pain, and something that should be fixed before 2.0.
Am I missing something, and is this still possible with radiusd -n radrelay?
Yes, it is. But it's more work.
And looking at the conf files, I think the main "libdir", "raddbdir", etc. stuff at the top should be moved into a separate "directories.conf" file. That way all of the other "radiusd.conf" and "radrelay.conf" files can just $INCLUDE it, which gives a central point for storing all changes.
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Kostas Kalevras Network Operations Center kkalev@noc.ntua.gr National Technical University of Athens, Greece Work Phone: +30 210 7721861 'Go back to the shadow' Gandalf
On Thu 07 Sep 2006 08:05, Kostas Kalevras wrote:
On Wed, 6 Sep 2006, Alan DeKok wrote:
Justin Church <jcc@unc.edu> wrote:
OK. The patch worked, since I can now run radiusd -n radrelay w/o the Abort, but I still am not seeing a way to replicate to multiple accounting servers with radiusd -n radrelay.
Unfortunately, it doesn't yet do that. The issue is that the server core is really designed to forward packets, not to clone them.
I think it's possible to clone the packets, it just requires additional work in the server core.
Just a side note on the clone packets issue i ve come across it in another situation. We act as a proxy for various ISPs and we need to have a way to replicate accounting-on/off packets (which obviously don't carry a username@realm attribute) to all ISPs. But currently this is not possible since we have a server logic of one request,one thread. Being able to use multiple Proxy-To-Realm attributes would be great.
I second this. -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Kostas Kalevras <kkalev@noc.ntua.gr> wrote:
Just a side note on the clone packets issue i ve come across it in another situation. We act as a proxy for various ISPs and we need to have a way to replicate accounting-on/off packets (which obviously don't carry a username@realm attribute) to all ISPs. But currently this is not possible since we have a server logic of one request,one thread. Being able to use multiple Proxy-To-Realm attributes would be great.
I think the easiest way to do this is to write a special-purpose 1-N proxying server. It's special purpose enough that I'm not sure that work belongs in the server core. i.e. Doing N proxies means what, exactly for pre/post-proxy sections? Do we add a queue of proxied packets to the REQUEST? The 1-N proxying server can look for special "proxy to X" attributes in the packet, strip them out, and proxy the packet to N different places. It can even read proxy.conf, so there's one source for configuration files. With a little more work, it can also read the "detail" files, and be radrelay, too. I don't think that's hard to do. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan DeKok wrote:
Kostas Kalevras <kkalev@noc.ntua.gr> wrote:
Just a side note on the clone packets issue i ve come across it in another situation. We act as a proxy for various ISPs and we need to have a way to replicate accounting-on/off packets (which obviously don't carry a username@realm attribute) to all ISPs. But currently this is not possible since we have a server logic of one request,one thread. Being able to use multiple Proxy-To-Realm attributes would be great.
I think the easiest way to do this is to write a special-purpose 1-N proxying server. It's special purpose enough that I'm not sure that work belongs in the server core. i.e. Doing N proxies means what, exactly for pre/post-proxy sections? Do we add a queue of proxied packets to the REQUEST?
The 1-N proxying server can look for special "proxy to X" attributes in the packet, strip them out, and proxy the packet to N different places. It can even read proxy.conf, so there's one source for configuration files. With a little more work, it can also read the "detail" files, and be radrelay, too.
How would the proxy.conf work? Would you define N identical realms with different remote servers, and the 1-N proxy server would replicate to the first N matches it finds in proxy.conf? -jc
I don't think that's hard to do.
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Justin Church <jcc@unc.edu> wrote:
How would the proxy.conf work? Would you define N identical realms with different remote servers, and the 1-N proxy server would replicate to the first N matches it finds in proxy.conf?
That's an option. I'm open to suggestions as to how to configure it. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Thu 07 Sep 2006 15:07, Alan DeKok wrote:
Kostas Kalevras <kkalev@noc.ntua.gr> wrote:
Just a side note on the clone packets issue i ve come across it in another situation. We act as a proxy for various ISPs and we need to have a way to replicate accounting-on/off packets (which obviously don't carry a username@realm attribute) to all ISPs. But currently this is not possible since we have a server logic of one request,one thread. Being able to use multiple Proxy-To-Realm attributes would be great.
I think the easiest way to do this is to write a special-purpose 1-N proxying server. It's special purpose enough that I'm not sure that work belongs in the server core. i.e. Doing N proxies means what, exactly for pre/post-proxy sections? Do we add a queue of proxied packets to the REQUEST?
The 1-N proxying server can look for special "proxy to X" attributes in the packet, strip them out, and proxy the packet to N different places. It can even read proxy.conf, so there's one source for configuration files. With a little more work, it can also read the "detail" files, and be radrelay, too.
Being able to selectively replicate an accounting packet N times may not be a standard configuration (although certainly usefull) but proxying accounting-on/off packets to some/all downstream servers is something that almost _everyone_ proxying accounting will want to do. This probaby warrants a new config option in proxy.conf (acctonoff-shotgun=yes/no) In particular any downstream servers running ippools need this information... Not to mention people who charge by the minute for a particular service.. Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Was there any final word on the direction of this and when it might be available? Thanks. -jc Peter Nixon wrote:
On Thu 07 Sep 2006 15:07, Alan DeKok wrote:
Kostas Kalevras <kkalev@noc.ntua.gr> wrote:
Just a side note on the clone packets issue i ve come across it in another situation. We act as a proxy for various ISPs and we need to have a way to replicate accounting-on/off packets (which obviously don't carry a username@realm attribute) to all ISPs. But currently this is not possible since we have a server logic of one request,one thread. Being able to use multiple Proxy-To-Realm attributes would be great. I think the easiest way to do this is to write a special-purpose 1-N proxying server. It's special purpose enough that I'm not sure that work belongs in the server core. i.e. Doing N proxies means what, exactly for pre/post-proxy sections? Do we add a queue of proxied packets to the REQUEST?
The 1-N proxying server can look for special "proxy to X" attributes in the packet, strip them out, and proxy the packet to N different places. It can even read proxy.conf, so there's one source for configuration files. With a little more work, it can also read the "detail" files, and be radrelay, too.
Being able to selectively replicate an accounting packet N times may not be a standard configuration (although certainly usefull) but proxying accounting-on/off packets to some/all downstream servers is something that almost _everyone_ proxying accounting will want to do. This probaby warrants a new config option in proxy.conf (acctonoff-shotgun=yes/no)
In particular any downstream servers running ippools need this information... Not to mention people who charge by the minute for a particular service..
Cheers
------------------------------------------------------------------------
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Justin Church <jcc@unc.edu> wrote:
Was there any final word on the direction of this and when it might be available?
Whenever someone gets time to do the work... Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
I've been playing with freeradius version that contains the patch discussed in this thread, and I'm not receiving any Account-Response packets from the server, even though the request seems to be logged correctly. Here's my radiusd -X for my test packet: jcc@rtc306:/usr/local/share/freeradius$ sudo radiusd -X Config: including file: /usr/local/etc/raddb/radiusd.conf Config: including file: /usr/local/etc/raddb/proxy.conf Config: including file: /usr/local/etc/raddb/clients.conf Config: including file: /usr/local/etc/raddb/snmp.conf Config: including file: /usr/local/etc/raddb/eap.conf Config: including file: /usr/local/etc/raddb/sql.conf Config: including file: /usr/local/etc/raddb/sql/mysql-dialup.conf FreeRADIUS Version 2.0.0-pre0, for host i686-pc-linux-gnu, built on Sep 6 2006 at 16:44:16 Starting - reading configuration files ... read_config_files: reading dictionary main: prefix = "/usr/local" main: localstatedir = "/usr/local/var" main: logdir = "/usr/local/var/log/radius" main: libdir = "/usr/local/lib" main: radacctdir = "/usr/local/var/log/radius/radacct" main: hostname_lookups = no main: max_request_time = 30 main: cleanup_delay = 5 main: max_requests = 1024 main: delete_blocked_requests = 0 main: allow_core_dumps = no main: log_stripped_names = no main: log_file = "/usr/local/var/log/radius/radius.log" main: log_auth = no main: log_auth_badpass = no main: log_auth_goodpass = no main: pidfile = "/usr/local/var/run/radiusd/radiusd.pid" main: checkrad = "/usr/local/sbin/checkrad" main: debug_level = 0 main: proxy_requests = yes log: syslog_facility = "daemon" proxy: retry_delay = 5 proxy: retry_count = 3 proxy: default_fallback = yes proxy: dead_time = 120 proxy: wake_all_if_all_dead = no security: max_attributes = 200 security: reject_delay = 1 security: status_server = no read_config_files: reading realms main: port = 1812 listen: type = "auth" listen: ipaddr = * listen: port = 0 listen: type = "acct" listen: ipaddr = * listen: port = 0 client: secret = "testing123" client: shortname = "localhost" client: nastype = "other" client: secret = "testing123" client: shortname = "localhost" client: secret = "testing123" client: shortname = "jcc-pc" radiusd: entering modules setup Module: Library search path is /usr/local/lib Module: Loaded exec exec: wait = yes exec: input_pairs = "request" exec: shell_escape = yes rlm_exec: wait=yes but no output defined. Did you mean output=none? Module: Instantiated exec (exec) Module: Loaded expr Module: Instantiated expr (expr) Module: Loaded expiration expiration: reply-message = "Password Has Expired " Module: Instantiated expiration (expiration) Module: Loaded logintime logintime: reply-message = "You are calling outside your allowed timespan " logintime: minimum-timeout = 60 Module: Instantiated logintime (logintime) Module: Loaded PAP pap: encryption_scheme = "auto" pap: auto_header = no Module: Instantiated pap (pap) Module: Loaded CHAP Module: Instantiated chap (chap) Module: Loaded MS-CHAP mschap: use_mppe = yes mschap: require_encryption = no mschap: require_strong = no mschap: with_ntdomain_hack = no Module: Instantiated mschap (mschap) Module: Loaded System unix: radwtmp = "/usr/local/var/log/radius/radwtmp" Module: Instantiated unix (unix) Module: Loaded eap eap: default_eap_type = "md5" eap: timer_expire = 60 eap: ignore_unknown_eap_types = no eap: cisco_accounting_username_bug = no rlm_eap: Loaded and initialized type md5 rlm_eap: Loaded and initialized type leap gtc: challenge = "Password: " gtc: auth_type = "PAP" rlm_eap: Loaded and initialized type gtc mschapv2: with_ntdomain_hack = no rlm_eap: Loaded and initialized type mschapv2 Module: Instantiated eap (eap) Module: Loaded preprocess preprocess: huntgroups = "/usr/local/etc/raddb/huntgroups" preprocess: hints = "/usr/local/etc/raddb/hints" preprocess: with_ascend_hack = no preprocess: ascend_channels_per_line = 23 preprocess: with_ntdomain_hack = no preprocess: with_specialix_jetstream_hack = no preprocess: with_cisco_vsa_hack = no preprocess: with_alvarion_vsa_hack = no Module: Instantiated preprocess (preprocess) Module: Loaded realm realm: format = "suffix" realm: delimiter = "@" realm: ignore_default = no realm: ignore_null = no Module: Instantiated realm (suffix) Module: Loaded files files: usersfile = "/usr/local/etc/raddb/users" files: acctusersfile = "/usr/local/etc/raddb/acct_users" files: preproxy_usersfile = "/usr/local/etc/raddb/preproxy_users" files: compat = "no" Module: Instantiated files (files) Module: Loaded Acct-Unique-Session-Id acct_unique: key = "User-Name, Acct-Session-Id, NAS-IP-Address, Client-IP-Address, NAS-Port" Module: Instantiated acct_unique (acct_unique) Module: Loaded perl perl: module = "/usr/local/etc/raddb/ami_handler.pl" perl: func_authorize = "authorize" perl: func_authenticate = "authenticate" perl: func_accounting = "accounting" perl: func_preacct = "preacct" perl: func_checksimul = "checksimul" perl: func_detach = "detach" perl: func_xlat = "xlat" perl: func_pre_proxy = "pre_proxy" perl: func_post_proxy = "post_proxy" perl: func_post_auth = "post_auth" perl: max_clones = 32 perl: start_clones = 5 perl: min_spare_clones = 3 perl: max_spare_clones = 3 perl: cleanup_delay = 5 perl: max_request_per_clone = 0 Module: Instantiated perl (perl) Module: Loaded detail detail: detailfile = "/usr/local/var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d" detail: header = "%t" detail: detailperm = 384 detail: dirperm = 493 detail: locking = no detail: log_packet_header = no Module: Instantiated detail (local-detail) detail: detailfile = "/usr/local/var/log/radius/radacct/radrelay-detail" detail: header = "%t" detail: detailperm = 384 detail: dirperm = 493 detail: locking = yes detail: log_packet_header = no Module: Instantiated detail (radrelay-detail) Module: Loaded radutmp radutmp: filename = "/usr/local/var/log/radius/radutmp" radutmp: username = "%{User-Name}" radutmp: case_sensitive = yes radutmp: check_with_nas = yes radutmp: perm = 384 radutmp: callerid = yes Module: Instantiated radutmp (radutmp) Initializing the thread pool... Listening on authentication address * port 1812 Listening on accounting address * port 1813 Listening on proxy address * port 1814 Ready to process requests. Nothing to do. Sleeping until we see a request. rad_recv: Accounting-Request packet from host 152.2.199.26 port 32813, id=35, length=65 User-Name = "jcc" NAS-Port = 1 Acct-Session-Id = "accounting-session-1" Sip-Transport-Proto = TLS Processing the preacct section of radiusd.conf modcall: entering group preacct for request 0 rlm_acct_unique: WARNING: Attribute Client-IP-Address was not found in request, unique ID MAY be inconsistent rlm_acct_unique: Hashing 'NAS-Port = 1,,NAS-IP-Address = 152.2.199.26,Acct-Session-Id = "accounting-session-1",User-Name = "jcc"' rlm_acct_unique: Acct-Unique-Session-ID = "b9953681ea576605". perl_pool: item 0x8185d50 asigned new request. Handled so far: 1 found interpetator at address 0x8185d50 rlm_perl: Added pair User-Name = jcc rlm_perl: Added pair Acct-Session-Id = accounting-session-1 rlm_perl: Added pair Sip-Transport-Proto = TLS rlm_perl: Added pair Acct-Unique-Session-Id = b9953681ea576605 rlm_perl: Added pair Calling-Station-Id = jcc-church@unc.edu rlm_perl: Added pair NAS-IP-Address = 152.2.199.26 rlm_perl: Added pair NAS-Port = 1 perl_pool total/active/spare [5/0/5] Could not get @DynaLoader::dl_librefs for unloading. Unreserve perl at address 0x8185d50 rlm_realm: No '@' in User-Name = "", looking up realm NULL rlm_realm: No such realm "NULL" modcall: group preacct returns noop for request 0 Processing the accounting section of radiusd.conf modcall: entering group accounting for request 0 radius_xlat: '/usr/local/var/log/radius/radacct/152.2.199.26/detail-20060925' rlm_detail: /usr/local/var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d expands to /usr/local/var/log/radius/radacct/152.2.199.26/detail-20060925 radius_xlat: 'Mon Sep 25 16:05:13 2006' radius_xlat: '/usr/local/var/log/radius/radacct/radrelay-detail' rlm_detail: /usr/local/var/log/radius/radacct/radrelay-detail expands to /usr/local/var/log/radius/radacct/radrelay-detail rlm_detail: Acquired filelock, tried 1 time(s) radius_xlat: 'Mon Sep 25 16:05:13 2006' rlm_detail: Released filelock rlm_unix: no Accounting-Status-Type attribute in request. rlm_radutmp: No Accounting-Status-Type record. modcall: group accounting returns noop for request 0 Finished request 0 Going to the next request --- Walking the entire request list --- Cleaning up request 0 ID 35 with timestamp 45183679 Nothing to do. Sleeping until we see a request. Anything in this debug indicate why the server doesn't send Accounting-Response? Thanks. -jc Alan DeKok wrote:
Peter Nixon <listuser@peternixon.net> wrote:
That would seem like th logical way to do it, and would certainly make the perl code clearer..
Ok. Unless Boian Jordanov has concerns, I'll commit a patch in a few days.
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Justin Church <jcc@unc.edu> wrote:
Anything in this debug indicate why the server doesn't send Accounting-Response?
The server didn't log the accounting information anywhere, therefore it's not safe to tell the NAS that the accoutning information was stored on the server. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
The server created an entry in my detail file. Is that not considered logging? If not, where should I look to see why the server isn't logging? rad_recv: Accounting-Request packet from host 152.2.199.26 port 32839, id=139, length=80 User-Name = "jcc" NAS-Port = 5060 Sip-Src-IP = 152.2.199.26 Sip-Transport-Proto = TLS Acct-Session-Id = "accounting-session-1-id" Processing the preacct section of radiusd.conf modcall: entering group preacct for request 3 rlm_acct_unique: WARNING: Attribute Client-IP-Address was not found in request, unique ID MAY be inconsistent rlm_acct_unique: Hashing 'NAS-Port = 5060,,NAS-IP-Address = 152.2.199.26,Acct-Session-Id = "accounting-session-1-id",User-Name = "jcc"' rlm_acct_unique: Acct-Unique-Session-ID = "7910d35136b9eb7a". rlm_realm: No '@' in User-Name = "jcc", looking up realm NULL rlm_realm: No such realm "NULL" modcall: group preacct returns noop for request 3 Processing the accounting section of radiusd.conf modcall: entering group accounting for request 3 radius_xlat: '/usr/local/var/log/radius/radacct/152.2.199.26/detail-20060925' rlm_detail: /usr/local/var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d expands to /usr/local/var/log/radius/radacct/152.2.199.26/detail-20060925 radius_xlat: 'Mon Sep 25 18:15:08 2006' radius_xlat: '/usr/local/var/log/radius/radacct/radrelay-detail' rlm_detail: /usr/local/var/log/radius/radacct/radrelay-detail expands to /usr/local/var/log/radius/radacct/radrelay-detail rlm_detail: Acquired filelock, tried 1 time(s) radius_xlat: 'Mon Sep 25 18:15:08 2006' rlm_detail: Released filelock rlm_unix: no Accounting-Status-Type attribute in request. rlm_radutmp: No Accounting-Status-Type record. modcall: group accounting returns noop for request 3 Finished request 3 Going to the next request --- Walking the entire request list --- Cleaning up request 3 ID 139 with timestamp 451854ec Nothing to do. Sleeping until we see a request. radrelay-detail: Mon Sep 25 18:15:08 2006 User-Name = "jcc" NAS-Port = 5060 Sip-Src-IP = 152.2.199.26 Sip-Transport-Proto = TLS Acct-Session-Id = "accounting-session-1-id" NAS-IP-Address = 152.2.199.26 Acct-Unique-Session-Id = "7910d35136b9eb7a" Timestamp = 1159222508 Thanks. -jc Alan DeKok wrote:
Justin Church <jcc@unc.edu> wrote:
Anything in this debug indicate why the server doesn't send Accounting-Response?
The server didn't log the accounting information anywhere, therefore it's not safe to tell the NAS that the accoutning information was stored on the server.
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Nevermind. I turned off -X and found this in radius.log: Mon Sep 25 18:19:23 2006 : Error: rlm_unix: no Accounting-Status-Type attribute in request. It shows up in stdout with -X also, but not as an Error, so I overlooked it. Added Accounting-Status-Type to packet, and server is now responding. Thanks. -jc Alan DeKok wrote:
Justin Church <jcc@unc.edu> wrote:
Anything in this debug indicate why the server doesn't send Accounting-Response?
The server didn't log the accounting information anywhere, therefore it's not safe to tell the NAS that the accoutning information was stored on the server.
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
When might this be available? Alan DeKok wrote:
I see the patch you're referring to, but after rethinking my question, I think what I'm really trying to do is rewrite $RAD_REQUEST, not $RAD_REPLY, and it does not appear that I can alter $RAD_REQUEST in any way - either change or add.
Hmm... looking into it in a little more detail, I think it would be even easier to do it another way. The code in CVS head has been updated to allow for ":=", to over-write existing attributes. But I think it might be even easier to simply use the hashes as-is, and replace the existing attribute lists.
i.e. put the attributes into perl hashes, and then make those perl hashes definitive for the new values of the attributes. This would involve throwing away the previous attributes entirely. So you would have to be *very* careful about modifying the hashes, but you would have complete flexibility.
Comments? I don't think this will go into 1.1.3, though...
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Alan DeKok wrote:
I see the patch you're referring to, but after rethinking my question, I think what I'm really trying to do is rewrite $RAD_REQUEST, not $RAD_REPLY, and it does not appear that I can alter $RAD_REQUEST in any way - either change or add.
Hmm... looking into it in a little more detail, I think it would be even easier to do it another way. The code in CVS head has been updated to allow for ":=", to over-write existing attributes. But I think it might be even easier to simply use the hashes as-is, and replace the existing attribute lists.
Sounds good. I assume you'll include %RAD_CHECK, as well as %RAD_REQUEST and %RAD_REPLY in this change. That would bring rlm_perl into line with other authentication modules, which can alter any of the three attribute lists.
i.e. put the attributes into perl hashes, and then make those perl hashes definitive for the new values of the attributes. This would involve throwing away the previous attributes entirely. So you would have to be *very* careful about modifying the hashes, but you would have complete flexibility.
What would be likely to happen if I screw up one of the attribute hashes? If that just screws up the current RADIUS request, I'd say go for it; I'm happy to have the power to shoot myself in the foot. But if it could crash the radiusd, well, I guess I'll have to be *very*, *VERY* careful. -- George C. Kaplan gckaplan@ack.berkeley.edu IST - Infrastructure Services 510-643-0496 University of California at Berkeley
"George C. Kaplan" <gckaplan@ack.berkeley.edu> wrote:
Sounds good. I assume you'll include %RAD_CHECK, as well as %RAD_REQUEST and %RAD_REPLY in this change. That would bring rlm_perl into line with other authentication modules, which can alter any of the three attribute lists.
Yes.
What would be likely to happen if I screw up one of the attribute hashes? If that just screws up the current RADIUS request, I'd say go for it; I'm happy to have the power to shoot myself in the foot. But if it could crash the radiusd, well, I guess I'll have to be *very*, *VERY* careful.
It will only affect one of the attribute lists. The rest of the server will be fine. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On 22/08/06, Alan DeKok <aland@deployingradius.com> wrote:
i.e. put the attributes into perl hashes, and then make those perl hashes definitive for the new values of the attributes. This would involve throwing away the previous attributes entirely. So you would have to be *very* careful about modifying the hashes, but you would have complete flexibility.
Comments? I don't think this will go into 1.1.3, though...
Yes, that sounds like a great idea, and is certainly more intuitive. Of course, you can look forward to lots more people munging their hashes and posting for support ;-) Thanks, Alex
JC> My goal is to inspect the received attributes JC> using rlm_perl in the preacct{} phase before they are written to log in JC> the accounting{} phase and possibly remove/rewrite/add attributes before JC> they are logged. Is this possible with rlm_perl? 1) You are trying this thing: preacct{ if( $RAD_REQUEST{'SomeAttr'} > someExpr ) { $RAD_REQUEST{'SomeAttr'}= NewValue; } } accounting{ logThisToYouDB( $RAD_REQUEST{'SomeAttr'} ); } 2) Why not to do this simply: accounting{ if( $RAD_REQUEST{'SomeAttr'} > someExpr ) { logThisToYouDB( NewValue ) else logThisToYouDB( $RAD_REQUEST{'SomeAttr'} ); } I think allow users to rewrite RAD_REQUEST attributes will be case for errors. Because this is a perverted logic Tell me plz a cause to do 1) not 2)?
participants (9)
-
Alan DeKok -
Alex French -
Boian Jordanov -
George C. Kaplan -
Justin Church -
KES -
Kostas Kalevras -
Peter Nixon -
Pshem Kowalczyk