rlm_attr_filter
hello, I want to filter attributes returned by a proxy, with freeradius 0.9.1, and I can get no result. I am asking myself how rlm_attr_filter can work since it has only an 'authorize' method called before the realm stuff. Why is this module not called in the post-proxy section ? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_attr_filter
=?iso-8859-1?Q?Pascal_S=E9guy?= [EMAIL PROTECTED] wrote: I am asking myself how rlm_attr_filter can work since it has only an 'authorize' method called before the realm stuff. Why is this module not called in the post-proxy section ? Because no one has supplied a patch to make it do that. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_attr_filter
- Original Message - From: Alan DeKok [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 18, 2003 5:50 PM Subject: Re: rlm_attr_filter =?iso-8859-1?Q?Pascal_S=E9guy?= [EMAIL PROTECTED] wrote: I am asking myself how rlm_attr_filter can work since it has only an 'authorize' method called before the realm stuff. Why is this module not called in the post-proxy section ? Because no one has supplied a patch to make it do that. ?? this means this nice module can't serve anything as is ? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_attr_filter
At 10:50 AM 9/18/2003, Alan DeKok wrote: =?iso-8859-1?Q?Pascal_S=E9guy?= [EMAIL PROTECTED] wrote: I am asking myself how rlm_attr_filter can work since it has only an 'authorize' method called before the realm stuff. Why is this module not called in the post-proxy section ? Because no one has supplied a patch to make it do that. I have one, we use it internally here in 'post-proxy' and it works well. I'll commit that later today, so you can pull it in the latest CVS builds from tomorrow on. -Chris -- \\\|||/// \ StarNet Inc. \ Chris Parker \ ~ ~ / \ WX *is* Wireless!\ Director, Engineering | @ @ |\ http://www.starnetwx.net \ (847) 963-0116 oOo---(_)---oOo--\-- \ Wholesale Internet Services - http://www.megapop.net - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_attr_filter
- Original Message - From: Chris Parker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 18, 2003 6:21 PM Subject: Re: rlm_attr_filter Why is this module not called in the post-proxy section ? Because no one has supplied a patch to make it do that. I have one, we use it internally here in 'post-proxy' and it works well. I'll commit that later today, so you can pull it in the latest CVS builds from tomorrow on. Great! Thanks. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
rlm_attr_filter updated, new functionality
The rlm_attr_filter module has been updated with some new functionality. o Each a/v pair in the reply is now compared against *ALL* rules for that attribute. This will allow multiple rules for the same attribute, IE: ... Idle-Timeout = 800, Idle-Timeout = 28800, ... The a/v pair must pass *ALL* rules to be allowed. If there are three rules for the attribute, and it passes 2 and fails 1, the attribute will not be allowed. o Two new operators have been added, to allow better wildcarded permit and deny rules: =*Always report pass !*Always report fail This allows a shortcut to always allow or deny an attribute. IE: ... Reply-Message *= ANY Ascend-Data-Filter *= ANY Proxy-State *= ANY ... This requires less overhead than the regexpression workaround that was in place previously, and is more portable. --- The documentation in 'doc/rlm_attr_filter' has been updated to reflect this, as well as the sample 'raddb/attrs' file. If any questions or problems are noted regarding this change, please post them to the list. -Chris -- \\\|||/// \ StarNet Inc. \Chris Parker \ ~ ~ / \ WX *is* Wireless!\ Director, Engineering | |\ http://www.starnetwx.net \ (847) 963-0116 oOo---(_)---oOo--\-- \ Wholesale Internet Services - http://www.megapop.net - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: rlm_attr_filter + Ascend-Data-Filter
This has been fixed in version 0.5. Even without the fix, the attribute is used properly, it was just displayed incorrectly. At 03:21 PM 3/21/2002 -0800, you wrote: Hi , I am facing a problem with a Ascend-Data-Filter ip in forward tcp est .I am using freeradius version 0.4 on a VA-linux box . When i used radtest or radclient to send a request which matches a profile in radius servers users file ,i almost get everything correctly except that this return attribute looks like X-Ascend-Data-Filter = ip input forward tcp where the est is somehow chopped . I have tried to debug this but could'nt yet find the problem . I have also patched the fix suggested in the attr_filter module but with no change to my output . Ideas ? Thanks , Hemlata. -Original Message- From: Charlie Watts [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 19, 2002 6:17 PM To: Chris Parker Cc: [EMAIL PROTECTED] Subject: Re: rlm_attr_filter + Ascend-Data-Filter On Tue, 19 Mar 2002, Chris Parker wrote: At 03:42 PM 3/19/2002 -0600, Chris Parker wrote: It looks like it's caused by the way FreeRADIUS is building the binary interpretation of the filter. Turned out to actually be problem with 'attr_filter' module. :\ You'll probably hate me for it, but I'm glad to hear it. Glad to hear you found it, that is. Thanks. :-) -- Charlie Watts [EMAIL PROTECTED] Frontier Internet, Inc. http://www.frontier.net/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html __ NetZero is now part of United Online Sign Up for NetZero Platinum Today Only $9.95 per month! http://www.netzero.net - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Randy Moore Axion Information Technologies, Inc. email [EMAIL PROTECTED] phone 301-408-1200 fax301-445-3947 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: rlm_attr_filter + Ascend-Data-Filter
Hi , I am facing a problem with a Ascend-Data-Filter ip in forward tcp est .I am using freeradius version 0.4 on a VA-linux box . When i used radtest or radclient to send a request which matches a profile in radius servers users file ,i almost get everything correctly except that this return attribute looks like X-Ascend-Data-Filter = ip input forward tcp where the est is somehow chopped . I have tried to debug this but could'nt yet find the problem . I have also patched the fix suggested in the attr_filter module but with no change to my output . Ideas ? Thanks , Hemlata. -Original Message- From: Charlie Watts [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 19, 2002 6:17 PM To: Chris Parker Cc: [EMAIL PROTECTED] Subject: Re: rlm_attr_filter + Ascend-Data-Filter On Tue, 19 Mar 2002, Chris Parker wrote: At 03:42 PM 3/19/2002 -0600, Chris Parker wrote: It looks like it's caused by the way FreeRADIUS is building the binary interpretation of the filter. Turned out to actually be problem with 'attr_filter' module. :\ You'll probably hate me for it, but I'm glad to hear it. Glad to hear you found it, that is. Thanks. :-) -- Charlie Watts [EMAIL PROTECTED] Frontier Internet, Inc. http://www.frontier.net/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html __ NetZero is now part of United Online Sign Up for NetZero Platinum Today Only $9.95 per month! http://www.netzero.net - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: rlm_attr_filter + Ascend-Data-Filter
At 03:21 PM 3/21/2002 -0800, Ahire, Hemlata wrote: Hi , I am facing a problem with a Ascend-Data-Filter ip in forward tcp est .I am using freeradius version 0.4 on a VA-linux box . When i used radtest or radclient to send a request which matches a profile in radius servers users file ,i almost get everything correctly except that this return attribute looks like X-Ascend-Data-Filter = ip input forward tcp where the est is somehow chopped . I have tried to debug this but could'nt yet find the problem . I have also patched the fix suggested in the attr_filter module but with no change to my output . Upgrade to the latest CVS. -Chris -- \\\|||/// \ StarNet Inc. \Chris Parker \ ~ ~ / \ WX *is* Wireless!\ Director, Engineering | |\ http://www.starnetwx.net \ (847) 963-0116 oOo---(_)---oOo--\-- \ Wholesale Internet Services - http://www.megapop.net - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_attr_filter + Ascend-Data-Filter
At 08:29 AM 3/19/2002 -0700, Charlie Watts wrote: On Wed, 13 Mar 2002, Chris Parker wrote: I'd just confirm that you are loading the latest libraries. I'm not able to duplicate the problem here with. It *could* be a library mismatch. The next step would be, as described above to get the raw binary data for the attribute that's being passed to 'print_abinary()' to see if it's the data that's bad or the function that's wrong. So it does work for you? With multiple Ascend-Data-Filter items? I did actually get this to duplicate. Not sure what exactly caused it. I'm checking more into it currently. I so hate being different. Hrm. :-/ It doesn't appear to be just you. Don't worry. :) I'm certain I've got the correct libraries. The only rlm_ files I have outside the source are in /usr/local/lib. If I remove them, the server doesn't work. It still doesn't work after a `make install`. Okay, that means it's a current bug. I would appreciate any other suggestions. Thanks for your time so far. I'll post a fix and commit it once you've verified it works for you as well. -Chris -- \\\|||/// \ StarNet Inc. \Chris Parker \ ~ ~ / \ WX *is* Wireless!\ Director, Engineering | |\ http://www.starnetwx.net \ (847) 963-0116 oOo---(_)---oOo--\-- \ Wholesale Internet Services - http://www.megapop.net - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_attr_filter + Ascend-Data-Filter
At 10:31 AM 3/19/2002 -0600, Chris Parker wrote: At 08:29 AM 3/19/2002 -0700, Charlie Watts wrote: On Wed, 13 Mar 2002, Chris Parker wrote: I'd just confirm that you are loading the latest libraries. I'm not able to duplicate the problem here with. It *could* be a library mismatch. The next step would be, as described above to get the raw binary data for the attribute that's being passed to 'print_abinary()' to see if it's the data that's bad or the function that's wrong. So it does work for you? With multiple Ascend-Data-Filter items? I did actually get this to duplicate. Not sure what exactly caused it. I'm checking more into it currently. It looks like it's caused by the way FreeRADIUS is building the binary interpretation of the filter. Good attribute ( ip in forward tcp est ): Ascend-Data-Filter = \001\001\001\000\000\000\000\000\000\000\000\000 \000\000\006\001\000\000\000\000\000\000\000\000 Bad attribute ( ip in forward tcp est ): Ascend-Data-Filter = \001\001\001\000\000\000\000\000\000\000\000\000 \000\000\000\000\000\000\000\000\000\000\000\000 \000\000\000\000\000\000\000\000 There are extra bytes, and the 'tcp' and 'est' bytes are not set. I'm looking into this further, it is definitely a problem with the current server. -Chris -- \\\|||/// \ StarNet Inc. \Chris Parker \ ~ ~ / \ WX *is* Wireless!\ Director, Engineering | |\ http://www.starnetwx.net \ (847) 963-0116 oOo---(_)---oOo--\-- \ Wholesale Internet Services - http://www.megapop.net - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_attr_filter + Ascend-Data-Filter
At 03:42 PM 3/19/2002 -0600, Chris Parker wrote: It looks like it's caused by the way FreeRADIUS is building the binary interpretation of the filter. Turned out to actually be problem with 'attr_filter' module. :\ Here's the patch ( it will be in CVS shortly ): *** rlm_attr_filter.c 2002/03/14 16:49:53 1.7 --- rlm_attr_filter.c 2002/03/19 23:55:13 *** static int attr_filter_authorize(void *i *** 300,308 tmp-lvalue = check_item-lvalue; break; default: !strNcpy((char *)tmp-strvalue, (char *)check_item-strvalue, !sizeof(tmp-strvalue)); tmp-length = check_item-length; break; } --- 300,308 tmp-lvalue = check_item-lvalue; break; default: !memcpy((char *)tmp-strvalue, (char *)check_item-strvalue, !check_item-length); tmp-length = check_item-length; break; } -Chris -- \\\|||/// \ StarNet Inc. \Chris Parker \ ~ ~ / \ WX *is* Wireless!\ Director, Engineering | |\ http://www.starnetwx.net \ (847) 963-0116 oOo---(_)---oOo--\-- \ Wholesale Internet Services - http://www.megapop.net - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_attr_filter + Ascend-Data-Filter
On Tue, 19 Mar 2002, Chris Parker wrote: At 03:42 PM 3/19/2002 -0600, Chris Parker wrote: It looks like it's caused by the way FreeRADIUS is building the binary interpretation of the filter. Turned out to actually be problem with 'attr_filter' module. :\ You'll probably hate me for it, but I'm glad to hear it. Glad to hear you found it, that is. Thanks. :-) -- Charlie Watts [EMAIL PROTECTED] Frontier Internet, Inc. http://www.frontier.net/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_attr_filter + Ascend-Data-Filter
On Tue, 12 Mar 2002, Chris Parker wrote: At 06:20 PM 3/11/2002 -0700, Charlie Watts wrote: On Mon, 11 Mar 2002, Chris Parker wrote: At 10:18 AM 3/11/2002 -0700, Charlie Watts wrote: I would hazzard that your radtest is interpreting the filters incorrectly. I was thinking perhaps it was showing the binary (ergh) versions of them. It was ancient and, indeed, probably broken. No matter, I've switched from it to the freeradius radtest; behaviour is still as described. I uncommented your DEBUG2 lines in rlm_attr_filter.c and re-compiled. Here's an example of what I see when using the := syntax: modcall: entering group authorize modcall[authorize]: module preprocess returns ok attr_filter: Matched entry realm.test at line 79 attr_filter: creating vp Service-Type - 1 - 2 attr_filter: creating vp Login-Service - 1 - 1 attr_filter: creating vp Ascend-Data-Filter - 4 - 0 attr_filter: creating vp Ascend-Data-Filter - 4 - 0 attr_filter: creating vp Ascend-Data-Filter - 4 - 0 attr_filter: creating vp Ascend-Data-Filter - 4 - 0 modcall[authorize]: module attr_filter returns updated That tells you that 'attr_filter' created 6 a/v pairs and added them to the reply. They are all separate vp's at this point. Ascend-Data-Filter = ip input forward 0 Ascend-Data-Filter = ip input forward 0 Ascend-Data-Filter = ip output drop 0 Ascend-Data-Filter = ip input forward 0 Finished request 0 Hmm, now that is a problem, as it shouldn't be setting 0. Is it really setting 0 ? It is getting ip input forward and ip input drop before the 0 - so at least part of the strvalue is getting through. Right? The problem is *possibly* in src/lib/filters.c, as that is where Data-Filters are parsed from text into binary data. I assume you mean print_abinary(), which I only see used once in the whole tree, in src/lib/print.c. If you aren't already, I'd upgrade to the latest CVS version, as there has been some work done at some point in the handling of Data-Filters, but I don't recall if that was before or after the 0.4 release. I'm using CVS. Wouldn't think to ask if I wasn't. :-) -- Charlie Watts [EMAIL PROTECTED] Frontier Internet, Inc. http://www.frontier.net/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_attr_filter + Ascend-Data-Filter
At 05:40 AM 3/13/2002 -0700, Charlie Watts wrote: On Tue, 12 Mar 2002, Chris Parker wrote: At 06:20 PM 3/11/2002 -0700, Charlie Watts wrote: On Mon, 11 Mar 2002, Chris Parker wrote: At 10:18 AM 3/11/2002 -0700, Charlie Watts wrote: I would hazzard that your radtest is interpreting the filters incorrectly. I was thinking perhaps it was showing the binary (ergh) versions of them. It was ancient and, indeed, probably broken. No matter, I've switched from it to the freeradius radtest; behaviour is still as described. I uncommented your DEBUG2 lines in rlm_attr_filter.c and re-compiled. Here's an example of what I see when using the := syntax: modcall: entering group authorize modcall[authorize]: module preprocess returns ok attr_filter: Matched entry realm.test at line 79 attr_filter: creating vp Service-Type - 1 - 2 attr_filter: creating vp Login-Service - 1 - 1 attr_filter: creating vp Ascend-Data-Filter - 4 - 0 attr_filter: creating vp Ascend-Data-Filter - 4 - 0 attr_filter: creating vp Ascend-Data-Filter - 4 - 0 attr_filter: creating vp Ascend-Data-Filter - 4 - 0 modcall[authorize]: module attr_filter returns updated That tells you that 'attr_filter' created 6 a/v pairs and added them to the reply. They are all separate vp's at this point. Ascend-Data-Filter = ip input forward 0 Ascend-Data-Filter = ip input forward 0 Ascend-Data-Filter = ip output drop 0 Ascend-Data-Filter = ip input forward 0 Finished request 0 Hmm, now that is a problem, as it shouldn't be setting 0. Is it really setting 0 ? It is getting ip input forward and ip input drop before the 0 - so at least part of the strvalue is getting through. Right? Maybe. Need to see the binary data for the string, before it's passed to the 'print_abinary()' function. Either the binary data is wrong, or print_abinary() is doing something wrong. The problem is *possibly* in src/lib/filters.c, as that is where Data-Filters are parsed from text into binary data. I assume you mean print_abinary(), which I only see used once in the whole tree, in src/lib/print.c. src/lib/filters.c is where the server takes the attributes and converts it to binary data for the attribute. src/lib/print.c is where it takes the binary data from the attribute and prints it in human readable text. It's possible that one of those is not doing it correctly. If you aren't already, I'd upgrade to the latest CVS version, as there has been some work done at some point in the handling of Data-Filters, but I don't recall if that was before or after the 0.4 release. I'm using CVS. Wouldn't think to ask if I wasn't. :-) I'd just confirm that you are loading the latest libraries. I'm not able to duplicate the problem here with. It *could* be a library mismatch. The next step would be, as described above to get the raw binary data for the attribute that's being passed to 'print_abinary()' to see if it's the data that's bad or the function that's wrong. -Chris -- \\\|||/// \ StarNet Inc. \Chris Parker \ ~ ~ / \ WX *is* Wireless!\ Director, Engineering | |\ http://www.starnetwx.net \ (847) 963-0116 oOo---(_)---oOo--\-- \ Wholesale Internet Services - http://www.megapop.net - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_attr_filter + Ascend-Data-Filter
At 06:20 PM 3/11/2002 -0700, Charlie Watts wrote: On Mon, 11 Mar 2002, Chris Parker wrote: At 10:18 AM 3/11/2002 -0700, Charlie Watts wrote: Hmmm, perhaps try using the += operator there. I don't get them back at all when I use +=. And looking at the docs source, += doesn't seem to be supported. Right, just a thought. := *is* the correct operator for you there. So is it in rlm_attr_filter or the core that the attributes are getting mangled? Neither. And here's what I get back: Vendor-Specific = V529:T242:L34::T1:L1::T1:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0: :T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0: What is this output from? Hrm, that's a non-freeradius radtest client. I was assuming that was the non-decoded binary Ascend-Data-Filter, but it might just be garbage. The freeradius radtest returns the same thing that the debug log shows. I would hazzard that your radtest is interpreting the filters incorrectly. I uncommented your DEBUG2 lines in rlm_attr_filter.c and re-compiled. Here's an example of what I see when using the := syntax: modcall: entering group authorize modcall[authorize]: module preprocess returns ok attr_filter: Matched entry realm.test at line 79 attr_filter: creating vp Service-Type - 1 - 2 attr_filter: creating vp Login-Service - 1 - 1 attr_filter: creating vp Ascend-Data-Filter - 4 - 0 attr_filter: creating vp Ascend-Data-Filter - 4 - 0 attr_filter: creating vp Ascend-Data-Filter - 4 - 0 attr_filter: creating vp Ascend-Data-Filter - 4 - 0 modcall[authorize]: module attr_filter returns updated That tells you that 'attr_filter' created 6 a/v pairs and added them to the reply. They are all separate vp's at this point. Ascend-Data-Filter = ip input forward 0 Ascend-Data-Filter = ip input forward 0 Ascend-Data-Filter = ip output drop 0 Ascend-Data-Filter = ip input forward 0 Finished request 0 Hmm, now that is a problem, as it shouldn't be setting 0. The problem is *possibly* in src/lib/filters.c, as that is where Data-Filters are parsed from text into binary data. It doesn't work even if I just use one Ascend-Data-Filter: realm.test Ascend-Data-Filter := ip in forward dstip 199.45.141.0/24 Still comes out as ip input forward 0. Right, it's either not building the binary data properly, or not decoding it properly. If you aren't already, I'd upgrade to the latest CVS version, as there has been some work done at some point in the handling of Data-Filters, but I don't recall if that was before or after the 0.4 release. (I see some comments in the source about Fall-Through being incomplete. I notice that it -always- falls through, despite Fall-Through = No being set.) Hmmm, I'll take a look at that today, and get Fall-Through = No to be respected. -Chris -- \\\|||/// \ StarNet Inc. \Chris Parker \ ~ ~ / \ WX *is* Wireless!\ Director, Engineering | |\ http://www.starnetwx.net \ (847) 963-0116 oOo---(_)---oOo--\-- \ Wholesale Internet Services - http://www.megapop.net - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: rlm_attr_filter + Ascend-Data-Filter
Hi, I have similar settings that are definitely working, here they are: Ascend-Client-Primary-DNS = x.x.x.x, Ascend-Client-Secondary-DNS = x.x.x.x, Ascend-Data-Filter = ip in forward dstip x.x.x.x/24, Ascend-Data-Filter = ip in drop, Ascend-Data-Filter = ip out forward, X-Ascend-Client-Primary-DNS = x.x.x.x, X-Ascend-Client-Secondary-DNS = x.x.x.x, X-Ascend-Data-Filter = ip in forward dstip x.x.x.x/24, X-Ascend-Data-Filter = ip in drop, X-Ascend-Data-Filter = ip out forward When I use radtest, here is the output: Sending Access-Request of id 186 to 127.0.0.1:1645 User-Name = Password = NAS-IP-Address = auth01 NAS-Port-Id = 1 rad_recv: Access-Accept packet from host 127.0.0.1:1645, id=186, length=308 Service-Type = Framed-User Framed-Protocol = PPP Framed-IP-Address = 255.255.255.254 Framed-MTU = 576 Framed-Compression = Van-Jacobson-TCP-IP Ascend-Client-Primary-DNS = x.x.x.x Ascend-Client-Secondary-DNS = x.x.x.x Ascend-Data-Filter = ip input forward 0 dstip x.x.x.x/24 Ascend-Data-Filter = ip input drop 0 Ascend-Data-Filter = ip output forward 0 X-Ascend-Client-Primary-DNS = x.x.x.x X-Ascend-Client-Secondary-DNS = x.x.x.x X-Ascend-Data-Filter = ip input forward 0 dstip x.x.x.x/24 X-Ascend-Data-Filter = ip input drop 0 X-Ascend-Data-Filter = ip output forward 0 Regards, Edgard Castro [EMAIL PROTECTED] Infrastructure Manager - iBEST S/A. +55 (21) 2220-2211 / +55 (21) 9146-2934 http://www.ibest.com.br -Original Message- From: Charlie Watts [mailto:[EMAIL PROTECTED]] Sent: Monday, March 11, 2002 10:20 PM To: [EMAIL PROTECTED] Subject: Re: rlm_attr_filter + Ascend-Data-Filter On Mon, 11 Mar 2002, Chris Parker wrote: At 10:18 AM 3/11/2002 -0700, Charlie Watts wrote: I'm having trouble with rlm_attr_filter and Ascend-Data-Filter. attrs: acsinc.net Ascend-Data-Filter := ip in forward tcp est, Ascend-Data-Filter := ip in forward dstip 199.45.141.0/24, Ascend-Data-Filter := ip in drop tcp dstport = 25, Ascend-Data-Filter := ip in forward Hmmm, perhaps try using the += operator there. I don't get them back at all when I use +=. And looking at the docs source, += doesn't seem to be supported. And here's some output from the debug log: Sending Access-Accept of id 173 to 199.45.141.1:1026 Ascend-Data-Filter = ip input forward 0 Ascend-Data-Filter = ip input forward 0 Ascend-Data-Filter = ip output drop 0 Ascend-Data-Filter = ip input forward 0 Here they are set as separate attributes, so it's not a problem with the rlm_attr_filter module. So is it in rlm_attr_filter or the core that the attributes are getting mangled? And here's what I get back: Vendor-Specific = V529:T242:L34::T1:L1::T1:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0: L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0: What is this output from? Hrm, that's a non-freeradius radtest client. I was assuming that was the non-decoded binary Ascend-Data-Filter, but it might just be garbage. The freeradius radtest returns the same thing that the debug log shows. I uncommented your DEBUG2 lines in rlm_attr_filter.c and re-compiled. Here's an example of what I see when using the := syntax: modcall: entering group authorize modcall[authorize]: module preprocess returns ok attr_filter: Matched entry realm.test at line 79 attr_filter: creating vp Service-Type - 1 - 2 attr_filter: creating vp Login-Service - 1 - 1 attr_filter: creating vp Ascend-Data-Filter - 4 - 0 attr_filter: creating vp Ascend-Data-Filter - 4 - 0 attr_filter: creating vp Ascend-Data-Filter - 4 - 0 attr_filter: creating vp Ascend-Data-Filter - 4 - 0 modcall[authorize]: module attr_filter returns updated modcall[authorize]: module suffix returns ok modcall[authorize]: module files returns notfound modcall: group authorize returns updated rad_check_password: Found Auth-Type rad_check_password: Auth-Type = Accept, accepting the user Login OK: [[EMAIL PROTECTED]] (from nas UNKNOWN-NAS port 0) Sending Access-Accept of id 230 to 199.45.200.140:1484 Service-Type = Framed-User Login-Service = Rlogin Ascend-Data-Filter = ip input forward 0 Ascend-Data-Filter = ip input forward 0 Ascend-Data-Filter = ip output drop 0 Ascend-Data-Filter = ip input forward 0 Finished request 0 It doesn't work even if I just use one Ascend-Data-Filter: realm.test Ascend-Data-Filter := ip in forward dstip 199.45.141.0/24 Still comes out as ip input forward 0. (I see some comments in the source about Fall-Through being incomplete. I notice that it -always- falls through, despite Fall-Through = No being set.) Appreciate your time. -- Charlie Watts
RE: rlm_attr_filter + Ascend-Data-Filter
On Tue, 12 Mar 2002, Edgard Castro wrote: I have similar settings that are definitely working, here they are: Ascend-Client-Primary-DNS = x.x.x.x, Ascend-Client-Secondary-DNS = x.x.x.x, Ascend-Data-Filter = ip in forward dstip x.x.x.x/24, Ascend-Data-Filter = ip in drop, Ascend-Data-Filter = ip out forward, X-Ascend-Client-Primary-DNS = x.x.x.x, X-Ascend-Client-Secondary-DNS = x.x.x.x, X-Ascend-Data-Filter = ip in forward dstip x.x.x.x/24, X-Ascend-Data-Filter = ip in drop, X-Ascend-Data-Filter = ip out forward Are you setting those in attrs and using rlm_attr_filter to apply them to proxied responses, or are you setting those in a 'users' file? It works fine for me if I set them in the users file. -- Charlie Watts [EMAIL PROTECTED] Frontier Internet, Inc. http://www.frontier.net/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
rlm_attr_filter + Ascend-Data-Filter
I'm having trouble with rlm_attr_filter and Ascend-Data-Filter. Indeed, there is a comment in the source: /* THIS SECTION NEEDS LOTS OF WORK TO GET THE ATTRIBUTE * FILTERING LOGIC WORKING PROPERLY. RIGHT NOW IT DOES * THINGS MOSLTY RIGHT. IT HAS SOME ISSUES WHEN YOU HAVE * MULTIPLE A/V PAIRS FROM THE SAME ATTRIBUTE ( IE, VSA'S ). * THAT NEEDS A BIT OF WORK STILL [EMAIL PROTECTED] */ Simpler things work fine; I can set the MTU, etc, just fine. Also, Ascend-Data-Filter gets returned correctly from user-file entries. Any suggestions? Here's my config: attrs: acsinc.net Ascend-Data-Filter := ip in forward tcp est, Ascend-Data-Filter := ip in forward dstip 199.45.141.0/24, Ascend-Data-Filter := ip in drop tcp dstport = 25, Ascend-Data-Filter := ip in forward And here's some output from the debug log: Sending Access-Accept of id 173 to 199.45.141.1:1026 Ascend-Data-Filter = ip input forward 0 Ascend-Data-Filter = ip input forward 0 Ascend-Data-Filter = ip output drop 0 Ascend-Data-Filter = ip input forward 0 Service-Type = Framed-User Framed-IP-Address = 255.255.255.254 Framed-IP-Netmask = 255.255.255.255 Framed-Protocol = PPP Framed-MTU = 1500 And here's what I get back: Vendor-Specific = V529:T242:L34::T1:L1::T1:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0: Vendor-Specific = V529:T242:L34::T1:L1::T1:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0: Vendor-Specific = V529:T242:L34::T1:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0: Vendor-Specific = V529:T242:L34::T1:L1::T1:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0: -- Charlie Watts [EMAIL PROTECTED] Frontier Internet, Inc. http://www.frontier.net/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_attr_filter + Ascend-Data-Filter
At 10:18 AM 3/11/2002 -0700, Charlie Watts wrote: I'm having trouble with rlm_attr_filter and Ascend-Data-Filter. Indeed, there is a comment in the source: /* THIS SECTION NEEDS LOTS OF WORK TO GET THE ATTRIBUTE * FILTERING LOGIC WORKING PROPERLY. RIGHT NOW IT DOES * THINGS MOSLTY RIGHT. IT HAS SOME ISSUES WHEN YOU HAVE * MULTIPLE A/V PAIRS FROM THE SAME ATTRIBUTE ( IE, VSA'S ). * THAT NEEDS A BIT OF WORK STILL [EMAIL PROTECTED] */ Yup, that comment is there, but that's not the problem you're having. Here's my config: attrs: acsinc.net Ascend-Data-Filter := ip in forward tcp est, Ascend-Data-Filter := ip in forward dstip 199.45.141.0/24, Ascend-Data-Filter := ip in drop tcp dstport = 25, Ascend-Data-Filter := ip in forward Hmmm, perhaps try using the += operator there. And here's some output from the debug log: Sending Access-Accept of id 173 to 199.45.141.1:1026 Ascend-Data-Filter = ip input forward 0 Ascend-Data-Filter = ip input forward 0 Ascend-Data-Filter = ip output drop 0 Ascend-Data-Filter = ip input forward 0 Here they are set as separate attributes, so it's not a problem with the rlm_attr_filter module. And here's what I get back: Vendor-Specific = V529:T242:L34::T1:L1::T1:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0: What is this output from? -Chris -- \\\|||/// \ StarNet Inc. \Chris Parker \ ~ ~ / \ WX *is* Wireless!\ Director, Engineering | @ @ |\ http://www.starnetwx.net \ (847) 963-0116 oOo---(_)---oOo--\-- \ Wholesale Internet Services - http://www.megapop.net - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_attr_filter + Ascend-Data-Filter
On Mon, 11 Mar 2002, Chris Parker wrote: At 10:18 AM 3/11/2002 -0700, Charlie Watts wrote: I'm having trouble with rlm_attr_filter and Ascend-Data-Filter. attrs: acsinc.net Ascend-Data-Filter := ip in forward tcp est, Ascend-Data-Filter := ip in forward dstip 199.45.141.0/24, Ascend-Data-Filter := ip in drop tcp dstport = 25, Ascend-Data-Filter := ip in forward Hmmm, perhaps try using the += operator there. I don't get them back at all when I use +=. And looking at the docs source, += doesn't seem to be supported. And here's some output from the debug log: Sending Access-Accept of id 173 to 199.45.141.1:1026 Ascend-Data-Filter = ip input forward 0 Ascend-Data-Filter = ip input forward 0 Ascend-Data-Filter = ip output drop 0 Ascend-Data-Filter = ip input forward 0 Here they are set as separate attributes, so it's not a problem with the rlm_attr_filter module. So is it in rlm_attr_filter or the core that the attributes are getting mangled? And here's what I get back: Vendor-Specific = V529:T242:L34::T1:L1::T1:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0::T0:L0: What is this output from? Hrm, that's a non-freeradius radtest client. I was assuming that was the non-decoded binary Ascend-Data-Filter, but it might just be garbage. The freeradius radtest returns the same thing that the debug log shows. I uncommented your DEBUG2 lines in rlm_attr_filter.c and re-compiled. Here's an example of what I see when using the := syntax: modcall: entering group authorize modcall[authorize]: module preprocess returns ok attr_filter: Matched entry realm.test at line 79 attr_filter: creating vp Service-Type - 1 - 2 attr_filter: creating vp Login-Service - 1 - 1 attr_filter: creating vp Ascend-Data-Filter - 4 - 0 attr_filter: creating vp Ascend-Data-Filter - 4 - 0 attr_filter: creating vp Ascend-Data-Filter - 4 - 0 attr_filter: creating vp Ascend-Data-Filter - 4 - 0 modcall[authorize]: module attr_filter returns updated modcall[authorize]: module suffix returns ok modcall[authorize]: module files returns notfound modcall: group authorize returns updated rad_check_password: Found Auth-Type rad_check_password: Auth-Type = Accept, accepting the user Login OK: [[EMAIL PROTECTED]] (from nas UNKNOWN-NAS port 0) Sending Access-Accept of id 230 to 199.45.200.140:1484 Service-Type = Framed-User Login-Service = Rlogin Ascend-Data-Filter = ip input forward 0 Ascend-Data-Filter = ip input forward 0 Ascend-Data-Filter = ip output drop 0 Ascend-Data-Filter = ip input forward 0 Finished request 0 It doesn't work even if I just use one Ascend-Data-Filter: realm.test Ascend-Data-Filter := ip in forward dstip 199.45.141.0/24 Still comes out as ip input forward 0. (I see some comments in the source about Fall-Through being incomplete. I notice that it -always- falls through, despite Fall-Through = No being set.) Appreciate your time. -- Charlie Watts [EMAIL PROTECTED] Frontier Internet, Inc. http://www.frontier.net/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
