October 2005 - Freeradius-Devel - lists.freeradius.org

Possible Bug in valuepair / rlm_file etc etc.
by Alister Winfield 04 Nov '05

04 Nov '05

I have found a potential bug in the way rlm_file or valuepair does the xlat of %{var} items. These are supposedly dynamic, being based on a per-packet replacement. The following example can be done a different way but its the simplest example I can think of ;-) Take the following from a users file (X-MyCLI filled in from some db in an earlier module). DEFAULT X-MyCLI != "%{Calling-Station-Id}", Auth-Type:="Reject" The db of valid CLI's might contain. user cli --------------- one 12345 two 54321 If you do two queries that should auth one thats sending: username=one, callingid=12345; the other username=two, callingid=54321. Only the first works the second failing because the in memory config for the check will have changed to read X-MyCLI != 12345 ...!!! Looking at the code this appears to be due to paircmp expanding the %{} on the structure passed to it (a potentially bad idea for so many reasons). The best solution, I suspect, is to copy the data sent to paircmp and work on the copy and not the original. The copy can be done on a per-pair way and if deemed expensive only for things that need xlat. .............................................. In sudo code: for (check; check->next ; ..... memcpy(&blah, check, sizeof(check)); Do the comparison using blah instead of check. memcpy(check, &blah, sizeof(check)); ............................................... I don't have a detailed patch yet as I have only done half the work required to avoid trashing the config but thus far it does fix my case. PS: Although I have only looked at 1.0.2 this appears to hold true of the CVS head as well. Am I missing something here and if not I'll be back soon with a complete patch (Currently I just save the old check_item and put it back which is fine in a single thread but not so clever in a threaded system). -- Alister Winfield

3 6

rlm_exec triggered hang or local weirdness?
by Joe Maimon 02 Nov '05

02 Nov '05

(long) I have been running radiusd cvs 9/29 + local mods for some time. (mostly under gdb with -fxx), to see if I can upgrade all systems to this or something later (plan to recheckpoint as soon as 9/29 is stable for me). As illustrated by previous unrelated posts, this server forks a lot (for every accounting which is confed for 5 minute updates per logged in user on the nas) to implement a ddns scheme. One issue that appears to be cropping up is where debug output and the server appears to freeze up. ===================================================== thread apply all bt shows this : Thread 11 (Thread -1290798160 (LWP 7382)): #0 0xb7ca438f in fork () from /lib/tls/libc.so.6 #1 0xb7f73064 in fork () from /lib/tls/libpthread.so.0 #2 0x08058a03 in rad_fork (exec_wait=0) at threads.c:1114 #3 0xb7fa8205 in radius_exec_program () from /usr/lib/freeradius/rlm_exec-1.1.0-pre0.so #4 0xb7fa8d8c in radius_exec_program () from /usr/lib/freeradius/rlm_exec-1.1.0-pre0.so #5 0x08054d26 in modcall (component=3, c=0x81b1188, request=0xb51033c8) at modcall.c:254 #6 0x080552d9 in call_one (component=Variable "component" is not available. ) at modcall.c:287 #7 0x08054eb5 in modcall (component=3, c=0x81afa08, request=0xb51033c8) at modcall.c:342 #8 0x08053f5f in indexed_modcall (comp=3, idx=Variable "idx" is not available. ) at modules.c:428 #9 0x0804f009 in rad_accounting (request=0xb51033c8) at acct.c:65 #10 0x08060f32 in rad_respond (request=0xb51033c8, fun=0x804efa0 <rad_accounting>) at request_process.c:456 #11 0x08057dba in request_handler_thread (arg=0x81b5828) at threads.c:585 #12 0xb7f6cccd in start_thread () from /lib/tls/libpthread.so.0 #13 0xb7ce3b0e in clone () from /lib/tls/libc.so.6 <the rest of the threads are at sem_wait> Thread 1 (Thread -1212102976 (LWP 27527)): #0 0xb7cf0d69 in pthread_setcanceltype () from /lib/tls/libc.so.6 #1 0xb7c7ac05 in malloc () from /lib/tls/libc.so.6 #2 0xb7f5a744 in rad_recv (fd=8) at radius.c:1063 #3 0x0805ec18 in proxy_socket_recv (listener=0xfffffffc, pfun=0xfffffffc, prequest=0xfffffffc) at listen.c:802 #4 0x0804d3c1 in main (argc=2, argv=0xbfabde44) at radiusd.c:665 ============================================ This tentatively appears to occur with -fxx NOT under gdb, normal is not currently known. cvs 3/16 does not have this issue when running normally. The only change I could detect as being obviously relevant is an added call to reap_children() in rad_fork() Now reap_children implements some magic voodoo tail head queue scheme that I havent managed to wrap my head around yet. debug output shows that radutmp (which is before the ddns exec module) is the last module to returns normally before. So I have added copious debug output. And I am having trouble understanding what I am seeing (nothing new there). In reap_children I have added some calls like this: ================================== --- /home/joe/download/radius/cvs/cvs-20050929/radiusd/src/main/threads.c 2005-09-14 21:21:14.000000000 -0400 +++ src/main/threads.c 2005-10-27 22:45:28.000000000 -0400 @@ -246,8 +248,10 @@ { if (thread_pool.wait_head != thread_pool.wait_tail) { int num; + int rval; pthread_mutex_lock(&thread_pool.wait_mutex); + FUNC_LINE_FILE(" mutex locked"); for (num = ((thread_pool.wait_tail + MAX_WAITERS) - thread_pool.wait_head) % MAX_WAITERS; num != 0; num--) { @@ -259,18 +263,35 @@ /* * Child is still alive: move it to the tail. */ - if (waitpid(pid, NULL, WNOHANG) == 0) { + FUNC_LINE_FILE(" wait for %d", pid); + if (waitpid(pid, &rval, WNOHANG) == 0) { if (((thread_pool.wait_tail + 1) % MAX_WAITERS) == thread_pool.wait_head) { rad_assert(0 == 1); } + FUNC_LINE_FILE(" wait for %d returned val\n" + " WIFEXITED(%d)" + " WEXITSTATUS(%d)" + " WIFSIGNALED(%d)" + " WTERMSIG(%d)" + " WIFSTOPPED(%d)" + " WSTOPSIG(%d)" + , pid, WIFEXITED(rval), + WIFEXITED(rval) ? WEXITSTATUS(rval) : 0, + WIFSIGNALED(rval), + WIFSIGNALED(rval) ? WTERMSIG(rval) : 0, + WIFSTOPPED(rval), + WIFSTOPPED(rval) ? WSTOPSIG(rval) : 0 + ); thread_pool.wait[thread_pool.wait_tail] = pid; thread_pool.wait_tail++; thread_pool.wait_tail %= MAX_WAITERS; } /* else no child, or was already reaped */ + else FUNC_LINE_FILE(" wait for %d returned noval", pid); } pthread_mutex_unlock(&thread_pool.wait_mutex); + FUNC_LINE_FILE(" mutex unlocked"); } } =============================================================== A sample of the output looks like this: ================================================================ reap_children() threads.c:254 mutex locked reap_children() threads.c:266 wait for 9240 reap_children() threads.c:285 wait for 9240 returned val WIFEXITED(0) WEXITSTATUS(0) WIFSIGNALED(1) WTERMSIG(84) WIFSTOPPED(0) WSTOPSIG(0) reap_children() threads.c:266 wait for 9241 reap_children() threads.c:285 wait for 9241 returned val WIFEXITED(0) WEXITSTATUS(0) WIFSIGNALED(1) WTERMSIG(84) WIFSTOPPED(0) WSTOPSIG(0) reap_children() threads.c:266 wait for 14565 reap_children() threads.c:285 wait for 14565 returned val WIFEXITED(0) WEXITSTATUS(0) WIFSIGNALED(1) WTERMSIG(84) WIFSTOPPED(0) WSTOPSIG(0) reap_children() threads.c:266 wait for 14566 reap_children() threads.c:285 wait for 14566 returned val WIFEXITED(0) WEXITSTATUS(0) WIFSIGNALED(1) WTERMSIG(84) WIFSTOPPED(0) WSTOPSIG(0) reap_children() threads.c:266 wait for 17694 reap_children() threads.c:285 wait for 17694 returned val WIFEXITED(0) WEXITSTATUS(0) WIFSIGNALED(1) WTERMSIG(84) WIFSTOPPED(0) WSTOPSIG(0) reap_children() threads.c:266 wait for 19290 reap_children() threads.c:285 wait for 19290 returned val WIFEXITED(0) WEXITSTATUS(0) WIFSIGNALED(1) WTERMSIG(84) WIFSTOPPED(0) WSTOPSIG(0) reap_children() threads.c:266 wait for 19291 reap_children() threads.c:285 wait for 19291 returned val WIFEXITED(0) WEXITSTATUS(0) WIFSIGNALED(1) WTERMSIG(84) WIFSTOPPED(0) WSTOPSIG(0) reap_children() threads.c:266 wait for 20399 reap_children() threads.c:285 wait for 20399 returned val WIFEXITED(0) WEXITSTATUS(0) WIFSIGNALED(1) WTERMSIG(84) WIFSTOPPED(0) WSTOPSIG(0) reap_children() threads.c:294 mutex unlocked ======================================================================== Question 1: Signal 84? Question 2: Appears that reap_children waits for thread pids, in addition to forked children? (see 9241 and 9240 and 20399..... below) ====================================================== freerad 6760 32641 6760 0 7 22:45 pts/15 00:00:00 src/main/.libs/radiusd -fxx freerad 6760 32641 6791 0 7 22:45 pts/15 00:00:00 src/main/.libs/radiusd -fxx freerad 6760 32641 6792 0 7 22:45 pts/15 00:00:00 src/main/.libs/radiusd -fxx freerad 6760 32641 6793 0 7 22:45 pts/15 00:00:00 src/main/.libs/radiusd -fxx freerad 6760 32641 6794 0 7 22:45 pts/15 00:00:00 src/main/.libs/radiusd -fxx freerad 6760 32641 6795 0 7 22:45 pts/15 00:00:00 src/main/.libs/radiusd -fxx freerad 6760 32641 19287 0 7 22:58 pts/15 00:00:00 src/main/.libs/radiusd -fxx freerad 9240 6760 9240 0 1 22:48 pts/15 00:00:00 src/main/.libs/radiusd -fxx freerad 9241 6760 9241 0 1 22:48 pts/15 00:00:00 src/main/.libs/radiusd -fxx freerad 14565 6760 14565 0 1 22:53 pts/15 00:00:00 src/main/.libs/radiusd -fxx freerad 14566 6760 14566 0 1 22:53 pts/15 00:00:00 src/main/.libs/radiusd -fxx freerad 17694 6760 17694 0 1 22:56 pts/15 00:00:00 src/main/.libs/radiusd -fxx freerad 19290 6760 19290 0 1 22:58 pts/15 00:00:00 src/main/.libs/radiusd -fxx freerad 19291 6760 19291 0 1 22:58 pts/15 00:00:00 src/main/.libs/radiusd -fxx freerad 20399 6760 20399 0 1 22:59 pts/15 00:00:00 src/main/.libs/radiusd -fxx freerad 22467 6760 22467 0 1 23:01 pts/15 00:00:00 src/main/.libs/radiusd -fxx ============================================================= How this has anything todo with my possible issue, I am not quite certain. misc: FUNC_LINE_FILE() is a local debug modification looks like this: #define FUNC_LINE_FILE(format, ...) do {\ printf("%s() %s:%d" format "\n",__func__,__FILE__,__LINE__, ## __VA_ARGS__);\ } while (0); (yes its missing a mutex lock, but since I put it into libradius.h I couldnt easily use DEBUG2) If anyone has any tips I would appreciate it. Joe

2 7

MS-CHAP-v2
by Dimitrios Kalogeras 31 Oct '05

31 Oct '05

Hi *, Do you know the status of MS-CHAP-v2 within free radius ? Is there anyone who has experience with the MS-CHAP-v2 issues ? I am facing an issue of CheckAuthenticatorResponse Failed between a cisco client and a freeradious server. Where should I start from ? I have a recorded session between the Radious Server and a Cisco NAS. The cisco engineer insists that there is a problem with the S calculation. Regards, Dimitrios -- -- Dimitrios K. Kalogeras Electrical Engineer Ph.D. Network Manager NTUA/GR-Net Network Management Center _____________________________________ icq: 11887484 voice: +30-210-772 1863 fax: +30-210-772 1866 e-mail: D.Kalogeras(a)noc.ntua.gr pub 1024D/F2A69A72 2002-12-13 Dimitrios Kalogeras <D.Kalogeras(a)noc.ntua.gr> Key fingerprint = 64C5 646D 8D33 A3FF 14D1 66C6 5127 54CC F2A6 9A72

2 1

Automatic report from sources (radiusd) between 30.10.2005 - 31.10.2005 GMT
by Automatic cvs log generator 31 Oct '05

31 Oct '05

CVS log entries from 30.10.2005 (Sun) 09:00:00 - 31.10.2005 (Mon) 09:00:01 GMT ===================================================== Summary by authors ===================================================== Author: fcusack File: radiusd/src/modules/rlm_otp/cardops/cryptocard.h; Revisions: 1.21 File: radiusd/src/modules/rlm_otp/otp_cardops.h; Revisions: 1.25 File: radiusd/src/modules/rlm_otp/cardops/cryptocard.c; Revisions: 1.22 File: radiusd/src/modules/rlm_otp/otp_cardops.c; Revisions: 1.45, 1.44 Author: nbk File: radiusd/src/main/auth.c; Revisions: 1.153 ===================================================== Combined list of identical log entries ===================================================== Description: persistent softfail (forced by nullstate) fixes Modified files: File: radiusd/src/modules/rlm_otp/otp_cardops.c; Revision: 1.44; Date: 2005/10/31 07:44:57; Author: fcusack; Lines: (+6 -3) File: radiusd/src/modules/rlm_otp/otp_cardops.h; Revision: 1.25; Date: 2005/10/31 07:44:57; Author: fcusack; Lines: (+2 -2) File: radiusd/src/modules/rlm_otp/cardops/cryptocard.c; Revision: 1.22; Date: 2005/10/31 07:44:57; Author: fcusack; Lines: (+5 -1) File: radiusd/src/modules/rlm_otp/cardops/cryptocard.h; Revision: 1.21; Date: 2005/10/31 07:44:57; Author: fcusack; Lines: (+2 -2) ===================================================== Log entries ===================================================== Description: Don't leak memory in rad_authenticate() when we receive an Access-Challenge from the home server. Also re-arrange the code which check the proxy reply, and update the comments. Modified files: File: radiusd/src/main/auth.c; Revision: 1.153; Date: 2005/10/30 16:51:21; Author: nbk; Lines: (+30 -39) ------------------------------- Description: isconsecutive(): test for persistent softfail to avoid broken math Modified files: File: radiusd/src/modules/rlm_otp/otp_cardops.c; Revision: 1.45; Date: 2005/10/31 08:29:43; Author: fcusack; Lines: (+14 -3) ===================================================== Summary of modified files ===================================================== File: radiusd/src/main/auth.c Revisions: 1.153 Authors: nbk (+30 -39) ------------------------------- File: radiusd/src/modules/rlm_otp/cardops/cryptocard.c Revisions: 1.22 Authors: fcusack (+5 -1) ------------------------------- File: radiusd/src/modules/rlm_otp/cardops/cryptocard.h Revisions: 1.21 Authors: fcusack (+2 -2) ------------------------------- File: radiusd/src/modules/rlm_otp/otp_cardops.c Revisions: 1.45, 1.44 Authors: fcusack (+14 -3), fcusack (+6 -3) ------------------------------- File: radiusd/src/modules/rlm_otp/otp_cardops.h Revisions: 1.25 Authors: fcusack (+2 -2) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0

Automatic report from sources (radiusd) between 29.10.2005 - 30.10.2005 GMT
by Automatic cvs log generator 30 Oct '05

30 Oct '05

CVS log entries from 29.10.2005 (Sat) 08:00:00 - 30.10.2005 (Sun) 09:00:00 GMT ===================================================== Summary by authors ===================================================== Author: nbk File: radiusd/src/main/auth.c; Revisions: 1.152 File: radiusd/src/main/acct.c; Revisions: 1.38 ===================================================== Combined list of identical log entries ===================================================== Description: Print a debug message with the name of the stanza which is used to run the modules. Modified files: File: radiusd/src/main/acct.c; Revision: 1.38; Date: 2005/10/29 20:11:53; Author: nbk; Lines: (+7 -4) File: radiusd/src/main/auth.c; Revision: 1.152; Date: 2005/10/29 20:11:53; Author: nbk; Lines: (+20 -17) ===================================================== Log entries ===================================================== ===================================================== Summary of modified files ===================================================== File: radiusd/src/main/acct.c Revisions: 1.38 Authors: nbk (+7 -4) ------------------------------- File: radiusd/src/main/auth.c Revisions: 1.152 Authors: nbk (+20 -17) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0

Automatic report from sources (radiusd) between 28.10.2005 - 29.10.2005 GMT
by Automatic cvs log generator 29 Oct '05

29 Oct '05

CVS log entries from 28.10.2005 (Fri) 08:00:00 - 29.10.2005 (Sat) 08:00:00 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/src/main/threads.c; Revisions: 1.100 File: radiusd/src/lib/misc.c; Revisions: 1.66 Author: fcusack File: radiusd/src/modules/rlm_otp/otp_cardops.h; Revisions: 1.24 File: radiusd/src/modules/rlm_otp/otp_cardops.c; Revisions: 1.43, 1.42 Author: nbk File: radiusd/doc/ChangeLog; Revisions: 1.57.2.31 ===================================================== Combined list of identical log entries ===================================================== Description: right shift OTP_CF_FRW and OTP_CF_TW mask bits to get value Modified files: File: radiusd/src/modules/rlm_otp/otp_cardops.c; Revision: 1.43; Date: 2005/10/29 05:46:27; Author: fcusack; Lines: (+4 -4) File: radiusd/src/modules/rlm_otp/otp_cardops.h; Revision: 1.24; Date: 2005/10/29 05:46:27; Author: fcusack; Lines: (+3 -1) ===================================================== Log entries ===================================================== Description: Added latest set of changes - Don't leak memory in module "rlm_sql". - Add PEAP machine authentication support in module "rlm_mschap". - Queue the request before looking for available threads. - Don't free the check items after we received the proxy reply. - Expand config variables in included files, too. - Check the return value of accounting modules and don't proxy invalid requests. - In rlm_passwd, don't close a file stream more than once. Modified files: File: radiusd/doc/ChangeLog; Revision: 1.57.2.31; Date: 2005/10/28 09:35:33; Author: nbk; Lines: (+12 -6) ------------------------------- Description: Correct typo in closefrom Modified files: File: radiusd/src/lib/misc.c; Revision: 1.66; Date: 2005/10/28 21:03:13; Author: aland; Lines: (+5 -3) ------------------------------- Description: Move table of PID's to wait for into a hash table, which makes it easier to manage. Modified files: File: radiusd/src/main/threads.c; Revision: 1.100; Date: 2005/10/28 21:06:56; Author: aland; Lines: (+70 -53) ------------------------------- Description: don't redefine _GNU_SOURCE if already defined Modified files: File: radiusd/src/modules/rlm_otp/otp_cardops.c; Revision: 1.42; Date: 2005/10/29 04:49:37; Author: fcusack; Lines: (+3 -3) ===================================================== Summary of modified files ===================================================== File: radiusd/doc/ChangeLog Revisions: 1.57.2.31 Authors: nbk (+12 -6) ------------------------------- File: radiusd/src/lib/misc.c Revisions: 1.66 Authors: aland (+5 -3) ------------------------------- File: radiusd/src/main/threads.c Revisions: 1.100 Authors: aland (+70 -53) ------------------------------- File: radiusd/src/modules/rlm_otp/otp_cardops.c Revisions: 1.43, 1.42 Authors: fcusack (+4 -4), fcusack (+3 -3) ------------------------------- File: radiusd/src/modules/rlm_otp/otp_cardops.h Revisions: 1.24 Authors: fcusack (+3 -1) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0

using DEBUG2 in child process of rlm_exec_wait()
by Joe Maimon 28 Oct '05

28 Oct '05

appears to lead to hung threads waiting to lock mutex in vradlog() So dont use it?

2 1

Automatic report from sources (radiusd) between 27.10.2005 - 28.10.2005 GMT
by Automatic cvs log generator 28 Oct '05

28 Oct '05

CVS log entries from 27.10.2005 (Thu) 08:00:01 - 28.10.2005 (Fri) 08:00:00 GMT ===================================================== Summary by authors ===================================================== Author: nbk File: radiusd/src/modules/rlm_passwd/rlm_passwd.c; Revisions: 1.26, 1.13.2.4 ===================================================== Log entries ===================================================== Description: Don't fclose() a file stream more than once. Bug found by Svein Hansen <svein.hansen(a)hive.no> Modified files: File: radiusd/src/modules/rlm_passwd/rlm_passwd.c; Revision: 1.26; Date: 2005/10/27 15:07:10; Author: nbk; Lines: (+11 -6) ------------------------------- Description: Pull from CVS head: Don't fclose() a file stream more than once. Modified files: File: radiusd/src/modules/rlm_passwd/rlm_passwd.c; Revision: 1.13.2.4; Date: 2005/10/27 15:07:16; Author: nbk; Lines: (+11 -6) ===================================================== Summary of modified files ===================================================== File: radiusd/src/modules/rlm_passwd/rlm_passwd.c Revisions: 1.26, 1.13.2.4 Authors: nbk (+11 -6), nbk (+11 -6) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0

Re:Documentation of the peap module
by Fabio 27 Oct '05

27 Oct '05

Sorry, I just see this is already in CVS. Thanks. > Hi, > first of all thanks for your great GPL'ed RADIUS server! > > Looking at the eap.conf file I see that the following options present in > rlm_eap_peap.c: > > use_tunneled_reply > copy_request_to_tunnel > proxy_tunneled_request_as_eap > > are not documented as the options in the ttls module. > > Can someone add the doc to eap.conf for the peap module (for the first two > is sufficient a copy and paste from the ttls module)? > > Thanks. > > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html >

1 0

Documentation of the peap module
by Fabio 27 Oct '05

27 Oct '05

Hi, first of all thanks for your great GPL'ed RADIUS server! Looking at the eap.conf file I see that the following options present in rlm_eap_peap.c: use_tunneled_reply copy_request_to_tunnel proxy_tunneled_request_as_eap are not documented as the options in the ttls module. Can someone add the doc to eap.conf for the peap module (for the first two is sufficient a copy and paste from the ttls module)? Thanks.

1 0