Hi, Another patch that Alan will no doubt neglect, others might find it useful though. This patch adds lower/uppercase xlat support so you can now do things like: ---- update request { Calling-Station-Id := "%{lower:%{Calling-Station-Id}}" } update request { Calling-Station-Id := "%{upper:%{Calling-Station-Id}}" } ---- Cheers -- Alexander Clouter .sigmonster says: Girls are better looking in snowstorms. -- Archie Goodwin --- src/main/xlat.c.orig 2010-09-20 16:10:54.000000000 +0000 +++ src/main/xlat.c 2010-09-20 16:23:41.000000000 +0000 @@ -465,6 +465,61 @@ return strlen(out); } +/* + * Lowercase a string + */ +static size_t xlat_lower(UNUSED void *instance, REQUEST *request, + char *fmt, char *out, size_t outlen, + UNUSED RADIUS_ESCAPE_STRING func) +{ + int i; + char buffer[1024]; + + if (!radius_xlat(buffer, sizeof(buffer), fmt, request, func)) { + *out = '\0'; + return 0; + } + + if (outlen < strlen(buffer)) { + snprintf(out, outlen, "lower_overflow"); + return strlen(out); + } + + for (i = 0; buffer[i] != '\0'; i++) + out[i] = tolower(buffer[i]); + + out[i] = '\0'; + + return strlen(out); +} + +/* + * Uppercase a string + */ +static size_t xlat_upper(UNUSED void *instance, REQUEST *request, + char *fmt, char *out, size_t outlen, + UNUSED RADIUS_ESCAPE_STRING func) +{ + int i; + char buffer[1024]; + + if (!radius_xlat(buffer, sizeof(buffer), fmt, request, func)) { + *out = '\0'; + return 0; + } + + if (outlen < strlen(buffer)) { + snprintf(out, outlen, "upper_overflow"); + return strlen(out); + } + + for (i = 0; buffer[i] != '\0'; i++) + out[i] = toupper(buffer[i]); + + out[i] = '\0'; + + return strlen(out); +} /* * Calculate the MD5 hash of a string. @@ -610,6 +665,16 @@ c = xlat_find("md5"); rad_assert(c != NULL); c->internal = TRUE; + + xlat_register("lower", xlat_lower, &xlat_inst[0]); + c = xlat_find("lower"); + rad_assert(c != NULL); + c->internal = TRUE; + + xlat_register("upper", xlat_upper, &xlat_inst[0]); + c = xlat_find("upper"); + rad_assert(c != NULL); + c->internal = TRUE; } /*
Alan DeKok <aland@deployingradius.com> wrote:
Another patch that Alan will no doubt neglect, others might find it useful though.
Already in 2.1.10, via another patch. This functionality is having enough demand that it's worth doing.
The Little Tin God known as 'Efficiency' is displeased with your patch... *Two* if() statements and two additional pointers, -3 to wisdom. :) Although I do now ponder why I bothered doing an 'upper' function in my patch. Now, if you could rewrite all your calls to the OpenSSL library code to use EVP functions instead I would be able to use my crypto-accelerators, then I say you are ready for a point release. On a serious note would that be a case of me having to do this if I wanted it? The reason I ask is that I have put FreeRADIUS on an OpenRD[1] (replacing the old 600W Dull boxen we have with a £200 7W nicety) and although regular non-EAP requests are fast I think the EAP ones are alot more expensive CPU wise due to the SSL overhead. Of course I have not profiled anything yet (do you have any profiling data supporting this or do I need to generate my own?) so could be wrong. Anyway, as with most ARM/MIPS SoC's they come with lots of goodies, including hardware crypto. I got OpenSSL using it which is nice, however I then discovered the hard way that FreeRADIUS does not use the EVP functions in OpenSSL and so offload engines cannot be used. Would you accept a change like this, or would I be wasting my time trying to submit this sort of thing? Cheers [1] http://www.marvell.com/platforms/open_rd.html -- Alexander Clouter .sigmonster says: Don't look back, the lemmings are gaining on you.
Alexander Clouter wrote:
The Little Tin God known as 'Efficiency' is displeased with your patch...
*Two* if() statements and two additional pointers, -3 to wisdom. :)
Yes, well... I didn't have your example to follow.
Although I do now ponder why I bothered doing an 'upper' function in my patch.
Now added, too.
Now, if you could rewrite all your calls to the OpenSSL library code to use EVP functions instead I would be able to use my crypto-accelerators, then I say you are ready for a point release. On a serious note would that be a case of me having to do this if I wanted it?
I don't have a crypto accelerator...
The reason I ask is that I have put FreeRADIUS on an OpenRD[1] (replacing the old 600W Dull boxen we have with a £200 7W nicety) and although regular non-EAP requests are fast I think the EAP ones are alot more expensive CPU wise due to the SSL overhead. Of course I have not profiled anything yet (do you have any profiling data supporting this or do I need to generate my own?) so could be wrong. Anyway, as with most ARM/MIPS SoC's they come with lots of goodies, including hardware crypto.
My $0.02 is that a reasonably modern machine can do many 100's of 2K RSA key ops per second. That should be enough for most purposes.
I got OpenSSL using it which is nice, however I then discovered the hard way that FreeRADIUS does not use the EVP functions in OpenSSL and so offload engines cannot be used.
Yes, well....
Would you accept a change like this, or would I be wasting my time trying to submit this sort of thing?
I'm interested in the patch. The easiest way to get it in is to break it into a series of small patches (i.e. github) that each add a small piece of functionality. Most of my hesitation in adding patches is: 1) formatting / portability 2) breaking *existing* functionality 3) multiple independent changes in one patch 4) reading 1000 lines of patch, trying to figure out WTF it does I haven't looked into the OpenSSL acceleration code, so I don't know how complicated it is to do. My suggestion is to break it up into patches as follows: 1) configuration options && data structures for using the engines i.e. CONF_PARSER stuff, etc. This lets it be configured, even it it does nothing. This change won't break anything, and should be simple to audit 2) actually using the engine... 3) maybe re-working the MD5/SHA calls in src/lib/* to use the OpenSSL engine? I don't know if that would be worth it, tho... Alan DeKok.
participants (2)
-
Alan DeKok -
Alexander Clouter