Re: rlm_perl and accounting
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: [EMAIL PROTECTED]:/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:
Re: rlm_perl and accounting
Justin Church [EMAIL PROTECTED] 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
Re: rlm_perl and accounting
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 [EMAIL PROTECTED] 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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl and accounting
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 [EMAIL PROTECTED] 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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl and accounting -- radrelay?
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl and accounting -- radrelay?
Justin Church [EMAIL PROTECTED] 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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl and accounting -- radrelay?
On Wed, 6 Sep 2006, Alan DeKok wrote: Justin Church [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] National Technical University of Athens, Greece Work Phone: +30 210 7721861 'Go back to the shadow' Gandalf - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl and accounting -- radrelay?
On Thu 07 Sep 2006 08:05, Kostas Kalevras wrote: On Wed, 6 Sep 2006, Alan DeKok wrote: Justin Church [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 pgpVso87fuQ9V.pgp Description: PGP signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl and accounting -- radrelay?
Kostas Kalevras [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl and accounting -- radrelay?
Justin Church [EMAIL PROTECTED] 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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl and accounting -- radrelay?
On Thu 07 Sep 2006 15:07, Alan DeKok wrote: Kostas Kalevras [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 pgp6QsEVZXvhz.pgp Description: PGP signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl and accounting -- radrelay?
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 [EMAIL PROTECTED]:/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 [EMAIL PROTECTED] 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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl and accounting -- radrelay?
Justin Church [EMAIL PROTECTED] 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
Re: rlm_perl and accounting -- radrelay?
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 [EMAIL PROTECTED] 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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl and accounting -- radrelay?
Justin Church [EMAIL PROTECTED] 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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl and accounting
Justin Church [EMAIL PROTECTED] 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
Re: rlm_perl and accounting
Pshem Kowalczyk [EMAIL PROTECTED] 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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl and accounting
On 8/29/06, Alan DeKok [EMAIL PROTECTED] wrote:
Pshem Kowalczyk [EMAIL PROTECTED] 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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl and accounting
Pshem Kowalczyk [EMAIL PROTECTED] 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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl and accounting
On 8/30/06, Alan DeKok [EMAIL PROTECTED] wrote:
Pshem Kowalczyk [EMAIL PROTECTED] 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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl and accounting
On Wednesday 23 August 2006 20:25, Alan DeKok wrote: Peter Nixon [EMAIL PROTECTED] 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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl and accounting
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);
Re: rlm_perl and accounting
On 22/08/06, Alan DeKok [EMAIL PROTECTED] wrote: i.e. put the attributes into perl hashes, and then make those perlhashes definitive for the new values of the attributes.This wouldinvolve throwing away the previous attributes entirely.So you wouldhave 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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl and accounting
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 pgpINIAYMb1en.pgp Description: PGP signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl and accounting
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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl and accounting
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[EMAIL PROTECTED] IST - Infrastructure Services 510-643-0496 University of California at Berkeley - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl and accounting
Peter Nixon [EMAIL PROTECTED] 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
Re: rlm_perl and accounting
George C. Kaplan [EMAIL PROTECTED] 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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl and accounting
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. AlexOn 22/08/06, Justin Church [EMAIL PROTECTED] wrote: I'm running freeradius v. 1.1.0 and am trying to use rlm_perl to rewriteaccounting attributes before they are written to log with detail andthen 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
Re: rlm_perl and accounting
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.
[EMAIL PROTECTED]:~/scripts$ perl -v
This is perl, v5.8.7 built for i486-linux-gnu-thread-multi
[EMAIL PROTECTED]:~/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* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl and accounting
Justin Church [EMAIL PROTECTED] 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 - 1.13.4.7
+++ src/modules/rlm_perl/rlm_perl.c 22 Aug 2006 22:08:00 -
@@ -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);
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl and accounting
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
Re: rlm_perl and accounting
On 8/23/06, Alan DeKok [EMAIL PROTECTED] 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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl and accounting
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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
