August 2009 - Freeradius-Devel - lists.freeradius.org

about oracle performance improvement
by zhongwei feng 26 Aug '09

26 Aug '09

hi everyone, i use rlm_sql driver oracle , and improve that performance. my method :change the querystr schema(and also backward compatible), and use OCIBindByName/OCIBindByPos functions , about 150 lines of code /* * SQL WITH BIND : <SQL>\P<BIND1>\P<BIND2>.....\P<BINDn> * BIND1 : <NAME>=<VALUE> ; the <NAME> is optional, if none, bindbyindex * */ Comparison of dynamic sql and binding sql, performance increased by 50% or even 400% (especially in the relatively slow CPU environment) BTW:raddb/sql/oracle/schema.sql, lack an index for the RADCHECK.username anyone can contact me , get the code , and / or commit them to the FreeRadius Project?

2 1

FW: MSCHAP Authentication Issue
by Garber, Neal 26 Aug '09

26 Aug '09

I apologize for posting in the wrong list (and for posting this again - I'm doing so to allow the thread to continue on the proper list).. > I suspect that it will. The mschap module should also pass the Name > field when calling ntlm_auth, too. And maybe print a warning if the > fields are different. I constructed a test program by extracting challenge_hash from rlm_mschap.c (and all supporting functions). I then extracted the peer challenge, authenticator challenge and NT-Response from the debug output of a failed request (User-Name was all lowercase, Name field was mixed case). I called challenge_hash with the all lowercase userid (to ensure it generated the same challenge as the failed request) - the challenge was identical. I then generated another challenge with the userid from the Name field in the response. Then, I executed ntlm_auth manually with the original challenge and the new challenge. The original failed (as I expected) and, low and behold, the new challenge (created using the Name field's userid) succeeded! I will now proceed to create a patch. I was planning to do a strncasecmp to ensure the only difference between the userid part of User-Name and the userid part of the Name field is case. If there are non-case differences, do you think a RLM_REJECT is in order or do you think it should just warn and use whatever is present (I can't think of a normal case where this would occur, but if you think this is better, then I would definitely use the Name field for the username parameter too)? I was thinking of rejecting the request, in this case, so this couldn't be used to bypass authorization. Interestingly, I copied the challenge and response from a successful and failed attempt and manually called ntlm_auth varying the case of the --username parameter and it didn't affect the results. In other words, --username=MYUSER or --username=myuser or --username=MyuseR all behave the same if the --challenge and --nt-response are correct).

2 2

Re:about oracle performance improvement
by zhongwei feng 26 Aug '09

26 Aug '09

--- org/sql_oracle.c +++ new/sql_oracle.c @@ -29,6 +29,25 @@ #include <oci.h> #include "rlm_sql.h" +#define MAXBIND 40 +/* + * SQL WITH BIND = <SQL>\P<BIND1>\P<BIND2>.....\P<BINDn> + * BIND1 = <NAME>=<VALUE> ; the <NAME> is optional, if none, bindbyindex + * + */ +typedef struct rlm_sql_oraclesockbind { + char * ptr ; + int idx ; + char * name ; + int namelen ; + char * value ; + int vallen; + + OCIBind *bindp ; +} rlm_sql_oraclesockbind; + + + typedef struct rlm_sql_oracle_sock { OCIEnv *env; OCIError *errHandle; @@ -39,11 +58,110 @@ int id; int in_use; struct timeval tv; + + rlm_sql_oraclesockbind binds[MAXBIND]; + int bindcount; } rlm_sql_oracle_sock; #define MAX_DATASTR_LEN 64 +/************************************************************************* + * + * Function: sql_bindparse + * + * Purpose: split the sql statement for pure sql , each bind item , etc . + * + * + *************************************************************************/ +static int sql_bindparse(SQLSOCK *sqlsocket, char * query) +{ + char * p = query ; + int count = 0 , i , k; + rlm_sql_oracle_sock *oracle_sock = sqlsocket->conn ; + oracle_sock->bindcount = 0 ; + + while (*p) { + printf("DEBUG:%s\n",p); + switch (*p) { + case '\\' : + if (p[1]!='P') { + break; + } + *p = '\0'; + oracle_sock->binds[count].ptr = p+2; + count ++ ; + p ++ ; + break; + //default + } /* end of switch(*p) */ + p ++ ; + if (count>=MAXBIND) + break; + } + + for(i=0, k = 0 ; k<count; k++){ + if (oracle_sock->binds[k].ptr==NULL) + continue; + if (oracle_sock->binds[k].ptr[0]=='\0') + continue; + if ((p=strchr(oracle_sock->binds[k].ptr, '='))==NULL) + continue; + *p = '\0'; + oracle_sock->binds[i].value = p+1; + oracle_sock->binds[i].vallen = strlen (oracle_sock->binds[i].value); + if (p==oracle_sock->binds[k].ptr){ + oracle_sock->binds[i].name = NULL; + } else { + oracle_sock->binds[i].name = oracle_sock->binds[k].ptr; + oracle_sock->binds[i].namelen = p - oracle_sock->binds[k].ptr; + } + oracle_sock->binds[i].idx = i+1 ; + radlog(L_DBG, "bind[%d] v_p is<%s>(%d)-<%s>(%d)", i, + oracle_sock->binds[i].name,oracle_sock->binds[i].namelen, + oracle_sock->binds[i].value,oracle_sock->binds[i].vallen ); + i ++ ; continue; + } + + oracle_sock->bindcount = i ; + + return 0 ; +} + + +static int sql_ocibind(SQLSOCK *sqlsocket) +{ + int i ; + rlm_sql_oracle_sock *oracle_sock = sqlsocket->conn ; + for(i=0;i<oracle_sock->bindcount; i++){ + if (oracle_sock->binds[i].name!=NULL){ + OCIBindByName( + oracle_sock->queryHandle, + &oracle_sock->binds[i].bindp, + oracle_sock->errHandle, + oracle_sock->binds[i].name, + oracle_sock->binds[i].namelen, + (ub1 *) oracle_sock->binds[i].value, + oracle_sock->binds[i].vallen+1, + SQLT_STR, (dvoid *) 0, (ub2 *) 0, (ub2) 0, (ub4) 0, (ub4 *) 0, + OCI_DEFAULT); + } else { + OCIBindByPos( + oracle_sock->queryHandle, + &oracle_sock->binds[i].bindp, + oracle_sock->errHandle, + oracle_sock->binds[i].idx, + (ub1 *) oracle_sock->binds[i].value, + oracle_sock->binds[i].vallen+1, + SQLT_STR, (dvoid *) 0, (ub2 *) 0, (ub2) 0, (ub4) 0, (ub4 *) 0, + OCI_DEFAULT); + } + } + + return 0; +} + + /************************************************************************* * * Function: sql_error @@ -248,6 +366,8 @@ return SQL_DOWN; } + sql_bindparse(sqlsocket, querystr); + if (OCIStmtPrepare (oracle_sock->queryHandle, oracle_sock->errHandle, querystr, strlen(querystr), OCI_NTV_SYNTAX, OCI_DEFAULT)) { @@ -255,6 +375,9 @@ return -1; } + if (oracle_sock->bindcount>0) + sql_ocibind(sqlsocket); + x = OCIStmtExecute(oracle_sock->conn, oracle_sock->queryHandle, oracle_sock->errHandle, @@ -306,6 +429,8 @@ return SQL_DOWN; } + sql_bindparse(sqlsocket, querystr); + if (OCIStmtPrepare (oracle_sock->queryHandle, oracle_sock->errHandle, querystr, strlen(querystr), OCI_NTV_SYNTAX, OCI_DEFAULT)) { @@ -313,6 +438,9 @@ return -1; } + if (oracle_sock->bindcount>0) + sql_ocibind(sqlsocket); + /* Query only one row by default (for now) */ x = OCIStmtExecute(oracle_sock->conn, oracle_sock->queryHandle, ============================================ diaup.conf authorize_check_query = "SELECT id,UserName,Attribute,Value,op FROM ${authcheck_table} WHERE Username = :uname ORDER BY id\\P:uname=%{SQL-User-Name}" accounting_update_query = "UPDATE ${acct_table1} \ SET FramedIPAddress = :framedip, \ AcctSessionTime = TO_NUMBER(:acctsesstime), \ AcctInputOctets = TO_NUMBER(:acct_in_oct) + TO_NUMBER(:acct_in_octG) * 4294967296, \ AcctOutputOctets = TO_NUMBER(:acct_out_oct) + TO_NUMBER(:acct_out_octG) * 4294967296 \ WHERE \ AcctSessionId = :acctsessid AND \ UserName = :uname AND \ NASIPAddress= :nasip AND \ AcctStopTime IS NULL\ \\P:framedip=%{Framed-IP-Address}\ \\P:acctsesstime=%{Acct-Session-Time}\ \\P:acct_in_oct=%{Acct-Input-Octets}\\P:acct_in_octG=%{Acct-Input-Gigawords}\ \\P:acct_out_oct=%{Acct-Input-Octets}\\P:acct_out_octG=%{Acct-Input-Gigawords}\ \\P:acctsessid=%{Acct-Session-Id}\ \\P:uname=%{SQL-User-Name}\ \\P:nasip=%{NAS-IP-Address}"

1 0

RADIUS/UDP and the DF bit
by Stefan Winter 25 Aug '09

25 Aug '09

Hello, now this is unpleasant: Apparently, many OSes set the DF bit on every datagram they send, if Path MTU discovery is turned on. Even on UDP packets. This breaks your RADIUS communication if datagram > MTU. I have reason to believe that this has led to numerous problems with EAP-TLS in eduroam, for example. It is of course not in principle a FreeRADIUS problem, but an OS one (speaking here of Linux in particular), but other software like BIND takes precautions against that and I think it might be good to do the same in FreeRADIUS as well (i.e. explicitly disable IP_DONTFRAG socket option). To illustrate the problem (FR 2.1.6 on a host called radius-1): 09:54:55.234018 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 291) tld1.eduroam.lu.56581 > radius-1.restena.lu.radius: [udp sum ok] RADIUS, length: 263 09:54:55.234315 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 314) radius-1.restena.lu.tdp-suite > eomund.restena.lu.radius: [udp sum ok] RADIUS, length: 286 09:54:55.241858 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto UDP (17), length 1123) eomund.restena.lu.radius > radius-1.restena.lu.tdp-suite: [udp sum ok] RADIUS, length: 1095 09:54:55.242170 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 1118) radius-1.restena.lu.radius > tld1.eduroam.lu.56581: [udp sum ok] RADIUS, length: 1090 "Flags [DF]" means pain. One workaround is to disable Path MTU discovery on the IP layer of the host (/proc/sys/net/ipv4/ip_no_pmtu_disc), but obviously, that's a bad workaround since it will ruin Path MTU discovery for every TCP service on the same host. Luckily, IPv6 doesn't seem to be affected since MTU discovery works differently there (AFAIK). The BIND sources have a small workaround in their socket code to get around that: #if defined(IP_MTU_DISCOVER) && defined(IP_PMTUDISC_DONT) /* * Turn off Path MTU discovery on IPv4/UDP sockets. */ if (sock->pf == AF_INET) { int action = IP_PMTUDISC_DONT; (void)setsockopt(sock->fd, IPPROTO_IP, IP_MTU_DISCOVER, &action, sizeof(action)); } #endif #if defined(IP_DONTFRAG) /* * Turn off Path MTU discovery on IPv4/UDP sockets. */ if (sock->pf == AF_INET) { int off = 0; (void)setsockopt(sock->fd, IPPROTO_IP, IP_DONTFRAG, &off, sizeof(off)); } #endif May I suggest to do a similar thing in FreeRADIUS? The same happens on Radiator BTW, and I will post a similar message to these guys as well. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473

3 7

Patch Format
by Garber, Neal 25 Aug '09

25 Aug '09

I have a patch that I would like to submit, but I'd like to format it in a way that is easiest to integrate. Other messages I've read indicate that this is git format. Can someone confirm that the instructions for doing this are here: http://git.freeradius.org/howto.html? If not, can you point me to a document that will show me how to provide the patches in the desired format? Thanks..

2 1

git format-patch - add protection wrapper around detail module
by Alan Buxey 24 Aug '09

24 Aug '09

hi, attached patch means that the detail module doesnt get poisoned as much by packets that it doesnt like alan

2 1

GIT Log for 2009-08-21 23:33 GMT
by aland＠deployingradius.com 21 Aug '09

21 Aug '09

commit 34f8e2c30fd9fc84b8241da7cd1b4045747d804a Author: Alan T. DeKok <aland(a)freeradius.org> Date: Fri Aug 21 11:29:21 2009 +0200 As posted to the list share/dictionary.foundry | 14 ++++++++++++++ 1 files changed, 14 insertions(+), 0 deletions(-)

1 0

Re: Buffered SQL for authentication failures?
by John Morrissey 21 Aug '09

21 Aug '09

[seems somewhat more appropriate on -devel, moving there] On Wed, Aug 05, 2009 at 01:11:33PM -0400, John Morrissey wrote: > I'm in the process of replacing OSG's Radiator with FreeRADIUS. I have our > relatively complex configuration mostly ported, but a few things have left > me stumped. > > I'd like to write authentication failures to an SQL database using a > detail listener so they're buffered, as with accounting: > > detail detail.auth { > detailfile = ${radacctdir}/detail-auth > detailperm = 0600 > header = "%t" > } > > post-auth { > Post-Auth-Type REJECT { > detail.auth > } > } > > server buffered-sql-auth { > listen { > type = detail > filename = ${radacctdir}/detail-auth > load_factor = 100 > } > post-auth { > sql > } > } > > Detail entries are picked up by the listener, but it never seems to do > anything with them: > > Going to the next request > Waking up in 0.7 seconds. > Polling for detail file /var/log/freeradius/radacct/detail-acct > Polling for detail file /var/log/freeradius/radacct/detail-auth > detail_recv: Renaming /var/log/freeradius/radacct/detail-auth -> /var/log/freeradius/radacct/detail-auth.work > detail_recv: Read packet from /var/log/freeradius/radacct/detail-auth.work > Packet-Type = Access-Reject > Framed-Protocol = PPP > Service-Type = Framed-User > Framed-IP-Address = 255.255.255.254 > Framed-Compression = Van-Jacobson-TCP-IP > Framed-MTU = 1500 > Acct-Delay-Time = 0 > server buffered-sql-auth { > } # server buffered-sql-auth > Finished request 7. > Cleaning up request 7 ID 41800 with timestamp +263 > > > It looks like detail_recv() explicitly sets its RAD_REQUEST_FUNP to > rad_accounting: > > *pfun = rad_accounting; > > I haven't looked much into the FreeRADIUS source yet; is it reasonably > easy to determine/loop through the configured handlers for the detail > listener to support a situation like this? Is there a better way of doing > this? To restate, my goal is to write failed authentication detail to a detail log that's then read by a detail listener and inserted into an SQL database. Looking at the code, I was thinking about adding an intermediate function that would call both rad_accounting() and rad_postauth(). Since default_component_results[] indicates NOOP for both of these, this should be straightforward. The problem now becomes that the post-auth rlm_detail is writing the RADIUS *response* to the detail log, since that's the packet that's being handled at that point. rlm_detail can't be listed in authenticate {}, so I can't use unlang to only call rlm_detail on Access-Reject. Modifying rlm_detail to have an authenticate handler seems... dirty. Any ideas? Is there a better way to accomplish failed auth buffered SQL insertion? john -- John Morrissey _o /\ ---- __o jwm(a)horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__

2 1

Year 2045 problems
by Joe Maimon 20 Aug '09

20 Aug '09

Wed Aug 19 11:34:04 2009 : Error: rlm_sql: Failed to create the pair: failed to parse time string "31 Jan 2045" Wed Aug 19 11:34:04 2009 : Error: rlm_sql (sql): Error getting data from database Wed Aug 19 11:34:04 2009 : Error: [sql] SQL query error; rejecting user The workaround is easy, stop setting Expiration, but I am curious as to where the fault is.

5 4

GIT Log for 2009-08-19 23:33 GMT
by aland＠deployingradius.com 19 Aug '09

19 Aug '09

commit eec417078d44cd3d39f94ba6c02c8ee1d9e0fbb3 Author: Alan T. DeKok <aland(a)freeradius.org> Date: Wed Aug 19 08:58:47 2009 +0200 Disallow NULL for regex comparisons src/lib/valuepair.c | 10 ++++++++-- 1 files changed, 8 insertions(+), 2 deletions(-)

1 0