In an accounting server, I would like to be able to parse the Class attribute with a regexp to pull parts out. However the standard dictionary defines it as 'octets' which makes it hard to parse - and I'd like to avoid modifying the dictionary if possible. Copying it to a 'string' attribute doesn't help, because it gets hex-expanded at that point. e.g. Reply-Message := "%{Class}" } gives Class = 0x466f6f7c426172 Reply-Message = "0x466f6f7c426172" I notice that recently a %{integer:...} expansion was added. Is there perhaps a case for a corresponding %{string:...} expansion? Or is there a better way to do this? Thanks, Brian.
Just add the line: ATTRIBUTE Class 25 string to the end of raddb/dictionary. It will override the type defined in the standard dictionaries, which you may not want to fiddle with too much. On Thu, Jan 27, 2011 at 2:45 PM, Brian Candler <B.Candler@pobox.com> wrote:
In an accounting server, I would like to be able to parse the Class attribute with a regexp to pull parts out. However the standard dictionary defines it as 'octets' which makes it hard to parse - and I'd like to avoid modifying the dictionary if possible.
Copying it to a 'string' attribute doesn't help, because it gets hex-expanded at that point. e.g.
Reply-Message := "%{Class}" }
gives
Class = 0x466f6f7c426172 Reply-Message = "0x466f6f7c426172"
I notice that recently a %{integer:...} expansion was added. Is there perhaps a case for a corresponding %{string:...} expansion? Or is there a better way to do this?
Thanks,
Brian. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Brian Candler wrote:
I notice that recently a %{integer:...} expansion was added. Is there perhaps a case for a corresponding %{string:...} expansion?
Yes. Editing the dictionaries is not recommended, as it can have additional side effects. Adding %{string:Class} is pretty specific. Alan DeKok.
I notice that recently a %{integer:...} expansion was added. Is there perhaps a case for a corresponding %{string:...} expansion?
Yes.
Editing the dictionaries is not recommended, as it can have additional side effects. Adding %{string:Class} is pretty specific.
OK, I've had a go at a patch. You can find it at https://github.com/candlerb/freeradius-server/tree/candlerb/string_expansion Aside: I guess you can't use this if you have an 'octets' value with an embedded null. If I set Class = 0x666f6f00626172 then Reply-Message = "%{string:Class}" expands to Reply-Message = "foo" Also, while doing this I also discovered a bug in the %{integer:...} expansion: it will cause freeradius to segfault if the vp is known in the dictionary but is not present in the request (radius_get_vp will return true but set vp to NULL). The fix is also in that branch, but I'll post it here too: diff --git a/src/main/xlat.c b/src/main/xlat.c index 0a02064..f1818e1 100644 --- a/src/main/xlat.c +++ b/src/main/xlat.c @@ -420,7 +420,7 @@ static size_t xlat_integer(void *instance, REQUEST *request, while (isspace((int) *fmt)) fmt++; - if (!radius_get_vp(request, fmt, &vp)) { + if (!radius_get_vp(request, fmt, &vp) || !vp) { *out = '\0'; return 0; } Regards, Brian.
Brian Candler wrote:
OK, I've had a go at a patch. You can find it at https://github.com/candlerb/freeradius-server/tree/candlerb/string_expansion
Aside: I guess you can't use this if you have an 'octets' value with an embedded null. If I set
That's easy enough to fix, and the server already includes code to handle non-printable characters in a string.
Also, while doing this I also discovered a bug in the %{integer:...} expansion: it will cause freeradius to segfault if the vp is known in the dictionary but is not present in the request (radius_get_vp will return true but set vp to NULL). The fix is also in that branch, but I'll post it here too:
Whoops. That needs fixing, yes. I've pushed fixes to the git repository. Alan DeKok.
participants (3)
-
Alan DeKok -
Brian Candler -
Eddie Stassen