January 2007 - Freeradius-Devel - lists.freeradius.org

rlm_mschap support for password changes
by Garber, Neal 28 Jan '07

28 Jan '07

Samba 3.0.24 will provide support for changing passwords via ntlm_auth. Unfortunately (for rlm_mschap in FR), it is implemented using a new helper protocol, "ntlm-change-password-1", which I believe would require non-trivial changes to rlm_mschap as it doesn't currently use ntlm_auth helper protocols. Does anyone have plans to incorporate this functionality? If so, I'd be willing to help. If not, I'm going to start investigating and implementing the changes required. I'm thinking that ideally, it would be implemented in a way that doesn't break the current method of configuring ntlm_auth in radiusd.conf (i.e., it would be backward compatible to avoid requiring everyone to change the config. if they aren't interested in the new functionality). Is anyone else interested in having this capability and/or have ideas on how best to integrate it?

2 1

POD/Disconnect-Packet Port
by Peter Nixon 27 Jan '07

27 Jan '07

Hi Guys radius.h has: #define PW_POD_UDP_PORT 1700 This is great, and works for me as it is the default for Cisco brand equipment however RFC 3576 specifies port 3799. I suggest that we change this in order to be "RFC compliant" instead of "Cisco compliant" by default. Does anyone have an issue with this? Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc

3 2

rlm_python
by Peter Nixon 26 Jan '07

26 Jan '07

Hi Guys Is anyone actually using rlm_python in production? Unlike rlm_perl we don't seem to have any example code or any decent documentation. I am looking at using it myself and just looking for some feedback.. Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc

1 0

fork and wait
by Joe Maimon 26 Jan '07

26 Jan '07

code calls rad_fork(1) (such as rad_check_ts()) This means that no entry is stored in thread_pool.waiters This means that rad_waitpid() calls reap_children() which means that subsequent calls to waitpid() -- since there is no thread_pool.waiters entry for the pid -- return an ECHILD, which leads rad_check_ts() to print this message radlog(L_ERR, "Check-TS: unknown error in waitpid()"); So basically rad_fork(1) and rad_waitpid() and waitpid() are now unreliable. Furthermore, using rad_fork(0) without rad_waitpid(pid,...,...) will eventualy result in a full thread_pool.waiters hashtable and calls to rad_fork(0) will fail. So waitpid(0,...,...) in reap_children() buys nothing except elimination of zombie processes by trading it in for causing calls of rad_fork(0) to fail. (why 0 and not -1 main waitpid..... -1 meaning wait for any child process. 0 meaning wait for any child process whose process group ID is equal to that of the calling process. ) I am getting errors forking my scripts off with rlm_exec -- apparently thread_pool.waiters is getting full somehow, since this is logged. Error: Couldn't fork /usr/local/sbin/radius-dns-update.sh: No child processes Which isnt a documented errno for fork() grep "No child" /usr/include/ -r /usr/include/asm-generic/errno-base.h:#define ECHILD 10 /* No child processes */ The fix? Here are some ideas. 1) reap_children() should only call waitpid() for entries in thread_pool.waiters -- this was the old way, should be fairly easy to revert to. This was changed due to zombies being created by creative forking in rlm_perl. I think that problem should have properly been resolved by using rad_fork() or by building its own long lived fork/wait mechanism or by properly daemonizing the child process. -- rad_fork(1)s or fork()s that are not followed by waitpid()s will result in zombies (which is a bug owned by the code doing the call to fork) IMHO this makes the most sense -- freeradius should not try to fix other code bugs by introducing all the breakage as descibed above. 2) reap_children() should create a thread_pool.waiters entry for pids that have exited for subsequent retrieval of status by rad_waitpid -- rad_fork(1)s or fork()s that are not followed by waitpid()s will result in thread_pool.waiters running out of elements. -- waitpid() is still unreliable -- rad_fork(1) is still (nearly) meaningless This can be handled by rad_fork() behaving differently, such as deleting all thread_pool.waiters elements that created by reap_children() if the thread_pool.waiters reaches its limit. This is a series of nasty kludges and workarounds for a problem that should exist in the first place. Attached find proof-of-concept patch 3) calls to rad_fork(1) should also result in creation of thread_pool.waiters element -- This doesnt completely solve anything and 2 is still needed. -- rad_fork(1) is meaningless 4) rad_fork() should mark elements in the hash table as deletable when the table is full -- after all, this is what exec_wait == 0 means, right? Perhaps to make it as correct as possible, it should only delete a percentage of the table, sorted by oldest entry. That might be hard. Why have a waiters pool anyway when calling waitpid(0 ? exec_wait == 1 processes get waited upon and their status discarded exec_wait == 0 processes get waited upon and their status kept until an explicit call to rad_waitpid() with the pid. #! /bin/sh /usr/share/dpatch/dpatch-run ## 360-rad_check_ts_waitpid.dpatch by <joe(a)nameserver3.ttec.com> ## ## All lines beginning with `## DP:' are a description of the patch. ## DP: No description. @DPATCH@ diff -urNad freeradius-2.0.0~/src/main/threads.c freeradius-2.0.0/src/main/threads.c --- freeradius-2.0.0~/src/main/threads.c 2007-01-17 09:00:25.000000000 -0500 +++ freeradius-2.0.0/src/main/threads.c 2007-01-17 09:02:37.000000000 -0500 @@ -113,10 +113,12 @@ RAD_REQUEST_FUNP fun; } request_queue_t; +#define MAX_WAITERS 1024 typedef struct thread_fork_t { pid_t pid; int status; int exited; + int reaper_created; } thread_fork_t; @@ -257,10 +259,10 @@ pid_t pid; int status; thread_fork_t mytf, *tf; - - if (lrad_hash_table_num_elements(thread_pool.waiters) == 0) return; - - pthread_mutex_lock(&thread_pool.wait_mutex); + int num_waiters = lrad_hash_table_num_elements(thread_pool.waiters); + + if (!num_waiters) + return; while (1) { pid = waitpid(0, &status, WNOHANG); @@ -268,12 +270,26 @@ mytf.pid = pid; tf = lrad_hash_table_finddata(thread_pool.waiters, &mytf); - if (!tf) continue; - - tf->status = status; + if (!tf) + { + tf = rad_malloc(sizeof(*tf)); + memset(tf, 0, sizeof(*tf)); + tf->pid = pid; + tf->status = status; + tf->exited = 1; + tf->reaper_created = 1; + if (!lrad_hash_table_insert(thread_pool.waiters, tf)) + { + free(tf); + tf = NULL; + } + if (++num_waiters >= MAX_WAITERS) + break; + continue; + } tf->exited = 1; + tf->status = status; } - pthread_mutex_unlock(&thread_pool.wait_mutex); } @@ -1049,16 +1065,29 @@ /* * Thread wrapper for fork(). */ +static int reap_reaper_children(void * context, void * data) +{ + thread_fork_t *tf = data; + if (tf->reaper_created) + lrad_hash_table_delete(thread_pool.waiters, tf); + return 0; +} + pid_t rad_fork(int exec_wait) { pid_t child_pid; + int num_waiters; if (exec_wait) return fork(); reap_children(); /* be nice to non-wait thingies */ - if (lrad_hash_table_num_elements(thread_pool.waiters) >= 1024) { - return -1; + if (lrad_hash_table_num_elements(thread_pool.waiters) >= MAX_WAITERS) { + lrad_hash_table_walk(thread_pool.waiters, reap_reaper_children, NULL); + if ((num_waiters = lrad_hash_table_num_elements(thread_pool.waiters)) >= MAX_WAITERS) { + radlog(L_ERR, "too many child waiters: %d", num_waiters); + return -1; + } } /* @@ -1104,8 +1133,8 @@ pid_t rad_waitpid(pid_t pid, int *status, int options) { thread_fork_t mytf, *tf; + pid_t child_pid = 0; - reap_children(); /* be nice to non-wait thingies */ if (pid <= 0) return -1; @@ -1117,22 +1146,21 @@ tf = lrad_hash_table_finddata(thread_pool.waiters, &mytf); if (!tf) { /* not found. It's a problem... */ - pthread_mutex_unlock(&thread_pool.wait_mutex); - return waitpid(pid, status, options); + child_pid = waitpid(pid, status, options); } - - if (tf->exited) { + else if (tf->exited) { *status = tf->status; lrad_hash_table_delete(thread_pool.waiters, &mytf); - pthread_mutex_unlock(&thread_pool.wait_mutex); - return pid; + child_pid = pid; } - /* - * Don't wait, and it hasn't exited. Return. + * else { + * Don't wait, and it hasn't exited. Return 0. + * } */ + reap_children(); /* be nice to non-wait thingies */ pthread_mutex_unlock(&thread_pool.wait_mutex); - return 0; + return child_pid; } #else /* HAVE_PTHREAD_H */

2 9

Automatic report from sources (radiusd) between 24.01.2007 - 25.01.2007 GMT
by Automatic cvs log generator 25 Jan '07

25 Jan '07

CVS log entries from 24.01.2007 (Wed) 09:00:01 - 25.01.2007 (Thu) 09:00:00 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/src/modules/rlm_eap/libeap/tls.c; Revisions: 1.6, 1.1.2.4 ===================================================== Log entries ===================================================== Description: Pull fix from 1.1 branch Modified files: File: radiusd/src/modules/rlm_eap/libeap/tls.c; Revision: 1.6; Date: 2007/01/24 12:38:25; Author: aland; Lines: (+11 -11) ------------------------------- Description: Fix longstanding bug where the session wasn't being properly terminated on SSL error. Instead, it continued, but set a bad pointer, causing a server crash. Modified files: File: radiusd/src/modules/rlm_eap/libeap/tls.c; Revision: 1.1.2.4; Date: 2007/01/24 12:24:49; Author: aland; Lines: (+10 -10) ===================================================== Summary of modified files ===================================================== File: radiusd/src/modules/rlm_eap/libeap/tls.c Revisions: 1.6, 1.1.2.4 Authors: aland (+11 -11), aland (+10 -10) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0

Automatic report from sources (radiusd) between 23.01.2007 - 24.01.2007 GMT
by Automatic cvs log generator 24 Jan '07

24 Jan '07

CVS log entries from 23.01.2007 (Tue) 09:00:00 - 24.01.2007 (Wed) 09:00:01 GMT ===================================================== Summary by authors ===================================================== Author: pnixon File: radiusd/raddb/experimental.conf; Revisions: 1.35 ===================================================== Log entries ===================================================== Description: Clean up the comments a little Modified files: File: radiusd/raddb/experimental.conf; Revision: 1.35; Date: 2007/01/23 16:26:06; Author: pnixon; Lines: (+8 -8) ===================================================== Summary of modified files ===================================================== File: radiusd/raddb/experimental.conf Revisions: 1.35 Authors: pnixon (+8 -8) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0

SQL inserts for accounting data
by Russell McConnachie 23 Jan '07

23 Jan '07

Hello, I am having a problem with my accounting section of my radiusd.conf configuration file. It seems if I have more than one directive such as 'sql' and then a second sql insert of accouting data called 'acme-packets' it caused the radiusd daemon to crash with a glibc pointer error. radiusd[26843]: segfault at 00000000000000b0 rip 00000032fa747edd rsp 0000000051818be0 error 4 radiusd[27894]: segfault at 0000000000000000 rip 00000032fa743550 rsp 000000005e02ccf0 error 4 radiusd[27917] trap invalid operand rip:38fd5306c8 rsp:409fc298 error:0 radiusd[28224]: segfault at 00000000000000b0 rip 00000032fa747edd rsp 0000000043c02be0 error 4 radiusd[28257]: segfault at 00000000000000b0 rip 00000032fa747edd rsp 0000000045004be0 error 4 radiusd[28285]: segfault at 0000000000000294 rip 00000032fa744f10 rsp 00000000413fecf8 error 4 -- CUT -- # # Log traffic to an SQL database. # # See "Accounting queries" in sql.conf # Temporary commented out because it is causing problems, it # seems # there can only be one instance of a SQL query/update per # "action". # action: (authentication, accounting, pre-processing....) sql # Cisco VoIP specific bulk accounting # pgsql-voip # Acme Packets bulk accounting acme-packets -- CUT -- sql acme-packets { ... accounting_start_query = "INSERT INTO radsbcacct_start(acct_status_type, nas_ip_address, nas_port, acct_session_id, \ acme_session_ingress_callid, acme_session_egress_callid, acme_session_protocol_type, \ calling_station_id, called_station_id, h323_setup_time, h323_connect_time, \ acme_session_egress_realm, acme_session_ingress_realm, acme_flowid_fs1_f, \ acme_flowtype_fs1_f, acme_flow_in_realm_fs1_f, acme_flow_in_src_addr_fs1_f, \ acme_flow_in_src_port_fs1_f, acme_flow_in_dst_addr_fs1_f, acme_flow_in_dst_port_fs1_f, \ acme_flow_out_realm_fs1_f, acme_flow_out_src_addr_fs1_f, acme_flow_out_src_port_fs1_f, \ acme_flow_out_dst_addr_fs1_f, acme_flow_out_dst_port_fs1_f, \ acme_flowid_fs2_f, acme_flowtype_fs2_f, acme_flow_in_realm_fs2_f, acme_flow_in_src_addr_fs2_f, \ acme_flow_in_src_port_fs2_f, acme_flow_in_dst_addr_fs2_f, acme_flow_in_dst_port_fs2_f, \ acme_flow_out_realm_fs2_f, acme_flow_out_src_addr_fs2_f, acme_flow_out_src_port_fs2_f, \ acme_flow_out_dst_addr_fs2_f, acme_flow_out_dst_port_fs2_f, client_ip_address, \ acct_unique_session_id) VALUES \ ('%{Acct-Status-Type}', '%{NAS-IP-Address}', %{NAS-Port}, '%{Acct-Session-Id}', '%{Acme-Session-Ingress-CallId}', '%{Acme-Session-Egress-CallId}', '%{Acme-Session-Protocol-Type}', '%{Calling-Station-Id}', '%{Called-Station-Id}', '%{h323-setup-time}', '%{h323-connect-time}', '%{Acme-Session-Egress-Realm}', '%{Acme-Session-Ingress-Realm}', '%{Acme-FlowID_FS1_F}', '%{Acme-FlowType_FS1_F}', '%{Acme-Flow-In-Realm_FS1_F}', '%{Acme-Flow-In-Src-Addr_FS1_F}', %{Acme-Flow-In-Src-Port_FS1_F}, '%{Acme-Flow-In-Dst-Addr_FS1_F}', %{Acme-Flow-In-Dst-Port_FS1_F}, '%{Acme-Flow-Out-Realm_FS1_F}', '%{Acme-Flow-Out-Src-Addr_FS1_F}', %{Acme-Flow-Out-Src-Port_FS1_F}, '%{Acme-Flow-Out-Dst-Addr_FS1_F}', %%{Acme-Flow-Out-Dst-Port_FS1_F}, '%{Acme-FlowID_FS1_F}', %'%{Acme-FlowType_FS1_F}', '%{Acme-Flow-In-Realm_FS1_F}', %'%{Acme-Flow-In-Src-Addr_FS1_F}', %{Acme-Flow-In-Src-Port_FS1_F}, %'%{Acme-Flow-In-Dst-Addr_FS1_F}', %{Acme-Flow-In-Dst-Port_FS1_F}, %'%{Acme-Flow-Out-Realm_FS1_F}', '%{Acme-Flow-Out-Src-Addr_FS1_F}', %%{Acme-Flow-Out-Src-Port_FS1_F}, '%{Acme-Flow-Out-Dst-Addr_FS1_F}', %%{Acme-Flow-Out-Dst-Port_FS1_F}, '%{Client-IP-Address}', %'%{Acct-Unique-Session-Id}')" ... } I know it is a huge query, but is it all of the accounting information which is sent to us by our SBC When both of these inserts are enabled I get a glibc pointer exception error. I am unable to regenerate the error right now being not many calls are being made and its not flooding the radius server with requests.

2 2

RADIUS Disconnect support
by Peter Nixon 23 Jan '07

23 Jan '07

Hi Guys I have been playing with (read: using in production) RADIUS disconnect support and I have a few ideas about how we can/should integrate it into FreeRADIUS server which I thought I would share with you all for your comments. Firstly let me explain how I am using it. I have the following defined: exec radsqlkill { wait = yes program = "/usr/local/bin/radsqlkill.pl %{Calling-Station-Id}" shell_escape = yes output = none packet_type = Access-Request } authorize { radsqlkill } Now, radsqlkill.pl is designed to kill any active sessions with a Disconnect packet based on info from the radacct table. It can be provided with a username, or in my case Calling-Station-Id. Basically this lets me do simultaneous use limiting but instead of rejecting the second login it disconnects the first and allows the second. I think that this functionality and more needs to be rolled into radiusd. Basically we need to be able to do the following things: 1) Receive a disconnect packet on port 1700 and check a shared secret (New listen type in radiusd.conf) 2) Query the radacct table to find disconnect attributes based on a supplied attributes (username, callingstationid etc) 3) Send disconnect packet(s) to NAS with a shared secret and return status Now the shared secret in 1) is different from the shared secret in 3). They are both NEW config options and need to be saved somewhere. I think to keep things simple 1) should be an additional option in each realm in proxy.conf (as Disconnect senders will _mostly_ correspond with home servers) and 3) should be an additional option in each client in clients.conf (as Disconnect receivers will _mostly_ correspond with client NAS) It is technically possible that we would want to allow disconnect packets from non home servers, and send them to NAS which are not clients (think where you have chained RADIUS proxies) but I think it will make things unnecessary complicated. What do others think? I think the 3 steps I have listed above will allow everyone to be able to do what they want with Disconnect packets. Basically in the situation where radius is acting as a proxy and you want to allow a home server to disconnect a user on a NAS client you will need all 3 steps (in order). To do what I am doing above with my perl script you will only need steps 2) and 3). People who want to generate disconnect attributes from arbitrary input (a script or custom module) will simply use 3). In all cases the module should look up the appropriate shared secret from the NAS table or clients.conf. Does anyone have anything to add to this? I plan to start implimenting this as I have time as my perl script causes a 500ms Authentication delay (mostly due to perl startup) which I would like to get rid of :-) Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc

2 2

Automatic report from sources (radiusd) between 22.01.2007 - 23.01.2007 GMT
by Automatic cvs log generator 23 Jan '07

23 Jan '07

CVS log entries from 22.01.2007 (Mon) 09:00:01 - 23.01.2007 (Tue) 09:00:00 GMT ===================================================== Summary by authors ===================================================== Author: pnixon File: radiusd/raddb/radiusd.conf.in; Revisions: 1.238, 1.237 ===================================================== Log entries ===================================================== Description: Update comments to correctly reflect which detail files contain User Passwords and additionally add an example "suppress" statement to each. Modified files: File: radiusd/raddb/radiusd.conf.in; Revision: 1.238; Date: 2007/01/23 02:00:06; Author: pnixon; Lines: (+11 -7) ------------------------------- Description: fix 2 minor typos in the comments Modified files: File: radiusd/raddb/radiusd.conf.in; Revision: 1.237; Date: 2007/01/22 16:51:27; Author: pnixon; Lines: (+3 -3) ===================================================== Summary of modified files ===================================================== File: radiusd/raddb/radiusd.conf.in Revisions: 1.238, 1.237 Authors: pnixon (+11 -7), pnixon (+3 -3) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0

checkrad cisco
by Joe Maimon 19 Jan '07

19 Jan '07

session_id doesnt appear to work, probably since my session ID's look like this 0/1/0/2.33_00000007 so snmpget doesnt work. But neither does snmpwalk -- without this patch. I dont know which is correct. --- /usr/sbin/checkrad 2006-12-14 02:22:21.000000000 -0500 +++ /usr/local/sbin/checkrad.deb 2007-01-19 06:48:25.000000000 @@ -401,7 +401,7 @@ if($login eq $ARGV[3]) { return 1; }else{ - $out=snmpwalk($ARGV[1],$pass,".iso.org.dod.internet.private.enterprises.9.10.19.1.3.1.1.3"); + $out=snmpwalk($ARGV[1],$pass,".iso.org.dod.internet.private.enterprises.9.9.150.1.1.3.1.2"); if($out=~/\"$ARGV[3]\"/){ return 1; }else{

2 1