April 2010 - Freeradius-Devel - lists.freeradius.org

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 13 Apr '10

13 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

Failed to insert event?
by Josip Almasi 09 Apr '10

09 Apr '10

Hi all, today my 2.0.2 died with 'Failed to insert event' message in wait_a_bit function (main/event.c). From what I've read, this can easily be fixed by assuring delay longer than timer resolution in fr_event_insert (lib/event.c). And, that was already fixed, during 2.0.3. Right? Thanks! Regards...

2 2

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

08 Apr '10

commit 39f2b8581c9c6bb5a4142670b39f780be69589a3 Author: Alan T. DeKok <aland(a)freeradius.org> Date: Thu Apr 8 09:59:55 2010 +0200 Make subdirs before modules Fixes "cannot build from clean directory" problem after switching to the new method of using "make" for recursing into subdirs Files changed: src/modules/Makefile | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) ====================================================================== commit 397533ff05725eef2c64898c15c34ad712041f9c Author: Alan T. DeKok <aland(a)freeradius.org> Date: Wed Apr 7 01:59:57 2010 +0200 Add missing 'break' to escape '%' properly. Files changed: src/modules/rlm_sqlcounter/rlm_sqlcounter.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) ====================================================================== commit c5da5a8f1af076c690463b5fb5010163377a2a8b Author: Alan T. DeKok <aland(a)freeradius.org> Date: Wed Apr 7 01:58:00 2010 +0200 On DHCP Discover fail, don't send a NAK Instead, just don't respond Files changed: src/modules/frs_dhcp/frs_dhcp.c | 12 ++++++++---- 1 files changed, 8 insertions(+), 4 deletions(-) ======================================================================

1 0

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

08 Apr '10

Please refer to the following post. ========================= > Author: Alan DeKok > Date: 2010-04-07 19:52 +800 > To: FreeRadius developers mailing list > Subject: Re: Radius server crash due to 35# bug > > Liu Linyong wrote: > > The conclusion: > > The 35# bug can recur rather easily. > > Hmm... I've run the server at 40K packets/s for *days*, and have been > unable to reproduce it. > > > We found FreeRadius server crash sometimes with load. > ... > > Then use gdb to run 'radiusd', and do load test with LoadRunner, which sending thousands of requests per second. > > How many requests in parallel? How many threads is the server using? ====> 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. > > > FreeRadius will cost little mem(16M) and cpu(1.6%). > > After an hour or so, the server will crash. These can be repeated easily. gdb show the position: > > It looks like a race condition, where data is accessed after it's been > freed. However, tracking it down is hard. > > Alan DeKok. ================================= Liu Linyong 2010-04-08

2 1

Radius server crash due to 35# bug
by Liu Linyong 07 Apr '10

07 Apr '10

Hi, The conclusion: The 35# bug can recur rather easily. We found FreeRadius server crash sometimes with load. To test the stability of the FreeRadius architecture, I modify the two functions: rad_authenticate() / rad_accounting(), they will do very simple things, and will not use any modules. int rad_accounting(REQUEST *request) { request->reply->code = PW_ACCOUNTING_RESPONSE; return RLM_MODULE_OK; } int rad_authenticate(REQUEST *request) { VALUE_PAIR *reply_tmp = NULL; reply_tmp = pairmake( "Service-Type", "Framed-User", T_OP_EQ); if( reply_tmp ) { pairxlatmove(request, &request->reply->vps, &reply_tmp); pairfree(&reply_tmp); } if (request->reply->code == 0) { request->reply->code = PW_AUTHENTICATION_ACK; } return RLM_MODULE_OK; } Then use gdb to run 'radiusd', and do load test with LoadRunner, which sending thousands of requests per second. FreeRadius will cost little mem(16M) and cpu(1.6%). After an hour or so, the server will crash. These can be repeated easily. gdb show the position: Program received signal SIGSEGV, Segmentation fault. 0xff376a6c in fr_packet_cmp (a=0x3d4070, b=0x0) at packet.c:139 139 if (a->sockfd < b->sockfd) return -1; (gdb) (gdb) (gdb) bt #0 0xff376a6c in fr_packet_cmp (a=0x3d4070, b=0x0) at packet.c:139 #1 0xff3680ec in list_find (ht=0x156fc8, head=0x156fe4, reversed=2911412273, data=0xffbff808) at hash.c:191 #2 0xff3685ec in fr_hash_table_finddata (ht=0x2469d0, data=0x156fe4) at hash.c:491 #3 0xff3771d0 in fr_packet_list_find (pl=0x156aa8, request=0x3d4070) at packet.c:557 #4 0x00032b88 in received_request (listener=0x15b848, packet=0x3d4070, prequest=0xffbff938, client=0x1101d8) at event.c:2746 #5 0x0001d5bc in acct_socket_recv (listener=0x15b848, pfun=0xffbff93c, prequest=0xffbff938) at listen.c:908 #6 0x000337d0 in event_socket_handler (xel=0x158450, fd=10, ctx=0x15b848) at event.c:3316 #7 0xff377f84 in fr_event_loop (el=0x158450) at event.c:400 #8 0x000284b4 in main (argc=2, argv=0xffbffb3c) at radiusd.c:398 The problem seems to be the same with 35# bug. (https://bugs.freeradius.org/bugzilla/show_bug.cgi?id=35) Environmnet: MEM: 24G phys mem OS: Solaris 5.10, sparc GCC: 3.3.2 GMAKE: 3.80 GDB: 6.8 CLIENT: LoadRunner (sending packages: auth & acct start & acct stop) FreeRadius server: 2-1-7 Is there any information else I should post here? *********************************************** Liu Linyong 2010-04-07

2 1

should discard packet when received AUTH header length < 20 ?
by WANG Tinggong 01 Apr '10

01 Apr '10

hi all, in src/main/listen.c , auth_socket_recv function, rad_recv_header uses MSG_PEEK flag. in case 0 <= rcode < 20, malfromed request still in the receive queue, should it be cleaned before line 757 ? 751 rcode = rad_recv_header(listener->fd, &src_ipaddr, &src_port, &code ); 752 if (rcode < 0) return 0; 753 754 RAD_STATS_TYPE_INC(listener, total_requests); 755 756 if (rcode < 20) { /* AUTH_HDR_LEN */ 757 RAD_STATS_TYPE_INC(listener, total_malformed_requests); 758 return 0; 759 } here is my patch against branch v2.1.x , does it make sense? thanks Tinggong --- src/main/listen.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/main/listen.c b/src/main/listen.c index 59ff314..855ee9c 100644 --- a/src/main/listen.c +++ b/src/main/listen.c @@ -754,6 +754,7 @@ static int auth_socket_recv(rad_listen_t *listener, RAD_STATS_TYPE_INC(listener, total_requests); if (rcode < 20) { /* AUTH_HDR_LEN */ + rad_recv_discard(listener->fd); RAD_STATS_TYPE_INC(listener, total_malformed_requests); return 0; }

2 1