Re: Pre-proxy attr_filter?
Thanks Chris!
Your patch cleared things up. It's up and filtering now.
It was indeed very simple (well, you have to know what to look for ;-).
Chris
On Mon, 2003-08-11 at 14:57, Chris Brotsos wrote:
At 11:03 AM 8/9/2003, you wrote:
Hi Chris,
I'm having problems finding your mail in the mailinglist history. It
could be too warm here to think about a good keyword to search for...
Can you post it again please?
Hello Chris,
It is attached as a file to this response. Please ignore the stuff about
memset(). I had this version of attr_filter for awhile, and Alan advised me
that the memset function was added to the instantiate function in a later
release. So if you have the memset(inst, 0, sizeof(*inst)); line in your
instantiate function...that's a good thing :o)
Thanks,
Chris Brotsos
? cvsdiff.txt
Index: rlm_attr_filter.c
===
RCS file: /source/radiusd/src/modules/rlm_attr_filter/rlm_attr_filter.c,v
retrieving revision 1.13
diff -u -r1.13 rlm_attr_filter.c
--- rlm_attr_filter.c 7 Jul 2003 19:04:05 - 1.13
+++ rlm_attr_filter.c 11 Aug 2003 12:58:08 -
@@ -3,7 +3,7 @@
* before sending reply to the NAS/Server that sent
* it to us.
*
- * Version: $Id: rlm_attr_filter.c,v 1.13 2003/07/07 19:04:05 aland Exp $
+ * Version: $Id: rlm_attr_filter.c,v 1.12 2002/08/24 16:54:56 aland Exp $
*
* This program is is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License, version 2 if the
@@ -41,7 +41,7 @@
#include radiusd.h
#include modules.h
-static const char rcsid[] = $Id: rlm_attr_filter.c,v 1.13 2003/07/07 19:04:05
aland Exp $;
+static const char rcsid[] = $Id: rlm_attr_filter.c,v 1.12 2002/08/24 16:54:56
aland Exp $;
struct attr_filter_instance {
@@ -152,10 +152,6 @@
int rcode;
inst = rad_malloc(sizeof *inst);
- if (!inst) {
- return -1;
- }
- memset(inst, 0, sizeof(*inst));
if (cf_section_parse(conf, inst, module_config) 0) {
free(inst);
@@ -407,6 +403,238 @@
}
/*
+ * Find the named realm in the database. Create the
+ * set of attribute-value pairs to check and reply with
+ * for this realm from the database.
+ */
+static int attr_filter_postproxy(void *instance, REQUEST *request)
+{
+ struct attr_filter_instance *inst = instance;
+ VALUE_PAIR *request_pairs;
+ VALUE_PAIR **reply_items;
+ VALUE_PAIR *reply_item;
+ VALUE_PAIR *reply_tmp = NULL;
+ VALUE_PAIR *check_item;
+ PAIR_LIST *pl;
+ int found = 0;
+ int compare;
+ int pass, fail;
+#ifdef HAVE_REGEX_H
+ regex_t reg;
+#endif
+ VALUE_PAIR *realmpair;
+REALM *realm;
+char*realmname;
+
+ /*
+ * It's not a proxy reply, so return NOOP
+ */
+
+ if( request-proxy == NULL ) {
+ return( RLM_MODULE_NOOP );
+ }
+
+ request_pairs = request-packet-vps;
+ reply_items = request-proxy_reply-vps;
+
+ /*
+ * Get the realm. Can't use request-config_items as
+ * that gets freed by rad_authenticate use the one
+ * set in the original request vps
+ */
+ realmpair = pairfind(request_pairs, PW_REALM);
+ if(!realmpair) {
+ /*Can't find a realm, so no filtering of attributes
+ *or should we use a DEFAULT entry?
+ *For now, just return NOTFOUND. (maybe NOOP?)
+ */
+ return RLM_MODULE_NOTFOUND;
+ }
+
+ realmname = (char *) realmpair-strvalue;
+realm = realm_find(realmname, FALSE);
+
+ /*
+ * Find the attr_filter profile entry for the realm.
+ */
+ for(pl = inst-attrs; pl; pl = pl-next) {
+
+ /*
+ * If the current entry is NOT a default,
+ * AND the realm does NOT match the current entry,
+ * then skip to the next entry.
+ */
+ if ( (strcmp(pl-name, DEFAULT) != 0)
+ (strcmp(realmname, pl-name) != 0) ) {
+ continue;
+ }
+
+ DEBUG2( attr_filter: Matched entry %s at line %d, pl-name,
pl-lineno);
+
+ found = 1;
+
+ check_item = pl-check;
+
+ while( check_item != NULL ) {
+
+ /*
+ * If it is a SET operator, add the attribute to
+ * the reply list without checking reply_items.
+ *
+ */
+
+ if( check_item-operator == T_OP_SET ) {
+ mypairappend(check_item, reply_tmp);
+
Re: Pre-proxy attr_filter?
Hi Alan,
On Tue, 2003-08-12 at 15:44, Alan DeKok wrote:
Chris van Meerendonk [EMAIL PROTECTED] wrote:
As far as I can see now the problem is that in the acct_users I've got
the following:
DEFAULT Huntgroup-Name == huntgroup, Replicate-To-Realm := realmname
Replicate-To-Realm doesn't work. Don't use it.
Use Proxy-To-Realm.
Ok. I followed the example in raddb/acct_users. The problem is equal. I
found out that I only need attr-filter during preproxy authorize, not
for accounting. Is it possible to simply detect in rlm_attr_filter if it
was called from the authorize section?
The huntgroups are treated different between users and acct_users, looks
like during the accounting-stage the only thing checked in huntgroups is
Called-Station-Id. To make this clear follows here the (hopefully)
relevant part of my config and logging.
In huntgroups I've the following entries:
cust1 Called-Station-Id =~ 1230{2,3}12$, User-Name == chris
cust1 Called-Station-Id =~ 1230{2,3}12$, User-Name == peter
cust1 Realm == customer1, Called-Station-Id =~ 1230{2,3}12$
cust2 Called-Station-Id =~ 1230{2,3}12$
In users:
DEFAULT Huntgroup-Name == cust1, Proxy-To-Realm =+ customer1
DEFAULT Huntgroup-Name == cust2, Proxy-To-Realm =+ customer2
In acct_users:
DEFAULT Huntgroup-Name == cust1, Proxy-To-Realm := customer1
DEFAULT Huntgroup-Name == cust2, Proxy-To-Realm := customer2
The strange thing is that if I dialin with user 'chris' I should be
treated as a Huntgroup cust1 user. Authentication says:
rad_recv: Access-Request packet from host 127.0.0.1:32795, id=84,
length=93
User-Name = chris
Service-Type = Framed-User
NAS-IP-Address = 203.63.154.1
NAS-Port = 1234
Called-Station-Id = 0512300012
Calling-Station-Id = 0523456789
NAS-Port-Type = Sync
User-Password = secret
modcall: entering group authorize
modcall[authorize]: module preprocess returns ok
modcall[authorize]: module attr_filter returns noop
rlm_realm: No '@' in User-Name = chris, looking up realm NULL
rlm_realm: No such realm NULL
modcall[authorize]: module suffix returns noop
huntgroups: Matched cust1 at 35
huntgroups: Matched cust1 at 35
users: Matched DEFAULT at 139
modcall[authorize]: module files returns ok
modcall: group authorize returns ok
modcall: entering group pre-proxy
attr_filter: Matched entry customer1 at line 29
modcall[pre-proxy]: module pre_proxy_filter returns updated
modcall: group pre-proxy returns updated
Accounting logging:
rad_recv: Accounting-Request packet from host 127.0.0.1:32795, id=5,
length=97
User-Name = chris
Service-Type = Framed-User
NAS-IP-Address = 203.63.154.1
NAS-Port = 1234
NAS-Port-Type = Sync
Acct-Session-Id = 1234
Acct-Status-Type = Start
Called-Station-Id = 0512300012
Calling-Station-Id = 0523456789
Acct-Delay-Time = 0
modcall: entering group preacct
modcall[preacct]: module preprocess returns noop
rlm_realm: No '@' in User-Name = chris, looking up realm NULL
rlm_realm: No such realm NULL
modcall[preacct]: module suffix returns noop
huntgroups: Matched cust2 at 53
acct_users: Matched DEFAULT at 8
modcall[preacct]: module files returns ok
modcall: group preacct returns ok
modcall: entering group accounting
rlm_acct_unique: WARNING: Attribute NAS-Port-Id was not found in
request, unique ID MAY be inconsistent
rlm_acct_unique: Hashing ',Client-IP-Address = 127.0.0.1,NAS-IP-Address
= 203.63.154.1,Acct-Session-Id = 1234,User-Name = chris'
rlm_acct_unique: Acct-Unique-Session-ID = 803936e096c5babd.
modcall[accounting]: module acct_unique returns ok
radius_xlat: '/var/log/freeradius/radacct/127.0.0.1/detail-20030813'
rlm_detail:
/var/log/freeradius/radacct/%{Client-IP-Address}/detail-%Y%m%d expands
to /var/log/freeradius/radacct/127.0.0.1/detail-20030813
rlm_detail: Freeradius-Proxied-To set to 127.0.0.1
modcall[accounting]: module detail returns ok
modcall: group accounting returns ok
modcall: entering group pre-proxy
attr_filter: Matched entry customer2 at line 38
modcall[pre-proxy]: module pre_proxy_filter returns updated
modcall: group pre-proxy returns updated
I've really no idea why the huntgroups matching between these two are
different, any ideas?
Thanks,
Chris
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Pre-proxy attr_filter?
At 11:03 AM 8/9/2003, you wrote:
Hi Chris,
I'm having problems finding your mail in the mailinglist history. It
could be too warm here to think about a good keyword to search for...
Can you post it again please?
Hello Chris,
It is attached as a file to this response. Please ignore the stuff about
memset(). I had this version of attr_filter for awhile, and Alan advised me
that the memset function was added to the instantiate function in a later
release. So if you have the memset(inst, 0, sizeof(*inst)); line in your
instantiate function...that's a good thing :o)
Thanks,
Chris Brotsos? cvsdiff.txt
Index: rlm_attr_filter.c
===
RCS file: /source/radiusd/src/modules/rlm_attr_filter/rlm_attr_filter.c,v
retrieving revision 1.13
diff -u -r1.13 rlm_attr_filter.c
--- rlm_attr_filter.c 7 Jul 2003 19:04:05 - 1.13
+++ rlm_attr_filter.c 11 Aug 2003 12:58:08 -
@@ -3,7 +3,7 @@
* before sending reply to the NAS/Server that sent
* it to us.
*
- * Version: $Id: rlm_attr_filter.c,v 1.13 2003/07/07 19:04:05 aland Exp $
+ * Version: $Id: rlm_attr_filter.c,v 1.12 2002/08/24 16:54:56 aland Exp $
*
* This program is is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License, version 2 if the
@@ -41,7 +41,7 @@
#include radiusd.h
#include modules.h
-static const char rcsid[] = $Id: rlm_attr_filter.c,v 1.13 2003/07/07 19:04:05 aland
Exp $;
+static const char rcsid[] = $Id: rlm_attr_filter.c,v 1.12 2002/08/24 16:54:56 aland
Exp $;
struct attr_filter_instance {
@@ -152,10 +152,6 @@
int rcode;
inst = rad_malloc(sizeof *inst);
- if (!inst) {
- return -1;
- }
- memset(inst, 0, sizeof(*inst));
if (cf_section_parse(conf, inst, module_config) 0) {
free(inst);
@@ -407,6 +403,238 @@
}
/*
+ * Find the named realm in the database. Create the
+ * set of attribute-value pairs to check and reply with
+ * for this realm from the database.
+ */
+static int attr_filter_postproxy(void *instance, REQUEST *request)
+{
+ struct attr_filter_instance *inst = instance;
+ VALUE_PAIR *request_pairs;
+ VALUE_PAIR **reply_items;
+ VALUE_PAIR *reply_item;
+ VALUE_PAIR *reply_tmp = NULL;
+ VALUE_PAIR *check_item;
+ PAIR_LIST *pl;
+ int found = 0;
+ int compare;
+ int pass, fail;
+#ifdef HAVE_REGEX_H
+ regex_t reg;
+#endif
+ VALUE_PAIR *realmpair;
+REALM *realm;
+char*realmname;
+
+ /*
+* It's not a proxy reply, so return NOOP
+*/
+
+ if( request-proxy == NULL ) {
+ return( RLM_MODULE_NOOP );
+ }
+
+ request_pairs = request-packet-vps;
+ reply_items = request-proxy_reply-vps;
+
+ /*
+* Get the realm. Can't use request-config_items as
+* that gets freed by rad_authenticate use the one
+* set in the original request vps
+*/
+ realmpair = pairfind(request_pairs, PW_REALM);
+ if(!realmpair) {
+ /*Can't find a realm, so no filtering of attributes
+*or should we use a DEFAULT entry?
+*For now, just return NOTFOUND. (maybe NOOP?)
+*/
+ return RLM_MODULE_NOTFOUND;
+ }
+
+ realmname = (char *) realmpair-strvalue;
+realm = realm_find(realmname, FALSE);
+
+ /*
+* Find the attr_filter profile entry for the realm.
+*/
+ for(pl = inst-attrs; pl; pl = pl-next) {
+
+ /*
+* If the current entry is NOT a default,
+* AND the realm does NOT match the current entry,
+* then skip to the next entry.
+*/
+ if ( (strcmp(pl-name, DEFAULT) != 0)
+ (strcmp(realmname, pl-name) != 0) ) {
+ continue;
+ }
+
+ DEBUG2( attr_filter: Matched entry %s at line %d, pl-name,
pl-lineno);
+
+ found = 1;
+
+ check_item = pl-check;
+
+ while( check_item != NULL ) {
+
+ /*
+* If it is a SET operator, add the attribute to
+* the reply list without checking reply_items.
+*
+*/
+
+ if( check_item-operator == T_OP_SET ) {
+ mypairappend(check_item, reply_tmp);
+ }
+ check_item = check_item-next;
+
+ } /* while( check_item != NULL ) */
+
+ /*
+* Iterate through the reply items, comparing each reply item to
Re: Pre-proxy attr_filter?
On Mon, 2003-08-11 at 16:45, Chris Brotsos wrote:
Another strange thing, if I dialin without a realm, that realm is added
after the files section (Proxy-To-Realm =+ realmname). This works for
authentication, but not for accounting. With pre-proxy an accounting
packet the attr_filter returns 'ok'. In the users, as well as the
acct_users file I have the Proxy-To-Realm item set.
Did you instantiate rlm_files in the preacct section (which is when it will
use acct_users)?
I personally use rlm_realm in the preacct section to take care of proxy-stuff.
My preacct section looks like this:
preacct{
preprocess
suffix
files
}
As far as I can see now the problem is that in the acct_users I've got
the following:
DEFAULT Huntgroup-Name == huntgroup, Replicate-To-Realm := realmname
This works in the users file, but not in acct_users. At least,
Replication works, but the realmname I configured isn't visible in the
attr_filter-module, called from pre-proxy.
This is probably different behaviour for authorize compared to preacct
in rlm_files I guess. Any ideas? Or am I trying to solve this the wrong
way?
Kind regards,
Chris
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Pre-proxy attr_filter?
At 09:15 AM 8/8/2003, you wrote: On Fri, 2003-08-08 at 15:48, Alan DeKok wrote: Chris van Meerendonk [EMAIL PROTECTED] wrote: Is it possible to filter attributes that are sent by using radius proxy to the home-server? Something like attr_filter in the pre-proxy stage? If attr_filter doesn't already have a pre-proxy stage, it should be ~2 minutes to add one. With freeradius 0.9.0 it says: radiusd.conf: attr_filter modules aren't allowed in 'pre-proxy' sections -- they have no such method. I've found the relevant code, will probable be ~2 hours to add (Sorry, I'm not that quick ;-) I'll give it a try. Awhile ago, I sent somebody on the list the post-proxy function for rlm_attr_filter. Take a look at what I changed, and you'll see that it is probably nothing more than taking the authorize function and modifying what reply_items points to for creating a valid pre-proxy function. The only semi-tricky mod to attr_filter was making an accounting function ;o). HTH, Chris Brotsos - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Pre-proxy attr_filter?
On Tue, 2003-08-12 at 15:11, Chris Brotsos wrote: This is probably different behaviour for authorize compared to preacct in rlm_files I guess. Any ideas? Or am I trying to solve this the wrong way? I've never really used the Replicate-To-Realm option, or changed any code regarding said check item, but maybe you need to use Proxy-To-Realm := realmname. I don't remember how the two VPs are handled differently, nor am I sure if you want the functionality of Proxy-To-Realm, but give that a try and see if you don't get what you want. It looks to me it's behaving the same as Replicate-To-Realm so I replaced Replicate by Proxy. I've got two problems right now (please see also my answer to Alan for details). Fist: With accounting I need a slightly different filter than with authorization. For both types pre-proxy is passed and they're both filtered. Actualy I only need filtering with authentication, so if I could detect in rlm_attr_filter by which type of packet it is I can just skip the accounting packets. Of course this makes it a useless extension for freeradius, but I would suit my needs. Second: The huntgroup problem. It looks really weird to me. But I'm still learning ;-) Thanks, Chris - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Pre-proxy attr_filter?
At 09:34 AM 8/11/2003, you wrote: I sent the post-proxy patch...you probably hadn't received it by the time you sent this. Yes, I guess I was a little impatient, a bad attitude of me... I included a patch this time with the post-proxy() and accounting() functions. Pay attention to the accounting function as it will mirror what you are trying to do (unlike authorize()). rlm_attr_filter was not really Can you explain what you mean by that? Well first, I didn't include post-proxy the second time...sorry 'bout that. I just meant that in the accounting function...I didn't look at the request-reply-vps or the request-proxy_reply-vps. I worked with the request-packet-vps because instead of being concerned with what I was sending back the NAS, I was concerned with what I was forwarding to the remote server (so pre-proxy could have been used). Another strange thing, if I dialin without a realm, that realm is added after the files section (Proxy-To-Realm =+ realmname). This works for authentication, but not for accounting. With pre-proxy an accounting packet the attr_filter returns 'ok'. In the users, as well as the acct_users file I have the Proxy-To-Realm item set. Did you instantiate rlm_files in the preacct section (which is when it will use acct_users)? I personally use rlm_realm in the preacct section to take care of proxy-stuff. Chris - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Pre-proxy attr_filter?
At 03:58 AM 8/12/2003, you wrote:
On Mon, 2003-08-11 at 16:45, Chris Brotsos wrote:
Another strange thing, if I dialin without a realm, that realm is added
after the files section (Proxy-To-Realm =+ realmname). This works for
authentication, but not for accounting. With pre-proxy an accounting
packet the attr_filter returns 'ok'. In the users, as well as the
acct_users file I have the Proxy-To-Realm item set.
Did you instantiate rlm_files in the preacct section (which is when it
will
use acct_users)?
I personally use rlm_realm in the preacct section to take care of
proxy-stuff.
My preacct section looks like this:
preacct{
preprocess
suffix
files
}
As far as I can see now the problem is that in the acct_users I've got
the following:
DEFAULT Huntgroup-Name == huntgroup, Replicate-To-Realm := realmname
This works in the users file, but not in acct_users. At least,
Replication works, but the realmname I configured isn't visible in the
attr_filter-module, called from pre-proxy.
This is probably different behaviour for authorize compared to preacct
in rlm_files I guess. Any ideas? Or am I trying to solve this the wrong
way?
I've never really used the Replicate-To-Realm option, or changed any code
regarding said check item, but maybe you need to use Proxy-To-Realm :=
realmname. I don't remember how the two VPs are handled differently, nor
am I sure if you want the functionality of Proxy-To-Realm, but give that a
try and see if you don't get what you want.
HTH,
Chris
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Pre-proxy attr_filter?
Chris van Meerendonk [EMAIL PROTECTED] wrote: As far as I can see now the problem is that in the acct_users I've got the following: DEFAULT Huntgroup-Name == huntgroup, Replicate-To-Realm := realmname Replicate-To-Realm doesn't work. Don't use it. Use Proxy-To-Realm. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Pre-proxy attr_filter?
At 08:06 AM 8/11/2003, you wrote:
On Fri, 2003-08-08 at 15:48, Alan DeKok wrote:
Chris van Meerendonk [EMAIL PROTECTED] wrote:
Is it possible to filter attributes that are sent by using radius proxy
to the home-server? Something like attr_filter in the pre-proxy stage?
If attr_filter doesn't already have a pre-proxy stage, it should be
~2 minutes to add one.
I'm doing something terribly wrong. Can you help me out? I've copied the
attr_filter_authorize routine and renamed it to attr_filter_preproxy.
Debug shows it is passing the routine. Also I put in some extra DEBUG2
lines to verify. It finds the correct realm, compares the entries
against the entries in the users file instead of the data comming from
the NAS. Probably as a result of this, the data is passed whatever the
results of the check are.
Can you give me a hint what I'm doing wrong? (Your 2-minute patch would
be great also ;-)
I sent the post-proxy patch...you probably hadn't received it by the time
you sent this.
I included a patch this time with the post-proxy() and accounting()
functions. Pay attention to the accounting function as it will mirror what
you are trying to do (unlike authorize()). rlm_attr_filter was not really
made to work on the VPS coming back from the NAS (it was intended to work
on VPS going to the NAS), so copying the authorize() function is not going
to do what you wanted.
The module will work on whichever pairs you tell it to. So, for example,
you probably have reply_items = request-reply-vps. The attributes from
the NAS are not in request-reply-vps, but the attributes added from
rlm_files or rlm_fastusers are.
If you are trying to modify the NAS VPs, then you need to work with the
request-packet-vps. So I go through a loop,
for (send_item = request_pairs...) {
while (check) {
}
if (fail ==0 pass 0) {
mypairappend(send_item, send_tmp);
}
}
pairfree(request-packet-vps);
request-packet-vps = send_tmp;
HTH,
Chris Brotsos
Thanks,
Chris
Alan DeKok.
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Index: rlm_attr_filter.c
===
RCS file: /source/radiusd/src/modules/rlm_attr_filter/rlm_attr_filter.c,v
retrieving revision 1.13
diff -u -r1.13 rlm_attr_filter.c
--- rlm_attr_filter.c 7 Jul 2003 19:04:05 - 1.13
+++ rlm_attr_filter.c 11 Aug 2003 13:21:51 -
@@ -3,7 +3,7 @@
* before sending reply to the NAS/Server that sent
* it to us.
*
- * Version: $Id: rlm_attr_filter.c,v 1.13 2003/07/07 19:04:05 aland Exp $
+ * Version: $Id: rlm_attr_filter.c,v 1.12 2002/08/24 16:54:56 aland Exp $
*
* This program is is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License, version 2 if the
@@ -41,7 +41,7 @@
#include radiusd.h
#include modules.h
-static const char rcsid[] = $Id: rlm_attr_filter.c,v 1.13 2003/07/07 19:04:05 aland
Exp $;
+static const char rcsid[] = $Id: rlm_attr_filter.c,v 1.12 2002/08/24 16:54:56 aland
Exp $;
struct attr_filter_instance {
@@ -152,10 +152,6 @@
int rcode;
inst = rad_malloc(sizeof *inst);
- if (!inst) {
- return -1;
- }
- memset(inst, 0, sizeof(*inst));
if (cf_section_parse(conf, inst, module_config) 0) {
free(inst);
@@ -173,7 +169,193 @@
*instance = inst;
return 0;
}
+/* Find the named realm in the database. Create the
+ * set of attribute-value pairs to check and forward with
+ * for this realm from the database.
+ */
+static int attr_filter_accounting(void *instance, REQUEST *request)
+{
+ struct attr_filter_instance *inst = instance;
+ VALUE_PAIR *request_pairs;
+ VALUE_PAIR *send_item;
+ VALUE_PAIR *send_tmp = NULL;
+ VALUE_PAIR *check_item;
+ PAIR_LIST *pl;
+ int found = 0;
+ int compare;
+ int pass, fail;
+#ifdef HAVE_REGEX_H
+ regex_t reg;
+#endif
+ VALUE_PAIR *realmpair;
+ REALM *realm;
+ char*realmname;
+ /*
+* Accounting is a bit different from the other functions.
+* Here we are concerned with what we are going to forward to
+* the remote server as opposed to concerns with what we will send
+* to the NAS based on a proxy reply to an auth request.
+*/
+ request_pairs = request-packet-vps;
+ if (request-packet-code != PW_ACCOUNTING_REQUEST) {
+ return (RLM_MODULE_NOOP);
+ }
+ /* Get the realm from the original request vps. */
+ realmpair = pairfind(request_pairs, PW_REALM);
+ if (!realmpair) {
+ /* If
Re: Pre-proxy attr_filter?
Hi Chris, I'm having problems finding your mail in the mailinglist history. It could be too warm here to think about a good keyword to search for... Can you post it again please? Thanks, Chris On Fri, 2003-08-08 at 16:28, Chris Brotsos wrote: At 09:15 AM 8/8/2003, you wrote: On Fri, 2003-08-08 at 15:48, Alan DeKok wrote: Chris van Meerendonk [EMAIL PROTECTED] wrote: Is it possible to filter attributes that are sent by using radius proxy to the home-server? Something like attr_filter in the pre-proxy stage? If attr_filter doesn't already have a pre-proxy stage, it should be ~2 minutes to add one. With freeradius 0.9.0 it says: radiusd.conf: attr_filter modules aren't allowed in 'pre-proxy' sections -- they have no such method. I've found the relevant code, will probable be ~2 hours to add (Sorry, I'm not that quick ;-) I'll give it a try. Awhile ago, I sent somebody on the list the post-proxy function for rlm_attr_filter. Take a look at what I changed, and you'll see that it is probably nothing more than taking the authorize function and modifying what reply_items points to for creating a valid pre-proxy function. The only semi-tricky mod to attr_filter was making an accounting function ;o). HTH, Chris Brotsos - 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: Pre-proxy attr_filter?
Chris van Meerendonk [EMAIL PROTECTED] wrote: Is it possible to filter attributes that are sent by using radius proxy to the home-server? Something like attr_filter in the pre-proxy stage? If attr_filter doesn't already have a pre-proxy stage, it should be ~2 minutes to add one. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Pre-proxy attr_filter?
I sent the post-proxy patch...you probably hadn't received it by the time you sent this. Yes, I guess I was a little impatient, a bad attitude of me... I included a patch this time with the post-proxy() and accounting() functions. Pay attention to the accounting function as it will mirror what you are trying to do (unlike authorize()). rlm_attr_filter was not really Can you explain what you mean by that? Another strange thing, if I dialin without a realm, that realm is added after the files section (Proxy-To-Realm =+ realmname). This works for authentication, but not for accounting. With pre-proxy an accounting packet the attr_filter returns 'ok'. In the users, as well as the acct_users file I have the Proxy-To-Realm item set. I'll take a look at it tomorrow. Thanks, Chris - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Pre-proxy attr_filter?
On Fri, 2003-08-08 at 15:48, Alan DeKok wrote: Chris van Meerendonk [EMAIL PROTECTED] wrote: Is it possible to filter attributes that are sent by using radius proxy to the home-server? Something like attr_filter in the pre-proxy stage? If attr_filter doesn't already have a pre-proxy stage, it should be ~2 minutes to add one. I'm doing something terribly wrong. Can you help me out? I've copied the attr_filter_authorize routine and renamed it to attr_filter_preproxy. Debug shows it is passing the routine. Also I put in some extra DEBUG2 lines to verify. It finds the correct realm, compares the entries against the entries in the users file instead of the data comming from the NAS. Probably as a result of this, the data is passed whatever the results of the check are. Can you give me a hint what I'm doing wrong? (Your 2-minute patch would be great also ;-) Thanks, Chris Alan DeKok. - 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: Pre-proxy attr_filter?
On Fri, 2003-08-08 at 15:48, Alan DeKok wrote: Chris van Meerendonk [EMAIL PROTECTED] wrote: Is it possible to filter attributes that are sent by using radius proxy to the home-server? Something like attr_filter in the pre-proxy stage? If attr_filter doesn't already have a pre-proxy stage, it should be ~2 minutes to add one. With freeradius 0.9.0 it says: radiusd.conf: attr_filter modules aren't allowed in 'pre-proxy' sections -- they have no such method. I've found the relevant code, will probable be ~2 hours to add (Sorry, I'm not that quick ;-) I'll give it a try. Thanks, Chris Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
