- Freeradius-Devel - lists.freeradius.org

RE: contributions to client
by Lewis Adam-VNQM87 21 Apr '10

21 Apr '10

Hi, while I cannot offer any advice, I am in a similar situation in that I am trying to get the client code to work and am fixing problems (e.g. missing Message-authenticator and support for CHAP) as I find them. Maybe those in charge can offer some guidelines about the direction the client code is going in. As I see it, freeRADIUS has 2 different and unrelated solutions for providing client functionality. 1. freeradius-client 2. radclient which is provided as part of freeradius-server As freeradius-client seems to offer a more complete client implementation, I have found myself using it as a base and then grafting on fixes from (what looks like) the more recent radclient. There are many differences between the underlying mechanisms and structures used by the 2 code bases which makes porting that much more time-consuming. So, is there a plan for freeradius-client or at least a preferred direction? Is there an aim to make the code bases more consistent? Radclient definitely seems to have some useful ideas that could be re-used. Adam. > Hi, > PortaOne, Inc. uses freeradius-client in some our products. > We want to pass some of our changes to upstream. > Which form is preferrable for this? > - post a bug for each > - post a patch for each to this list (LKML style) > - post a description with link > ? > > Currently they are > - add generating of Message-Authenticator (RFC3579) > - switching from gethostbyname*() to getaddrinfo() (suitable > for all our > platforms and conforms to latter standards) > - printing unknown attributes in response using special syntax > to aid in issue debugging, instead of dropping the whole response > - generating correct error code in case of unparseable response > - allow to differ source address and NAS-IP-Address in request > - multiple servers in config file > - remove endian check and macros as unused and conflicting > - misc. fixes on compiler warnings

2 1

freeradius-client | multiple authservers and REJECT_RC
by Stefan Karss 21 Apr '10

21 Apr '10

Hello, configuring multiple authserver in freeradius client the client retries to authenticate a user to all authservers configured although REJECT_RC is returned. This means an unauthenticated user (wrong password, no access rights) gets retried on all other authservers: line 117-119 (buildreq.c): for (i=0; (i < aaaserver->max) && (result != OK_RC) && (result != BADRESP_RC) ; i++, now = rc_getctime()) { This means that only if the result is OK (login succeeded) or the result is bogus (BADRESP_RC) the login is not retried. Is this the expected behaviour? I'd expect a failover to the other authservers on return codes other than OK_RC or REJECT_RC - as those are the only real radius replies. Could someone please also shed some light on the question: Will radius_deadtime work for other requests than PW_ACCOUNTING_REQUEST, as start_time gets initialized only if request_type is PW_ACCOUNTING_REQUEST? I don't seem to get the meaning of the code here... Rgds, Stefan

2 3

another dictionary conflict for Operator-Name (126)
by Stefan Winter 21 Apr '10

21 Apr '10

Hi, yesterday I stumbled over dictionary.usr: # dictionary.usr USR Robotics dictionary. # USR specific attributes # ATTRIBUTE Multi-Link-Flag 126 integer VALUE Multi-Link-Flag True 1 VALUE Multi-Link-Flag False 0 This is another case of clashing IETF-space attributes with vendor ignorance (just like with Ascend-Temporary-Routes a few weeks back). I think that U.S. Robotics rests in peace since quite a while now. Could this attribute be commented out for 2.2.0? We are seriously looking into depending on Operator-Name (string) and it doesn't really help that multiple conflicting dictionaries re-assign it to an integer :-( 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

1 1

FreeRADIUS 2.1.8 fails to build when configured --without-pthreads
by Scott Neugroschl 20 Apr '10

20 Apr '10

FreeRADIUS 2.1.8 HP NonStop OSS src/main/event.c compile fails when configured --without-pthreads, because WITH_PROXY is still defined in radius.h I defined WITHOUT_PROXY and WITHOUT_COA and am still getting a lot of errors. Any advice? Also, how should WITHOUT_PROXY/WITHOUT_COA/whatever be specified during configure -- by using CPPFLAGS? And how should I report nitpicky gcc-isms?

3 6

rlm_ldap.c patch
by Kenneth Grady 19 Apr '10

19 Apr '10

$ diff -c rlm_ldap.c.orig freeradius-server-2.1.8v3/src/modules/rlm_ldap/rlm_ldap.c *** rlm_ldap.c.orig Mon Apr 19 10:44:27 2010 --- freeradius-server-2.1.8v3/src/modules/rlm_ldap/rlm_ldap.c Mon Apr 19 10:40:35 2010 *************** *** 2241,2248 **** LDAP_OPT_ON); if (inst->rebind == 1) { ! ldap_set_rebind_proc(ld, ldap_rebind, ! inst); } } else { rc=ldap_set_option(ld, LDAP_OPT_REFERRALS, --- 2241,2252 ---- LDAP_OPT_ON); if (inst->rebind == 1) { ! ldap_set_rebind_proc(ld, ! #if LDAP_SET_REBIND_PROC_ARGS != 3 ! ldap_rebind); ! #else ! ldap_rebind, inst); ! #endif } } else { rc=ldap_set_option(ld, LDAP_OPT_REFERRALS,

2 1

GIT Log for 2010-04-16 23:33 GMT
by aland＠deployingradius.com 16 Apr '10

16 Apr '10

commit ee478c06e48fc57190d20e9cf708c413efa89399 Author: Alan T. DeKok <aland(a)freeradius.org> Date: Fri Apr 16 16:12:01 2010 +0200 Don't block when doing 'exec wait', and reading from pipe. If the child is slow, then reading from the pipe will block until the child exits. This will happen even if we intend later to wait only 10 seconds for the child pid. The solution is to call select() on the pipe. After 10 seconds, if no progress has been made: kill -TERM the child, close the pipe, and clean up the child PID. Files changed: src/main/exec.c | 95 ++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 94 insertions(+), 1 deletions(-) ====================================================================== commit a2b12c6682e567e2e20f19bc989ac897ec2158f1 Author: Alan T. DeKok <aland(a)freeradius.org> Date: Wed Apr 14 05:00:39 2010 +0200 append tunneled reply, rather than moving it This means that the operators are ignored, and any proxied packet (with operators '=' for multiple VSAs of the same name) will get handled properly. Files changed: .../rlm_eap/types/rlm_eap_peap/rlm_eap_peap.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) ====================================================================== commit 75e1d596966d89995e57b50d91cc4e5bb13a51ec Author: Alan T. DeKok <aland(a)freeradius.org> Date: Wed Apr 14 04:59:26 2010 +0200 Fix node comparison on delete This could be the cause of bug #35. Files changed: src/lib/hash.c | 9 +-------- 1 files changed, 1 insertions(+), 8 deletions(-) ====================================================================== commit f3a0d669dff5ca73b12f0724f38e66f00a360ea7 Author: Alan T. DeKok <aland(a)freeradius.org> Date: Tue Apr 13 15:16:10 2010 +0200 Fixed typo. This should help divorce CoA from normal packets. The previous fix worked, but this one is the real source of the bug Files changed: src/main/event.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) ====================================================================== commit aab6b744e4afa1568985a320dc9e70c1c4d501f4 Author: Alan T. DeKok <aland(a)freeradius.org> Date: Mon Apr 12 11:36:52 2010 +0200 Print out hex for invalid data in PEAP tunnel. This helps debug issues. Also change the "had sent TLV failure" message to a LONG set of instructions for people who can't be bothered reading the debug output. Files changed: src/modules/rlm_eap/types/rlm_eap_peap/peap.c | 45 +++++++++++++++---------- 1 files changed, 27 insertions(+), 18 deletions(-) ====================================================================== commit a9be9015fff08fa9940ffed572a21729ebca3a5e Author: Alan T. DeKok <aland(a)freeradius.org> Date: Fri Apr 9 16:53:03 2010 +0200 Make request->number unsigned So that we don't print negative numbers Files changed: src/include/radiusd.h | 2 +- src/main/event.c | 53 ++++++++++++++++++++++++------------------------- 2 files changed, 27 insertions(+), 28 deletions(-) ====================================================================== commit 88cda786d8ce29cbccaf9be832d29abf16c1b6f8 Author: Alan T. DeKok <aland(a)freeradius.org> Date: Fri Apr 9 12:17:36 2010 +0200 Ensure correct build order include -> lib -> modules -> main Files changed: src/Makefile | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) ======================================================================

1 0

Status-Server support for RADIUS client
by Lewis Adam-VNQM87 14 Apr '10

14 Apr '10

Hi, I'm in the process of developing an embedded client based on the 1.1.6 client code. We have a requirement for issuing a Status-Server request and I can see, as it stands, the code doesn't work. The freeRADIUS server I am working with expects a PW_MESSAGE_AUTHENTICATOR attribute. The function rc_check() in lib\buildreq.c currently does not add the PW_MESSAGE_AUTHENTICATOR attribute. Searching for PW_MESSAGE_AUTHENTICATOR in the server code, I found the following code in src\module\rlm_eam\eap.c : vp = paircreate(PW_MESSAGE_AUTHENTICATOR, PW_TYPE_OCTETS); memset(vp->vp_octets, 0, AUTH_VECTOR_LEN); vp->length = AUTH_VECTOR_LEN; pairadd(&(request->reply->vps), vp); So, my questions are: 1. If the Status-Server request is experimental, is it known whether (many) other commercial RADIUS server products are supporting it? 2. Are there requirements and if so guidelines for creating meaningful authenticator values rather than all zeroes as above? 3. Are there any plans to update the client code with support for the PW_MESSAGE_AUTHENTICATOR attribute? Regards, Adam.

2 1

Two queries or SQL command for account on and acct off
by Toledo, Luis Carlos 14 Apr '10

14 Apr '10

Is it possible to have two diferent queries or SQL commands for "accounting on" and "accounting off" requests without change rlm_sql.c code ? Thanks Luis

2 1

Re: Re: Re: Radius server crash due to 35# bug
by Liu Linyong 14 Apr '10

14 Apr '10

Hello Alan, I have a question. For V2-1-7, in hash.c, please refer to the follows, static int list_delete(fr_hash_table_t *ht, fr_hash_entry_t **head, fr_hash_entry_t *node) { ...... for (cur = *head; cur != &ht->null; cur = cur->next) { if (cur == node) { // WHY NOT "if (cur->reversed == node->reversed)" ??? if (ht->cmp) { int cmp = ht->cmp(node->data, cur->data); // If cur == node, IS THIS NECESSARY? if (cmp > 0) break; if (cmp < 0) continue; } ....... } > Date: Thu, 08 Apr 2010 18:21:26 +0200 > From: Alan DeKok <aland@???> > Subject: Re: Radius server crash due to 35# bug > To: FreeRadius developers mailing list > <freeradius-devel@???> > Message-ID: <4BBE0286.50509@???> > Content-Type: text/plain; charset=ISO-8859-1 > > Liu Linyong wrote: > > 4K requests/sec. > > start_servers = 5 and max_servers = 32. But totally 9 threads were created.(That is: 3 more threads were created after initializing) > > > > Oh, I've set max_requests = 102400 in radiusd.conf. > > Hmm... I've tested it with sustained 30K packets/s for ~12 hours, and > haven't seen an issue. > > This seems to be a hard problem to reproduce. > > Alan DeKok. >

2 2

Re: Re: Re: Radius server crash due to 35# bug
by Liu Linyong 13 Apr '10

13 Apr '10

> Date: Thu, 08 Apr 2010 18:21:26 +0200 > From: Alan DeKok <aland(a)deployingradius.com> > Subject: Re: Radius server crash due to 35# bug > To: FreeRadius developers mailing list > <freeradius-devel(a)lists.freeradius.org> > Message-ID: <4BBE0286.50509(a)deployingradius.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Liu Linyong wrote: > > 4K requests/sec. > > start_servers = 5 and max_servers = 32. But totally 9 threads were created.(That is: 3 more threads were created after initializing) > > > > Oh, I've set max_requests = 102400 in radiusd.conf. > > Hmm... I've tested it with sustained 30K packets/s for ~12 hours, and > haven't seen an issue. > > This seems to be a hard problem to reproduce. > > Alan DeKok. > [V2-1-7] Maybe the test environments are different, so I can always reproduce the problem in an hour or so in my test ;) Yesterday, I removed the codes associated to 'hash' when receiving a request from NAS. That is: In main/event.c received_request(), will not find node from hash table, nor inserte into. BUT just add to FIFOs by thread_pool_addrequest(). Then test it for 12 hours, it work fine!! There may be something wrong with the 'hash' codes, I guess ;) Hmm... it's hard for me to understand the fr_hash_table_fixup(), then I think this 'black box' may have something wrong, haha... Besides, in src/main/event.c Ln1199, should "#ifdef WTH_COA " to be "#ifdef WITH_COA "? V2-1-8 also has this code.

2 1