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

New dynamic IP pools module
by Pawel Foremski 25 Feb '07

25 Feb '07

Hi group, Here is a new FreeRADIUS module which provides dynamic IP addresses. It uses some new approaches and IMHO has greater functionality in some areas than already existing solutions. More information: http://projects.asn.pl/freemods/wiki/rlm_netvim_pools Source code (last test with v. 1.1.3): svn co http://svn.asn.pl/freemods/trunk/rlm_netvim_pool The code has been in production use since 2005, so I would consider it quite stable. BTW, I would like to submit a new vendor-specific RADIUS dictionary to the FreeRADIUS project: http://svn.asn.pl/misc/freeradius/dictionary.asn We, guys at ASN, develop a Linux distribution for network access servers - Lintrack [1] - and we use this dictionary for functionality implemented in our system. I would like to thank the FreeRADIUS development team for their great work. It's one of the best coded servers implemented in C I've ever seen (at least the core ;-)). Stay tuned for our further contributions to the project (and hey, don't miss our FreeRADIUS web interface [2])!. [1] http://www.lintrack.org/ [2] http://projects.asn.pl/ara/ Cheers, -- Pawel Foremski pjf(a)asn.pl

4 13

Bug in radclient when parsing long value from file (FreeRADIUS 1.1.3)
by Geoffroy Arnoud 07 Feb '07

07 Feb '07

Hi all, There a bug in radclient when reading a valuepair from a file, when the value is to long to be read, when written in hexadecimal. Actually, when a value can be at most 253 bytes (on the network), when expressed in hexadecimal, it requires 253x2 + 2 (0x) characters. Here is a sample request that shows the issue. NAS-IP-Address = 10.194.96.114 Framed-IP-Address = 192.168.100.69 Event-Timestamp = "Dec 18 2006 08:42:08 CET" Acct-Status-Type = Stop WISPr-Location-Name = "Something" Acct-Output-Octets = 32411 Acct-Terminate-Cause = Session-Timeout Acct-Session-Id = "00000743" NAS-Identifier = "SomethingNAS" Acct-Output-Gigawords = 0 NAS-Port-Type = Virtual User-Name = "user@company" Acct-Session-Time = 600 Acct-Input-Gigawords = 0 Class = 0x53425232434cc383c2a6c382c2b4c383efbfbdc383c2adc383c2a7c383c2acc383c5b8c383e280b9c383c2b7c3a2e2809ac2ac11c3a2e2809ac2ac3901c3a2e2809ac2ac08c3afc2bfc2bdc385c2bec3a2e282acc2bac383c2acc383c2a7c3a2e282acc593c383e280b0c383c5bec382c2be02c3a2e2809ac2ac17c3afc2bfc2bdc385e2809cc385e28099c383c2a6c3a2e282acc593c3af Acct-Input-Octets = 324352 The bug is located in file src/lib/valuepair.c in function pairread. A patch is attached that increases the size of the "value" buffer to 512 bytes. Does anyone see side effects? Best regards, Geoff. ___________________________________________________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com

2 1

Question about rad_fork
by Garber, Neal 01 Feb '07

01 Feb '07

While reviewing rad_fork, as part of an enhancement I'm working on, I found something questionable. After the call to fork, it tests if child_pid != 0 (to see if the parent is the process executing, I presume). If true, then, the child_pid is added to the thread pool and the thread pool mutex is unlocked. However, if the fork failed, -1 is returned (and stored in child_pid), which I believe will then be added to the thread pool (because -1 != 0 and there isn't an explicit test for fork success/failure). Shouldn't there be a test for fork success (child_pid > 0) before adding to the thread pool? Perhaps this isn't a big deal because fork probably doesn't fail that often. But, it isn't clear to me what would happen in reap_children when it calls waitpid with -1 as this tells waitpid to return status for any child. Am I missing something? If not, and you want me to submit a bug report with the minor code change, let me know..

4 9

RFC 3748 compliancy
by Geoffroy Arnoud 01 Feb '07

01 Feb '07

hi all, I took a look at EAP method source code (even if crypto is not my speciality), and I'm wondering if all EAP methods shipped into freeRADIUS are compliant with RFC3748, regarding MSK and EMSK generation? This RFC states that "EAP method supporting key derivation MUST export a Master Session Key (MSK) of at least 64 octets, and an Extended Master Session Key (EMSK) of at least 64 octets." (§ 7.10) Which are the EAP methods that supports key derivation? And regarding other EAP methods, is there a way to add EMSK generation (maybe this is a stupid question)? I need those answers to see if FreeRADIUS would be able to act as a EAP RADIUS server compliant with WiMAX NWG stage 3. Many thanks for your answers Geoff. ___________________________________________________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com

2 2

Acct-Status-Type block
by Peter Nixon 01 Feb '07

01 Feb '07

It just occurred to me that it would be pretty cool to be able to do: accounting { Acct-Status-Type Stop { ## Log stop packets to disk stop_log } } In the same manner as: post-auth { Post-Auth-Type REJECT { ## Log authentication rejects to disk reply_log } } Is there any way to do this at present (short of writing a custom module)? Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc

2 2

Re: Vendor statement re: CVE-2007-0080
by Alan DeKok 30 Jan '07

30 Jan '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chang, Robert wrote: > Thank you for bringing this to our attention. I'm in the process of > updating this vulnerability with the vendor statement, the updated > evaluation, and the overview. I've read the Security Focus thread, and > I understand the vector of attack is through the manipulation of a > configuration file (stored locally). Yes. > However, it seems like obtaining > additional access privileges is still possible if a normal user was > given write/complete access to the program's directory. To me, that's a misconfiguration of local file permissions, and not a vulnerability in the server. > Could you > please confirm that a local user with full access to application's > directory cannot gain root access to the machine? If a local user can > gain root access, by default, Confidentiality, Integrity, and > Availability are set to complete. If a local user can write to the config files, then *any* server available on the net is vulnerable to this attack. There's no way for a server to reliably determine that users with write permission on the files are "authorized", or "unauthorized". Since many servers can be configured to execute arbitrary programs, this "vulnerability" would appear to be common across a wide range of servers. And in any case, it has nothing whatsoever to do with the SMB buffer overflow. And users who cannot run arbitrary programs as root can still cause configuration file parse errors, and take down programs that are critical to a systems operation. > Each NVD vulnerability is based on > worst-case, so the final scoring would reflect the worst case of root > access. If this is impossible by design, then I'll be sure to update > the vulnerability accordingly. Thank you again for your help. Like many servers, FreeRADIUS permits arbitrary programs to be executed from the configuration files. Buffer overflows are unnecessary, as there are ways to configure the server to directly execute arbitrary programs. As a data point, I just tested Apache2. It is similarly "vulnerable" to the "exploit" of local file permissions, since it also is able to run as "root". If you list this as a vulnerability in FreeRADIUS, then I'm curious as to whether or not you'd accept a similar vulnerability notification for Apache2. If so, I will submit one. If not, please explain why. I'm also curious as to how the server can determine that users with write permission are not, in fact, authorized to write to the configuration files. Some minimal checking is possible, but it does not help in all circumstances, and it can likewise be bypassed by local file permission misconfigurations. Alan DeKok Project Leader The FreeRADIUS Server Project PGP key: http://freeradius.org/pgp/aland@freeradius.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRb4rKakul4vkAkl9AQL6twP9EYmIxtWKmLMM5aeGvNNgznb6D43+Nlx3 nL1yxSkFbN7bjYqKtPQ74MdDH4RaI3jYJktqOb8vqRrl3cxq/NBK67w1gC8y3tOT qqsVkjw5gHi6hYC4i79p2lVG/7SvFo2BTdAhlgkqewxNIYFcKAqdGUmjGsB+azfk 5yRQE1y+nzA= =BxuH -----END PGP SIGNATURE-----

2 1

SecurityTracker Alert ID 1017463
by Alan DeKok 29 Jan '07

29 Jan '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 SecurityTracker Alert ID 1017463 was recently brought to our attention. Our official statement about this issue is: - -- Official Vendor Statement from the FreeRADIUS Server project This issue is not a security vulnerability. The exploit is available only to local administrators who have write access to the server configuration files. As such, this issue has no security impact on any system running FreeRADIUS. - -- Official Vendor Statement from the FreeRADIUS Server project Please update the title and impact fields to indicate that the issue is NOT remotely exploitable. The "solution" is simple: ensure that only authorized users have write access to the server configuration files. We are curious as to why the issue is labelled "remote execution of code". The original notification did not claim that the issue was vulnerable to remote exploit. If you have any additional data that causes you to believe it is remotely exploitable, that information should be supplied to us so we can fix the problem. Barring additional data, we believe that the issue is non-existent, and has no security impact on any system running FreeRADIUS. Alan DeKok Project Leader The FreeRADIUS Server Project -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRb3g+6kul4vkAkl9AQL59QP/TO4aw3BpNkr3k3/lFqh2jYCymjEPjC1T GsVrW3ptuzDqO/JJ9lMWZYVPOjVWcfYWSPJg7COj+cHgDV331wC2feGeeWkgb3lG SbmX/wv9I+rSTSe3xkTtQL8Fe3tdtNbAaeIIeYx9AhB4c8rv+vO6GKFIXkaEdUq+ 7VoUZqykEbk= =OnAE -----END PGP SIGNATURE-----

1 0

freeradius-smbconnectserver-bo (31248) feedback
by Alan DeKok 29 Jan '07

29 Jan '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Please update your database with the following vendor statement re: the FreeRADIUS SMB_Connect_Server issue. - -- Official Vendor Statement from the FreeRADIUS Server project This issue is not a security vulnerability. The exploit is available only to local administrators who have write access to the server configuration files. As such, this issue has no security impact on any system running FreeRADIUS. - -- Official Vendor Statement from the FreeRADIUS Server project The current "Description" is, in fact, nonsensical: > By sending a specially-crafted SMB request containing a malformed > Con_Handle parameter, a remote attacker could overflow a buffer and > execute arbitrary code on the system. "Con_Handle" is a data structure inside of the server, and is therefore never sent in a SMB request. The issue is not remotely exploitable, and we are curious as to how ISS arrived at the above text. The original notification did not state that the problem was remotely exploitable. We suggest the following text for the Description, Remedy, and Consequences sections: - -- Description FreeRADIUS is vulnerable to a buffer overflow, caused by improper bounds checking by the SMB_Connect_Server() function of the SMB_Handle_Type class. Local administrators can update the configuration file to overflow a buffer when the server starts. This issue cannot be exploited remotely, and can only be exploited by users who have write access to the server configuration files. - -- Description: - -- Remedy: Administrators should ensure that unauthorized users do not have write access to the server configuration files. - -- Remedy: - -- Consequences: None. - -- Consequences: This issue is not a real vulnerability, and we therefore request that you update your database to indicate that. Alan DeKok. Project Leader The FreeRADIUS Server Project -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRb3fY6kul4vkAkl9AQJtUQQAhOLB4VO3zwNBdPKqTbdTTAA+kgFW66ew NRd1I8pZah0aUUeVCX/+fNC6E6HuWjs93oyJ/Rqi4acK/5EEVxLubMmsQnIDd9+i XFdXIsZSz+e2n8Kc1hxIcgNTnc3ZXretUeIOBxUGngcVLwmTtfGGfK/uZVjw4iHV PGOKIEeG5cQ= =TkSw -----END PGP SIGNATURE-----

1 0

Vendor statement re: CVE-2007-0080
by Alan DeKok 29 Jan '07

29 Jan '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 CVE-2007-0080 was recently brought to our attention. Please find our official response below. In short, the response of 3APA3A is correct. (i.e. http://www.securityfocus.com/archive/1/455812/100/0/threaded) We believe that the correct CVSS base score metrics are as follows: http://nvd.nist.gov/cvss.cfm?name=CVE-2007-0080&vector=(AV:L/AC:L/Au:R/C:N/… The issue is NOT remotely exploitable. The attack complexity is low (editing a configuration file). Only authenticated administrators on the local machine can cause this issue. There is no confidentiality impact, as the administrator already has complete access to the local system. There is no integrity or availability impact, because exploiting the issue is done by the local administrator who runs code he is permitted to run, with a privilege level he is permitted to use. Please update the CVE listing with the above CVSS base score. For publication on the web site, our official statement is: - -- Official Vendor Statement from the FreeRADIUS Server project This issue is not a security vulnerability. The exploit is available only to local administrators who have write access to the server configuration files. As such, this issue has no security impact on any system running FreeRADIUS. - -- Official Vendor Statement from the FreeRADIUS Server project Please also update the Overview, with the following suggested text: - -- Overview A buffer overflow in the SMB_Connect_Server function in FreeRADIUS 1.1.4 and earlier allows attackers to execute arbitrary code related to the server desthost field of an SMB_Handle_Type instance. This issue can not be exploited remotely, and can only be exploited by administrators who have write access to the server configuration files. - -- Overview As additional information, the originator of the issue did not contact us for an official vendor statement, and did not respond to our attempts to discuss this issue. Our security contact is clearly available on the web site (http://freeradius.org/security.html) and includes a PGP key for authentication confidentiality. We suggest anyone who believes they find an issue in FreeRADIUS contact us before making the issue public. Alan DeKok Project Leader The FreeRADIUS Server Project -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRb3Seakul4vkAkl9AQLH2gP/Uvi+92B5me9E/nq6tlG58RrlNfsQoRHG E6Kilk/9CACjOHRLk02dLo9eVN9kZYCZ8eOL8ki9Mfx7hRfFFWPmrWQ41w71wegO n85oOooXdH5O8gu/5siu3RlsBkHKfNo72ywMz8xJGbKHUlDcFhoZWNqZOGVIjDW6 TH/oa8nmnYo= =/Jg6 -----END PGP SIGNATURE-----

1 0

freeradius-client
by Chris Parker 28 Jan '07

28 Jan '07

Having some issues with freeradius-client. :) I've build a CDR module for FreeSwitch ( www.freeswitch.org ) that uses the radiusclient library to send accounting data. Right now, it's just sending some basic data as a proof of concept ( User-Name, Call(ed|ing)-Station, etc. ). It sends okay, but the packet is rejected by FreeRADIUS ( v1.1.3 ) with an invalid shared-secret. Here's the relevant code from the client library where it calculates the Req Authenticator: if (data->code == PW_ACCOUNTING_REQUEST) { rc_log(LOG_ERR,"DEBUG-signing accounting request\n"); total_length = rc_pack_list(data->send_pairs, secret, auth) + AUTH_HDR_LEN; auth->length = htons ((unsigned short) total_length); memset((char *) auth->vector, 0, AUTH_VECTOR_LEN); secretlen = strlen (secret); memcpy ((char *) auth + total_length, secret, secretlen); /* cparker */ rc_log(LOG_ERR,"DEBUG-code,seq %d:%d, secret %s, length %d\n", auth->code, auth->id, secret, total_length); rc_md5_calc (vector, (unsigned char *) auth, total_length + secretlen); memcpy ((char *) auth->vector, (char *) vector, AUTH_VECTOR_LEN); } This outputs: DEBUG-code,seq 4:212, secret testing123, length 204 The resulting packet ( intercepted with tcpdump ) is length 204: RADIUS, length: 204 Accounting Request (4), id: 0xd0, Authenticator: 57fe69699a09491bf38cf5e24bdd847b Accounting Status Attribute (40), length: 6, Value: Stop Username Attribute (1), length: 52, Value: starnetusa.net/ 18479630116(a)test-td1.starnetusa.net Called Station Attribute (30), length: 12, Value: 8478797989 Calling Station Attribute (31), length: 52, Value: starnetusa.net/18479630116@test-td1.starnetusa.net Accounting Session Time Attribute (46), length: 6, Value: 540:48:23 hours NAS Port Attribute (5), length: 6, Value: 0 Accounting Delay Attribute (41), length: 6, Value: 00 secs NAS IP Address Attribute (4), length: 6, Value: dev- cr1.starnetusa.net 0x0000: 4500 00e8 0001 4000 4011 773b d87e 901a E.....@.@.w;.~.. 0x0010: d87e 81b1 8030 0715 00d4 c3ae 04d0 00cc .~... 0.......... 0x0020: 57fe 6969 9a09 491b f38c f5e2 4bdd 847b W.ii..I.....K..{ 0x0030: 2806 0000 0002 2c26 6565 3265 3864 3062 (.....,&ee2e8d0b 0x0040: 2d61 3266 392d 3465 3233 2d38 3037 382d - a2f9-4e23-8078- 0x0050: 6638 3162 3731 3361 3732 6139 0134 7374 f81b713a72a9.4st 0x0060: 6172 6e65 7475 7361 2e6e 6574 2f31 3834 arnetusa.net/184 0x0070: 3739 3633 3031 3136 4074 6573 742d 7464 79630116@test-td 0x0080: 312e 7374 6172 6e65 7475 7361 2e6e 6574 1.starnetusa.net 0x0090: 1e0c 3834 3738 3739 3739 3839 1f34 7374 .. 8478797989.4st 0x00a0: 6172 6e65 7475 7361 2e6e 6574 2f31 3834 arnetusa.net/184 0x00b0: 3739 3633 3031 3136 4074 6573 742d 7464 79630116@test-td 0x00c0: 312e 7374 6172 6e65 7475 7361 2e6e 6574 1.starnetusa.net 0x00d0: 2e06 001d b517 0506 0000 0000 2906 0000 ............)... 0x00e0: 0000 0406 d87e 901a .....~.. Any ideas on what's wrong with this? -Chris -- Chris Parker Director, Engineering US LEC Corp. Internet Telephony & ISP Operations (888)212-0099 Fax (847)963-1302 Wholesale Internet Services http://www.megapop.net VoiceEclipse, The Fresh Alternative http://www.voiceeclipse.com NOTICE: Message is sent IN CONFIDENCE to addressees. It may contain information that is privileged, proprietary or confidential.

5 14

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

Automatic report from sources (radiusd) between 18.01.2007 - 19.01.2007 GMT
by Automatic cvs log generator 19 Jan '07

19 Jan '07

CVS log entries from 18.01.2007 (Thu) 09:00:00 - 19.01.2007 (Fri) 09:00:00 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/doc/rlm_sqlcounter; Revisions: 1.3.6.3 File: radiusd/raddb/radiusd.conf.in; Revisions: 1.188.2.4.2.15 ===================================================== Combined list of identical log entries ===================================================== Description: Remove old text, and clarify other text Modified files: File: radiusd/doc/rlm_sqlcounter; Revision: 1.3.6.3; Date: 2007/01/18 14:01:20; Author: aland; Lines: (+23 -45) File: radiusd/raddb/radiusd.conf.in; Revision: 1.188.2.4.2.15; Date: 2007/01/18 14:01:19; Author: aland; Lines: (+6 -1) ===================================================== Log entries ===================================================== ===================================================== Summary of modified files ===================================================== File: radiusd/doc/rlm_sqlcounter Revisions: 1.3.6.3 Authors: aland (+23 -45) ------------------------------- File: radiusd/raddb/radiusd.conf.in Revisions: 1.188.2.4.2.15 Authors: aland (+6 -1) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0

Need help
by Abhinay Sinha 18 Jan '07

18 Jan '07

Hi, I am developing a billing package for ISPs. I am trying to use the freeradius server, but my problem is that my database schemas are complex and won't be working with the available modules. That means I will have to develop a custom module for my software and compile it with freeradius. My problem is that if I do that, it won't be compatible with general RADIUS servers and I'll have to provide the software with freeradius server and my module. So will it mean that I'll have to keep my software GPL, since I am using and distributing freeradius and also it contains mysql server, or can I distribute my software commercially? Kindly help me and tell me what can be done regarding the same? Thanks in advance. Abhinay

5 25

segfault when mysql server is unreachable for period of time
by Joe Maimon 17 Jan '07

17 Jan '07

Anyone else run into this?

2 2

cancelling requests due to max_request_time
by Frank Cusack 16 Jan '07

16 Jan '07

request_list.c around line 574, calling pthread_cancel() on the thread handling a timed out request is a bad idea. It can leave resources hanging, like a locked mutex for ownership of an ldap file descriptor. In order for pthread_cancel() to be a good idea, most modules would need to take care to disable cancellation while they hold resources open, and/or set cancellation handlers to clean them up. That's a lot of work and there's a lot of room for bugs there. But I can't think of a better approach. You don't want to let threads just run to completion and waste resources. -frank

2 5

RE: Need help
by Alexander Schrab 15 Jan '07

15 Jan '07

> But you're right, that's too much work. I'll update the > "digest" module so that that much work is no longer necessary. Speaking of which, has anyone any updated info on the RFC4590 status? /Alex

2 1