From freeradius-devel@lists.freeradius.org Mon Mar 1 09:02:35 2004 From: freeradius-devel@lists.freeradius.org (Automatic cvs log generator) Date: Mon, 1 Mar 2004 03:02:35 -0600 (CST) Subject: Automatic report from sources (radiusd) between 29.02.2004 - 01.03.2004 GMT Message-ID: <20040301090235.83EC677463@webhost1.starnetusa.net> CVS log entries from 29.02.2004 (Sun) 09:00:01 - 01.03.2004 (Mon) 09:00:01 GMT ===================================================== Summary by authors ===================================================== Author: kkalev File: radiusd/src/modules/rlm_pap/rlm_pap.c; Revisions: 1.15 File: radiusd/src/modules/rlm_ldap/rlm_ldap.c; Revisions: 1.118 File: radiusd/dialup_admin/bin/monthly_tot_stats; Revisions: 1.5 File: radiusd/dialup_admin/Changelog; Revisions: 1.183 File: radiusd/src/modules/rlm_sql/drivers/rlm_sql_postgresql/db_postgresql.sql; Revisions: 1.16 File: radiusd/src/modules/rlm_ippool/rlm_ippool.c; Revisions: 1.30 File: radiusd/raddb/radiusd.conf.in; Revisions: 1.176 File: radiusd/dialup_admin/conf/config.php3; Revisions: 1.10 File: radiusd/dialup_admin/bin/tot_stats; Revisions: 1.5 File: radiusd/raddb/postgresql.conf; Revisions: 1.14 ===================================================== Combined list of identical log entries ===================================================== Description: * Add a patch from Neil McCalden to not put spaces in the -p argument to the mysql binary. * Fix a bug in conf/config.php3. Patch from Neil McCalden Modified files: File: radiusd/dialup_admin/Changelog; Revision: 1.183; Date: 2004/02/29 12:16:17; Author: kkalev; Lines: (+2 -0) File: radiusd/dialup_admin/bin/monthly_tot_stats; Revision: 1.5; Date: 2004/02/29 12:16:17; Author: kkalev; Lines: (+1 -1) File: radiusd/dialup_admin/bin/tot_stats; Revision: 1.5; Date: 2004/02/29 12:16:17; Author: kkalev; Lines: (+1 -1) File: radiusd/dialup_admin/conf/config.php3; Revision: 1.10; Date: 2004/02/29 12:16:17; Author: kkalev; Lines: (+1 -2) ------------------------------- Description: Replace user with username in postauth table. Patch by Guy Fraser Modified files: File: radiusd/raddb/postgresql.conf; Revision: 1.14; Date: 2004/02/29 13:06:57; Author: kkalev; Lines: (+1 -1) File: radiusd/src/modules/rlm_sql/drivers/rlm_sql_postgresql/db_postgresql.sql; Revision: 1.16; Date: 2004/02/29 13:06:58; Author: kkalev; Lines: (+2 -2) ===================================================== Log entries ===================================================== Description: Also update radiusd.conf Modified files: File: radiusd/raddb/radiusd.conf.in; Revision: 1.176; Date: 2004/02/29 13:35:16; Author: kkalev; Lines: (+5 -1) ------------------------------- Description: Add a timestamp and a timeout attribute in ippool_info. When we assign an ip we set timestamp to request->timestamp and timeout to %{Session-Timeout:-0}. When we search for a free entry we check if timeout has expired. If it has then we free the entry. We also add a maximum timeout configuration directive. If it is non zero then we also use that one to free entries. Modified files: File: radiusd/src/modules/rlm_ippool/rlm_ippool.c; Revision: 1.30; Date: 2004/02/29 13:33:17; Author: kkalev; Lines: (+26 -3) ------------------------------- Description: If we are passed an empty password log a module failure message not an error message Modified files: File: radiusd/src/modules/rlm_ldap/rlm_ldap.c; Revision: 1.118; Date: 2004/02/29 13:55:08; Author: kkalev; Lines: (+6 -2) ------------------------------- Description: Also be able to use Crypt-Password attribute. If we are passed an empty password create a module failure message and fail not just log an error message Modified files: File: radiusd/src/modules/rlm_pap/rlm_pap.c; Revision: 1.15; Date: 2004/02/29 13:52:50; Author: kkalev; Lines: (+13 -4) ===================================================== Summary of modified files ===================================================== File: radiusd/dialup_admin/Changelog Revisions: 1.183 Authors: kkalev (+2 -0) ------------------------------- File: radiusd/dialup_admin/bin/monthly_tot_stats Revisions: 1.5 Authors: kkalev (+1 -1) ------------------------------- File: radiusd/dialup_admin/bin/tot_stats Revisions: 1.5 Authors: kkalev (+1 -1) ------------------------------- File: radiusd/dialup_admin/conf/config.php3 Revisions: 1.10 Authors: kkalev (+1 -2) ------------------------------- File: radiusd/raddb/postgresql.conf Revisions: 1.14 Authors: kkalev (+1 -1) ------------------------------- File: radiusd/raddb/radiusd.conf.in Revisions: 1.176 Authors: kkalev (+5 -1) ------------------------------- File: radiusd/src/modules/rlm_ippool/rlm_ippool.c Revisions: 1.30 Authors: kkalev (+26 -3) ------------------------------- File: radiusd/src/modules/rlm_ldap/rlm_ldap.c Revisions: 1.118 Authors: kkalev (+6 -2) ------------------------------- File: radiusd/src/modules/rlm_pap/rlm_pap.c Revisions: 1.15 Authors: kkalev (+13 -4) ------------------------------- File: radiusd/src/modules/rlm_sql/drivers/rlm_sql_postgresql/db_postgresql.sql Revisions: 1.16 Authors: kkalev (+2 -2) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl From freeradius-devel@lists.freeradius.org Mon Mar 1 10:28:31 2004 From: freeradius-devel@lists.freeradius.org (Adrian Pavlykevych) Date: Mon, 01 Mar 2004 12:28:31 +0200 Subject: Automatic report from sources (radiusd) between 29.02.2004 - 01.03.2004 GMT In-Reply-To: <20040301090235.83EC677463@webhost1.starnetusa.net> References: <20040301090235.83EC677463@webhost1.starnetusa.net> Message-ID: <4043104F.4090100@polynet.lviv.ua> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Description: > If we are passed an empty password log a module failure message not an error message > Modified files: > File: radiusd/src/modules/rlm_ldap/rlm_ldap.c; Revision: 1.118; > Date: 2004/02/29 13:55:08; Author: kkalev; Lines: (+6 -2) This has compatibility issue in itself. E.g. Novell eDirectory 8.x will accept _any_ username and empty password and treat such connection as anonymous, if anonymous access is allowed. Of course, it should not do that, but it does, hence this error generation in rlm_ldap. Please make this config option, if you feel that rlm_ldap should accept usernames with empty passwords. Regards, - -- Adrian Pavlykevych -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) iD8DBQFAQxBYdWQndLibxtARAlpBAJ9BdyRYr91yCR+55D7vjGjxhFRaeACffup3 khOCadrRxj6ek0QYORpZ+5Y= =+1QB -----END PGP SIGNATURE----- From freeradius-devel@lists.freeradius.org Mon Mar 1 10:34:56 2004 From: freeradius-devel@lists.freeradius.org (Adrian Pavlykevych) Date: Mon, 01 Mar 2004 12:34:56 +0200 Subject: Automatic report from sources (radiusd) between 29.02.2004 - 01.03.2004 GMT In-Reply-To: <4043104F.4090100@polynet.lviv.ua> References: <20040301090235.83EC677463@webhost1.starnetusa.net> <4043104F.4090100@polynet.lviv.ua> Message-ID: <404311D0.9050109@polynet.lviv.ua> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adrian Pavlykevych wrote: >>> Description: >>> If we are passed an empty password log a module failure message not an >>> error message >>> Modified files: >>> File: radiusd/src/modules/rlm_ldap/rlm_ldap.c; Revision: 1.118; >>> Date: 2004/02/29 13:55:08; Author: kkalev; Lines: (+6 -2) > > > This has compatibility issue in itself. E.g. Novell eDirectory 8.x will > accept _any_ username and empty password and treat such connection as > anonymous, if anonymous access is allowed. Of course, it should not do > that, but it does, hence this error generation in rlm_ldap. > > Please make this config option, if you feel that rlm_ldap should accept > usernames with empty passwords. Oops, I have misunderstood commit message, please ignore previous post. I was thinking that code is being modified to pass empty password to ldap connection routine. Now, after review of CVS diff, I understand my mistake. Sorry, - -- Adrian Pavlykevych -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) iD8DBQFAQxHQdWQndLibxtARAsS2AJ4wjUAjFIrSzvRYNlniE22uyfN9GQCgvqUR j+/M9efzi+kGaEzasEcgX8c= =C0mM -----END PGP SIGNATURE----- From freeradius-devel@lists.freeradius.org Mon Mar 1 14:49:33 2004 From: freeradius-devel@lists.freeradius.org (David@lolling.org) Date: Mon, 1 Mar 2004 08:49:33 -0600 Subject: Proxy based on IP or by realm References: <20040228143816.5D844170BB@mail.nitros9.org> Message-ID: <003601c3ff9c$7aac9e60$6402010a@anpinetwork.com> > You can proxy on any criteria you want. Just match a packet, and > set Proxy-To-Realm. > DEFAULT Attribute-Name == value, Proxy-To-Realm := "foo" > So in terms of allowing a range of IP addresses, what is the syntax? Is the same syntax that is allowed in clients.conf allowed here as well. For example, is 192.168.0.0/24 valid syntax for DEFAULT Client-NAS-IP == 192.168.0.0/24 , Proxy-To-Realm := "foo.bar" Thanks, Dave From freeradius-devel@lists.freeradius.org Mon Mar 1 17:37:43 2004 From: freeradius-devel@lists.freeradius.org (R. Bernstein) Date: Mon, 1 Mar 2004 12:37:43 -0500 Subject: patch to radwho to make "Location" field 15 digits (from 9) Message-ID: <16451.29927.607150.796409@yuban150.mc.yu.edu> Below is a small patch to increase the size on the "Location" field seen in radwho. For us the location is an IP address; 9 digits doesn't give the crucial entier lower-order octet of an IP address. The following patch increases this 15 digits (but some probably may want more if IP v6 or a DNS name were used.). Comments? Thanks for all the great work. --- radwho.c 2002-10-30 15:38:18.000000000 -0500 +++ /usr/local/src/freeradius-snapshot-20040203/src/main/radwho.c 2004-02-19 15:10:39.000000000 -0500 @@ -54,17 +54,17 @@ * Header above output and format. */ static const char *hdr1 = -"Login Name What TTY When From Location"; -static const char *ufmt1 = "%-10.10s %-17.17s %-5.5s %-4.4s %-9.9s %-9.9s %-.16s%s"; +"Login Name What TTY When From Location"; +static const char *ufmt1 = "%-10.10s %-17.17s %-5.5s %-4.4s %-9.9s %-15.15s %-.16s%s"; static const char *ufmt1r = "%s,%s,%s,%s,%s,%s,%s%s"; -static const char *rfmt1 = "%-10.10s %-17.17s %-5.5s %s%-3d %-9.9s %-9.9s %-.19s%s"; +static const char *rfmt1 = "%-10.10s %-17.17s %-5.5s %s%-3d %-9.9s %-15.15s %-.19s%s"; static const char *rfmt1r = "%s,%s,%s,%s%d,%s,%s,%s%s"; static const char *hdr2 = -"Login Port What When From Location"; -static const char *ufmt2 = "%-10.10s %-6.6d %-7.7s %-13.13s %-10.10s %-.16s%s"; +"Login Port What When From Location"; +static const char *ufmt2 = "%-10.10s %-6.6d %-7.7s %-13.13s %-15.15s %-.16s%s"; static const char *ufmt2r = "%s,%d,%s,%s,%s,%s%s"; -static const char *rfmt2 = "%-10.10s %s%-5d %-6.6s %-13.13s %-10.10s %-.28s%s"; +static const char *rfmt2 = "%-10.10s %s%-5d %-6.6s %-13.13s %-15.15s %-.28s%s"; static const char *rfmt2r = "%s,%s%d,%s,%s,%s,%s%s"; static const char *eol = "\n"; From freeradius-devel@lists.freeradius.org Mon Mar 1 19:03:08 2004 From: freeradius-devel@lists.freeradius.org (Eddie Stassen) Date: Mon, 01 Mar 2004 21:03:08 +0200 Subject: rlm_realm behaviour Message-ID: <404388EC.8@saix.net> I have come across a problem with the rlm_realm implementation when using both prefix and suffix realms in conjunction with NULL realms. config entry: authorize { prefix suffix blah blah } proxy.conf: realm realma { ... } realm realmb { ... } realm NULL { ... } user logs in as: realma/user - proxy to realma (correct) user logs in as: user - proxy to NULL realm (correct) user logs in as: user@realmb - ooops prefix module gets no match and proxies to NULL realm Basically in this case the suffix module is never activated. I dont think this was intended behaviour as the NULL realms came in long after the rlm_realm module was written. I dont see a simple workaround, (well I do workaround it using user file entries) although it does highlight something which I have found to be a minor concern for a while; the fact that one cannot specify realms individually as prefix or suffix. Perhaps the solution would be then to have rlm_realm have its own config file. Then there would be separation between the proxy.conf entries and the actual strings used to match realms. proxy.conf would only require one entry for each remote host and the realms config would map between realms and remote hosts. Of course one could say that the intended behaviour could be achieved by DEFAULT entries in the user file, but i suspect this is not quite as efficient as using a dedicated realms module.(and not as 'nice' either). I could start working on something like this, but of course would be reluctant if there is no interested. Any thoughts? Eddie From freeradius-devel@lists.freeradius.org Mon Mar 1 19:14:05 2004 From: freeradius-devel@lists.freeradius.org (Chris Parker) Date: Mon, 01 Mar 2004 13:14:05 -0600 Subject: rlm_realm behaviour In-Reply-To: <404388EC.8@saix.net> References: <404388EC.8@saix.net> Message-ID: <6.0.1.1.2.20040301131103.035c82f8@mail.starnetusa.net> At 01:03 PM 3/1/2004, Eddie Stassen wrote: >I have come across a problem with the rlm_realm implementation when using >both prefix and suffix realms in conjunction with NULL realms. >config entry: >authorize { > prefix > suffix > blah blah >} > >proxy.conf: >realm realma { > ... >} >realm realmb { > ... >} >realm NULL { > ... >} > >user logs in as: realma/user - proxy to realma (correct) >user logs in as: user - proxy to NULL realm (correct) >user logs in as: user@realmb - ooops prefix module gets no match and >proxies to NULL realm This same problem has occured on occasion or two here. I think the best solution is to add: skip_null skip_default options to the rlm_realm config. They should default to 'no' to maintain current behaviour. If set to 'yes' then the module will not match on NULL or DEFAULT, allowing you to have multiple rlm_realm instances, with only the last one matching NULL and DEFAULT. I'll commit code to this effect shortly, unless someone sees another better way to handle this. -Chris -- \\\|||/// \ StarNet Inc. \ Chris Parker \ ~ ~ / \ Wholesale Internet \ Director, Engineering | @ @ | \ http://www.starnetusa.net \ (847) 963-0116 oOo---(_)---oOo--\------------------------------------------------------ \ Outpace the Competition - http://www.getmespeed.com From freeradius-devel@lists.freeradius.org Mon Mar 1 20:21:30 2004 From: freeradius-devel@lists.freeradius.org (Eddie Stassen) Date: Mon, 01 Mar 2004 22:21:30 +0200 Subject: rlm_realm behaviour In-Reply-To: <6.0.1.1.2.20040301131103.035c82f8@mail.starnetusa.net> References: <404388EC.8@saix.net> <6.0.1.1.2.20040301131103.035c82f8@mail.starnetusa.net> Message-ID: <40439B4A.6000705@saix.net> Chris Parker wrote: > At 01:03 PM 3/1/2004, Eddie Stassen wrote: > >> I have come across a problem with the rlm_realm implementation when >> using both prefix and suffix realms in conjunction with NULL realms. >> config entry: >> authorize { >> prefix >> suffix >> blah blah >> } >> >> proxy.conf: >> realm realma { >> ... >> } >> realm realmb { >> ... >> } >> realm NULL { >> ... >> } >> >> user logs in as: realma/user - proxy to realma (correct) >> user logs in as: user - proxy to NULL realm (correct) >> user logs in as: user@realmb - ooops prefix module gets no match and >> proxies to NULL realm > > > This same problem has occured on occasion or two here. > > I think the best solution is to add: > > skip_null > skip_default > > options to the rlm_realm config. They should default to 'no' to maintain > current behaviour. If set to 'yes' then the module will not match on > NULL or DEFAULT, allowing you to have multiple rlm_realm instances, with > only the last one matching NULL and DEFAULT. OK, that sounds good. Do you think there is any merit in the rest of my statement though? 1. Although not creating problems at the moment, it would be nice to have those realms designated as prefix to be used as prefixes only and the same for suffix. 2. We have in one case several hundred realms pointing to the same group of servers. This means the same servers appearing several hundred times in the realms list. This seems a bit inefficent as far as searching the list etc. A looser coupling between realm and hosts would be more elegant IMO. Eddie From freeradius-devel@lists.freeradius.org Mon Mar 1 22:32:38 2004 From: freeradius-devel@lists.freeradius.org (Andreas Wolf) Date: Mon, 1 Mar 2004 14:32:38 -0800 Subject: freeRADIUS changes required for Panther compatibility Message-ID: <580DD884-6BD0-11D8-A523-003065FC4CE8@mac.com> --Apple-Mail-2--1058573198 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Hi, I found two problems with the CVS snapshot of 02/27/04. One crash, when used with the Panther supplicant and a linking problem in rlm_mschap. I don't have patches but I found ways to hack around it: First, freeradius still crashes in the rlm_eap_ttls module when Panther is used as the supplicant. Panther is a little out of spec when it comes to diameter AVP padding, but freeradius should not crash: Mon Mar 1 11:47:20 2004 : Debug: modcall: entering group authenticate for request 4 Mon Mar 1 11:47:20 2004 : Debug: modsingle[authenticate]: calling eap (rlm_eap) for request 4 Mon Mar 1 11:47:20 2004 : Debug: rlm_eap: Request found, released from the list Mon Mar 1 11:47:20 2004 : Debug: rlm_eap: EAP/ttls Mon Mar 1 11:47:20 2004 : Debug: rlm_eap: processing type ttls Mon Mar 1 11:47:20 2004 : Debug: rlm_eap_ttls: Authenticate Mon Mar 1 11:47:20 2004 : Debug: rlm_eap_tls: processing TLS Mon Mar 1 11:47:20 2004 : Info: rlm_eap_tls: Length Included Mon Mar 1 11:47:20 2004 : Debug: eaptls_verify returned 11 Mon Mar 1 11:47:20 2004 : Debug: eaptls_process returned 7 Mon Mar 1 11:47:20 2004 : Debug: rlm_eap_ttls: Session established. Proceeding to decode tunneled attributes. TTLS tunnel data in 0000: 00 00 00 01 00 00 00 0c 74 65 73 74 00 00 00 0b TTLS tunnel data in 0010: 80 00 00 1c 00 00 01 37 c9 3e cc 9f d5 7c 1f 68 TTLS tunnel data in 0020: 5d a2 9e 33 e7 f9 cb 1d 00 00 00 19 80 00 00 3e TTLS tunnel data in 0030: 00 00 01 37 3a 00 59 0e 6a 28 2f 83 6d e8 7c 66 TTLS tunnel data in 0040: d4 96 78 8d d3 45 00 00 00 00 00 00 00 00 00 55 TTLS tunnel data in 0050: 54 4d 06 cb af 1c e3 cd 47 a8 ec 21 65 73 99 f2 TTLS tunnel data in 0060: 75 b0 60 d1 6e b4 Program received signal EXC_BAD_ACCESS, Could not access memory. 0xffff8cdc in __memcpy () (gdb) bt #0 0xffff8cdc in __memcpy () #1 0x0024b51c in state_key () #2 0x0024bd4c in state_key () #3 0x0024b1e4 in state_key () #4 0x00214404 in eaptype_call (atype=0x3c9220, handler=0x2b4194) at eap.c:167 #5 0x002147f0 in eaptype_select (inst=0x0, handler=0x0) at eap.c:353 #6 0x00213c40 in magic2 () at rlm_eap.c:269 #7 0x0000ba70 in call_modsingle (component=3969628, sp=0x3b6630, request=0x3c7750, default_result=-17) at modcall.c:212 #8 0x0000bcec in modcall (component=0, c=0x3b6630, request=0x21038) at modcall.c:323 #9 0x0000bb08 in call_modgroup (component=0, g=0x260ff8, request=0x3c7750, default_result=-17) at modcall.c:237 #10 0x0000bc8c in modcall (component=0, c=0x3c08a0, request=0x3c7750) at modcall.c:314 #11 0x0000823c in rad_check_password (request=0x3c7750) at auth.c:353 #12 0x000085ec in rad_authenticate (request=0x3c7750) at auth.c:615 #13 0x000038a8 in rad_respond (request=0x3c7750, fun=0x836c ) at radiusd.c:1764 #14 0x00003554 in main (argc=-1073747136, argv=0x3c7750) at radiusd.c:1552 It attempts to memcopy with an insanely large number for the length, due to an unsigned-signed integer problem in diameter_verify(). Here is my hack (but I don't propose this as a fix), which makes sure that the data_len of the tunneled attributes does not get a negative value for an unsigned integer: RCS file: /source/radiusd/src/modules/rlm_eap/types/rlm_eap_ttls/ttls.c,v retrieving revision 1.11 diff -r1.11 ttls.c 42c42 < static int diameter_verify(const uint8_t *data, int data_len) --- > static int diameter_verify(const uint8_t *data, int* data_length) 46a47 > int data_len = *data_length; 144,146c145,147 < DEBUG2(" rlm_eap_ttls: ERROR! Diameter attribute overflows packet!"); < return 0; < --- > *data_length += length - data_len; > DEBUG2(" rlm_eap_ttls: ERROR! Diameter attribute overflows packet! -> %d %d", data_len, length); > break; 364,365c365,372 < < data_len -= length; --- > > if(data_len > length) > data_len -= length; > else > { > data_len = 0; > length = data_len; > } 837c844 < if (!diameter_verify(data, (int) data_len)) { --- > if (!diameter_verify(data, (int*) &data_len)) { BTW, I've noted this bug last October and Alan said he found the problem - he might have the real fix for this problem. The other problem is that the rlm_mschap module is missing some symbols defined in libradius.so. Mon Mar 1 10:06:31 2004 : Debug: auth: type "MS-CHAP" Mon Mar 1 10:06:31 2004 : Debug: modcall: entering group Auth-Type for request 4 Mon Mar 1 10:06:31 2004 : Debug: modsingle[authenticate]: calling mschap (rlm_mschap) for request 4 dyld: /usr/local/freeradius/sbin/radiusd Undefined symbols: _lrad_lmpwdhash Program received signal SIGTRAP, Trace/breakpoint trap. 0x8fe019e0 in __dyld_halt () (gdb) bt #0 0x8fe019e0 in __dyld_halt () #1 0x8fe0a8c4 in __dyld_check_and_report_undefineds () #2 0x8fe11838 in __dyld_link_in_need_modules () #3 0x8fe113f4 in __dyld_bind_lazy_symbol_reference () #4 0x8fe01620 in __dyld_stub_binding_helper_interface () #5 0x000d6a1c in mschap_authenticate (instance=0x3b5270, request=0x3c8a20) at rlm_mschap.c:679 #6 0x0000ba70 in call_modsingle (component=76, sp=0x3b57e0, request=0x3c8a20, default_result=10) at modcall.c:212 #7 0x0000bcec in modcall (component=0, c=0x3b57e0, request=0x21038) at modcall.c:323 #8 0x0000bb08 in call_modgroup (component=0, g=0x0, request=0x3c8a20, default_result=10) at modcall.c:237 #9 0x0000bc8c in modcall (component=0, c=0x3b5890, request=0x3c8a20) at modcall.c:314 #10 0x0000823c in rad_check_password (request=0x3c8a20) at auth.c:353 #11 0x000085ec in rad_authenticate (request=0x3c8a20) at auth.c:615 #12 0x0024214c in eapttls_process (handler=0x3c6d70, tls_session=0x2ab000) at ttls.c:1039 #13 0x00241188 in eapttls_authenticate (arg=0x3bfee0, handler=0x3c6d70) at rlm_eap_ttls.c:235 #14 0x00215404 in eaptype_call (atype=0x2bb000, handler=0x21038) at eap.c:167 #15 0x002157f0 in eaptype_select (inst=0x2ab000, handler=0x3c6d70) at eap.c:353 #16 0x00214c40 in eap_authenticate (instance=0x1805600, request=0x3c7750) at rlm_eap.c:269 #17 0x0000ba70 in call_modsingle (component=76, sp=0x3b6630, request=0x3c7750, default_result=10) at modcall.c:212 #18 0x0000bcec in modcall (component=0, c=0x3b6630, request=0x21038) at modcall.c:323 #19 0x0000bb08 in call_modgroup (component=0, g=0x0, request=0x3c7750, default_result=10) at modcall.c:237 #20 0x0000bc8c in modcall (component=0, c=0x3c0750, request=0x3c7750) at modcall.c:314 #21 0x0000823c in rad_check_password (request=0x3c7750) at auth.c:353 #22 0x000085ec in rad_authenticate (request=0x3c7750) at auth.c:615 #23 0x000038a8 in rad_respond (request=0x3c7750, fun=0x836c ) at radiusd.c:1764 #24 0x00003554 in main (argc=-1073747136, argv=0x3c7750) at radiusd.c:1552 It works when I force to link against lib/libradius.so (e.g. in the debugger). (gdb) set env DYLD_INSERT_LIBRARIES /usr/local/freeradius/lib/libradius.so There is probably something else wrong with the Makefiles but I found by trial and error that this change fixes it: RCS file: /source/radiusd/src/modules/rlm_mschap/Makefile,v retrieving revision 1.11 diff -r1.11 Makefile 2,4c2,4 < SRCS = rlm_mschap.c --- > SRCS = rlm_mschap.c ../../lib/smbdes.c ../../lib/md4.c ../../lib/sha1.c -Andreas --Apple-Mail-2--1058573198 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII Hi, I found two problems with the CVS snapshot of 02/27/04. One crash, when used with the Panther supplicant and a linking problem in rlm_mschap. I don't have patches but I found ways to hack around it: Times First, freeradius still crashes in the rlm_eap_ttls module when Panther is used as the supplicant. Panther is a little out of spec when it comes to diameter AVP padding, but freeradius should not crash: CourierMon Mar 1 11:47:20 2004 : Debug: modcall: entering group authenticate for request 4 Mon Mar 1 11:47:20 2004 : Debug: modsingle[authenticate]: calling eap (rlm_eap) for request 4 Mon Mar 1 11:47:20 2004 : Debug: rlm_eap: Request found, released from the list Mon Mar 1 11:47:20 2004 : Debug: rlm_eap: EAP/ttls Mon Mar 1 11:47:20 2004 : Debug: rlm_eap: processing type ttls Mon Mar 1 11:47:20 2004 : Debug: rlm_eap_ttls: Authenticate Mon Mar 1 11:47:20 2004 : Debug: rlm_eap_tls: processing TLS Mon Mar 1 11:47:20 2004 : Info: rlm_eap_tls: Length Included Mon Mar 1 11:47:20 2004 : Debug: eaptls_verify returned 11 Mon Mar 1 11:47:20 2004 : Debug: eaptls_process returned 7 Mon Mar 1 11:47:20 2004 : Debug: rlm_eap_ttls: Session established. Proceeding to decode tunneled attributes. TTLS tunnel data in 0000: 00 00 00 01 00 00 00 0c 74 65 73 74 00 00 00 0b TTLS tunnel data in 0010: 80 00 00 1c 00 00 01 37 c9 3e cc 9f d5 7c 1f 68 TTLS tunnel data in 0020: 5d a2 9e 33 e7 f9 cb 1d 00 00 00 19 80 00 00 3e TTLS tunnel data in 0030: 00 00 01 37 3a 00 59 0e 6a 28 2f 83 6d e8 7c 66 TTLS tunnel data in 0040: d4 96 78 8d d3 45 00 00 00 00 00 00 00 00 00 55 TTLS tunnel data in 0050: 54 4d 06 cb af 1c e3 cd 47 a8 ec 21 65 73 99 f2 TTLS tunnel data in 0060: 75 b0 60 d1 6e b4 Program received signal EXC_BAD_ACCESS, Could not access memory. 0xffff8cdc in __memcpy () (gdb) bt #0 0xffff8cdc in __memcpy () #1 0x0024b51c in state_key () #2 0x0024bd4c in state_key () #3 0x0024b1e4 in state_key () #4 0x00214404 in eaptype_call (atype=0x3c9220, handler=0x2b4194) at eap.c:167 #5 0x002147f0 in eaptype_select (inst=0x0, handler=0x0) at eap.c:353 #6 0x00213c40 in magic2 () at rlm_eap.c:269 #7 0x0000ba70 in call_modsingle (component=3969628, sp=0x3b6630, request=0x3c7750, default_result=-17) at modcall.c:212 #8 0x0000bcec in modcall (component=0, c=0x3b6630, request=0x21038) at modcall.c:323 #9 0x0000bb08 in call_modgroup (component=0, g=0x260ff8, request=0x3c7750, default_result=-17) at modcall.c:237 #10 0x0000bc8c in modcall (component=0, c=0x3c08a0, request=0x3c7750) at modcall.c:314 #11 0x0000823c in rad_check_password (request=0x3c7750) at auth.c:353 #12 0x000085ec in rad_authenticate (request=0x3c7750) at auth.c:615 #13 0x000038a8 in rad_respond (request=0x3c7750, fun=0x836c ) at radiusd.c:1764 #14 0x00003554 in main (argc=-1073747136, argv=0x3c7750) at radiusd.c:1552 It attempts to memcopy with an insanely large number for the length, due to an unsigned-signed integer problem in diameter_verify(). TimesHere is my hack (but I don't propose this as a fix), which makes sure that the data_len of the tunneled attributes does not get a negative value for an unsigned integer: CourierRCS file: /source/radiusd/src/modules/rlm_eap/types/rlm_eap_ttls/ttls.c,v retrieving revision 1.11 diff -r1.11 ttls.c 42c42 << static int diameter_verify(const uint8_t *data, int data_len) --- > static int diameter_verify(const uint8_t *data, int* data_length) 46a47 > int data_len = *data_length; 144,146c145,147 << DEBUG2(" rlm_eap_ttls: ERROR! Diameter attribute overflows packet!"); << return 0; << --- > *data_length += length - data_len; > DEBUG2(" rlm_eap_ttls: ERROR! Diameter attribute overflows packet! -> %d %d", data_len, length); > break; 364,365c365,372 << << data_len -= length; --- > > if(data_len > length) > data_len -= length; > else > { > data_len = 0; > length = data_len; > } 837c844 << if (!diameter_verify(data, (int) data_len)) { --- > if (!diameter_verify(data, (int*) &data_len)) { BTW, I've noted this bug last October and Alan said he found the problem - he might have the real fix for this problem. TimesThe other problem is that the rlm_mschap module is missing some symbols defined in libradius.so. CourierMon Mar 1 10:06:31 2004 : Debug: auth: type "MS-CHAP" Mon Mar 1 10:06:31 2004 : Debug: modcall: entering group Auth-Type for request 4 Mon Mar 1 10:06:31 2004 : Debug: modsingle[authenticate]: calling mschap (rlm_mschap) for request 4 dyld: /usr/local/freeradius/sbin/radiusd Undefined symbols: _lrad_lmpwdhash Program received signal SIGTRAP, Trace/breakpoint trap. 0x8fe019e0 in __dyld_halt () (gdb) bt #0 0x8fe019e0 in __dyld_halt () #1 0x8fe0a8c4 in __dyld_check_and_report_undefineds () #2 0x8fe11838 in __dyld_link_in_need_modules () #3 0x8fe113f4 in __dyld_bind_lazy_symbol_reference () #4 0x8fe01620 in __dyld_stub_binding_helper_interface () #5 0x000d6a1c in mschap_authenticate (instance=0x3b5270, request=0x3c8a20) at rlm_mschap.c:679 #6 0x0000ba70 in call_modsingle (component=76, sp=0x3b57e0, request=0x3c8a20, default_result=10) at modcall.c:212 #7 0x0000bcec in modcall (component=0, c=0x3b57e0, request=0x21038) at modcall.c:323 #8 0x0000bb08 in call_modgroup (component=0, g=0x0, request=0x3c8a20, default_result=10) at modcall.c:237 #9 0x0000bc8c in modcall (component=0, c=0x3b5890, request=0x3c8a20) at modcall.c:314 #10 0x0000823c in rad_check_password (request=0x3c8a20) at auth.c:353 #11 0x000085ec in rad_authenticate (request=0x3c8a20) at auth.c:615 #12 0x0024214c in eapttls_process (handler=0x3c6d70, tls_session=0x2ab000) at ttls.c:1039 #13 0x00241188 in eapttls_authenticate (arg=0x3bfee0, handler=0x3c6d70) at rlm_eap_ttls.c:235 #14 0x00215404 in eaptype_call (atype=0x2bb000, handler=0x21038) at eap.c:167 #15 0x002157f0 in eaptype_select (inst=0x2ab000, handler=0x3c6d70) at eap.c:353 #16 0x00214c40 in eap_authenticate (instance=0x1805600, request=0x3c7750) at rlm_eap.c:269 #17 0x0000ba70 in call_modsingle (component=76, sp=0x3b6630, request=0x3c7750, default_result=10) at modcall.c:212 #18 0x0000bcec in modcall (component=0, c=0x3b6630, request=0x21038) at modcall.c:323 #19 0x0000bb08 in call_modgroup (component=0, g=0x0, request=0x3c7750, default_result=10) at modcall.c:237 #20 0x0000bc8c in modcall (component=0, c=0x3c0750, request=0x3c7750) at modcall.c:314 #21 0x0000823c in rad_check_password (request=0x3c7750) at auth.c:353 #22 0x000085ec in rad_authenticate (request=0x3c7750) at auth.c:615 #23 0x000038a8 in rad_respond (request=0x3c7750, fun=0x836c ) at radiusd.c:1764 #24 0x00003554 in main (argc=-1073747136, argv=0x3c7750) at radiusd.c:1552 TimesIt works when I force to link against lib/libradius.so (e.g. in the debugger). Courier(gdb) set env DYLD_INSERT_LIBRARIES /usr/local/freeradius/lib/libradius.so TimesThere is probably something else wrong with the Makefiles but I found by trial and error that this change fixes it: CourierRCS file: /source/radiusd/src/modules/rlm_mschap/Makefile,v retrieving revision 1.11 diff -r1.11 Makefile 2,4c2,4 << SRCS = rlm_mschap.c --- > SRCS = rlm_mschap.c ../../lib/smbdes.c ../../lib/md4.c ../../lib/sha1.c -Andreas --Apple-Mail-2--1058573198-- From freeradius-devel@lists.freeradius.org Tue Mar 2 06:51:34 2004 From: freeradius-devel@lists.freeradius.org (Bruce Cook) Date: Tue, 02 Mar 2004 14:51:34 +0800 Subject: ippool & SQL Message-ID: <40442EF6.7070408@usertools.net> A little while ago I saw a question on the list about modifying rlm_ippool to use a SQL database rather than gdbm. Is there someone out there looking at this currently ? It's something I will require shortly, and as it's not in the latest CVS, I guess that I'll have to have a go myself if it hasn't already been started. Bruce From freeradius-devel@lists.freeradius.org Tue Mar 2 10:30:44 2004 From: freeradius-devel@lists.freeradius.org (Nicolas Baradakis) Date: Tue, 2 Mar 2004 11:30:44 +0100 Subject: ippool & SQL In-Reply-To: <40442EF6.7070408@usertools.net> References: <40442EF6.7070408@usertools.net> Message-ID: <20040302103044.GD3404@asuka.tech.sitadelle.com> Bruce Cook wrote: > A little while ago I saw a question on the list about modifying > rlm_ippool to use a SQL database rather than gdbm. Is there someone > out there looking at this currently ? I don't think it is supported by the server, but it is a very interesting feature. When you have multiple servers, a SQL database is more appropriate than sharing gdbm files to manage the pool of IP addresses. > It's something I will require shortly, and as it's not in the latest > CVS, I guess that I'll have to have a go myself if it hasn't already > been started. Somebody has posted a module to the list a long time ago. http://lists.cistron.nl/pipermail/freeradius-users/2002-December/014220.html We are not using it here, but my colleague Thomas did some simple tests. (just in case we need this later...) It seems to work, but be careful: it doesn't seem to be under GPL. -- Nicolas Baradakis From freeradius-devel@lists.freeradius.org Tue Mar 2 16:39:32 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Tue, 02 Mar 2004 11:39:32 -0500 Subject: ippool & SQL In-Reply-To: Your message of "Tue, 02 Mar 2004 11:30:44 +0100." <20040302103044.GD3404@asuka.tech.sitadelle.com> Message-ID: <20040302163932.98ED3170BB@mail.nitros9.org> Nicolas Baradakis wrote: > Somebody has posted a module to the list a long time ago. > http://lists.cistron.nl/pipermail/freeradius-users/2002-December/014220.html > > We are not using it here, but my colleague Thomas did some simple > tests. (just in case we need this later...) It seems to work, but be > careful: it doesn't seem to be under GPL. It doesn't just link to the server, it includes source code from the rlm_sql module into itself. That says to me it's under the GPL, as nothing else permits them to do that. Plus, they distribute it as a "sh" file, not a "tar" file, which goes an updates *other* files in the server. That's inappropriate. Alan DeKok. From freeradius-devel@lists.freeradius.org Tue Mar 2 16:42:47 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Tue, 02 Mar 2004 11:42:47 -0500 Subject: rlm_realm behaviour In-Reply-To: Your message of "Mon, 01 Mar 2004 22:21:30 +0200." <40439B4A.6000705@saix.net> Message-ID: <20040302164247.ACE53170BB@mail.nitros9.org> Eddie Stassen wrote: > 1. Although not creating problems at the moment, it would be nice to > have those realms designated as prefix to be used as prefixes only and > the same for suffix. That should be relatively straightforward: Update the "realms" configuration to add a "type = prefix/suffix" configuration entry. Have rlm_realm check it. > 2. We have in one case several hundred realms pointing to the same group > of servers. This means the same servers appearing several hundred times > in the realms list. This seems a bit inefficent as far as searching the > list etc. A looser coupling between realm and hosts would be more > elegant IMO. Hmm... how about a list of aliases for realms? In proxy.conf, you could do: aliases { foo = bar baz = bar stuff = other more = other ... } So long as you define the "bar" and "other" realms, it should be possible to do... Alan DeKok. From freeradius-devel@lists.freeradius.org Tue Mar 2 17:12:09 2004 From: freeradius-devel@lists.freeradius.org (Chris Parker) Date: Tue, 02 Mar 2004 11:12:09 -0600 Subject: rlm_realm behaviour In-Reply-To: <20040302164247.ACE53170BB@mail.nitros9.org> References: <20040302164247.ACE53170BB@mail.nitros9.org> Message-ID: <6.0.1.1.2.20040302110633.0351dc80@mail.starnetusa.net> At 10:42 AM 3/2/2004, Alan DeKok wrote: >Eddie Stassen wrote: > > 1. Although not creating problems at the moment, it would be nice to > > have those realms designated as prefix to be used as prefixes only and > > the same for suffix. > > That should be relatively straightforward: Update the "realms" >configuration to add a "type = prefix/suffix" configuration entry. >Have rlm_realm check it. That's pretty simple as well. I can add that same time I add the module options to skip matching 'NULL' and 'DEFAULT' ( to allow multiple instances of rlm_realm to coexist with NULL and DEFAULT realms ). > > 2. We have in one case several hundred realms pointing to the same group > > of servers. This means the same servers appearing several hundred times > > in the realms list. This seems a bit inefficent as far as searching the > > list etc. A looser coupling between realm and hosts would be more > > elegant IMO. > > Hmm... how about a list of aliases for realms? In proxy.conf, you >could do: > > aliases { > foo = bar > baz = bar > > stuff = other > more = other > ... > } We handle several thousand realms. If you have more than a handful, I strongly suggest creating a mechanism to autogenerate your proxy.conf, such as an SQL database backend to populate into the file, which is then pushed out to your radius servers. It is then irrelevant how many entries, since you can manipulate it through sql queries, ala: >update radius set auth_1 = "10.10.10.10" where auth_1 like "10.10.2.2"; -Chris -- \\\|||/// \ StarNet Inc. \ Chris Parker \ ~ ~ / \ Wholesale Internet \ Director, Engineering | @ @ | \ http://www.starnetusa.net \ (847) 963-0116 oOo---(_)---oOo--\------------------------------------------------------ \ Outpace the Competition - http://www.getmespeed.com From freeradius-devel@lists.freeradius.org Tue Mar 2 17:25:12 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Tue, 02 Mar 2004 12:25:12 -0500 Subject: freeRADIUS changes required for Panther compatibility In-Reply-To: Your message of "Mon, 01 Mar 2004 14:32:38 PST." <580DD884-6BD0-11D8-A523-003065FC4CE8@mac.com> Message-ID: <20040302172512.122F6170BB@mail.nitros9.org> Andreas Wolf wrote: > First, freeradius still crashes in the rlm_eap_ttls module when Panther > is used as the supplicant. Panther is a little out of spec when it > comes to diameter AVP padding, but freeradius should not crash: Ok... the fix was to update diameter2vp() to check for non-aligned attributes. diameter_verify() was checking for them, but diameter2vp() wasn't. > The other problem is that the rlm_mschap module is missing some symbols > defined in libradius.so. Very strange. Maybe rlm_mschap has to be linked against -lradius? I don't see why... the server is linked against -lradius and rlm_mschap. So the linker (if it has any brains) should find -lradius. Alan DeKok. From freeradius-devel@lists.freeradius.org Tue Mar 2 18:40:30 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Tue, 02 Mar 2004 13:40:30 -0500 Subject: Is: Cisco AP 12xx accounting bug Was: EAP-TTLS and accounting In-Reply-To: Your message of "Thu, 26 Feb 2004 12:02:33 +0100." <403DD249.9040906@arnes.si> Message-ID: <20040302184030.96083170BB@mail.nitros9.org> =?UTF-8?B?Um9rIFBhcGXFvg==?= wrote: > Cisco AP-1230B firmware 12.2(13)JA1 has a bug. It wants a NULL > terminted attribute User-Name :-/. However it is sending the same > attribute as non-NULL terminated. See logs: > The 'o' comes becouse Cisco just copies "s5" over "anonymous" and it > terminates one less character than it should. Yuck. > I've created a patch with a workaround. Ok.. I've added a similar patch to rlm_eap.c, because that bug is for *all* EAP protocols, and not just TTLS. Alan DeKok. From freeradius-devel@lists.freeradius.org Tue Mar 2 19:01:14 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Tue, 02 Mar 2004 14:01:14 -0500 Subject: radclient In-Reply-To: Your message of "Sat, 28 Feb 2004 15:36:40 +0100." <20040228143640.GB28126@asuka.tech.sitadelle.com> Message-ID: <20040302190114.ED1F9170BB@mail.nitros9.org> Nicolas Baradakis wrote: > I ran into a another problem: when giving the option -r 1 and multiple > options -f, the timeout isn't honoured and lots of request are removed > from the tree before receiving the reply of the server. Ok, I've added the patch, thanks. Alan DeKok. From freeradius-devel@lists.freeradius.org Tue Mar 2 19:08:27 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Tue, 02 Mar 2004 14:08:27 -0500 Subject: Proxy based on IP or by realm In-Reply-To: Your message of "Mon, 01 Mar 2004 08:49:33 CST." <003601c3ff9c$7aac9e60$6402010a@anpinetwork.com> Message-ID: <20040302190827.7DED5170BB@mail.nitros9.org> "David@lolling.org" wrote: > So in terms of allowing a range of IP addresses, what is the syntax? IP addresses. Or, a regex. DEFAULT Client-NAS-IP =~ "^192.168\.0\." ... Cheezy, but it works. Alan DeKok. From freeradius-devel@lists.freeradius.org Tue Mar 2 20:43:15 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Tue, 02 Mar 2004 15:43:15 -0500 Subject: New proxy trees (was Re: filters.c ) In-Reply-To: Your message of "Fri, 27 Feb 2004 15:43:54 CST." <09FE52CE-696E-11D8-9D18-000A95EFE8AA@starnetusa.net> Message-ID: <20040302204315.A464F170BB@mail.nitros9.org> Chris Brotsos wrote: > Well, it works in the sense that nothing is broken :p. I'm not, > however, getting the results I was expecting. At first, I thought it > might just be because two of my machines was too slow, but that was not > the case. I think the problem is a little more esoteric. Without the "proxy requests in a tree" code, the server walks linearly through ~1000's of requests to find the REQUEST for a reply from a home server. With he "proxy requests in a tree" code, the server has a LOT of mutex locking/unlocking, and then does a O(log(N)) search. I think the answer is that a non-mutex-protected linear walk is faster than a mutex-protected binary search. Oh well, I had such hopes... Alan DeKok. From freeradius-devel@lists.freeradius.org Tue Mar 2 20:49:28 2004 From: freeradius-devel@lists.freeradius.org (Michael Griego) Date: Tue, 02 Mar 2004 14:49:28 -0600 Subject: New proxy trees (was Re: filters.c ) In-Reply-To: <20040302204315.A464F170BB@mail.nitros9.org> References: <20040302204315.A464F170BB@mail.nitros9.org> Message-ID: <1078260568.24051.18.camel@enterprise.utdallas.edu> On Tue, 2004-03-02 at 14:43, Alan DeKok wrote: > I think the answer is that a non-mutex-protected linear walk is > faster than a mutex-protected binary search. Why does the search have to be mutex-protected? Or is the locking/unlocking simply a byproduct of all the tree-editing going on? -- --Mike ----------------------------------- Michael Griego Wireless LAN Project Manager The University of Texas at Dallas From freeradius-devel@lists.freeradius.org Tue Mar 2 20:59:27 2004 From: freeradius-devel@lists.freeradius.org (Chris Brotsos) Date: Tue, 2 Mar 2004 14:59:27 -0600 Subject: New proxy trees (was Re: filters.c ) In-Reply-To: <20040302204315.A464F170BB@mail.nitros9.org> References: <20040302204315.A464F170BB@mail.nitros9.org> Message-ID: <7E5F33DE-6C8C-11D8-9265-000A95EFE8AA@starnetusa.net> On Mar 2, 2004, at 2:43 PM, Alan DeKok wrote: > Chris Brotsos wrote: >> Well, it works in the sense that nothing is broken :p. I'm not, >> however, getting the results I was expecting. At first, I thought it >> might just be because two of my machines was too slow, but that was >> not >> the case. > > I think the problem is a little more esoteric. > > Without the "proxy requests in a tree" code, the server walks > linearly through ~1000's of requests to find the REQUEST for a reply > from a home server. > > With he "proxy requests in a tree" code, the server has a LOT of > mutex locking/unlocking, and then does a O(log(N)) search. Well, I have some positive results to post, but I wanted to complete two 50000 request runs before actually posting them. But, as long as we're on the topic, here are the very positive results of radclient run against 0.9.3 and today's CVS head. 10000 requests: Run on CVS head (today's copy) with #define WITH_RBTREE in request_list.c: Total approved auths: 10000 Total denied auths: 0 Total lost auths: 0 real 11m41.150s user 3m9.510s sys 8m27.860s Run on old 0.9.3 code: Total approved auths: 10000 Total denied auths: 0 Total lost auths: 0 real 12m44.950s user 3m30.580s sys 9m9.770s 64 seconds is definitely an improvement, and that's only over 10000 requests. The changes, at least, have sped up proxy queueing from 0.9.3. I'll send the 50000 request results later (I filled up my disk from radius.log after the second 50000 set and want to make sure that didn't skew the results any, so I started over). > > I think the answer is that a non-mutex-protected linear walk is > faster than a mutex-protected binary search. > > Oh well, I had such hopes... After I run the 50000 0.9.3 vs. 1.0-pre tests, I'll re-run the #(un)def WITH_RBTREE tests at 50000. We'll see what happens under an even heavier load; I know we proxy off quite a few more than 10000 requests a day ;). Thanks, Chris From freeradius-devel@lists.freeradius.org Tue Mar 2 21:13:14 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Tue, 02 Mar 2004 16:13:14 -0500 Subject: New proxy trees (was Re: filters.c ) In-Reply-To: Your message of "Tue, 02 Mar 2004 14:49:28 CST." <1078260568.24051.18.camel@enterprise.utdallas.edu> Message-ID: <20040302211315.F14C7170BB@mail.nitros9.org> Michael Griego wrote: > Why does the search have to be mutex-protected? Or is the > locking/unlocking simply a byproduct of all the tree-editing going on? Yes. The tree is having proxied requests inserted by the child threads, and looked up/deleted by the main server core thread. So there has to be a mutex. If there is another way, I'd like to hear it... Alan DeKok. From freeradius-devel@lists.freeradius.org Tue Mar 2 21:17:57 2004 From: freeradius-devel@lists.freeradius.org (Eddie Stassen) Date: Tue, 02 Mar 2004 23:17:57 +0200 Subject: rlm_realm behaviour In-Reply-To: <6.0.1.1.2.20040302110633.0351dc80@mail.starnetusa.net> References: <20040302164247.ACE53170BB@mail.nitros9.org> <6.0.1.1.2.20040302110633.0351dc80@mail.starnetusa.net> Message-ID: <4044FA05.4060308@saix.net> Chris Parker wrote: > At 10:42 AM 3/2/2004, Alan DeKok wrote: > >> Eddie Stassen wrote: >> > 1. Although not creating problems at the moment, it would be nice to >> > have those realms designated as prefix to be used as prefixes only and >> > the same for suffix. >> >> That should be relatively straightforward: Update the "realms" >> configuration to add a "type = prefix/suffix" configuration entry. >> Have rlm_realm check it. > > > That's pretty simple as well. I can add that same time I add the > module options to skip matching 'NULL' and 'DEFAULT' ( to allow > multiple instances of rlm_realm to coexist with NULL and DEFAULT > realms ). The delimiter character would then have to be part of the realm config entry as well in case one had multiple prefix/suffix modules. > >> > 2. We have in one case several hundred realms pointing to the same >> group >> > of servers. This means the same servers appearing several hundred >> times >> > in the realms list. This seems a bit inefficent as far as searching >> the >> > list etc. A looser coupling between realm and hosts would be more >> > elegant IMO. >> >> Hmm... how about a list of aliases for realms? In proxy.conf, you >> could do: >> >> aliases { >> foo = bar >> baz = bar >> >> stuff = other >> more = other >> ... >> } > > > We handle several thousand realms. If you have more than a handful, > I strongly suggest creating a mechanism to autogenerate your proxy.conf, > such as an SQL database backend to populate into the file, which is then > pushed out to your radius servers. It is then irrelevant how many > entries, since you can manipulate it through sql queries, ala: > > >update radius set auth_1 = "10.10.10.10" where auth_1 like "10.10.2.2"; > I already have all my dynamic radius configs auto generated and pushed from a database. I was thinking more in terms of the server internals and the fact that one would (in my case at least) have a large number of realms pointing to a comparatively small number of servers. I guess one could describe the current scenario in database terms as "not normalized". I would suggest something like: proxy.conf: server ISPA { authaddress = .... } server ISPA { ..... } server ISPB { etc. and then each rlm_realm instance would have its own configuration file: suffix.conf: realm ispa.com { proxy_to = ISPA } etc. prefix.conf: realm ispb { etc. It would have the advantage of making the search list for realms shorter as the server would not have to search through duplicate realm entries. There would be two lookups however, once for the realm and then for the actual server. The server list should be significantly shorter though. Eddie. From freeradius-devel@lists.freeradius.org Tue Mar 2 21:22:20 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Tue, 2 Mar 2004 16:22:20 -0500 (EST) Subject: Web page of people involved... Message-ID: <200403022122.i22LMJ602088@newgiles.nitros9.org> I think it's about time to have a web page naming the people involved, and their roles. This gives everyone a little more credit, and gives the project a little more credibility. My suggestions: Paul Hampson - Release coordinator Chris Parker - Web site host (other title?) Michael Griego - Patch Manager (This is new: he volunteered) Kostas Kalevras - Administration interface & LDAP guy... Alan DeKok - Project Co-Founder and Project Leader Miquel van Smoorenburg - Project Co-Founder and President Emiterus Anyone else we should list? Comments on the titles? Speak up... I'll be updating the web page in the next few days. Alan DeKok. From freeradius-devel@lists.freeradius.org Tue Mar 2 21:23:22 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Tue, 02 Mar 2004 16:23:22 -0500 Subject: rlm_realm behaviour In-Reply-To: Your message of "Tue, 02 Mar 2004 11:12:09 CST." <6.0.1.1.2.20040302110633.0351dc80@mail.starnetusa.net> Message-ID: <20040302212322.CFE9A170BB@mail.nitros9.org> Chris Parker wrote: > We handle several thousand realms. Hmm... this says to me like there should be some more tree management code added for clients & realms. Maybe tomorrow... Alan DeKok. From freeradius-devel@lists.freeradius.org Tue Mar 2 21:25:38 2004 From: freeradius-devel@lists.freeradius.org (Michael Griego) Date: Tue, 02 Mar 2004 15:25:38 -0600 Subject: Web page of people involved... In-Reply-To: <200403022122.i22LMJ602088@newgiles.nitros9.org> References: <200403022122.i22LMJ602088@newgiles.nitros9.org> Message-ID: <1078262738.24051.20.camel@enterprise.utdallas.edu> Sounds great. I have a much better feel for everybody and their roles now. :) -- --Mike ----------------------------------- Michael Griego Wireless LAN Project Manager The University of Texas at Dallas From freeradius-devel@lists.freeradius.org Tue Mar 2 21:40:55 2004 From: freeradius-devel@lists.freeradius.org (Chris Parker) Date: Tue, 02 Mar 2004 15:40:55 -0600 Subject: rlm_realm behaviour In-Reply-To: <4044FA05.4060308@saix.net> References: <20040302164247.ACE53170BB@mail.nitros9.org> <6.0.1.1.2.20040302110633.0351dc80@mail.starnetusa.net> <4044FA05.4060308@saix.net> Message-ID: <6.0.1.1.2.20040302153242.03876ec0@mail.starnetusa.net> At 03:17 PM 3/2/2004, Eddie Stassen wrote: >Chris Parker wrote: > >>At 10:42 AM 3/2/2004, Alan DeKok wrote: >> >>>Eddie Stassen wrote: >>> > 1. Although not creating problems at the moment, it would be nice to >>> > have those realms designated as prefix to be used as prefixes only and >>> > the same for suffix. >>> >>> That should be relatively straightforward: Update the "realms" >>>configuration to add a "type = prefix/suffix" configuration entry. >>>Have rlm_realm check it. >> >>That's pretty simple as well. I can add that same time I add the >>module options to skip matching 'NULL' and 'DEFAULT' ( to allow >>multiple instances of rlm_realm to coexist with NULL and DEFAULT >>realms ). > >The delimiter character would then have to be part of the realm config >entry as well in case one had multiple prefix/suffix modules. Hmm, good point there. Well, I'll hold off on that for now. The NULL/DEFAULT skipping is more immediate need I think. >>> > 2. We have in one case several hundred realms pointing to the same group >>> > of servers. This means the same servers appearing several hundred times >>> > in the realms list. This seems a bit inefficent as far as searching the >>> > list etc. A looser coupling between realm and hosts would be more >>> > elegant IMO. >>> >>> Hmm... how about a list of aliases for realms? In proxy.conf, you >>>could do: >>> >>> aliases { >>> foo = bar >>> baz = bar >>> >>> stuff = other >>> more = other >>> ... >>> } >> >>We handle several thousand realms. If you have more than a handful, >>I strongly suggest creating a mechanism to autogenerate your proxy.conf, >>such as an SQL database backend to populate into the file, which is then >>pushed out to your radius servers. It is then irrelevant how many >>entries, since you can manipulate it through sql queries, ala: >> >update radius set auth_1 = "10.10.10.10" where auth_1 like "10.10.2.2"; > >I already have all my dynamic radius configs auto generated and pushed >from a database. I was thinking more in terms of the server internals and >the fact that one would (in my case at least) have a large number of >realms pointing to a comparatively small number of servers. I guess one >could describe the current scenario in database terms as "not >normalized". I would suggest something like: > >proxy.conf: > >server ISPA { > authaddress = .... >} >server ISPA { > ..... >} >server ISPB { > etc. > >and then each rlm_realm instance would have its own configuration file: > >suffix.conf: > >realm ispa.com { > proxy_to = ISPA >} >etc. > >prefix.conf: > >realm ispb { > etc. > >It would have the advantage of making the search list for realms shorter >as the server would not have to search through duplicate realm >entries. There would be two lookups however, once for the realm and then >for the actual server. The server list should be significantly shorter though. List being shorter vs. two lookups. I'll take the single lookup. What makes sense from a human readability standpoint does not always make sense from a code execution standpoint. You have R number of realms. You have S number of servers. Worst case: You have O(R) + O(S) to get the answer of where you need to proxy. I think we'd rather leave it at O(R). And if you do have separate files for each realm instance, if you support the same realms as both prefix and suffix, then you don't gain any benefit, as you still have to search O(R) for each instance. -Chris -- \\\|||/// \ StarNet Inc. \ Chris Parker \ ~ ~ / \ Wholesale Internet \ Director, Engineering | @ @ | \ http://www.starnetusa.net \ (847) 963-0116 oOo---(_)---oOo--\------------------------------------------------------ \ Outpace the Competition - http://www.getmespeed.com From freeradius-devel@lists.freeradius.org Tue Mar 2 21:43:34 2004 From: freeradius-devel@lists.freeradius.org (Chris Parker) Date: Tue, 02 Mar 2004 15:43:34 -0600 Subject: Web page of people involved... In-Reply-To: <200403022122.i22LMJ602088@newgiles.nitros9.org> References: <200403022122.i22LMJ602088@newgiles.nitros9.org> Message-ID: <6.0.1.1.2.20040302154115.034d37b0@mail.starnetusa.net> At 03:22 PM 3/2/2004, Alan DeKok wrote: > I think it's about time to have a web page naming the people >involved, and their roles. This gives everyone a little more credit, >and gives the project a little more credibility. > > My suggestions: > > Paul Hampson - Release coordinator > > Chris Parker - Web site host (other title?) Server monkey? :) Since it's also keeping the 'bugs' site up, and the CVS, FTP, functional as well. "Server Administrator" perhaps? > Michael Griego - Patch Manager > (This is new: he volunteered) Cool! -Chris -- \\\|||/// \ StarNet Inc. \ Chris Parker \ ~ ~ / \ Wholesale Internet \ Director, Engineering | @ @ | \ http://www.starnetusa.net \ (847) 963-0116 oOo---(_)---oOo--\------------------------------------------------------ \ Outpace the Competition - http://www.getmespeed.com From freeradius-devel@lists.freeradius.org Tue Mar 2 21:45:29 2004 From: freeradius-devel@lists.freeradius.org (Chris Parker) Date: Tue, 02 Mar 2004 15:45:29 -0600 Subject: rlm_realm behaviour In-Reply-To: <20040302212322.CFE9A170BB@mail.nitros9.org> References: <20040302212322.CFE9A170BB@mail.nitros9.org> Message-ID: <6.0.1.1.2.20040302154344.0387ca98@mail.starnetusa.net> At 03:23 PM 3/2/2004, Alan DeKok wrote: >Chris Parker wrote: > > We handle several thousand realms. > > Hmm... this says to me like there should be some more tree >management code added for clients & realms. And this would not need to mutex locked, so we should see real improvement there. :) -Chris -- \\\|||/// \ StarNet Inc. \ Chris Parker \ ~ ~ / \ Wholesale Internet \ Director, Engineering | @ @ | \ http://www.starnetusa.net \ (847) 963-0116 oOo---(_)---oOo--\------------------------------------------------------ \ Outpace the Competition - http://www.getmespeed.com From freeradius-devel@lists.freeradius.org Tue Mar 2 22:09:51 2004 From: freeradius-devel@lists.freeradius.org (Paul Hampson) Date: Wed, 3 Mar 2004 09:09:51 +1100 Subject: Web page of people involved... In-Reply-To: <200403022122.i22LMJ602088@newgiles.nitros9.org> References: <200403022122.i22LMJ602088@newgiles.nitros9.org> Message-ID: <20040302220951.GB24362@yurika.videohost.com.au> On Tue, Mar 02, 2004 at 04:22:20PM -0500, Alan DeKok wrote: > I think it's about time to have a web page naming the people > involved, and their roles. This gives everyone a little more credit, > and gives the project a little more credibility. > > My suggestions: > > Paul Hampson - Release coordinator I dunno if you want to put it up there as well, but I'm the Debian Maintainer too. Steve Langasek sponsors the uploads for me into the archive. For your consideration. :-) -- Paul "TBBle" Hampson, on an alternate email client. From freeradius-devel@lists.freeradius.org Wed Mar 3 02:31:57 2004 From: freeradius-devel@lists.freeradius.org (Andreas Wolf) Date: Tue, 2 Mar 2004 18:31:57 -0800 Subject: freeRADIUS changes required for Panther compatibility In-Reply-To: <20040302172512.122F6170BB@mail.nitros9.org> References: <20040302172512.122F6170BB@mail.nitros9.org> Message-ID: On Mar 2, 2004, at 9:25 AM, Alan DeKok wrote: > Andreas Wolf wrote: >> First, freeradius still crashes in the rlm_eap_ttls module when >> Panther >> is used as the supplicant. Panther is a little out of spec when it >> comes to diameter AVP padding, but freeradius should not crash: > > Ok... the fix was to update diameter2vp() to check for non-aligned > attributes. diameter_verify() was checking for them, but > diameter2vp() wasn't. I have verified this fix. It works now and it is much cleaner that way, thanks. The other (linking) problem persists and because of that freeRADIUS crashes on Panther if some client attempts e.g. PEAP authentication (which uses the rlm_mschap module). I could make PEAP work with the hack I mentioned. This wouldn't be the first time the Mac OS X linker proofs to be, well, odd. -Andreas > >> The other problem is that the rlm_mschap module is missing some >> symbols >> defined in libradius.so. > > Very strange. Maybe rlm_mschap has to be linked against -lradius? > > I don't see why... the server is linked against -lradius and > rlm_mschap. So the linker (if it has any brains) should find > -lradius. > > Alan DeKok. > > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/devel.html -------------- Andreas Wolf Apple Computer, Inc. Projects, AirPort Engineering From freeradius-devel@lists.freeradius.org Wed Mar 3 06:12:44 2004 From: freeradius-devel@lists.freeradius.org (Ruslan A Dautkhanov) Date: Wed, 03 Mar 2004 13:12:44 +0700 Subject: ippool & SQL Message-ID: <4045775C.10903@scn.ru> This is a cryptographically signed message in MIME format. --------------ms010408010201050204080303 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > A little while ago I saw a question on the list about modifying rlm_ippool > to use a SQL database rather than gdbm. Is there someone out there looking > at this currently ? > > It's something I will require shortly, and as it's not in the latest > CVS, I guess > that I'll have to have a go myself if it hasn't already been started. Hello ! Some ppls post to this list this stuf. That version is works pretty fine, very stable, BUT(!) it's ugly since use differrent pools of SQL DB connections for each(!) IP-pool! So, for example, if you have 4 IP-pools and standart SQL db-pool with 10 connections, than you have 10 * (1+4) = 50 db connections. I have rewritted it - my module use standart pool of DB connections - you need only 10 connections now. If you have interest in this, I can post URL where my version of module sql_ippool lives. We use it in productional environment for an one year with hard load without any problems. -- best regards, Ruslan A Dautkhanov rusland@scn.ru --------------ms010408010201050204080303 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII3TCC AskwggIyoAMCAQICAwsqlzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDMxMTE4MDQxNjMzWhcNMDQxMTE3MDQxNjMz WjBAMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR0wGwYJKoZIhvcNAQkBFg5y dXNsYW5kQHNjbi5ydTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAfBajdRPJx JFT8qNAYO209TK56UQ8vaBplFOLkdMOxcCbTsV9TROHjzV2/+qKdNohjJruzJazvP1Y0N8yj E8qtlI72uAGJfImWF0zUL+2Q9m0KOjImoLbns9SDvsIgnQgPgv5dd5xuPJdWhJOrv4cThBkB tJtGI3w8mQz6o8MH+SC7w+U6QsAwXd0dqtOdXDiyW6Uj1jvXkUYgOJj/kefDmwze6baOpgji TWk2XW1gkVWzO2XNp5pzeg79xLm60jeXlyFXDMvdmTCmYhLB2UfH5L5dOVUV7DWjEurH0vVB L2DVYibnTeQYBh7T/nsMQWjF2TUZRwrOXWvEY7Zz14MCAwEAAaMrMCkwGQYDVR0RBBIwEIEO cnVzbGFuZEBzY24ucnUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCgU3RLfxTR /SO3oLGk7mKb8cCT2uqYLusdywSiDh4xmc5tBe+u5p9gBatKz8dB9dU+6Ey/aaxfhRa5QWj+ K0DT/BvTNENp5QNH0/ff0vGwg4OYuW0FX0T5d9W8fJr3hORydS7lsxBQD5sFe0Olp8slfRnR y+wKCXs2SHCgyQOwujCCAskwggIyoAMCAQICAwsqlzANBgkqhkiG9w0BAQQFADBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDMxMTE4MDQxNjMz WhcNMDQxMTE3MDQxNjMzWjBAMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR0w GwYJKoZIhvcNAQkBFg5ydXNsYW5kQHNjbi5ydTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAMAfBajdRPJxJFT8qNAYO209TK56UQ8vaBplFOLkdMOxcCbTsV9TROHjzV2/+qKd NohjJruzJazvP1Y0N8yjE8qtlI72uAGJfImWF0zUL+2Q9m0KOjImoLbns9SDvsIgnQgPgv5d d5xuPJdWhJOrv4cThBkBtJtGI3w8mQz6o8MH+SC7w+U6QsAwXd0dqtOdXDiyW6Uj1jvXkUYg OJj/kefDmwze6baOpgjiTWk2XW1gkVWzO2XNp5pzeg79xLm60jeXlyFXDMvdmTCmYhLB2UfH 5L5dOVUV7DWjEurH0vVBL2DVYibnTeQYBh7T/nsMQWjF2TUZRwrOXWvEY7Zz14MCAwEAAaMr MCkwGQYDVR0RBBIwEIEOcnVzbGFuZEBzY24ucnUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0B AQQFAAOBgQCgU3RLfxTR/SO3oLGk7mKb8cCT2uqYLusdywSiDh4xmc5tBe+u5p9gBatKz8dB 9dU+6Ey/aaxfhRa5QWj+K0DT/BvTNENp5QNH0/ff0vGwg4OYuW0FX0T5d9W8fJr3hORydS7l sxBQD5sFe0Olp8slfRnRy+wKCXs2SHCgyQOwujCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcN AQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNv bTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYD VQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkV cI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMG A1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZy ZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJp dmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIX oUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggM7MIIDNwIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIDCyqXMAkGBSsOAwIaBQCgggGnMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA0MDMwMzA2MTI0NFowIwYJKoZIhvcNAQkEMRYEFI352Vh6m8u+DBJw dAMnJzeZd+r1MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFr MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLKpcw egYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg SXNzdWluZyBDQQIDCyqXMA0GCSqGSIb3DQEBAQUABIIBAI+qyFc1wYBx3Fs8OEhmcS8Qy+n5 dMltJtAKveUncmWQZbUfeXrjtf03sMnXyqsW8OGWJmJagjPeWZo1YyD8xqmsVAItBqnBZ6qO aQsRCQ/Z7kuX+vCcm6CYURUhevUY43B7jVOdHKJJOZCUVSGjySao5oNsi0t483nwAvkjX0ih XNq5IAzmXjtNSRclbVz9gs/xrHYvZ+UP5cXRKl4rzE4S+RgqYMkZ3hpDOdtagIy0u2guC+la W+tLomnk+9a8MtUl92QUn0XRF8oYcmiLwVP39nkhqyAZ8BBSl31xxqRvCpI5uDQmoMdvLFQs eFg531TEqC05aTauTyTI1lol7kwAAAAAAAA= --------------ms010408010201050204080303-- From freeradius-devel@lists.freeradius.org Wed Mar 3 07:15:53 2004 From: freeradius-devel@lists.freeradius.org (Eddie Stassen) Date: Wed, 03 Mar 2004 09:15:53 +0200 Subject: rlm_realm behaviour In-Reply-To: <6.0.1.1.2.20040302153242.03876ec0@mail.starnetusa.net> References: <20040302164247.ACE53170BB@mail.nitros9.org> <6.0.1.1.2.20040302110633.0351dc80@mail.starnetusa.net> <4044FA05.4060308@saix.net> <6.0.1.1.2.20040302153242.03876ec0@mail.starnetusa.net> Message-ID: <40458629.8030005@saix.net> Chris Parker wrote: > At 03:17 PM 3/2/2004, Eddie Stassen wrote: > >> Chris Parker wrote: >> >>> At 10:42 AM 3/2/2004, Alan DeKok wrote: >>> >>>> Eddie Stassen wrote: >>>> > 1. Although not creating problems at the moment, it would be nice to >>>> > have those realms designated as prefix to be used as prefixes only >>>> and >>>> > the same for suffix. >>>> >>>> That should be relatively straightforward: Update the "realms" >>>> configuration to add a "type = prefix/suffix" configuration entry. >>>> Have rlm_realm check it. >>> >>> >>> That's pretty simple as well. I can add that same time I add the >>> module options to skip matching 'NULL' and 'DEFAULT' ( to allow >>> multiple instances of rlm_realm to coexist with NULL and DEFAULT >>> realms ). >> >> >> The delimiter character would then have to be part of the realm config >> entry as well in case one had multiple prefix/suffix modules. > > > Hmm, good point there. Well, I'll hold off on that for now. The > NULL/DEFAULT skipping is more immediate need I think. > >>>> > 2. We have in one case several hundred realms pointing to the same >>>> group >>>> > of servers. This means the same servers appearing several hundred >>>> times >>>> > in the realms list. This seems a bit inefficent as far as >>>> searching the >>>> > list etc. A looser coupling between realm and hosts would be more >>>> > elegant IMO. >>>> >>>> Hmm... how about a list of aliases for realms? In proxy.conf, you >>>> could do: >>>> >>>> aliases { >>>> foo = bar >>>> baz = bar >>>> >>>> stuff = other >>>> more = other >>>> ... >>>> } >>> >>> >>> We handle several thousand realms. If you have more than a handful, >>> I strongly suggest creating a mechanism to autogenerate your proxy.conf, >>> such as an SQL database backend to populate into the file, which is then >>> pushed out to your radius servers. It is then irrelevant how many >>> entries, since you can manipulate it through sql queries, ala: >>> >update radius set auth_1 = "10.10.10.10" where auth_1 like >>> "10.10.2.2"; >> >> >> I already have all my dynamic radius configs auto generated and pushed >> from a database. I was thinking more in terms of the server internals >> and the fact that one would (in my case at least) have a large number >> of realms pointing to a comparatively small number of servers. I >> guess one could describe the current scenario in database terms as >> "not normalized". I would suggest something like: >> >> proxy.conf: >> >> server ISPA { >> authaddress = .... >> } >> server ISPA { >> ..... >> } >> server ISPB { >> etc. >> >> and then each rlm_realm instance would have its own configuration file: >> >> suffix.conf: >> >> realm ispa.com { >> proxy_to = ISPA >> } >> etc. >> >> prefix.conf: >> >> realm ispb { >> etc. >> >> It would have the advantage of making the search list for realms >> shorter as the server would not have to search through duplicate realm >> entries. There would be two lookups however, once for the realm and >> then for the actual server. The server list should be significantly >> shorter though. > > > List being shorter vs. two lookups. I'll take the single lookup. What > makes sense from a human readability standpoint does not always make > sense from a code execution standpoint. > > You have R number of realms. You have S number of servers. > > Worst case: You have O(R) + O(S) to get the answer of where you need to > proxy. > > I think we'd rather leave it at O(R). > > And if you do have separate files for each realm instance, if you support > the same realms as both prefix and suffix, then you don't gain any benefit, > as you still have to search O(R) for each instance. I dont quite agree with your lookup argument. Lets say for eaxmple you have 1000 realms with an average of 2 servers per realm and 100 servers in total. Worst case at present: 2000 entries to search through Worst case with my suggestion: 1000 + 100 But then, perhaps I am splitting hairs here... - Eddie Stassen From freeradius-devel@lists.freeradius.org Wed Mar 3 08:18:18 2004 From: freeradius-devel@lists.freeradius.org (Paul Hampson) Date: Wed, 3 Mar 2004 19:18:18 +1100 Subject: ippool & SQL In-Reply-To: <4045775C.10903@scn.ru> References: <4045775C.10903@scn.ru> Message-ID: <20040303081818.GB28930@yurika.videohost.com.au> On Wed, Mar 03, 2004 at 01:12:44PM +0700, Ruslan A Dautkhanov wrote: > >A little while ago I saw a question on the list about modifying rlm_ippool > >to use a SQL database rather than gdbm. Is there someone out there looking > >at this currently ? > > > >It's something I will require shortly, and as it's not in the latest > >CVS, I guess > >that I'll have to have a go myself if it hasn't already been started. > Hello ! > Some ppls post to this list this stuf. That version is works pretty fine, > very stable, BUT(!) it's ugly since use differrent pools of SQL DB > connections > for each(!) IP-pool! So, for example, if you have 4 IP-pools and standart > SQL db-pool with 10 connections, than you have 10 * (1+4) = 50 db > connections. True that. > I have rewritted it - my module use standart pool of DB connections - you > need only 10 connections now. If you have interest in this, I can post URL > where my version of module sql_ippool lives. We use it in productional > environment > for an one year with hard load without any problems. I would think the ideal was to have rlm_sql provide SQL connection pools, and have sub-modules which have different functions (eg ippool, auth, acct, etc) allowing amusing and interesting failover setups and such like to work (as well as submodules which provide drivers...) I'm not volunteering to do this, mind you... I'm still trying to make time for autoconf 2.57 support. :-) -- Paul "TBBle" Hampson, on an alternate email client From freeradius-devel@lists.freeradius.org Wed Mar 3 09:05:23 2004 From: freeradius-devel@lists.freeradius.org (Automatic cvs log generator) Date: Wed, 3 Mar 2004 03:05:23 -0600 (CST) Subject: Automatic report from sources (radiusd) between 02.03.2004 - 03.03.2004 GMT Message-ID: <20040303090523.4165E7745F@webhost1.starnetusa.net> CVS log entries from 02.03.2004 (Tue) 09:00:01 - 03.03.2004 (Wed) 09:00:04 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/src/main/modules.c; Revisions: 1.84 File: radiusd/src/modules/rlm_eap/types/rlm_eap_ttls/ttls.c; Revisions: 1.12 File: radiusd/src/modules/rlm_eap/rlm_eap.c; Revisions: 1.24 File: radiusd/src/main/request_list.c; Revisions: 1.29 File: radiusd/src/main/modcall.c; Revisions: 1.21 File: radiusd/src/main/radclient.c; Revisions: 1.71, 1.70 Author: kkalev File: radiusd/dialup_admin/Changelog; Revisions: 1.184 File: radiusd/dialup_admin/bin/log_badlogins; Revisions: 1.18 Author: mgriego File: radiusd/src/main/radiusd.c; Revisions: 1.312, 1.311 File: radiusd/src/modules/rlm_eap/rlm_eap.h; Revisions: 1.13 ===================================================== Combined list of identical log entries ===================================================== Description: In log_badlogins add a newline after every sql query so that the resulting file can be editable Modified files: File: radiusd/dialup_admin/Changelog; Revision: 1.184; Date: 2004/03/02 13:27:35; Author: kkalev; Lines: (+1 -0) File: radiusd/dialup_admin/bin/log_badlogins; Revision: 1.18; Date: 2004/03/02 13:27:35; Author: kkalev; Lines: (+1 -1) ===================================================== Log entries ===================================================== Description: Print out a warning message for groups which are empty. Modified files: File: radiusd/src/main/modcall.c; Revision: 1.21; Date: 2004/03/02 22:33:55; Author: aland; Lines: (+9 -1) ------------------------------- Description: Be less annoying about messages. If a block is empty, and we didn't pick a particular type to call, then don't complain. Modified files: File: radiusd/src/main/modules.c; Revision: 1.84; Date: 2004/03/02 18:52:24; Author: aland; Lines: (+4 -4) ------------------------------- Description: Re-arrange send_one_packet, based on comments from Nicolas Baradakis Modified files: File: radiusd/src/main/radclient.c; Revision: 1.71; Date: 2004/03/02 18:57:34; Author: aland; Lines: (+35 -31) ------------------------------- Description: Got rid of radsend_walk function, and moved the code to the main-line Modified files: File: radiusd/src/main/radclient.c; Revision: 1.70; Date: 2004/03/02 18:52:53; Author: aland; Lines: (+33 -34) ------------------------------- Description: Must have a semicolon at the end of the line. Modified files: File: radiusd/src/main/radiusd.c; Revision: 1.312; Date: 2004/03/02 23:48:01; Author: mgriego; Lines: (+3 -3) ------------------------------- Description: Make 'radiusd -s' not daemonize like the man page says it won't. Modified files: File: radiusd/src/main/radiusd.c; Revision: 1.311; Date: 2004/03/02 23:43:19; Author: mgriego; Lines: (+4 -3) ------------------------------- Description: When proxying synchronously, if retry_delay * retry_count is exceeded, then mark the realm dead, even if we didn't send that many retries. Patch from Chris Brotsos Modified files: File: radiusd/src/main/request_list.c; Revision: 1.29; Date: 2004/03/02 18:20:11; Author: aland; Lines: (+15 -2) ------------------------------- Description: Cisco AP1230B firmware 12.2(13)JA1 has a bug. When given a User-Name attribute in an Access-Accept, it copies one more byte than it should. So we work around it by configurably adding an extra zero byte. Based on a patch from rok.papez Modified files: File: radiusd/src/modules/rlm_eap/rlm_eap.c; Revision: 1.24; Date: 2004/03/02 18:37:16; Author: aland; Lines: (+14 -2) ------------------------------- Description: Added cisco_accouting_username_bug to the rlm_eap_t. Modified files: File: radiusd/src/modules/rlm_eap/rlm_eap.h; Revision: 1.13; Date: 2004/03/02 23:57:40; Author: mgriego; Lines: (+2 -1) ------------------------------- Description: Clean up the code a little more. Print out more error messages. In diameter2vp, check for data_len == length BEFORE padding length, just like in diamater_verify. This will fix problems with broken clients which don't pad. Modified files: File: radiusd/src/modules/rlm_eap/types/rlm_eap_ttls/ttls.c; Revision: 1.12; Date: 2004/03/02 17:19:44; Author: aland; Lines: (+86 -62) ===================================================== Summary of modified files ===================================================== File: radiusd/dialup_admin/Changelog Revisions: 1.184 Authors: kkalev (+1 -0) ------------------------------- File: radiusd/dialup_admin/bin/log_badlogins Revisions: 1.18 Authors: kkalev (+1 -1) ------------------------------- File: radiusd/src/main/modcall.c Revisions: 1.21 Authors: aland (+9 -1) ------------------------------- File: radiusd/src/main/modules.c Revisions: 1.84 Authors: aland (+4 -4) ------------------------------- File: radiusd/src/main/radclient.c Revisions: 1.71, 1.70 Authors: aland (+35 -31), aland (+33 -34) ------------------------------- File: radiusd/src/main/radiusd.c Revisions: 1.312, 1.311 Authors: mgriego (+3 -3), mgriego (+4 -3) ------------------------------- File: radiusd/src/main/request_list.c Revisions: 1.29 Authors: aland (+15 -2) ------------------------------- File: radiusd/src/modules/rlm_eap/rlm_eap.c Revisions: 1.24 Authors: aland (+14 -2) ------------------------------- File: radiusd/src/modules/rlm_eap/rlm_eap.h Revisions: 1.13 Authors: mgriego (+2 -1) ------------------------------- File: radiusd/src/modules/rlm_eap/types/rlm_eap_ttls/ttls.c Revisions: 1.12 Authors: aland (+86 -62) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl From freeradius-devel@lists.freeradius.org Wed Mar 3 02:28:54 2004 From: freeradius-devel@lists.freeradius.org (Andreas Wolf) Date: Tue, 2 Mar 2004 18:28:54 -0800 Subject: freeRADIUS changes required for Panther compatibility In-Reply-To: <20040302172512.122F6170BB@mail.nitros9.org> References: <20040302172512.122F6170BB@mail.nitros9.org> Message-ID: <8400FF78-6CBA-11D8-BBBC-003065CB0118@apple.com> On Mar 2, 2004, at 9:25 AM, Alan DeKok wrote: > Andreas Wolf wrote: >> First, freeradius still crashes in the rlm_eap_ttls module when >> Panther >> is used as the supplicant. Panther is a little out of spec when it >> comes to diameter AVP padding, but freeradius should not crash: > > Ok... the fix was to update diameter2vp() to check for non-aligned > attributes. diameter_verify() was checking for them, but > diameter2vp() wasn't. I have verified this fix. It works now and it is much cleaner that way, thanks. The other (linking) problem persists and because of that freeRADIUS crashes on Panther if some client attempts e.g. PEAP authentication (which uses the rlm_mschap module). I could make PEAP work with the hack I mentioned. This wouldn't be the first time the Mac OS X linker proofs to be, well, odd. -Andreas > >> The other problem is that the rlm_mschap module is missing some >> symbols >> defined in libradius.so. > > Very strange. Maybe rlm_mschap has to be linked against -lradius? > > I don't see why... the server is linked against -lradius and > rlm_mschap. So the linker (if it has any brains) should find > -lradius. > > Alan DeKok. > > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/devel.html From freeradius-devel@lists.freeradius.org Wed Mar 3 17:18:17 2004 From: freeradius-devel@lists.freeradius.org (Chris Parker) Date: Wed, 03 Mar 2004 11:18:17 -0600 Subject: rlm_realm behaviour In-Reply-To: <40458629.8030005@saix.net> References: <20040302164247.ACE53170BB@mail.nitros9.org> <6.0.1.1.2.20040302110633.0351dc80@mail.starnetusa.net> <4044FA05.4060308@saix.net> <6.0.1.1.2.20040302153242.03876ec0@mail.starnetusa.net> <40458629.8030005@saix.net> Message-ID: <6.0.1.1.2.20040303111342.037c0db0@mail.starnetusa.net> At 01:15 AM 3/3/2004, Eddie Stassen wrote: >I dont quite agree with your lookup argument. Lets say for eaxmple you >have 1000 realms with an average of 2 servers per realm and 100 servers in >total. > >Worst case at present: 2000 entries to search through > >Worst case with my suggestion: 1000 + 100 Not in the example you showed. You'll have server entry 1, and server entry 2, so you'd still need two realm entries. Unless you were proposing something different? Regardless, Alan's suggestion to make the realm list an rb-tree will make it moot, as it wouldn't be a linear search through the list. -Chris -- \\\|||/// \ StarNet Inc. \ Chris Parker \ ~ ~ / \ Wholesale Internet \ Director, Engineering | @ @ | \ http://www.starnetusa.net \ (847) 963-0116 oOo---(_)---oOo--\------------------------------------------------------ \ Outpace the Competition - http://www.getmespeed.com From freeradius-devel@lists.freeradius.org Wed Mar 3 19:56:27 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Wed, 03 Mar 2004 14:56:27 -0500 Subject: freeRADIUS changes required for Panther compatibility In-Reply-To: Your message of "Tue, 02 Mar 2004 18:28:54 PST." <8400FF78-6CBA-11D8-BBBC-003065CB0118@apple.com> Message-ID: <20040303195627.74721170C1@mail.nitros9.org> Andreas Wolf wrote: > The other (linking) problem persists and because of that freeRADIUS > crashes on Panther > if some client attempts e.g. PEAP authentication (which uses the > rlm_mschap module). > I could make PEAP work with the hack I mentioned. I've updated rlm_mschap/Makefile. It should work now. > This wouldn't be the first time the Mac OS X linker proofs to be, well, > odd. I agree. Alan DeKok. From freeradius-devel@lists.freeradius.org Wed Mar 3 21:48:09 2004 From: freeradius-devel@lists.freeradius.org (Eddie Stassen) Date: Wed, 03 Mar 2004 23:48:09 +0200 Subject: rlm_realm behaviour In-Reply-To: <6.0.1.1.2.20040303111342.037c0db0@mail.starnetusa.net> References: <20040302164247.ACE53170BB@mail.nitros9.org> <6.0.1.1.2.20040302110633.0351dc80@mail.starnetusa.net> <4044FA05.4060308@saix.net> <6.0.1.1.2.20040302153242.03876ec0@mail.starnetusa.net> <40458629.8030005@saix.net> <6.0.1.1.2.20040303111342.037c0db0@mail.starnetusa.net> Message-ID: <40465299.1090303@saix.net> Chris Parker wrote: > At 01:15 AM 3/3/2004, Eddie Stassen wrote: > >> I dont quite agree with your lookup argument. Lets say for eaxmple >> you have 1000 realms with an average of 2 servers per realm and 100 >> servers in total. >> >> Worst case at present: 2000 entries to search through >> >> Worst case with my suggestion: 1000 + 100 > > > Not in the example you showed. You'll have server entry 1, and server > entry 2, so you'd still need two realm entries. Unless you were > proposing something different? Not quite. Perhaps in my laziness/quest for brevity I didnt make it very clear. The realm module has a list of realms, 1 entry per realm. Each realm entry has a reference to a proxy group. Thus the realm list is searched for a realm and the resulting proxy group name is used to find an available server from the server list. The server list contain entries for all the servers and is indexed on the proxy group name. > > Regardless, Alan's suggestion to make the realm list an rb-tree will > make it moot, as it wouldn't be a linear search through the list. I must admit my knowledge of RB trees is very limited, and forgive me if this is a dumb question, but can they handle duplicate keys? (as would be the case here) From freeradius-devel@lists.freeradius.org Wed Mar 3 22:07:10 2004 From: freeradius-devel@lists.freeradius.org (Kostas Kalevras) Date: Thu, 4 Mar 2004 00:07:10 +0200 (EET) Subject: ippool & SQL In-Reply-To: <4045775C.10903@scn.ru> References: <4045775C.10903@scn.ru> Message-ID: <20040303235829.B45254@ajax.noc.ntua.gr> On Wed, 3 Mar 2004, Ruslan A Dautkhanov wrote: > > A little while ago I saw a question on the list about modifying rlm_ippool > > to use a SQL database rather than gdbm. Is there someone out there looking > > at this currently ? > > > > It's something I will require shortly, and as it's not in the latest > > CVS, I guess > > that I'll have to have a go myself if it hasn't already been started. > > Hello ! > > Some ppls post to this list this stuf. That version is works pretty fine, > very stable, BUT(!) it's ugly since use differrent pools of SQL DB connections > for each(!) IP-pool! So, for example, if you have 4 IP-pools and standart > SQL db-pool with 10 connections, than you have 10 * (1+4) = 50 db connections. > I have rewritted it - my module use standart pool of DB connections - you > need only 10 connections now. If you have interest in this, I can post URL > where my version of module sql_ippool lives. We use it in productional environment > for an one year with hard load without any problems. One other option is to just patch rlm_ippool to either use the data in an accounting-start to renew the assigned ip's or pass the corresponding data in a State attribute which will later be passed back in the accounting-start and used to renew the assigned ip. That way you only need to have radrelay working between your radius servers, and the ip db's will remain synchronized. There will be a time difference between the actual ip assignment on the primary radius server and the ip db update on the secondary one('s) but that should not be a big problem. Though using SQL could probably be somewhat quicker for really large ip spaces, since rlm_ippool needs to do a linear search to find a free entry. Even that impact can be minimized if you use memory mapped db files though. (put the corresponding gdbm files on a tmpfs partition, we use that for the rlm_counter module and it creates a noticable difference). > > > -- > best regards, > Ruslan A Dautkhanov rusland@scn.ru > > > -- Kostas Kalevras Network Operations Center kkalev@noc.ntua.gr National Technical University of Athens, Greece Work Phone: +30 210 7721861 'Go back to the shadow' Gandalf From freeradius-devel@lists.freeradius.org Wed Mar 3 23:45:12 2004 From: freeradius-devel@lists.freeradius.org (Andreas Wolf) Date: Wed, 3 Mar 2004 15:45:12 -0800 Subject: freeRADIUS changes required for Panther compatibility In-Reply-To: <20040303195627.74721170C1@mail.nitros9.org> References: <20040303195627.74721170C1@mail.nitros9.org> Message-ID: On Mar 3, 2004, at 11:56 AM, Alan DeKok wrote: > I've updated rlm_mschap/Makefile. It should work now. thanks, Alan, I tried the fix; your change makes sense but the compiler/linker doesn't: > /Volumes/Workdisk/freeRadius/freeradius-snapshot-20040227/libtool > --mode=compile gcc -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS > -DOPENSSL_NO_KRB5 > -Wall -D_GNU_SOURCE -g -Wshadow -Wpointer-arith -Wcast-qual > -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes > -Wmissing-declara > tions -Wnested-externs -W -Wredundant-decls -Wundef -I../../include > -c rlm_mschap.c > rm -f .libs/rlm_mschap.lo > gcc -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -DOPENSSL_NO_KRB5 > -Wall -D_GNU_SOURCE -g -Wshadow -Wpointer-arith -Wcast-qual > -Wcast-align -Wwrite- > strings -Wstrict-prototypes -Wmissing-prototypes > -Wmissing-declarations -Wnested-externs -W -Wredundant-decls -Wundef > -I../../include -c rlm_mschap.c > -fno-common -DPIC -o .libs/rlm_mschap.lo > rlm_mschap.c: In function `mppe_chap2_gen_keys128': > rlm_mschap.c:509: warning: unused parameter `secret' > rlm_mschap.c:509: warning: unused parameter `vector' > /usr/include/ctype.h: At top level: > rlm_mschap.c:61: warning: `rcsid' defined but not used > gcc -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -DOPENSSL_NO_KRB5 > -Wall -D_GNU_SOURCE -g -Wshadow -Wpointer-arith -Wcast-qual > -Wcast-align -Wwrite- > strings -Wstrict-prototypes -Wmissing-prototypes > -Wmissing-declarations -Wnested-externs -W -Wredundant-decls -Wundef > -I../../include -c rlm_mschap.c > -o rlm_mschap.o >/dev/null 2>&1 > mv -f .libs/rlm_mschap.lo rlm_mschap.lo > /Volumes/Workdisk/freeRadius/freeradius-snapshot-20040227/libtool > --mode=link gcc -release 1.0.0-pre0 \ > -module -export-dynamic -g -O2 -D_REENTRANT > -D_POSIX_PTHREAD_SEMANTICS -DOPENSSL_NO_KRB5 -Wall -D_GNU_SOURCE -g > -Wshadow -Wpointer-arith -Wcast-qua > l -Wcast-align -Wwrite-strings -Wstrict-prototypes > -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -W > -Wredundant-decls -Wundef -I../../ > include -L../../lib -lradius \ > -o rlm_mschap.la -rpath /usr/local/freeradius/lib rlm_mschap.lo > -lresolv -lpthread > rm -fr .libs/rlm_mschap.la .libs/rlm_mschap.* > .libs/rlm_mschap-1.0.0-pre0.* > gcc -dynamiclib -flat_namespace -undefined suppress -o > .libs/rlm_mschap-1.0.0-pre0.so rlm_mschap.lo > -L/Volumes/Workdisk/freeRadius/freeradius-snapsh > ot-20040227/src/lib > -L/Volumes/Workdisk/freeRadius/freeradius-snapshot-20040227/src/lib/ > .libs -lradius -lresolv -lpthread -lc -install_name /usr/loca > l/freeradius/lib/rlm_mschap-1.0.0-pre0.so > ld: common symbols not allowed with MH_DYLIB output format with the > -multi_module option > /Volumes/Workdisk/freeRadius/freeradius-snapshot-20040227/src/lib/ > libradius.a(log.o) definition of common _librad_errstr (size 1024) > /usr/bin/libtool: internal link edit command failed > make[6]: *** [rlm_mschap.la] Error 1 > make[5]: *** [common] Error 1 > make[4]: *** [all] Error 2 > make[3]: *** [common] Error 1 > make[2]: *** [all] Error 2 > make[1]: *** [common] Error 1 > make: *** [all] Error 2 Weird, when I force it to dynamically link against libradius.so it didn't complain, but now it doesn't like to link statically against libradius.a ? -Andreas From freeradius-devel@lists.freeradius.org Thu Mar 4 09:02:43 2004 From: freeradius-devel@lists.freeradius.org (Automatic cvs log generator) Date: Thu, 4 Mar 2004 03:02:43 -0600 (CST) Subject: Automatic report from sources (radiusd) between 03.03.2004 - 04.03.2004 GMT Message-ID: <20040304090243.CCDCD77459@webhost1.starnetusa.net> CVS log entries from 03.03.2004 (Wed) 09:00:04 - 04.03.2004 (Thu) 09:00:01 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/src/main/modules.c; Revisions: 1.85 File: radiusd/raddb/radiusd.conf.in; Revisions: 1.177 File: radiusd/src/modules/rlm_mschap/Makefile; Revisions: 1.12 File: radiusd/src/modules/rlm_mschap/rlm_mschap.c; Revisions: 1.49 ===================================================== Log entries ===================================================== Description: added gtc{} to eap{} Modified files: File: radiusd/raddb/radiusd.conf.in; Revision: 1.177; Date: 2004/03/03 16:58:40; Author: aland; Lines: (+32 -1) ------------------------------- Description: Added another debug message about which section it's processing Modified files: File: radiusd/src/main/modules.c; Revision: 1.85; Date: 2004/03/03 15:56:57; Author: aland; Lines: (+5 -2) ------------------------------- Description: Explicitly link to -lradius, to get functions defined there, for platforms like Mac OSX, which can't figure out that since radiusd is linked to -lradius, and radiusd is also linked to rlm_mschap, then it shouldn't be rocket science to have rlm_mschap use the symbols from -lradius. Instead, it forces you to link rlm_mschap against -lradius. Weird. Modified files: File: radiusd/src/modules/rlm_mschap/Makefile; Revision: 1.12; Date: 2004/03/03 19:52:36; Author: aland; Lines: (+1 -0) ------------------------------- Description: The encryption of the MPPE keys is done by tunnel_pwencode, so we don't do it here, and we don't need to pass "secret" or "request" to the gen keys function Modified files: File: radiusd/src/modules/rlm_mschap/rlm_mschap.c; Revision: 1.49; Date: 2004/03/03 19:50:50; Author: aland; Lines: (+6 -9) ===================================================== Summary of modified files ===================================================== File: radiusd/raddb/radiusd.conf.in Revisions: 1.177 Authors: aland (+32 -1) ------------------------------- File: radiusd/src/main/modules.c Revisions: 1.85 Authors: aland (+5 -2) ------------------------------- File: radiusd/src/modules/rlm_mschap/Makefile Revisions: 1.12 Authors: aland (+1 -0) ------------------------------- File: radiusd/src/modules/rlm_mschap/rlm_mschap.c Revisions: 1.49 Authors: aland (+6 -9) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl From freeradius-devel@lists.freeradius.org Thu Mar 4 09:30:45 2004 From: freeradius-devel@lists.freeradius.org (Rok Papez) Date: Thu, 04 Mar 2004 10:30:45 +0100 Subject: Automatic report from sources (radiusd) between 02.03.2004 - 03.03.2004 GMT In-Reply-To: <20040303090523.4165E7745F@webhost1.starnetusa.net> References: <20040303090523.4165E7745F@webhost1.starnetusa.net> Message-ID: <4046F745.2070104@arnes.si> Hello! Automatic cvs log generator wrote: > ------------------------------- > Description: > Cisco AP1230B firmware 12.2(13)JA1 has a bug. When given a > User-Name attribute in an Access-Accept, it copies one more byte > than it should. > > So we work around it by configurably adding an extra zero byte. > File: radiusd/src/modules/rlm_eap/rlm_eap.c; Revision: 1.24; > Date: 2004/03/02 18:37:16; Author: aland; Lines: (+14 -2) > ------------------------------- Tested, OK. May I suggest updating the documentation ? --------------------------------------------------- --- raddb/radiusd.conf.in.orig 2004-03-04 10:27:58.000000000 +0100 +++ raddb/radiusd.conf.in 2004-03-04 10:28:58.000000000 +0100 @@ -650,6 +650,14 @@ # rejected. ignore_unknown_eap_types = no + # Cisco AP1230B firmware 12.2(13)JA1 has a bug. When given + # a User-Name attribute in an Access-Accept, it copies one + # more byte than it should. + # + # We can work around it by configurably adding an extra + # zero byte. + cisco_accounting_username_bug = no + # Supported EAP-types # --------------------------------------------------- -- Lep pozdrav, Rok Papez. From freeradius-devel@lists.freeradius.org Thu Mar 4 11:07:25 2004 From: freeradius-devel@lists.freeradius.org (=?iso-8859-1?Q?Pascal_S=E9guy?=) Date: Thu, 4 Mar 2004 12:07:25 +0100 Subject: operator != bug [patch] Message-ID: <025601c401d8$e4d0f640$05ca10ac@chinook> Hello, I try to make an user profile with an "attribute !=3D value" in the check-items, and this condition is not respected (the profile match even = if attribute equals the value). I saw a lot of awful things in paircmp() file src/main/valuepair.c which also affect =3D=3D and other operators. Here is a patch: --- /home/pascal/w/new/freeradius/radiusd/src/main/valuepair.c Fri Nov 21 15:29:58 2003 +++ valuepair.c Thu Mar 4 10:41:57 2004 @@ -76,7 +76,10 @@ /* * Sanity check. */ -#if 0 +#if 1 + /* Should this test really be optional ?? (pseguy) + * I think it could be: assert(request->attribute =3D=3D check->attribu= te) + */ if (request->attribute !=3D check->attribute) return -2; #endif @@ -273,10 +276,28 @@ } /* - * Not found, it's not a match. + * Not found */ if (auth_item =3D=3D NULL) { - return -1; + + switch (check_item->operator) { + case T_OP_NE: /* If operator is "!=3D" then not matching is a succe= ss (pseguy) */ + continue; /* it's a match */ + + default: /* Perhaps we should we make special case for other operators (pseguy) */ + return -1; /* it's not a match. */ + + } + } + + /* + * Now take care to not compare username with + * Nas-Identifier neither carrots against turnips. + * (pseguy) + */ + if(auth_item->attribute !=3D check_item->attribute) { + auth_item =3D auth_item->next; + goto try_again; } /* @@ -316,7 +337,11 @@ break; case T_OP_NE: - if (compare =3D=3D 0) result =3D -1; + /* If pairs match while we proceed an "!=3D" operator, then + * abort imediately paircmp() because we have found a + * case which invalidate one check-item (pseguy) + */ + if (compare =3D=3D 0) return(-1); break; case T_OP_LT: --- Pascal S=E9guy From freeradius-devel@lists.freeradius.org Thu Mar 4 13:33:13 2004 From: freeradius-devel@lists.freeradius.org (=?iso-8859-1?Q?Pascal_S=E9guy?=) Date: Thu, 4 Mar 2004 14:33:13 +0100 Subject: huntgroup [patch] Message-ID: <02fc01c401ed$3eb25cd0$05ca10ac@chinook> Hello, I think there is a bug in the Huntgroup-Name attribute matching mechanism. The paircmp() for searching the NAS-IP-Address is done on the parameter "request" which hold only the remainder of attributes list, not all the request list, I think. Here the patch: ---=20 /home/pascal/w/new/freeradius/radiusd/src/modules/rlm_preprocess/rlm_prep= roc ess.c Mon Jul 7 21:17:31 2003 +++ ../modules/rlm_preprocess/rlm_preprocess.c Wed Mar 3 17:04:57 2004 @@ -487,7 +487,7 @@ for (i =3D data->huntgroups; i; i =3D i->next) { if (strcmp(i->name, huntgroup) !=3D 0) continue; - if (paircmp(req, request, i->check, NULL) =3D=3D 0) { + if (paircmp(req, req->packet->vps /*request*/, i->check, NULL) =3D=3D 0) { DEBUG2(" huntgroups: Matched %s at %d", i->name, i->lineno); break; --- Pascal S=E9guy From freeradius-devel@lists.freeradius.org Thu Mar 4 15:45:53 2004 From: freeradius-devel@lists.freeradius.org (Nicolas Baradakis) Date: Thu, 4 Mar 2004 16:45:53 +0100 Subject: radclient In-Reply-To: <20040225205404.EA949170BB@mail.nitros9.org> References: <20040224162956.GB6771@asuka.tech.sitadelle.com> <20040225205404.EA949170BB@mail.nitros9.org> Message-ID: <20040304154553.GK3404@asuka.tech.sitadelle.com> Alan DeKok wrote: > For now, specify 4 '-f' on the command line, and the server will > send 4 packets in parallel. This should be fairly useful for serious > load testing. I prefer to have a command line option to specify the number of packets sent in parallel for 2 reasons: 1. We usually test the server with no less than 30 requests in parallel, so it implies spliting the input file in 30 pieces and then giving 30 options -f on the command line. I'd prefer a lot giving just the option -p 30 on the command line. 2. We also want to rerun exactely the same test except that we increase the number of parallel requests. It allows to see how the server comports itself when the load is increasing. The following patch adds support for an option -p, and then give to the new radclient exactely the same functionalities as the pthread version I posted earlier. Index: src/main/radclient.c =================================================================== RCS file: /source/radiusd/src/main/radclient.c,v retrieving revision 1.71 diff -u -r1.71 radclient.c --- src/main/radclient.c 2 Mar 2004 18:57:34 -0000 1.71 +++ src/main/radclient.c 4 Mar 2004 15:32:36 -0000 @@ -114,6 +114,7 @@ fprintf(stderr, " -s Print out summary information of auth results.\n"); fprintf(stderr, " -v Show program version information.\n"); fprintf(stderr, " -x Debugging mode.\n"); + fprintf(stderr, " -p nbr Send 'nbr' packets in parallel\n"); exit(1); } @@ -683,6 +684,7 @@ char filesecret[256]; FILE *fp; int do_summary = 0; + int parallel = 1; int id; radclient_t *this; @@ -701,7 +703,7 @@ exit(1); } - while ((c = getopt(argc, argv, "c:d:f:hi:qst:r:S:xv")) != EOF) switch(c) { + while ((c = getopt(argc, argv, "c:d:f:hi:p:qr:S:st:xv")) != EOF) switch(c) { case 'c': if (!isdigit((int) *optarg)) usage(); @@ -773,6 +775,10 @@ } secret = filesecret; break; + case 'p': + parallel = atoi(optarg); + if (parallel <= 0) usage(); + break; case 'h': default: usage(); @@ -901,7 +907,7 @@ */ do { radclient_t *next; - const char *filename = NULL; + int n; done = 1; sleep_time = -1; @@ -910,7 +916,9 @@ * Walk over the packets, sending them. */ - for (this = radclient_head; this != NULL; this = next) { + n = 0; + this = radclient_head; + while (n < parallel && this != NULL) { next = this->next; /* @@ -925,36 +933,37 @@ */ if (this->done) { radclient_free(this); + this = next; continue; } /* - * Packets from multiple '-f' are sent - * in parallel. Packets from one file - * are sent in series. + * Send the current packet. */ - if (this->filename != filename) { - filename = this->filename; - - /* - * Send the current packet. - */ - send_one_packet(this); + send_one_packet(this); - /* - * If we haven't sent this packet - * often enough, we're not done, - * and we shouldn't sleep. - */ - if (this->resend < resend_count) { - done = 0; - sleep_time = 0; - } - } else { /* haven't sent this packet, we're not done */ - assert(this->done == 0); - assert(this->reply == NULL); + /* + * If we haven't sent this packet + * often enough, we're not done, + * and we shouldn't sleep. + */ + if (this->resend < resend_count) { done = 0; + sleep_time = 0; } + + this = next; + n++; + } + + /* + * Remaining packets in the list + * We're not done + */ + if (this != NULL) { + assert(this->done == 0); + assert(this->reply == NULL); + done = 0; } /* -- Nicolas Baradakis From freeradius-devel@lists.freeradius.org Thu Mar 4 15:55:45 2004 From: freeradius-devel@lists.freeradius.org (Michael Griego) Date: Thu, 04 Mar 2004 09:55:45 -0600 Subject: huntgroup [patch] In-Reply-To: <02fc01c401ed$3eb25cd0$05ca10ac@chinook> References: <02fc01c401ed$3eb25cd0$05ca10ac@chinook> Message-ID: <1078415745.28492.21.camel@enterprise.utdallas.edu> Take a look around at how the code interacts. It is the job of the caller (in the case, the caller of paircmp since this is registered as a paircompare hook) to pass the correct VALUE_PAIR list. You'll see in other portions of the rlm_preprocess.c file that request->packet->vps is passed to paircmp. --Mike On Thu, 2004-03-04 at 07:33, Pascal S=E9guy wrote: > Hello, >=20 > I think there is a bug in the Huntgroup-Name attribute matching mechani= sm. >=20 > The paircmp() for searching the NAS-IP-Address is done on the parameter > "request" which hold only the remainder of attributes list, not all the > request list, I think. >=20 > Here the patch: >=20 > ---=20 > /home/pascal/w/new/freeradius/radiusd/src/modules/rlm_preprocess/rlm_pr= eproc > ess.c Mon Jul 7 21:17:31 2003 > +++ ../modules/rlm_preprocess/rlm_preprocess.c Wed Mar 3 17:04:57 200= 4 > @@ -487,7 +487,7 @@ > for (i =3D data->huntgroups; i; i =3D i->next) { > if (strcmp(i->name, huntgroup) !=3D 0) > continue; > - if (paircmp(req, request, i->check, NULL) =3D=3D 0) { > + if (paircmp(req, req->packet->vps /*request*/, i->check= , > NULL) =3D=3D 0) { > DEBUG2(" huntgroups: Matched %s at %d", > i->name, i->lineno); > break; >=20 >=20 > --- > Pascal S=E9guy >=20 >=20 > -=20 > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/dev= el.html --=20 --Mike ----------------------------------- Michael Griego Wireless LAN Project Manager The University of Texas at Dallas From freeradius-devel@lists.freeradius.org Thu Mar 4 16:21:02 2004 From: freeradius-devel@lists.freeradius.org (Chris Brotsos) Date: Thu, 4 Mar 2004 10:21:02 -0600 Subject: New proxy trees (was Re: filters.c ) In-Reply-To: <7E5F33DE-6C8C-11D8-9265-000A95EFE8AA@starnetusa.net> References: <20040302204315.A464F170BB@mail.nitros9.org> <7E5F33DE-6C8C-11D8-9265-000A95EFE8AA@starnetusa.net> Message-ID: >> > > After I run the 50000 0.9.3 vs. 1.0-pre tests, I'll re-run the > #(un)def WITH_RBTREE tests at 50000. We'll see what happens under an > even heavier load; I know we proxy off quite a few more than 10000 > requests a day ;). > Just reporting back the results. Last time, with 10,000 requests, the linear search was 8 seconds faster. Under 50,000 the linear search was 11 seconds faster then the rb-search. Either way, no significant difference. Plus when running these tests, the limitations of the servers executing radclient and/or receiving 50,000 contiguous requests, running as web servers, and having GNOME Desktop in memory must be considered. Under our live system, the request_list will be cleared more frequently and be handled by more powerful, dedicated-to-RADIUS-only, servers. I'm satisfied with the test results and still think that the RBTree might scale better than a linear traversal under a system with a fluctuating number of requests coming in bursts. Thanks, Chris From freeradius-devel@lists.freeradius.org Thu Mar 4 16:22:55 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Thu, 04 Mar 2004 11:22:55 -0500 Subject: Automatic report from sources (radiusd) between 02.03.2004 - 03.03.2004 GMT In-Reply-To: Your message of "Thu, 04 Mar 2004 10:30:45 +0100." <4046F745.2070104@arnes.si> Message-ID: <20040304162255.3672716D00@mail.nitros9.org> Rok Papez wrote: > May I suggest updating the documentation ? Added, thanks. Alan DeKok. From freeradius-devel@lists.freeradius.org Thu Mar 4 18:35:07 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Thu, 04 Mar 2004 13:35:07 -0500 Subject: freeRADIUS changes required for Panther compatibility In-Reply-To: Your message of "Wed, 03 Mar 2004 15:45:12 PST." Message-ID: <20040304183507.4488A16FCC@mail.nitros9.org> Andreas Wolf wrote: > thanks, Alan, I tried the fix; your change makes sense but the > compiler/linker doesn't: I'll see what I can do. Alan DeKok. From freeradius-devel@lists.freeradius.org Thu Mar 4 19:03:07 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Thu, 04 Mar 2004 14:03:07 -0500 Subject: operator != bug [patch] In-Reply-To: Your message of "Thu, 04 Mar 2004 12:07:25 +0100." <025601c401d8$e4d0f640$05ca10ac@chinook> Message-ID: <20040304190307.64E8216D00@mail.nitros9.org> =?iso-8859-1?Q?Pascal_S=E9guy?= wrote: > I try to make an user profile with an "attribute !=3D value" in the > check-items, and this condition is not respected (the profile match even > if attribute equals the value). I don't see that behaviour on my system: #--- users DEFAULT NAS-Port == 0, User-Name != "bob" Reply-Message = "not bob", Fall-Through = 1 aland User-Password == "aland" #--- #--- radtest Sending Access-Request of id 235 to 127.0.0.1:2000 User-Name = "aland" User-Password = "aland" NAS-IP-Address = localhost NAS-Port = 0 rad_recv: Access-Accept packet from host 127.0.0.1:2000, id=235, length=29 Reply-Message = "not bob" #--- > Here is a patch: ... > (pseguy) */ ,,, > operators (pseguy) */ > + * (pseguy) Putting your name into the comments is annoying. Alan DeKok. From freeradius-devel@lists.freeradius.org Thu Mar 4 21:43:18 2004 From: freeradius-devel@lists.freeradius.org (freeradius-devel@lists.freeradius.org) Date: Thu, 04 Mar 2004 15:43:18 -0600 Subject: radclient file parsing patch Message-ID: <200403042143.i24LhIBL052826@tig.oss.uswest.net> This appears to fix a radclient crash when radclient's input ends with a blank line. radclient_init called radclient_free, but necessarily did so before radclient_head and radclient_tail had been set. The change to radclient_init (the chunk starting at line 209) keeps this condition (or a syntax error) from throwing away the successfully-read VP lists. Index: src/main/radclient.c =================================================================== RCS file: /source/radiusd/src/main/radclient.c,v retrieving revision 1.71 diff -u -r1.71 radclient.c --- src/main/radclient.c 2 Mar 2004 18:57:34 -0000 1.71 +++ src/main/radclient.c 4 Mar 2004 21:40:38 -0000 @@ -134,7 +134,7 @@ if (prev) { assert(radclient_head != radclient); prev->next = next; - } else { + } else if (radclient_head) { assert(radclient_head == radclient); radclient_head = next; } @@ -142,7 +142,7 @@ if (next) { assert(radclient_tail != radclient); next->prev = prev; - } else { + } else if (radclient_tail) { assert(radclient_tail == radclient); radclient_tail = prev; } @@ -209,7 +209,7 @@ radclient->request->vps = readvp2(fp, &filedone, "radclient:"); if (!radclient->request->vps) { radclient_free(radclient); - return NULL; /* memory leak "start" */ + return start; } /* -- Chris Mikkelson | ... a pet peeve of mine is people who directly edit cmikk@qwest.net | the .cf file instead of using the m4 configuration | files ... I treat the .cf file as a binary file | - you should too. --- Eric Allman From freeradius-devel@lists.freeradius.org Thu Mar 4 23:03:10 2004 From: freeradius-devel@lists.freeradius.org (David@lolling.org) Date: Thu, 4 Mar 2004 17:03:10 -0600 Subject: Proxy based on IP or by realm References: <20040302190827.7DED5170BB@mail.nitros9.org> Message-ID: <000701c4023c$ef817ab0$6402010a@anpinetwork.com> > > IP addresses. > > Or, a regex. > > DEFAULT Client-NAS-IP =~ "^192.168\.0\." ... > > Cheezy, but it works. so the /24 notation that can be used in clients.conf will not work? From freeradius-devel@lists.freeradius.org Fri Mar 5 09:02:46 2004 From: freeradius-devel@lists.freeradius.org (Automatic cvs log generator) Date: Fri, 5 Mar 2004 03:02:46 -0600 (CST) Subject: Automatic report from sources (radiusd) between 04.03.2004 - 05.03.2004 GMT Message-ID: <20040305090246.7A41C7745C@webhost1.starnetusa.net> CVS log entries from 04.03.2004 (Thu) 09:00:01 - 05.03.2004 (Fri) 09:00:01 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/raddb/radiusd.conf.in; Revisions: 1.178 File: radiusd/src/modules/rlm_mschap/Makefile; Revisions: 1.13 ===================================================== Log entries ===================================================== Description: Added docs for cisco_accounting_username_bug Modified files: File: radiusd/raddb/radiusd.conf.in; Revision: 1.178; Date: 2004/03/04 16:19:25; Author: aland; Lines: (+9 -1) ------------------------------- Description: Nope... Panther doesn't like this, either. Modified files: File: radiusd/src/modules/rlm_mschap/Makefile; Revision: 1.13; Date: 2004/03/04 16:06:40; Author: aland; Lines: (+1 -1) ===================================================== Summary of modified files ===================================================== File: radiusd/raddb/radiusd.conf.in Revisions: 1.178 Authors: aland (+9 -1) ------------------------------- File: radiusd/src/modules/rlm_mschap/Makefile Revisions: 1.13 Authors: aland (+1 -1) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl From freeradius-devel@lists.freeradius.org Fri Mar 5 11:30:00 2004 From: freeradius-devel@lists.freeradius.org (=?Windows-1252?Q?Pascal_S=E9guy?=) Date: Fri, 5 Mar 2004 12:30:00 +0100 Subject: operator != bug [patch] References: <20040304190307.64E8216D00@mail.nitros9.org> Message-ID: <00fd01c402a5$32cc5d90$05ca10ac@chinook> ----- Original Message ----- From: "Alan DeKok" To: Sent: Thursday, March 04, 2004 8:03 PM Subject: Re: operator != bug [patch] > =?iso-8859-1?Q?Pascal_S=E9guy?= wrote: > > I try to make an user profile with an "attribute !=3D value" in the > > check-items, and this condition is not respected (the profile match even > > if attribute equals the value). > > I don't see that behaviour on my system: Try this: #--- users DEFAULT User-Password == "aland", NAS-Port == 0, Login-IP-Host != 172.16.0.1 Reply-Message = "not 172.16.0.1 !" #--- radclient Sending Access-Request of id 253 to 172.16.202.7:1812 User-Name = "aland" User-Password = "aland" NAS-IP-Address = localhost NAS-Port = 0 Login-IP-Host = 172.16.0.1 Login-IP-Host = 172.16.0.2 rad_recv: Access-Accept packet from host 172.16.202.7:1812, id=253, length=38 Reply-Message = "not 172.16.0.1 !" > > operators (pseguy) */ > > + * (pseguy) > > Putting your name into the comments is annoying. > SHIT - I'll never do it again Master. -- (anonymous joker) From freeradius-devel@lists.freeradius.org Fri Mar 5 13:32:02 2004 From: freeradius-devel@lists.freeradius.org (=?Windows-1252?Q?Pascal_S=E9guy?=) Date: Fri, 5 Mar 2004 14:32:02 +0100 Subject: operator != bug [patch] References: <20040304190307.64E8216D00@mail.nitros9.org> Message-ID: <015901c402b6$5d49fd50$05ca10ac@chinook> ----- Original Message ----- From: "Alan DeKok" To: Sent: Thursday, March 04, 2004 8:03 PM Subject: Re: operator != bug [patch] > =?iso-8859-1?Q?Pascal_S=E9guy?= wrote: > > I try to make an user profile with an "attribute !=3D value" in the > > check-items, and this condition is not respected (the profile match even > > if attribute equals the value). > > I don't see that behaviour on my system: Try this more funny case, perhaps it is not the same bug as before and this is the case that actualy bother me, and what for is my patch: #--- users DEFAULT User-Password == "test", Huntgroup-Name != "psnet" Reply-Message = "not psnet" #--- huntgroups psnet NAS-IP-Address == 172.16.202.7 #--- radtest (executed from 172.16.202.7) Sending Access-Request of id 26 to 172.16.202.7:1812 User-Name = "aland" User-Password = "test" NAS-IP-Address = localhost rad_recv: Access-Accept packet from host 172.16.202.7:1812, id=26, length=31 Reply-Message = "not psnet" From freeradius-devel@lists.freeradius.org Fri Mar 5 14:27:33 2004 From: freeradius-devel@lists.freeradius.org (=?iso-8859-1?Q?Pascal_S=E9guy?=) Date: Fri, 5 Mar 2004 15:27:33 +0100 Subject: huntgroup [patch] References: <02fc01c401ed$3eb25cd0$05ca10ac@chinook> <1078415745.28492.21.camel@enterprise.utdallas.edu> Message-ID: <019501c402bd$ffdc03e0$05ca10ac@chinook> OK, so why paircmp calls huntgroup_cmp (via paircompare) with the "reques= t" argument (the third) holding the remaining of the request list: src/main/valuepair.c line 301: /* * OK it is present now compare them. */ compare =3D paircompare(req, auth_item, check_item, check, reply)= ; switch (check_item->operator) { case T_OP_EQ: default: I think paircmp should make a local copy of the *auth_item VP and set the local_auth_item.next to zero before calling huntgroup_cmp. Anyway, when tracing paircmp with this scenario (which produce wrong result), we can see wrong interaction between paircmp and huntgroup_cmp: #--- users DEFAULT User-Password =3D=3D "test", Huntgroup-Name !=3D "psnet" Reply-Message =3D "not psnet" #--- huntgroups psnet NAS-IP-Address =3D=3D 172.16.202.7 #--- radtest (executed from 172.16.202.7) Sending Access-Request of id 26 to 172.16.202.7:1812 User-Name =3D "aland" User-Password =3D "test" NAS-IP-Address =3D localhost rad_recv: Access-Accept packet from host 172.16.202.7:1812, id=3D26, leng= th=3D31 Reply-Message =3D "not psnet" ----- Original Message -----=20 From: "Michael Griego" To: Sent: Thursday, March 04, 2004 4:55 PM Subject: Re: huntgroup [patch] > Take a look around at how the code interacts. It is the job of the > caller (in the case, the caller of paircmp since this is registered as = a > paircompare hook) to pass the correct VALUE_PAIR list. You'll see in > other portions of the rlm_preprocess.c file that request->packet->vps i= s > passed to paircmp. > > --Mike > > > On Thu, 2004-03-04 at 07:33, Pascal S=E9guy wrote: > > Hello, > > > > I think there is a bug in the Huntgroup-Name attribute matching mechanism. > > > > The paircmp() for searching the NAS-IP-Address is done on the paramet= er > > "request" which hold only the remainder of attributes list, not all t= he > > request list, I think. > > > > Here the patch: > > > > ---=20 > > /home/pascal/w/new/freeradius/radiusd/src/modules/rlm_preprocess/rlm_prep= roc > > ess.c Mon Jul 7 21:17:31 2003 > > +++ ../modules/rlm_preprocess/rlm_preprocess.c Wed Mar 3 17:04:57 2= 004 > > @@ -487,7 +487,7 @@ > > for (i =3D data->huntgroups; i; i =3D i->next) { > > if (strcmp(i->name, huntgroup) !=3D 0) > > continue; > > - if (paircmp(req, request, i->check, NULL) =3D=3D 0) { > > + if (paircmp(req, req->packet->vps /*request*/, i->che= ck, > > NULL) =3D=3D 0) { > > DEBUG2(" huntgroups: Matched %s at %d", > > i->name, i->lineno); > > break; > > > > > > --- > > Pascal S=E9guy > > > > > > - > > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html > --=20 > > --Mike > > ----------------------------------- > Michael Griego > Wireless LAN Project Manager > The University of Texas at Dallas > > > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html > > From freeradius-devel@lists.freeradius.org Fri Mar 5 18:32:24 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Fri, 05 Mar 2004 13:32:24 -0500 Subject: huntgroup [patch] In-Reply-To: Your message of "Fri, 05 Mar 2004 15:27:33 +0100." <019501c402bd$ffdc03e0$05ca10ac@chinook> Message-ID: <20040305183224.6415516FD1@mail.nitros9.org> =?iso-8859-1?Q?Pascal_S=E9guy?= wrote: > OK, so why paircmp calls huntgroup_cmp (via paircompare) with the > "request" argument (the third) holding the remaining of the request > list: I think that the problem is the huntgroup_cmp() function shouldn't exist. Delete all references to it, and try again. Alan DeKok. From freeradius-devel@lists.freeradius.org Sat Mar 6 09:02:33 2004 From: freeradius-devel@lists.freeradius.org (Automatic cvs log generator) Date: Sat, 6 Mar 2004 03:02:33 -0600 (CST) Subject: Automatic report from sources (radiusd) between 05.03.2004 - 06.03.2004 GMT Message-ID: <20040306090233.9D1E977466@webhost1.starnetusa.net> CVS log entries from 05.03.2004 (Fri) 09:00:01 - 06.03.2004 (Sat) 09:00:01 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/src/modules/rlm_eap/types/rlm_eap_ttls/rlm_eap_ttls.c; Revisions: 1.5 File: radiusd/src/modules/rlm_eap/types/rlm_eap_ttls/ttls.c; Revisions: 1.13 File: radiusd/src/lib/valuepair.c; Revisions: 1.81 File: radiusd/configure.in; Revisions: 1.195 File: radiusd/configure; Revisions: 1.92 ===================================================== Combined list of identical log entries ===================================================== Description: eapttls_process() was sometimes returning PW_FOO, and sometimes returning RLM_MODULE_FOO. That's bad. The code has now been fixed to be consistent. Modified files: File: radiusd/src/modules/rlm_eap/types/rlm_eap_ttls/rlm_eap_ttls.c; Revision: 1.5; Date: 2004/03/05 17:51:17; Author: aland; Lines: (+2 -2) File: radiusd/src/modules/rlm_eap/types/rlm_eap_ttls/ttls.c; Revision: 1.13; Date: 2004/03/05 17:51:17; Author: aland; Lines: (+24 -4) ------------------------------- Description: If we've found openssl/ssl.h, then set -I$OPENSSL_INCLUDE Patch from Rok Papez Modified files: File: radiusd/configure; Revision: 1.92; Date: 2004/03/05 17:33:31; Author: aland; Lines: (+105 -102) File: radiusd/configure.in; Revision: 1.195; Date: 2004/03/05 17:33:31; Author: aland; Lines: (+4 -1) ===================================================== Log entries ===================================================== Description: Catch people who type 1 character hex strings Modified files: File: radiusd/src/lib/valuepair.c; Revision: 1.81; Date: 2004/03/05 20:45:26; Author: aland; Lines: (+13 -2) ===================================================== Summary of modified files ===================================================== File: radiusd/configure Revisions: 1.92 Authors: aland (+105 -102) ------------------------------- File: radiusd/configure.in Revisions: 1.195 Authors: aland (+4 -1) ------------------------------- File: radiusd/src/lib/valuepair.c Revisions: 1.81 Authors: aland (+13 -2) ------------------------------- File: radiusd/src/modules/rlm_eap/types/rlm_eap_ttls/rlm_eap_ttls.c Revisions: 1.5 Authors: aland (+2 -2) ------------------------------- File: radiusd/src/modules/rlm_eap/types/rlm_eap_ttls/ttls.c Revisions: 1.13 Authors: aland (+24 -4) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl From freeradius-devel@lists.freeradius.org Sat Mar 6 09:30:14 2004 From: freeradius-devel@lists.freeradius.org (Martin Seine) Date: Sat, 06 Mar 2004 10:30:14 +0100 Subject: Patch radrelay.c Message-ID: <40499A26.4080203@buelow-masiak.de> Hello, Sadly I found, that my last patch to radrelay broke up the thing, because there's just one character missing ... The following patch will fix this and I double-checked that it's working this time ... Sorry for the inconvenience, Martin Seine --- src/main/radrelay.c 26 Feb 2004 19:04:26 -0000 1.20 +++ src/main/radrelay.c 6 Mar 2004 09:25:27 -0000 @@ -248,7 +248,7 @@ * being flushed properly. Things should be ok next time * around. */ - if (strlen(buf)) { + if (!strlen(buf)) { fprintf(stdout, "read_one: ZERO BYTE\n"); fseek(fp, fpos + 1, SEEK_SET); break; From freeradius-devel@lists.freeradius.org Sat Mar 6 15:05:06 2004 From: freeradius-devel@lists.freeradius.org (Martin Seine) Date: Sat, 06 Mar 2004 16:05:06 +0100 Subject: Config-File fixup Message-ID: <4049E8A2.4040307@buelow-masiak.de> Hello List, Appended are some small fixes to the parsing of the config-file. Reasons for this patches are: - Ensure, that in case of corrupt file (including 0x00-Bytes) no race condition on line-checking (cbuf[len - 1] could become cbuf[-1]) occurs - strip primarily whitespace from end of the line (I simplified for stripping characters < 0x21), so that a continuation \ with following spaces is correctly detected (I just spent hours finding such a space in the config-files :-( ). Bye, Martin Seine --- src/main/conffile.c 26 Feb 2004 19:04:22 -0000 1.99 +++ src/main/conffile.c 6 Mar 2004 14:57:58 -0000 @@ -607,27 +607,32 @@ * We've filled the buffer, and there isn't * a CR in it. Die! */ - if ((len == sizeof(buf)) && - (cbuf[len - 1] != '\n')) { - radlog(L_ERR, "%s[%d]: Line too long", - cf, *lineno); - cf_section_free(&cs); - return NULL; - } + if (len > 0) { + if ((len == sizeof(buf)) && + (cbuf[len - 1] != '\n')) { + radlog(L_ERR, "%s[%d]: Line too long", + cf, *lineno); + cf_section_free(&cs); + return NULL; + } - /* - * Check for continuations. - */ - if (cbuf[len - 1] == '\n') len--; + /* + * Check for continuations. + */ + /* + * Strip trailing whitespace, for speed assume < 0x21 is whitespace + */ + while ((cbuf[len - 1] < 0x21) && len > 0) len--; - /* - * Last character is '\\'. Over-write it, - * and read another line. - */ - if ((len > 0) && (cbuf[len - 1] == '\\')) { - cbuf[len - 1] = '\0'; - cbuf += len - 1; - continue; + /* + * Last character is '\\'. Over-write it, + * and read another line. + */ + if ((len > 0) && (cbuf[len - 1] == '\\')) { + cbuf[len - 1] = '\0'; + cbuf += len - 1; + continue; + } } /* From freeradius-devel@lists.freeradius.org Mon Mar 8 10:25:09 2004 From: freeradius-devel@lists.freeradius.org (=?Windows-1252?Q?Pascal_S=E9guy?=) Date: Mon, 8 Mar 2004 11:25:09 +0100 Subject: huntgroup [patch] References: <20040305183224.6415516FD1@mail.nitros9.org> Message-ID: <02af01c404f7$a27d9970$05ca10ac@chinook> ----- Original Message -----=20 From: "Alan DeKok" To: Sent: Friday, March 05, 2004 7:32 PM Subject: Re: huntgroup [patch] > =3D?iso-8859-1?Q?Pascal_S=3DE9guy?=3D wrote: > > OK, so why paircmp calls huntgroup_cmp (via paircompare) with the > > "request" argument (the third) holding the remaining of the request > > list: > > I think that the problem is the huntgroup_cmp() function shouldn't exist. > > Delete all references to it, and try again. It's not so simple. I have in my company the following profile (not set by me): #--- hungroups LNS-TH2 Client-IP-Address =3D=3D 62.110.12.234 [...] Realm_isp1 Realm =3D=3D "realm1" Realm_isp1 Realm =3D=3D "realm2" [...] #--- users # DEFAULT isp1 ADSL DEFAULT Huntgroup-Name =3D=3D "Realm_isp1", Huntgroup-Name =3D=3D "LNS-TH= 2" Service-Type =3D Framed-User, Framed-Protocol =3D PPP, Context-Name =3D "isp1", ... If we suppress huntgroup_cmp() this profile will not work anymore because huntgroup_access() only set one Huntgroup-Name VP: rlm_preprocess.c line 537 : /* * We've matched the huntgroup, so add it in * to the list of request pairs. */ vp =3D pairfind(request_pairs, PW_HUNTGROUP_NAME); if (!vp) { vp =3D paircreate(PW_HUNTGROUP_NAME, PW_TYPE_STRING); The question is: - Is it acceptable to have more than one occurence of the Huntgroup-Name = VP in a request? (I think yes) If yes, we can patch huntgroup_access() to allow this, and suppress huntgroup_cmp(). If no, we have to keep huntgroup_cmp() and to apply the patch I propose= d, really : +++ ../modules/rlm_preprocess/rlm_preprocess.c Wed Mar 3 17:04:57 2004 @@ -487,7 +487,7 @@ for (i =3D data->huntgroups; i; i =3D i->next) { if (strcmp(i->name, huntgroup) !=3D 0) continue; - if (paircmp(req, request, i->check, NULL) =3D=3D 0) { + if (paircmp(req, req->packet->vps /*request*/, i->check, NULL) =3D=3D 0) { DEBUG2(" huntgroups: Matched %s at %d", i->name, i->lineno); break; --- Pascal S=E9guy From freeradius-devel@lists.freeradius.org Mon Mar 8 13:19:02 2004 From: freeradius-devel@lists.freeradius.org (Rok Papez) Date: Mon, 08 Mar 2004 14:19:02 +0100 Subject: patch -- Re: denying access to a NULL realm In-Reply-To: <40489948.6020000@arnes.si> References: <40489948.6020000@arnes.si> Message-ID: <404C72C6.8020806@arnes.si> Rok Papez wrote: > What is the best way to "block" the NULL realm ? > > Blocking of any realm would also be very usefull if users from > some other realm wouldn't be allowed to log into this network. I've added a realm option that blocks a certain realm. This way I can deny access for users from certain realms and when used with a NULL realm, users are forced to always specify a @realm with their username :). =============================================================== --- raddb/proxy.conf.orig 2004-03-08 14:08:16.000000000 +0100 +++ raddb/proxy.conf 2004-03-08 14:11:07.000000000 +0100 @@ -278,6 +278,14 @@ #} # +# All users have to enter username@realm or their access is +# blocked. +# +#realm NULL { +# blocked +#} + +# # This realm is for ALL OTHER requests. # #realm DEFAULT { --- doc/proxy.orig 2004-03-08 14:00:25.000000000 +0100 +++ doc/proxy 2004-03-08 14:07:02.000000000 +0100 @@ -67,6 +67,10 @@ user who enters 'user@foobar' from being proxied if the 'foobar' realm configuration contains 'notrealm'. This function used to be called 'notsuffix', and the old syntax is still supported. + - blocked: + User access from blocked realm is denied. Usable for denying + access from the listed realm. + 2. WHAT HAPPENS --- ./src/include/radiusd.h.orig 2004-03-08 13:23:44.000000000 +0100 +++ ./src/include/radiusd.h 2004-03-08 13:24:25.000000000 +0100 @@ -121,6 +121,7 @@ int striprealm; int trusted; /* old */ int notrealm; + int blocked; /* realm is blocked and user should be rejected */ int active; /* is it dead? */ time_t wakeup; /* when we should try it again */ int acct_active; --- ./src/main/files.c.orig 2004-03-08 13:33:48.000000000 +0100 +++ ./src/main/files.c 2004-03-08 13:34:46.000000000 +0100 @@ -444,6 +444,8 @@ c->notrealm = 1; if (strstr(opts, "notsuffix") != NULL) c->notrealm = 1; + if (strstr(opts, "blocked") != NULL) + c->blocked = 1; } c->next = NULL; --- ./src/main/mainconfig.c.orig 2004-03-08 13:33:54.000000000 +0100 +++ ./src/main/mainconfig.c 2004-03-08 13:35:41.000000000 +0100 @@ -479,6 +479,8 @@ c->notrealm = 1; if ((cf_section_value_find(cs, "notsuffix")) != NULL) c->notrealm = 1; + if ((cf_section_value_find(cs, "blocked")) != NULL) + c->blocked = 1; if ((t = cf_section_value_find(cs,"ldflag")) != NULL) { static const LRAD_NAME_NUMBER ldflags[] = { { "fail_over", 0 }, --- ./src/modules/rlm_realm/rlm_realm.c.orig 2004-03-08 13:25:00.000000000 +0100 +++ ./src/modules/rlm_realm/rlm_realm.c 2004-03-08 13:32:46.000000000 +0100 @@ -212,6 +212,10 @@ * Perhaps accounting proxying was turned off. */ case PW_ACCOUNTING_REQUEST: + if (1 == realm->blocked) { + DEBUG2(" rlm_realm: Realm is blocked."); + break; + } if (realm->acct_ipaddr == htonl(INADDR_NONE)) { DEBUG2(" rlm_realm: Accounting realm is LOCAL."); return NULL; @@ -227,6 +231,10 @@ * Perhaps authentication proxying was turned off. */ case PW_AUTHENTICATION_REQUEST: + if (1 == realm->blocked) { + DEBUG2(" rlm_realm: Realm is blocked."); + break; + } if (realm->ipaddr == htonl(INADDR_NONE)) { DEBUG2(" rlm_realm: Authentication realm is LOCAL."); return NULL; @@ -353,6 +361,13 @@ } /* + * If realm is blocked, reject the request. + */ + if (realm->blocked) { + return RLM_MODULE_REJECT; + } + + /* * Maybe add a Proxy-To-Realm attribute to the request. */ DEBUG2(" rlm_realm: Preparing to proxy authentication request to realm \"%s\"\n", @@ -371,9 +386,9 @@ const char *name = (char *)request->username->strvalue; REALM *realm; - if (!name) - return RLM_MODULE_OK; - + if (!name) { + return RLM_MODULE_OK; + } /* * Check if we've got to proxy the request. @@ -385,6 +400,12 @@ return RLM_MODULE_NOOP; } + /* + * If realm is blocked, reject the request. + */ + if (realm->blocked) { + return RLM_MODULE_REJECT; + } /* * Maybe add a Proxy-To-Realm attribute to the request. =============================================================== -- Lep pozdrav, Rok Papez. From freeradius-devel@lists.freeradius.org Mon Mar 8 16:17:11 2004 From: freeradius-devel@lists.freeradius.org (Michael Griego) Date: Mon, 08 Mar 2004 10:17:11 -0600 Subject: huntgroup [patch] In-Reply-To: <02af01c404f7$a27d9970$05ca10ac@chinook> References: <20040305183224.6415516FD1@mail.nitros9.org> <02af01c404f7$a27d9970$05ca10ac@chinook> Message-ID: <1078762631.22701.17.camel@enterprise.utdallas.edu> On Mon, 2004-03-08 at 04:25, Pascal S=E9guy wrote: > It's not so simple. I think you're making it harder than it needs to be. > I have in my company the following profile (not set by me): >=20 >=20 > #--- hungroups >=20 > LNS-TH2 Client-IP-Address =3D=3D 62.110.12.234 > [...] > Realm_isp1 Realm =3D=3D "realm1" > Realm_isp1 Realm =3D=3D "realm2" > [...] >=20 > #--- users >=20 > # DEFAULT isp1 ADSL >=20 > DEFAULT Huntgroup-Name =3D=3D "Realm_isp1", Huntgroup-Name =3D=3D "LNS-= TH2" > Service-Type =3D Framed-User, > Framed-Protocol =3D PPP, > Context-Name =3D "isp1", > ... Based on this configuration, I have a couple of observations: 1. It seems that you're processing a Realm module instance before preprocess. You didn't post your radiusd.conf, so I can't tell for sure. This seems a little odd, but OK. 2. I think you (or whoever designed your radius config) are forcing Huntgroups to do more than they were intended to do. You should be processing Realm information in the users file, not as part of a huntgroup. 3. If you insist on processing realms in the Huntgroups file, you could fix this whole problem by changing your Huntgroup file to read: LNS-TH2 Client-IP-Address =3D=3D 62.110.12.234 LNS-TH2-isp1 Client-IP-Address =3D=3D 62.110.12.234, Realm =3D=3D "realm1= " LNS-TH2-isp2 Client-IP-Address =3D=3D 62.110.12.234, Realm =3D=3D "realm2= " Then you match your users file on the different Huntgroups. > The question is: > - Is it acceptable to have more than one occurence of the Huntgroup-Nam= e VP > in a request? (I think yes) The first time I read your post, I agreed. The more I think about it, however, the more I strongly disagree. After looking over the code and other pieces, I believe the Huntgroups were not designed to handle this and should not be forced to handle this. The huntgroups file even talks about huntgroups that are "subgroups" of another huntgroup. This is exactly what you're talking about needing here. > If no, we have to keep huntgroup_cmp() and to apply the patch I propose= d, > really : No we don't... Dropping the huntgroup_cmp function would take care of this. --=20 --Mike ----------------------------------- Michael Griego Wireless LAN Project Manager The University of Texas at Dallas From freeradius-devel@lists.freeradius.org Mon Mar 8 18:03:01 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Mon, 08 Mar 2004 13:03:01 -0500 Subject: New proxy trees (was Re: filters.c ) In-Reply-To: Your message of "Thu, 04 Mar 2004 10:21:02 CST." Message-ID: <20040308180301.F08E716D00@mail.nitros9.org> Chris Brotsos wrote: > Just reporting back the results. Last time, with 10,000 requests, the > linear search was 8 seconds faster. Under 50,000 the linear search was > 11 seconds faster then the rb-search. Either way, no significant > difference. That's not as good as I would have liked, but it's OK. This means that we can now fix the proxy packet ID problem, as we now have mutex locks around critical sections. We might lose a little bit of time, but that's the cost to be paid for being correct. > I'm satisfied with the test results and still think that the RBTree > might scale better than a linear traversal under a system with a > fluctuating number of requests coming in bursts. Sounds good to me. Alan DeKok. From freeradius-devel@lists.freeradius.org Mon Mar 8 17:57:44 2004 From: freeradius-devel@lists.freeradius.org (=?iso-8859-1?Q?Pascal_S=E9guy?=) Date: Mon, 8 Mar 2004 18:57:44 +0100 Subject: huntgroup [patch] References: <20040305183224.6415516FD1@mail.nitros9.org> <02af01c404f7$a27d9970$05ca10ac@chinook> <1078762631.22701.17.camel@enterprise.utdallas.edu> Message-ID: <031901c40536$dba3e260$05ca10ac@chinook> ----- Original Message -----=20 From: "Michael Griego" To: Sent: Monday, March 08, 2004 5:17 PM Subject: Re: huntgroup [patch] > > > > DEFAULT Huntgroup-Name =3D=3D "Realm_isp1", Huntgroup-Name =3D=3D "LN= S-TH2" > > Service-Type =3D Framed-User, > > Framed-Protocol =3D PPP, > > Context-Name =3D "isp1", > > ... > > Based on this configuration, I have a couple of observations: > 1. It seems that you're processing a Realm module instance before > preprocess. No, preprocess first, realms after and this doesn't matter because huntgroups are evaluated during paircmp() (eg: when parsing user file), n= ot during preprocess authorize. That's why the huntgroup_cmp() exits I think. > 2. I think you (or whoever designed your radius config) are forcing > Huntgroups to do more than they were intended to do. You should be > processing Realm information in the users file, not as part of a > huntgroup. I thought that the first time I saw what they do with huntgroups in my company, I'm not so shure now. > 3. If you insist on processing realms in the Huntgroups file, you could > fix this whole problem by changing your Huntgroup file to read: > > LNS-TH2 Client-IP-Address =3D=3D 62.110.12.234 > LNS-TH2-isp1 Client-IP-Address =3D=3D 62.110.12.234, Realm =3D=3D "real= m1" > LNS-TH2-isp2 Client-IP-Address =3D=3D 62.110.12.234, Realm =3D=3D "real= m2" > > Then you match your users file on the different Huntgroups. That's a good idea. > > > The question is: > > - Is it acceptable to have more than one occurence of the Huntgroup-N= ame VP > > in a request? (I think yes) > > The first time I read your post, I agreed. The more I think about it, > however, the more I strongly disagree. After looking over the code and > other pieces, I believe the Huntgroups were not designed to handle this > and should not be forced to handle this. The huntgroups file even talk= s > about huntgroups that are "subgroups" of another huntgroup. This is > exactly what you're talking about needing here. Ok, so we keep huntgroup_cmp() but are you aware that this function is bugged and my patch is a correct fix ? (need also to apply the patch I ha= ve posted for paircmp() opreator !=3D ). -- Pascal S=E9guy From freeradius-devel@lists.freeradius.org Mon Mar 8 18:11:22 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Mon, 08 Mar 2004 13:11:22 -0500 Subject: rlm_realm behaviour In-Reply-To: Your message of "Wed, 03 Mar 2004 23:48:09 +0200." <40465299.1090303@saix.net> Message-ID: <20040308181122.EB50516D00@mail.nitros9.org> Eddie Stassen wrote: > I must admit my knowledge of RB trees is very limited, and forgive me if > this is a dumb question, but can they handle duplicate keys? (as would > be the case here) No, but it's trivial to have an entry be a linked list of entries. I've taken a quick look at rbtree stuff for clients/realms, and I don't think it will make it in before 1.0. Alan DeKok. From freeradius-devel@lists.freeradius.org Tue Mar 9 09:02:47 2004 From: freeradius-devel@lists.freeradius.org (Automatic cvs log generator) Date: Tue, 9 Mar 2004 03:02:47 -0600 (CST) Subject: Automatic report from sources (radiusd) between 08.03.2004 - 09.03.2004 GMT Message-ID: <20040309090247.7D47277460@webhost1.starnetusa.net> CVS log entries from 08.03.2004 (Mon) 09:00:01 - 09.03.2004 (Tue) 09:00:01 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/doc/ChangeLog; Revisions: 1.46 File: radiusd/src/main/auth.c; Revisions: 1.136 File: radiusd/src/modules/rlm_eap/rlm_eap.c; Revisions: 1.25 File: radiusd/src/include/libradius.h; Revisions: 1.75 File: radiusd/src/main/radiusd.c; Revisions: 1.313 File: radiusd/src/modules/rlm_eap/eap.h; Revisions: 1.27 File: radiusd/src/lib/rbtree.c; Revisions: 1.9 File: radiusd/src/include/radiusd.h; Revisions: 1.152 ===================================================== Combined list of identical log entries ===================================================== Description: Added 'const', for paranoia Modified files: File: radiusd/src/include/libradius.h; Revision: 1.75; Date: 2004/03/08 21:47:06; Author: aland; Lines: (+4 -4) File: radiusd/src/lib/rbtree.c; Revision: 1.9; Date: 2004/03/08 21:47:06; Author: aland; Lines: (+5 -5) ===================================================== Log entries ===================================================== Description: More updates Modified files: File: radiusd/doc/ChangeLog; Revision: 1.46; Date: 2004/03/08 21:45:12; Author: aland; Lines: (+6 -1) ------------------------------- Description: Export rad_postauth() Modified files: File: radiusd/src/include/radiusd.h; Revision: 1.152; Date: 2004/03/08 22:04:36; Author: aland; Lines: (+2 -1) ------------------------------- Description: Expose rad_postauth Modified files: File: radiusd/src/main/auth.c; Revision: 1.136; Date: 2004/03/08 21:51:03; Author: aland; Lines: (+7 -4) ------------------------------- Description: -X means debug_flag +=2. This lets "-xX" set it to 3, rather than 2 Modified files: File: radiusd/src/main/radiusd.c; Revision: 1.313; Date: 2004/03/08 21:47:57; Author: aland; Lines: (+3 -3) ------------------------------- Description: Added submodule tunnel callback Modified files: File: radiusd/src/modules/rlm_eap/eap.h; Revision: 1.27; Date: 2004/03/08 21:51:30; Author: aland; Lines: (+2 -1) ------------------------------- Description: If this VP isn't a LEAP thing, go to the next one. This prevents an infinite loop. Modified files: File: radiusd/src/modules/rlm_eap/rlm_eap.c; Revision: 1.25; Date: 2004/03/08 19:11:08; Author: aland; Lines: (+7 -2) ===================================================== Summary of modified files ===================================================== File: radiusd/doc/ChangeLog Revisions: 1.46 Authors: aland (+6 -1) ------------------------------- File: radiusd/src/include/libradius.h Revisions: 1.75 Authors: aland (+4 -4) ------------------------------- File: radiusd/src/include/radiusd.h Revisions: 1.152 Authors: aland (+2 -1) ------------------------------- File: radiusd/src/lib/rbtree.c Revisions: 1.9 Authors: aland (+5 -5) ------------------------------- File: radiusd/src/main/auth.c Revisions: 1.136 Authors: aland (+7 -4) ------------------------------- File: radiusd/src/main/radiusd.c Revisions: 1.313 Authors: aland (+3 -3) ------------------------------- File: radiusd/src/modules/rlm_eap/eap.h Revisions: 1.27 Authors: aland (+2 -1) ------------------------------- File: radiusd/src/modules/rlm_eap/rlm_eap.c Revisions: 1.25 Authors: aland (+7 -2) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl From freeradius-devel@lists.freeradius.org Tue Mar 9 09:40:35 2004 From: freeradius-devel@lists.freeradius.org (Rok Papez) Date: Tue, 09 Mar 2004 10:40:35 +0100 Subject: patch -- Re: denying access to a NULL realm In-Reply-To: <6.0.3.0.2.20040308091605.0344ae80@mail.starnetusa.net> References: <40489948.6020000@arnes.si> <404C72C6.8020806@arnes.si> <6.0.3.0.2.20040308091605.0344ae80@mail.starnetusa.net> Message-ID: <404D9113.3070106@arnes.si> Hello Chris. Chris Parker wrote: >> Rok Papez wrote: >> >>> What is the best way to "block" the NULL realm ? >>> Blocking of any realm would also be very usefull if users from >>> some other realm wouldn't be allowed to log into this network. >> >> >> I've added a realm option that blocks a certain realm. This way I can >> deny access for users from certain realms and when used with a NULL >> realm, users are forced to always specify a @realm with their username >> :). > > > What's wrong with putting this in the 'users' file: > > DEFAULT Realm == NULL, Auth-Type := Reject > Fall-Through = No Now that you mentioned it... :)) not much except: 1. I couldn't find this solution even after RTFMing extensively in ./doc and googling for it (it was easier to code the required functionality :-/) 2. You still need to configure realm NULL as LOCAL and split configuration for this in two seperate files. If we have "notrealm" and it's actualy a no-op we can also have "blocked" ;)). -- Lep pozdrav, Rok Papez. From freeradius-devel@lists.freeradius.org Tue Mar 9 13:14:08 2004 From: freeradius-devel@lists.freeradius.org (Blinov A. Sergey) Date: Tue, 9 Mar 2004 16:14:08 +0300 Subject: RFC number ? In-Reply-To: <20040218114919.GB27893@asuka.tech.sitadelle.com> References: <200402172004.i1HK4xv11123@newgiles.nitros9.org> <20040218114919.GB27893@asuka.tech.sitadelle.com> Message-ID: <20040309131408.GE26102@kmv.ru> Greeting.. I'm looking in src/main/util.c function rfc_clean. My question is: What RFC number describe return Vendor Specific Attribute in Access-Reject ? I found only some of them EAP-Message, Message-Authenticator, MS-CHAP-Error Thank's.. -- Blinov A. Sergey, POST Ltd. system administrator Phone: +7 8652 972729, +7 8793 467937 Email: blny@kmv.ru Information: BLNY-RIPN, BLNY-RIPE From freeradius-devel@lists.freeradius.org Tue Mar 9 13:17:29 2004 From: freeradius-devel@lists.freeradius.org (Blinov A. Sergey) Date: Tue, 9 Mar 2004 16:17:29 +0300 Subject: RFC number ? Message-ID: <20040309131729.GF26102@kmv.ru> Sorry.. EAP-Message and Message-Authenticator not a VSA -- Blinov A. Sergey, POST Ltd. system administrator Phone: +7 8652 972729, +7 8793 467937 Email: blny@kmv.ru Information: BLNY-RIPN, BLNY-RIPE From freeradius-devel@lists.freeradius.org Tue Mar 9 16:20:56 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Tue, 09 Mar 2004 11:20:56 -0500 Subject: RFC number ? In-Reply-To: Your message of "Tue, 09 Mar 2004 16:14:08 +0300." <20040309131408.GE26102@kmv.ru> Message-ID: <20040309162056.9EBC0170D8@mail.nitros9.org> "Blinov A. Sergey" wrote: > I'm looking in src/main/util.c function rfc_clean. My question is: > > What RFC number describe return Vendor Specific Attribute in Access-Reject ? None. Alan DeKok. From freeradius-devel@lists.freeradius.org Tue Mar 9 17:10:42 2004 From: freeradius-devel@lists.freeradius.org (=?iso-8859-1?Q?Pascal_S=E9guy?=) Date: Tue, 9 Mar 2004 18:10:42 +0100 Subject: huntgroup and operator "!=" patch References: <20040305183224.6415516FD1@mail.nitros9.org> <02af01c404f7$a27d9970$05ca10ac@chinook> <1078762631.22701.17.camel@enterprise.utdallas.edu> <031901c40536$dba3e260$05ca10ac@chinook> Message-ID: <043201c405f9$8c16da40$05ca10ac@chinook> This is a multi-part message in MIME format. ------=_NextPart_000_042F_01C40601.D5AFF8F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by wakanosato.ps id i29HAos9000325 ----- Original Message -----=20 From: "Pascal S=E9guy" To: Sent: Monday, March 08, 2004 6:57 PM Subject: Re: huntgroup [patch] > Ok, so we keep huntgroup_cmp() but are you aware that this function is > bugged and my patch is a correct fix ? I have changed my opinion. We can consider the bug is in paircmp(). A patch is attached for huntgroup_cmp() which just comments how it works = so we will not break our mind anymore to understand it. Is also attached a patch for paircmp(). It resolves the two problems I ha= ve reported on operator !=3D. -- Pascal S=E9guy ------=_NextPart_000_042F_01C40601.D5AFF8F0 Content-Type: text/plain; name="rlm_preprocess_patch.txt" Content-Disposition: attachment; filename="rlm_preprocess_patch.txt" Content-Transfer-Encoding: quoted-printable --- = /home/pascal/w/new/freeradius/radiusd/src/modules/rlm_preprocess/rlm_prep= rocess.c Mon Jul 7 21:17:31 2003 +++ ../modules/rlm_preprocess/rlm_preprocess.c Tue Mar 9 15:04:02 2004 @@ -471,6 +471,32 @@ /* * See if the huntgroup matches. This function is * tied to the "Huntgroup" keyword. + * + * Implementation notes: + * + * This function souldn't normally exist. In fact, it would be easy to = leave paircmp to + * compare strings value from the Huntgroup-Name AVP from the request = against the Huntgroup-Name + * AVP from the check-item. + * This is not implemented in that way for two reasons: + * + * - First the huntgroup may be based upon attribute which are not yet = calculated at the + * time the Huntgroup-Name AVP is inserted in the request (during = preprocess_authorize), exemple: + * the "Realm" AVP which is normally calculated after. So a direct = string compare is impossible. + * + * - Second, this desing allow a request to be matched against more = than one huntgroup even if only + * one Huntgroup-Name AVP is inserted in the request by = preprocess_authorize. + * eg: DEFAULT Huntgroup-Name =3D=3D "LNS-NET1", Huntgroup-Name = =3D=3D "ISP1" + * with huntgroups: + * LNS-NET1 Client-IP-Address =3D=3D 172.16.0.1 + * ISP1 Realm =3D=3D "isp1.com" + * ISP1 Realm =3D=3D "isp1.net" + * + * The real details of the implementation is somewhat complicated: + * huntgroup_cmp is registered to compare not whith Huntgroup-Name AVP = but + * with *all* attributes of the request. So when one check-item of type = Huntgroup-Name + * is encoutered by paircmp, paircmp calls huntgroup_cmp for every AVP = of the request-list. + * And huntgroup_cmp calls paircmp to match the check-list of the = corresponding huntgroup + * against the current request item, so huntgroups are matched on the = fly. */ static int huntgroup_cmp(void *instance, REQUEST *req, VALUE_PAIR = *request, VALUE_PAIR *check, VALUE_PAIR *check_pairs, VALUE_PAIR = **reply_pairs) ------=_NextPart_000_042F_01C40601.D5AFF8F0 Content-Type: text/plain; name="valuepair_patch.txt" Content-Disposition: attachment; filename="valuepair_patch.txt" Content-Transfer-Encoding: quoted-printable --- /home/pascal/w/new/freeradius/radiusd/src/main/valuepair.c Fri Nov = 21 15:29:58 2003 +++ valuepair.c Tue Mar 9 17:18:42 2004 @@ -273,10 +273,18 @@ } /* - * Not found, it's not a match. + * Not found */ if (auth_item =3D=3D NULL) { - return -1; + + switch (check_item->operator) { + case T_OP_NE: /* If operator is "!=3D", reaching the end of list = with no match is a success */ + continue; /* it's a match */ + + default: /* Perhaps we should we make special case for other = operators */ + return -1; /* it's not a match. */ + + } } /* @@ -301,7 +309,20 @@ /* * OK it is present now compare them. */ - compare =3D paircompare(req, auth_item, check_item, check, reply); + { + /* + * Make a local copy of AVP arguments to prevent custom + * compare handlers to loop thru .next member + * (as huntgroup_cmp did) + * Don't tell me this is CPU expensive. + */ + VALUE_PAIR local_check_item =3D *check_item; + VALUE_PAIR local_auth_item =3D *auth_item; + + local_check_item.next =3D 0; + local_auth_item.next =3D 0; + compare =3D paircompare(req, &local_auth_item, &local_check_item, = check, reply); + } switch (check_item->operator) { case T_OP_EQ: @@ -316,7 +337,12 @@ break; case T_OP_NE: - if (compare =3D=3D 0) result =3D -1; + /* If pairs match while we proceed an "!=3D" operator, then + * abort imediately paircmp() because we have found a + * pair which invalidate one check-item + */ + if (compare =3D=3D 0) return(-1); + result =3D -1; break; case T_OP_LT: ------=_NextPart_000_042F_01C40601.D5AFF8F0-- From freeradius-devel@lists.freeradius.org Wed Mar 10 09:02:38 2004 From: freeradius-devel@lists.freeradius.org (Automatic cvs log generator) Date: Wed, 10 Mar 2004 03:02:38 -0600 (CST) Subject: Automatic report from sources (radiusd) between 09.03.2004 - 10.03.2004 GMT Message-ID: <20040310090238.CF8AC77474@webhost1.starnetusa.net> CVS log entries from 09.03.2004 (Tue) 09:00:01 - 10.03.2004 (Wed) 09:00:01 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/share/dictionary.extreme; Revisions: 1.2 ===================================================== Log entries ===================================================== Description: Added attributes as posted to the list today Modified files: File: radiusd/share/dictionary.extreme; Revision: 1.2; Date: 2004/03/09 16:01:13; Author: aland; Lines: (+5 -1) ===================================================== Summary of modified files ===================================================== File: radiusd/share/dictionary.extreme Revisions: 1.2 Authors: aland (+5 -1) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl From freeradius-devel@lists.freeradius.org Thu Mar 11 09:02:38 2004 From: freeradius-devel@lists.freeradius.org (Automatic cvs log generator) Date: Thu, 11 Mar 2004 03:02:38 -0600 (CST) Subject: Automatic report from sources (radiusd) between 10.03.2004 - 11.03.2004 GMT Message-ID: <20040311090238.06CAA77463@webhost1.starnetusa.net> CVS log entries from 10.03.2004 (Wed) 09:00:01 - 11.03.2004 (Thu) 09:00:01 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/src/modules/rlm_eap/types/rlm_eap_ttls/ttls.c; Revisions: 1.14 Author: kkalev File: radiusd/dialup_admin/Changelog; Revisions: 1.185 File: radiusd/dialup_admin/bin/log_badlogins; Revisions: 1.19 ===================================================== Combined list of identical log entries ===================================================== Description: Add a force directive in log_badlogins. If uncommented it will force inserts even if there are sql errors. That can help in case there is one sql query which stops the whole failed logins logging system from working Modified files: File: radiusd/dialup_admin/Changelog; Revision: 1.185; Date: 2004/03/10 14:29:32; Author: kkalev; Lines: (+3 -0) File: radiusd/dialup_admin/bin/log_badlogins; Revision: 1.19; Date: 2004/03/10 14:29:32; Author: kkalev; Lines: (+7 -0) ===================================================== Log entries ===================================================== Description: Padding is "NOT unaligned data", not "aligned data" Modified files: File: radiusd/src/modules/rlm_eap/types/rlm_eap_ttls/ttls.c; Revision: 1.14; Date: 2004/03/10 20:29:20; Author: aland; Lines: (+2 -2) ===================================================== Summary of modified files ===================================================== File: radiusd/dialup_admin/Changelog Revisions: 1.185 Authors: kkalev (+3 -0) ------------------------------- File: radiusd/dialup_admin/bin/log_badlogins Revisions: 1.19 Authors: kkalev (+7 -0) ------------------------------- File: radiusd/src/modules/rlm_eap/types/rlm_eap_ttls/ttls.c Revisions: 1.14 Authors: aland (+2 -2) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl From freeradius-devel@lists.freeradius.org Fri Mar 12 14:56:49 2004 From: freeradius-devel@lists.freeradius.org (Rok Papez) Date: Fri, 12 Mar 2004 15:56:49 +0100 Subject: PATCH -- Static linking issue, rlm_sql/drivers Message-ID: <4051CFB1.3010905@arnes.si> Hello! When freeradius is configured for static linking (./configure --disable-shared) it fails to link with rlm_sql driver modules. The attached patch links the rlm_sql/drivers in the same way as rlm_eap/types are linked. --- src/main/Makefile.in.orig 2004-03-12 15:50:55.000000000 +0100 +++ src/main/Makefile.in 2004-03-12 15:51:44.000000000 +0100 @@ -31,14 +31,17 @@ # MODULES += rlm_eap_md5 rlm_eap_leap rlm_eap_tls rlm_eap_ttls rlm_eap_sim MODULES += rlm_eap_peap rlm_eap_mschapv2 rlm_eap_gtc +MODULES += rlm_sql_db2 rlm_sql_freetds rlm_sql_iodbc rlm_sql_mysql rlm_sql_oracle rlm_sql_postgresql rlm_sql_sybase rlm_sql_unixodbc ifneq ($(OPENSSL_LIBS),) LIBS += -L$(OPENSSL_LIBS) -L../modules/rlm_eap/libeap -leap -lcrypto -lssl -lcrypto -lssl endif # MODULE_LIBS += $(shell for x in $(MODULES);do test -f ../modules/$$x/$$x.la && echo -dlpreopen ../modules/$$x/$$x.la;done) -MODULE_LIBS += $(shell for x in $(MODULES);do test -f ../modules/*/types/$$x/$$x.la && echo -dlpreopen ../modules/*/types/$$x/$$x.la;done) MODULE_OBJS += $(shell for x in $(MODULES);do test -f ../modules/$$x/$$x.la && echo ../modules/$$x/$$x.la;done) +MODULE_LIBS += $(shell for x in $(MODULES);do test -f ../modules/*/types/$$x/$$x.la && echo -dlpreopen ../modules/*/types/$$x/$$x.la;done) MODULE_OBJS += $(shell for x in $(MODULES);do test -f ../modules/*/types/$$x/$$x.la && echo ../modules/*/types/$$x/$$x.la;done) +MODULE_LIBS += $(shell for x in $(MODULES);do test -f ../modules/*/drivers/$$x/$$x.la && echo -dlpreopen ../modules/*/drivers/$$x/$$x.la;done) +MODULE_OBJS += $(shell for x in $(MODULES);do test -f ../modules/*/drivers/$$x/$$x.la && echo ../modules/*/drivers/$$x/$$x.la;done) endif LIBS += -lradius $(SNMP_LIBS) -- best regards, Rok Papez. From freeradius-devel@lists.freeradius.org Fri Mar 12 16:31:15 2004 From: freeradius-devel@lists.freeradius.org (Oleg Gritsinevich) Date: Fri, 12 Mar 2004 18:31:15 +0200 Subject: Alpha don't like the code Message-ID: <20040312163115.GA2167@kunashir.ukrpack.net> Hi, All! I've discovered some troubles with new rb-tree code on Linux/Alpha. Server segfaulting when reading of dictionnaries. Backtrace follows: #0 0x200003d0950 in strcasecmp () from /lib/libc.so.6.1 #1 0x12004dd30 in valuefixup_cmp (a=0x1201198c0, b=0x120119850) at dict.c:734 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ #2 0x12005ee00 in rbtree_insert (tree=0x120118750, Data=0x1201198c0) at rbtree.c:252 #3 0x12004ccfc in dict_addvalue (namestr=0x11fffcf50 "VJ-TCP-IP", attrstr=0x11fffd150 "Framed-Compression", value=1) at dict.c:280 #4 0x12004d440 in process_value ( fn=0x11fffd2a0 "/home/oleg/wifirad/share/freeradius/dictionary.compat", line=21, data=0x0) at dict.c:445 #5 0x12004da2c in my_dict_init ( dir=0x11fffd660 "/home/oleg/wifirad/share/freeradius", fn=0x11fffd2a0 "/home/oleg/wifirad/share/freeradius/dictionary.compat", src_file=0x11fffd3a0 "VALUE", src_line=536859552) at dict.c:595 The machine don't like this code: static int valuefixup_cmp(const void *a, const void *b) { int rcode; rcode = strcasecmp((const char *) ((const DICT_VALUE *)a)->attr, (const char *) ((const DICT_VALUE *)b)->attr); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ if (rcode != 0) return rcode; return (((const DICT_VALUE *)a)->value - ((const DICT_VALUE *)b)->value); } Commentary for this function says "Compare values by name, keying off of the value number, and then the value number." I don't have deep understanding of rb-tree stuff but I see that code tries to compare names of _attributes_ instead of names of _values_ (as commentary says). Maybe this string should look like this?: rcode = strcasecmp((const char *) ((const DICT_VALUE *)a)->name, (const char *) ((const DICT_VALUE *)b)->name); If I wrong and it really should look like strcmp(...->attr, ...->attr) anyway it's impossible on alpha because you define DICT_VALUE as: typedef struct dict_value { char name[40]; int attr; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ int value; } DICT_VALUE; 'attr' in this definition has sizeof = 4 and you try to use it as a pointer to string in the code, but on alpha pointers have sizeof = 8 and 'attr' must have type of 'long', so it should look like this: #ifdef __alpha__ long attr; #else int attr; #endif I don't understand the thing: if you going to use DICT_VALUE->attr as (char*) why don't you declare it as (char*) in DICT_VALUE? This memory arithmetic and jugglery with types (int) -> (char*) -> (int) makes me and my machine mad. I really can't understand pieces of code like this (lib/dict.c:dict_addvalue): if (dattr) { dval->attr = dattr->attr; } else { dval->attr = (int) strdup(attrstr); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ rbtree_insert(values_fixup, dval); return 0; } And I see it in many places. It's awful. Can you supply definitions of rb-tree-related structures such as DICT_VALUE in include/libradius.h with commentaries that describe _real_ purpose of it's members? Then I will try to fix the code. One more question. I want to build the server as a huge static executable with all modules compiled in for debug purposes. What options I must provide to 'configure' script to accomplish it? Some time ago I did it, but now I can't remember how :-) -- With best regards, Oleg Gritsinevich From freeradius-devel@lists.freeradius.org Fri Mar 12 19:04:15 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Fri, 12 Mar 2004 14:04:15 -0500 Subject: Alpha don't like the code In-Reply-To: Your message of "Fri, 12 Mar 2004 18:31:15 +0200." <20040312163115.GA2167@kunashir.ukrpack.net> Message-ID: <20040312190415.13B3A170F5@mail.nitros9.org> Oleg Gritsinevich wrote: > I don't understand the thing: if you going to use DICT_VALUE->attr > as (char*) why don't you declare it as (char*) in DICT_VALUE? The code is a terrible hack. > And I see it in many places. It's awful. Yes. > Can you supply definitions of rb-tree-related structures such as > DICT_VALUE in include/libradius.h with commentaries that describe _real_ > purpose of it's members? Then I will try to fix the code. The "fixup" related code is a hack to permit the server to read VALUE's from a dictionary file before the ATTRIBUTE has been defined. There's probably a better way of doing it... > One more question. I want to build the server as a huge static > executable with all modules compiled in for debug purposes. What options I > must provide to 'configure' script to accomplish it? Some time ago I did > it, but now I can't remember how :-) $ ./configure --disable-shared Alan DeKok. From freeradius-devel@lists.freeradius.org Fri Mar 12 22:19:28 2004 From: freeradius-devel@lists.freeradius.org (Michael Griego) Date: Fri, 12 Mar 2004 16:19:28 -0600 Subject: xlat question Message-ID: <1079129968.3805.21.camel@enterprise.utdallas.edu> When a module registers an xlat function (such as sql_xlat), the value returned by that function is the length of the string appended to the xlat output. In the function decode_attribute, a registered xlat function is searched for as part of the decoding. If a function does exist, it is called, and found is set to 1. If the function does not return anything, however (such as in, the processing failed, or no results were found), found is still set to 1. My opinion is that if the do_xlat function returns 0, decode_attribute should treat it as though the attribute was not found (set found=0). Treating the xlat functions in this manner allows you to use :- processing correctly, as in: Reply-Message = %{sql:SELECT reply FROM table:-No Reply} I created a patch to do just this. It checks the return value from do_xlat. If the return is 0, it sets found=0, else, it sets found=1 and increments q by the returned value. It's working great in the exact type of situation as exampled above. Before I committed this to cvs, I just wanted to make sure no one saw any problems with making this change. I don't think it would break anything else, but I want to make sure everyone else thinks the same thing as this is part of the server core. :) -- --Mike ----------------------------------- Michael Griego Wireless LAN Project Manager The University of Texas at Dallas From freeradius-devel@lists.freeradius.org Sat Mar 13 09:02:43 2004 From: freeradius-devel@lists.freeradius.org (Automatic cvs log generator) Date: Sat, 13 Mar 2004 03:02:43 -0600 (CST) Subject: Automatic report from sources (radiusd) between 12.03.2004 - 13.03.2004 GMT Message-ID: <20040313090243.553C37745C@webhost1.starnetusa.net> CVS log entries from 12.03.2004 (Fri) 09:00:01 - 13.03.2004 (Sat) 09:00:01 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/src/modules/rlm_eap/types/rlm_eap_peap/peap.c; Revisions: 1.11, 1.10 File: radiusd/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c; Revisions: 1.19 File: radiusd/src/modules/rlm_eap/rlm_eap.c; Revisions: 1.26 File: radiusd/src/modules/rlm_eap/types/rlm_eap_mschapv2/rlm_eap_mschapv2.c; Revisions: 1.6, 1.5 File: radiusd/src/modules/rlm_files/rlm_files.c; Revisions: 1.61 File: radiusd/src/lib/dict.c; Revisions: 1.50 File: radiusd/src/modules/rlm_fastusers/rlm_fastusers.c; Revisions: 1.32 ===================================================== Log entries ===================================================== Description: A little better way of dealing with DICT_VALUEs that are defined out of order Modified files: File: radiusd/src/lib/dict.c; Revision: 1.50; Date: 2004/03/12 21:33:37; Author: aland; Lines: (+69 -72) ------------------------------- Description: If the tunneled EAP session returned early because the server is acting as a protocol translator for proxying (EAP-FOO to FOO), then remember what's going on for later. Modified files: File: radiusd/src/modules/rlm_eap/rlm_eap.c; Revision: 1.26; Date: 2004/03/12 16:14:53; Author: aland; Lines: (+25 -6) ------------------------------- Description: Added instance, so that we can control with_ntdomain_hack, for proxying EAP-MS-CHAP-V2 as MSCHAP-V2. The wonderful Windows clients send User-Name = "DOMAIN\\user", but calculate the MS-CHAP response based on "user", so they lie to us. WTF were those people thinking? Modified files: File: radiusd/src/modules/rlm_eap/types/rlm_eap_mschapv2/rlm_eap_mschapv2.c; Revision: 1.6; Date: 2004/03/12 16:31:22; Author: aland; Lines: (+77 -5) ------------------------------- Description: After we've called MS-CHAP for authentication, delete the MPPE keys from the response. Handle proxying of EAP-MS-CHAP-V2 as MS-CHAP-V2 Modified files: File: radiusd/src/modules/rlm_eap/types/rlm_eap_mschapv2/rlm_eap_mschapv2.c; Revision: 1.5; Date: 2004/03/12 16:19:50; Author: aland; Lines: (+124 -1) ------------------------------- Description: Don't bother fixing these things up incorrectly Modified files: File: radiusd/src/modules/rlm_eap/types/rlm_eap_peap/peap.c; Revision: 1.11; Date: 2004/03/12 18:23:14; Author: aland; Lines: (+1 -25) ------------------------------- Description: Look for post-proxy for tunneled session, and do it, if configured Modified files: File: radiusd/src/modules/rlm_eap/types/rlm_eap_peap/peap.c; Revision: 1.10; Date: 2004/03/12 16:35:48; Author: aland; Lines: (+174 -8) ------------------------------- Description: A little prettier printing for -Xx Modified files: File: radiusd/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c; Revision: 1.19; Date: 2004/03/12 16:12:35; Author: aland; Lines: (+3 -2) ------------------------------- Description: Get rid of "long" types. They're not needed. Modified files: File: radiusd/src/modules/rlm_fastusers/rlm_fastusers.c; Revision: 1.32; Date: 2004/03/12 19:06:56; Author: aland; Lines: (+10 -10) ------------------------------- Description: Minor formatting Modified files: File: radiusd/src/modules/rlm_files/rlm_files.c; Revision: 1.61; Date: 2004/03/12 16:12:53; Author: aland; Lines: (+4 -4) ===================================================== Summary of modified files ===================================================== File: radiusd/src/lib/dict.c Revisions: 1.50 Authors: aland (+69 -72) ------------------------------- File: radiusd/src/modules/rlm_eap/rlm_eap.c Revisions: 1.26 Authors: aland (+25 -6) ------------------------------- File: radiusd/src/modules/rlm_eap/types/rlm_eap_mschapv2/rlm_eap_mschapv2.c Revisions: 1.6, 1.5 Authors: aland (+77 -5), aland (+124 -1) ------------------------------- File: radiusd/src/modules/rlm_eap/types/rlm_eap_peap/peap.c Revisions: 1.11, 1.10 Authors: aland (+1 -25), aland (+174 -8) ------------------------------- File: radiusd/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c Revisions: 1.19 Authors: aland (+3 -2) ------------------------------- File: radiusd/src/modules/rlm_fastusers/rlm_fastusers.c Revisions: 1.32 Authors: aland (+10 -10) ------------------------------- File: radiusd/src/modules/rlm_files/rlm_files.c Revisions: 1.61 Authors: aland (+4 -4) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl From freeradius-devel@lists.freeradius.org Sat Mar 13 16:09:36 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Sat, 13 Mar 2004 11:09:36 -0500 Subject: xlat question In-Reply-To: Your message of "Fri, 12 Mar 2004 16:19:28 CST." <1079129968.3805.21.camel@enterprise.utdallas.edu> Message-ID: <20040313160936.C4FA716FDF@mail.nitros9.org> Michael Griego wrote: > Treating the xlat functions > in this manner allows you to use :- processing correctly, as in: > > Reply-Message = %{sql:SELECT reply FROM table:-No Reply} > > I created a patch to do just this. Sounds good to me. We should also take a look into increasing the size of those strings, so they can be longer than 253 bytes. In other news, we should probably get rid of ``, and just xlat all double-quoted strings... Alan DeKok. From freeradius-devel@lists.freeradius.org Sat Mar 13 18:07:55 2004 From: freeradius-devel@lists.freeradius.org (Oleg Gritsinevich) Date: Sat, 13 Mar 2004 20:07:55 +0200 Subject: Automatic report from sources (radiusd) between 12.03.2004 - 13.03.2004 GMT In-Reply-To: <20040313090243.553C37745C@webhost1.starnetusa.net> References: <20040313090243.553C37745C@webhost1.starnetusa.net> Message-ID: <20040313180754.GA2493@kunashir.ukrpack.net> On Sat, Mar 13, 2004 at 03:02:43AM -0600, Automatic cvs log generator wrote: [skip] > ===================================================== > Description: > A little better way of dealing with DICT_VALUEs that are defined > out of order > Modified files: > File: radiusd/src/lib/dict.c; Revision: 1.50; > Date: 2004/03/12 21:33:37; Author: aland; Lines: (+69 -72) > ------------------------------- Thanks, Alan! It works now. -- With best regards, Oleg Gritsinevich From freeradius-devel@lists.freeradius.org Sun Mar 14 09:02:37 2004 From: freeradius-devel@lists.freeradius.org (Automatic cvs log generator) Date: Sun, 14 Mar 2004 03:02:37 -0600 (CST) Subject: Automatic report from sources (radiusd) between 13.03.2004 - 14.03.2004 GMT Message-ID: <20040314090237.8D42977473@webhost1.starnetusa.net> CVS log entries from 13.03.2004 (Sat) 09:00:01 - 14.03.2004 (Sun) 09:00:01 GMT ===================================================== Summary by authors ===================================================== Author: cparker File: radiusd/man/man5/rlm_counter.5; Revisions: 1.1 File: radiusd/man/man5/rlm_mschap.5; Revisions: 1.1 ===================================================== Combined list of identical log entries ===================================================== Description: More man pages for commonly used modules. Modified files: File: radiusd/man/man5/rlm_counter.5; Revision: 1.1; Date: 2004/03/14 01:25:10; Author: cparker; File: radiusd/man/man5/rlm_mschap.5; Revision: 1.1; Date: 2004/03/14 01:25:10; Author: cparker; ===================================================== Log entries ===================================================== ===================================================== Summary of modified files ===================================================== File: radiusd/man/man5/rlm_counter.5 Revisions: 1.1 Authors: cparker ------------------------------- File: radiusd/man/man5/rlm_mschap.5 Revisions: 1.1 Authors: cparker -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl From freeradius-devel@lists.freeradius.org Sun Mar 14 18:53:10 2004 From: freeradius-devel@lists.freeradius.org (Chris Parker) Date: Sun, 14 Mar 2004 12:53:10 -0600 Subject: eap.conf ? Message-ID: <6.0.3.0.2.20040314125236.0370bdc8@mail.starnetusa.net> I've been watching the EAP section of radiusd.conf getting bigger and bigger, and I think it might be worthwhile to move the EAP secion to a separate file ala 'sql.conf'. This way, it's easy for those who aren't using it to not be confused by all the EAP options, and would only have a single $INCLUDE line to comment if they so choose. Thoughts? -Chris -- \\\|||/// \ StarNet Inc. \ Chris Parker \ ~ ~ / \ Wholesale Internet \ Director, Engineering | @ @ | \ http://www.starnetusa.net \ (847) 963-0116 oOo---(_)---oOo--\------------------------------------------------------ \ Outpace the Competition - http://www.getmespeed.com From freeradius-devel@lists.freeradius.org Sun Mar 14 23:05:23 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Sun, 14 Mar 2004 18:05:23 -0500 Subject: eap.conf ? In-Reply-To: Your message of "Sun, 14 Mar 2004 12:53:10 CST." <6.0.3.0.2.20040314125236.0370bdc8@mail.starnetusa.net> Message-ID: <20040314230524.009DE170BB@mail.nitros9.org> Chris Parker wrote: > I've been watching the EAP section of radiusd.conf getting bigger and bigger, > and I think it might be worthwhile to move the EAP secion to a separate > file ala 'sql.conf'. This way, it's easy for those who aren't using it > to not be confused by all the EAP options, and would only have a single > $INCLUDE line to comment if they so choose. Sounds good to me. In a similar line of thinking, "sql.conf" should be simplified into common SQL configurations, and per-DB schemas. Being able to do something like this would be useful: sql_type = mysql driver = rlm_sql_${sql_type} $INCLUDE sql-${sql_type}.conf Alan DeKok. From freeradius-devel@lists.freeradius.org Mon Mar 15 01:34:17 2004 From: freeradius-devel@lists.freeradius.org (Chris Parker) Date: Sun, 14 Mar 2004 19:34:17 -0600 Subject: rlm_realm behaviour In-Reply-To: <40439B4A.6000705@saix.net> References: <404388EC.8@saix.net> <6.0.1.1.2.20040301131103.035c82f8@mail.starnetusa.net> <40439B4A.6000705@saix.net> Message-ID: <6.0.3.0.2.20040314193136.03680c10@mail.starnetusa.net> At 02:21 PM 3/1/2004, Eddie Stassen wrote: >Chris Parker wrote: > >>At 01:03 PM 3/1/2004, Eddie Stassen wrote: >> >>>I have come across a problem with the rlm_realm implementation when >>>using both prefix and suffix realms in conjunction with NULL realms. >>>config entry: >>>authorize { >>> prefix >>> suffix >>> blah blah >>>} >>> >>>proxy.conf: >>>realm realma { >>> ... >>>} >>>realm realmb { >>> ... >>>} >>>realm NULL { >>> ... >>>} >>> >>>user logs in as: realma/user - proxy to realma (correct) >>>user logs in as: user - proxy to NULL realm (correct) >>>user logs in as: user@realmb - ooops prefix module gets no match and >>>proxies to NULL realm >> >>This same problem has occured on occasion or two here. >>I think the best solution is to add: >> skip_null >> skip_default >>options to the rlm_realm config. They should default to 'no' to maintain >>current behaviour. If set to 'yes' then the module will not match on >>NULL or DEFAULT, allowing you to have multiple rlm_realm instances, with >>only the last one matching NULL and DEFAULT. > >OK, that sounds good. The code and config options to support this were comitted tonight and are available in the latest CVS. The man page rlm_realm(5) and radiusd.conf.in have been updated with the new config options as well. I've tested it here, and it works for every case I've tested. The two options default to 'no' to maintian current behaviour for backwards compatability. -Chris -- \\\|||/// \ StarNet Inc. \ Chris Parker \ ~ ~ / \ Wholesale Internet \ Director, Engineering | @ @ | \ http://www.starnetusa.net \ (847) 963-0116 oOo---(_)---oOo--\------------------------------------------------------ \ Outpace the Competition - http://www.getmespeed.com From freeradius-devel@lists.freeradius.org Mon Mar 15 09:02:46 2004 From: freeradius-devel@lists.freeradius.org (Automatic cvs log generator) Date: Mon, 15 Mar 2004 03:02:46 -0600 (CST) Subject: Automatic report from sources (radiusd) between 14.03.2004 - 15.03.2004 GMT Message-ID: <20040315090246.A22677745A@webhost1.starnetusa.net> CVS log entries from 14.03.2004 (Sun) 09:00:01 - 15.03.2004 (Mon) 09:00:01 GMT ===================================================== Summary by authors ===================================================== Author: cparker File: radiusd/src/modules/rlm_realm/rlm_realm.c; Revisions: 1.48 File: radiusd/raddb/radiusd.conf.in; Revisions: 1.179 File: radiusd/man/man5/rlm_realm.5; Revisions: 1.2 ===================================================== Combined list of identical log entries ===================================================== Description: Added two realm module configure options. Ignore_default and ignore_null. Boolean values that can be set to yes to cause the specific module instance to not return a match on DEFAULT or NULL realms respectively. This allows mutliple realm modules to coexist with DEFAULT and NULL entries in 'raddb/proxy.conf' much nicer. Updated man page, and radiusd.conf with examples. Modified files: File: radiusd/man/man5/rlm_realm.5; Revision: 1.2; Date: 2004/03/15 01:27:11; Author: cparker; Lines: (+11 -1) File: radiusd/raddb/radiusd.conf.in; Revision: 1.179; Date: 2004/03/15 01:27:11; Author: cparker; Lines: (+18 -4) File: radiusd/src/modules/rlm_realm/rlm_realm.c; Revision: 1.48; Date: 2004/03/15 01:27:11; Author: cparker; Lines: (+21 -3) ===================================================== Log entries ===================================================== ===================================================== Summary of modified files ===================================================== File: radiusd/man/man5/rlm_realm.5 Revisions: 1.2 Authors: cparker (+11 -1) ------------------------------- File: radiusd/raddb/radiusd.conf.in Revisions: 1.179 Authors: cparker (+18 -4) ------------------------------- File: radiusd/src/modules/rlm_realm/rlm_realm.c Revisions: 1.48 Authors: cparker (+21 -3) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl From freeradius-devel@lists.freeradius.org Mon Mar 15 19:21:34 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Mon, 15 Mar 2004 14:21:34 -0500 Subject: radclient file parsing patch In-Reply-To: Your message of "Thu, 04 Mar 2004 15:43:18 CST." <200403042143.i24LhIBL052826@tig.oss.uswest.net> Message-ID: <20040315192134.B47D616D00@mail.nitros9.org> cmikk@qwest.net wrote: > This appears to fix a radclient crash when radclient's > input ends with a blank line. radclient_init called > radclient_free, but necessarily did so before > radclient_head and radclient_tail had been set. Applied, thanks. Alan DeKok. From freeradius-devel@lists.freeradius.org Tue Mar 16 09:03:00 2004 From: freeradius-devel@lists.freeradius.org (Automatic cvs log generator) Date: Tue, 16 Mar 2004 03:03:00 -0600 (CST) Subject: Automatic report from sources (radiusd) between 15.03.2004 - 16.03.2004 GMT Message-ID: <20040316090300.AD3A077458@webhost1.starnetusa.net> CVS log entries from 15.03.2004 (Mon) 09:00:01 - 16.03.2004 (Tue) 09:00:01 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/raddb/eap.conf; Revisions: 1.1 File: radiusd/raddb/radiusd.conf.in; Revisions: 1.180 File: radiusd/src/main/radclient.c; Revisions: 1.72 ===================================================== Combined list of identical log entries ===================================================== Description: Moved EAP section to its own configuration file, as it was getting large Modified files: File: radiusd/raddb/eap.conf; Revision: 1.1; Date: 2004/03/15 19:10:47; Author: aland; File: radiusd/raddb/radiusd.conf.in; Revision: 1.180; Date: 2004/03/15 19:10:47; Author: aland; Lines: (+4 -264) ===================================================== Log entries ===================================================== Description: If input ends in one or more blank lines, don't get excited. Patch from Chris Mikkelson Modified files: File: radiusd/src/main/radclient.c; Revision: 1.72; Date: 2004/03/15 19:17:43; Author: aland; Lines: (+8 -7) ===================================================== Summary of modified files ===================================================== File: radiusd/raddb/eap.conf Revisions: 1.1 Authors: aland ------------------------------- File: radiusd/raddb/radiusd.conf.in Revisions: 1.180 Authors: aland (+4 -264) ------------------------------- File: radiusd/src/main/radclient.c Revisions: 1.72 Authors: aland (+8 -7) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl From freeradius-devel@lists.freeradius.org Tue Mar 16 11:59:50 2004 From: freeradius-devel@lists.freeradius.org (Rok Papez) Date: Tue, 16 Mar 2004 12:59:50 +0100 Subject: PATCH -- Static linking issue, rlm_sql/drivers In-Reply-To: <4051CFB1.3010905@arnes.si> References: <4051CFB1.3010905@arnes.si> Message-ID: <4056EC36.40507@arnes.si> Hello! Has anyone had time to look at this ? It's actualy a trivial patch... Should it be done in some other way ? Rok Papez wrote: > Hello! > > When freeradius is configured for static linking (./configure > --disable-shared) it fails > to link with rlm_sql driver modules. The attached patch links the > rlm_sql/drivers > in the same way as rlm_eap/types are linked. --- src/main/Makefile.in.orig 2004-03-12 15:50:55.000000000 +0100 +++ src/main/Makefile.in 2004-03-12 15:51:44.000000000 +0100 @@ -31,14 +31,17 @@ # MODULES += rlm_eap_md5 rlm_eap_leap rlm_eap_tls rlm_eap_ttls rlm_eap_sim MODULES += rlm_eap_peap rlm_eap_mschapv2 rlm_eap_gtc +MODULES += rlm_sql_db2 rlm_sql_freetds rlm_sql_iodbc rlm_sql_mysql rlm_sql_oracle rlm_sql_postgresql rlm_sql_sybase rlm_sql_unixodbc ifneq ($(OPENSSL_LIBS),) LIBS += -L$(OPENSSL_LIBS) -L../modules/rlm_eap/libeap -leap -lcrypto -lssl -lcrypto -lssl endif # MODULE_LIBS += $(shell for x in $(MODULES);do test -f ../modules/$$x/$$x.la && echo -dlpreopen ../modules/$$x/$$x.la;done) -MODULE_LIBS += $(shell for x in $(MODULES);do test -f ../modules/*/types/$$x/$$x.la && echo -dlpreopen ../modules/*/types/$$x/$$x.la;done) MODULE_OBJS += $(shell for x in $(MODULES);do test -f ../modules/$$x/$$x.la && echo ../modules/$$x/$$x.la;done) +MODULE_LIBS += $(shell for x in $(MODULES);do test -f ../modules/*/types/$$x/$$x.la && echo -dlpreopen ../modules/*/types/$$x/$$x.la;done) MODULE_OBJS += $(shell for x in $(MODULES);do test -f ../modules/*/types/$$x/$$x.la && echo ../modules/*/types/$$x/$$x.la;done) +MODULE_LIBS += $(shell for x in $(MODULES);do test -f ../modules/*/drivers/$$x/$$x.la && echo -dlpreopen ../modules/*/drivers/$$x/$$x.la;done) +MODULE_OBJS += $(shell for x in $(MODULES);do test -f ../modules/*/drivers/$$x/$$x.la && echo ../modules/*/drivers/$$x/$$x.la;done) endif LIBS += -lradius $(SNMP_LIBS) -- Lep pozdrav, Rok Papez. From freeradius-devel@lists.freeradius.org Tue Mar 16 14:49:27 2004 From: freeradius-devel@lists.freeradius.org (Oleg Gritsinevich) Date: Tue, 16 Mar 2004 16:49:27 +0200 Subject: Automatic report from sources (radiusd) between 15.03.2004 - 16.03.2004 GMT In-Reply-To: <20040316090300.AD3A077458@webhost1.starnetusa.net> References: <20040316090300.AD3A077458@webhost1.starnetusa.net> Message-ID: <20040316144927.GA1736@kunashir.ukrpack.net> On Tue, Mar 16, 2004 at 03:03:00AM -0600, Automatic cvs log generator wrote: [skip] > Moved EAP section to its own configuration file, as it was > getting large There is small typo in eap.conf and I think it's need to reflect appearance of 'with_ntdomain_hack' option for mschapv2 in config file {or|and} in documentation. --- raddb/eap.conf.orig Tue Mar 16 16:42:48 2004 +++ raddb/eap.conf Tue Mar 16 16:45:01 2004 @@ -15,7 +15,7 @@ # # For now, only one default EAP type may be used at a time. # -` # If the EAP-Type attribute is set by another module, + # If the EAP-Type attribute is set by another module, # then that EAP type takes precedence over the # default type configured here. # @@ -261,6 +261,11 @@ # currently support. # mschapv2 { + # Windows sends us a username in the form of + # DOMAIN\user, but sends the challenge response + # based on only the user portion. This hack + # corrects for that incorrect behavior. + # with_ntdomain_hack = no } } -- With best regards, Oleg Gritsinevich From freeradius-devel@lists.freeradius.org Tue Mar 16 15:58:20 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Tue, 16 Mar 2004 10:58:20 -0500 Subject: Automatic report from sources (radiusd) between 15.03.2004 - 16.03.2004 GMT In-Reply-To: Your message of "Tue, 16 Mar 2004 16:49:27 +0200." <20040316144927.GA1736@kunashir.ukrpack.net> Message-ID: <20040316155820.AAA24170BB@mail.nitros9.org> Oleg Gritsinevich wrote: > There is small typo in eap.conf I'll fix that. > and I think it's need to reflect appearance of 'with_ntdomain_hack' > option for mschapv2 in config file {or|and} in documentation. That configuration options is used in the non-EAP mschap module. It's appearance in the mschapv2 module is a result of other issues... Alan DeKok. From freeradius-devel@lists.freeradius.org Tue Mar 16 23:42:33 2004 From: freeradius-devel@lists.freeradius.org (Guy Fraser) Date: Tue, 16 Mar 2004 16:42:33 -0700 Subject: Dialup admin bin Message-ID: <405790E9.9040007@incentre.net> Hi Kostas Would you look into including my dialup_admin/bin patches into CVS. The patches add configurable MySQL/PostgreSQL or UCD/Net SNMP compatability as well as a couple of enhancements. There is a full description and a link to a unified patch on this website: http://sphinx.incentre.net/ I rebuilt the patch and tested it against CVS as of : 2004 Mar 16 16:25 MST I have been waiting since mid December for these patches to be applied to CVS. -- Guy Fraser Network Administrator The Internet Centre 780-450-6787 , 1-888-450-6787 From freeradius-devel@lists.freeradius.org Wed Mar 17 09:02:41 2004 From: freeradius-devel@lists.freeradius.org (Automatic cvs log generator) Date: Wed, 17 Mar 2004 03:02:41 -0600 (CST) Subject: Automatic report from sources (radiusd) between 16.03.2004 - 17.03.2004 GMT Message-ID: <20040317090241.59366774F3@webhost1.starnetusa.net> CVS log entries from 16.03.2004 (Tue) 09:00:01 - 17.03.2004 (Wed) 09:00:01 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/raddb/eap.conf; Revisions: 1.2 File: radiusd/src/modules/rlm_eap/types/rlm_eap_ttls/ttls.c; Revisions: 1.15 Author: mgriego File: radiusd/src/main/xlat.c; Revisions: 1.68 ===================================================== Log entries ===================================================== Description: Removed unnecessary character Modified files: File: radiusd/raddb/eap.conf; Revision: 1.2; Date: 2004/03/16 15:54:57; Author: aland; Lines: (+2 -2) ------------------------------- Description: Check return value from registered xlat functions. If return value is 0, treat the attribute as not found. Modified files: File: radiusd/src/main/xlat.c; Revision: 1.68; Date: 2004/03/16 15:16:14; Author: mgriego; Lines: (+11 -5) ------------------------------- Description: Flush the buffer after writing to it Modified files: File: radiusd/src/modules/rlm_eap/types/rlm_eap_ttls/ttls.c; Revision: 1.15; Date: 2004/03/16 15:30:15; Author: aland; Lines: (+2 -1) ===================================================== Summary of modified files ===================================================== File: radiusd/raddb/eap.conf Revisions: 1.2 Authors: aland (+2 -2) ------------------------------- File: radiusd/src/main/xlat.c Revisions: 1.68 Authors: mgriego (+11 -5) ------------------------------- File: radiusd/src/modules/rlm_eap/types/rlm_eap_ttls/ttls.c Revisions: 1.15 Authors: aland (+2 -1) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl From freeradius-devel@lists.freeradius.org Thu Mar 18 01:55:08 2004 From: freeradius-devel@lists.freeradius.org (??) Date: Wed, 17 Mar 2004 19:55:08 CST 0008 Subject: The EAP-SIM test cases always return Failure Message-ID: <7e24e462d0dea542733fa52a45469e63@magicmail> This is a MIME encoded message. --MagicMail--52450846867180d98fe773f110c7cd3e9a332fdc3 Content-Type: text/plain; charset=iso-8895-1 Content-Transfer-Encoding: base64 SGkgYWxhbiwNCkkgZG93bmxvYWQgMy4xNiBDVlMgc25hcHNob3QsIGFuZCBpbnN0YWxsIGZyZWVy YWRpdXMgc3VjY2Vzc2Z1bGx5LiBJIHdhbnQgdG8gdGVzdCB3aGV0aGVyIEVBUC1TSU0gaXMgYWxy ZWFkeSBzdXBwb3J0ZWQuIEkgcmVwbGFjZWQgcmFkaXVzZC5jb25mIGFuZCAidXNlcnMiIHdpdGgg dGhlIGV4YW1wbGVzIGluIGVhcHNpbS0wMyBkaXJlY3RvcnkuIE9mIGNvdXJzZSB0aGUgcHJlZml4 IGRpcmVjdGl2ZSB3YXMgbW9kaWZpZWQgdG8gbXkgaW5zdGFsbGF0aW9uIGRpcmVjdG9yeS4gSG93 ZXZlciwgYWxsIG9mIHRoZSBlYXBzaW0gcmVsYXRlZCB0ZXN0cyBmYWlsZWQgd2l0aCAiRUFQLUNv ZGU9ZmFpbHVyZSIuDQpEbyB3ZSBoYXZlIGEgc3VjY2VzcyBjYXNlPyBvciBFQVAtU0lNIGlzIG5v dCBmdWxseSBzdXBwb3J0ZWQgeWV0Pw0KVGhhbmtzIQ0KU2h1cmFsCi0tDQpVU1RDIEFsdW1uaSBF bWFpbCBTeXN0ZW0gCgo= --MagicMail--52450846867180d98fe773f110c7cd3e9a332fdc3 Content-Type: text/html Content-Transfer-Encoding: base64 PEhUTUw+PGJvZHk+PFA+SGkgYWxhbiw8L1A+DQo8UD5JIGRvd25sb2FkIDMuMTYgQ1ZTIHNuYXBz aG90LCBhbmQgaW5zdGFsbCBmcmVlcmFkaXVzIHN1Y2Nlc3NmdWxseS4gSSB3YW50IHRvIHRlc3Qg d2hldGhlciBFQVAtU0lNIGlzIGFscmVhZHkgc3VwcG9ydGVkLiBJIHJlcGxhY2VkIHJhZGl1c2Qu Y29uZiBhbmQgInVzZXJzIiB3aXRoIHRoZSBleGFtcGxlcyBpbiBlYXBzaW0tMDMgZGlyZWN0b3J5 LiBPZiBjb3Vyc2UgdGhlIHByZWZpeCBkaXJlY3RpdmUgd2FzIG1vZGlmaWVkIHRvIG15IGluc3Rh bGxhdGlvbiBkaXJlY3RvcnkuIEhvd2V2ZXIsIGFsbCBvZiB0aGUgZWFwc2ltIHJlbGF0ZWQgdGVz dHMgZmFpbGVkIHdpdGggIkVBUC1Db2RlPWZhaWx1cmUiLjwvUD4NCjxQPkRvIHdlIGhhdmUgYSBz dWNjZXNzIGNhc2U/IG9yIEVBUC1TSU0gaXMgbm90IGZ1bGx5IHN1cHBvcnRlZCB5ZXQ/PC9QPg0K PFA+VGhhbmtzITwvUD4NCjxQPlNodXJhbDwvUD48L2JvZHk+PC9IVE1MPjxicj4KLS0NClVTVEMg QWx1bW5pIEVtYWlsIFN5c3RlbSA8YnI+Cjxicj4K --MagicMail--52450846867180d98fe773f110c7cd3e9a332fdc3-- From freeradius-devel@lists.freeradius.org Wed Mar 17 16:44:46 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Wed, 17 Mar 2004 11:44:46 -0500 Subject: The EAP-SIM test cases always return Failure In-Reply-To: Your message of "Wed, 17 Mar 1908 19:55:08 CST." <7e24e462d0dea542733fa52a45469e63@magicmail> Message-ID: <20040317164446.8882C16FD1@mail.nitros9.org> "??" wrote: ... Do not "CC" me on mail to the list. It's annoying. I read the list. > I download 3.16 CVS snapshot, and install freeradius successfully. I > want to test whether EAP-SIM is already supported. I replaced > radiusd.conf and "users" with the examples in eapsim-03 > directory. Of course the prefix directive was modified to my > installation directory. However, all of the eapsim related tests > failed with "EAP-Code=failure". So run the server in debugging mode to see why. > Do we have a success case? or EAP-SIM is not fully supported yet? It's supported, and verified to work. Alan DeKok. From freeradius-devel@lists.freeradius.org Thu Mar 18 09:02:42 2004 From: freeradius-devel@lists.freeradius.org (Automatic cvs log generator) Date: Thu, 18 Mar 2004 03:02:42 -0600 (CST) Subject: Automatic report from sources (radiusd) between 17.03.2004 - 18.03.2004 GMT Message-ID: <20040318090242.C7B877745C@webhost1.starnetusa.net> CVS log entries from 17.03.2004 (Wed) 09:00:01 - 18.03.2004 (Thu) 09:00:01 GMT ===================================================== Summary by authors ===================================================== Author: pnixon File: radiusd/suse/freeradius.spec; Revisions: 1.10 ===================================================== Log entries ===================================================== Description: Update to SuSE build files to include files in /etc/raddb/certs/ Modified files: File: radiusd/suse/freeradius.spec; Revision: 1.10; Date: 2004/03/17 21:24:26; Author: pnixon; Lines: (+20 -0) ===================================================== Summary of modified files ===================================================== File: radiusd/suse/freeradius.spec Revisions: 1.10 Authors: pnixon (+20 -0) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl From freeradius-devel@lists.freeradius.org Thu Mar 18 19:02:05 2004 From: freeradius-devel@lists.freeradius.org (Daniel Carroll) Date: Thu, 18 Mar 2004 12:02:05 -0700 Subject: Patch for rlm_ldap - access_attr_used_for_allow enhancement Message-ID: <20040318190205.GA30374@mesastate.edu> Hello, Are ehnancements to Freeradius still being accepted, or are bugfixes the only submissions being considered until FreeRadius 1.0.0 is released? The following patch extends the semantics of access_attr_used_for_allow. The default behaviour is the same (when it's set to "no" or "yes"), but the new setting ("parent") will make the server query the parent container for access_attr if it isn't defined in the user's object. The default value remains the same ("yes"). This patch also updates the documentation to describe the new setting. The motivation for this patch is that it allows adminstrators in Novell Netware shops to swap out Novell's radius server for FreeRadius without needing to restructure data in NDS (Novell's Directory Service -- which can be "exported" to LDAP) to get the same behaviour under FreeRadius. This patch is similar to one that I submitted a little over a year ago (against freeradius-0.8.1), except that: - This is a diff against the CVS version of freeradius from two or three days ago. - The objection to the prior patch was that it could recursively search to the top of the LDAP tree, looking for the first occurrence of access_attr. This version checks only the user object itself, and then the container object if access_attr_used_for_allow is set to "parent" and the user object doesn't have access_attr set. If it helps at all, I've been running on the the old patch (from a year ago) for about a year now without problems. The new patch below I am currently using without problems as well, but it has been in production for only a few days. Thanks! - Dan (Daniel Carroll - Mesa State College) diff -ru freeradius-cvs20040316/doc/rlm_ldap build-fr/doc/rlm_ldap --- freeradius-cvs20040316/doc/rlm_ldap Wed Dec 3 07:32:42 2003 +++ build-fr/doc/rlm_ldap Thu Mar 18 11:34:05 2004 @@ -144,19 +144,27 @@ # # profile_attribute = "radiusProfileDn" -# access_attr_used_for_allow: Define if the access attribute (described -# below) will be used to allow access (meaning if it exists then user -# remote access will be allowed) or to deny access. default: yes - used -# to allow access +# access_attr_used_for_allow: no/yes/parent +# Define if the access attribute (described below) will be used to allow +# access (meaning if it exists then user remote access will be allowed) +# or to deny access. +# +# default: yes - used to allow access -# access_attr: if attribute is specified, module checks for its -# existance in user object. If access_attr_used_for_allow is set to -# yes: If it exists the user is allowed to get remote access. If it -# exists and is set to FALSE the user is denied remote access. If it -# does not exist user is denied remote access by default if -# access_attr_used_for_allow is set to no: If it exists the user is -# denied remote access. If it does not exist user is allowed remote -# access. +# access_attr: if this attribute is specified, the module checks for its +# existance in the user object. +# If access_attr_used_for_allow is set to no: +# If access_attr does not exist user is allowed remote access. +# If access_attr exists the user is denied remote access. +# If access_attr_used_for_allow is set to yes: +# If access_attr does not exist user is denied remote access. +# If access_attr exists and is set to FALSE, the user is denied +# remote access. +# If access_attr exists the user is allowed remote access. +# If access_attr_used_for_allow is set to parent: +# Similar to access_attr_used_for_allow = yes, except +# that the container object is checked for access_attr +# if it isn't set in the user or profile object. # # default: NULL - don't check for the attribute diff -ru freeradius-cvs20040316/src/modules/rlm_ldap/rlm_ldap.c build-fr/src/modules/rlm_ldap/rlm_ldap.c --- freeradius-cvs20040316/src/modules/rlm_ldap/rlm_ldap.c Sun Feb 29 06:55:08 2004 +++ build-fr/src/modules/rlm_ldap/rlm_ldap.c Thu Mar 18 10:40:23 2004 @@ -251,9 +251,10 @@ int num_conns; int do_comp; int do_xlat; - int default_allow; int failed_conns; int is_url; + int search_parent; + char *default_allow; char *login; char *password; char *filter; @@ -320,7 +321,7 @@ {"ldap_debug", PW_TYPE_INTEGER, offsetof(ldap_instance,ldap_debug), NULL, "0x0000"}, {"ldap_connections_number", PW_TYPE_INTEGER, offsetof(ldap_instance,num_conns), NULL, "5"}, {"compare_check_items", PW_TYPE_BOOLEAN, offsetof(ldap_instance,do_comp), NULL, "no"}, - {"access_attr_used_for_allow", PW_TYPE_BOOLEAN, offsetof(ldap_instance,default_allow), NULL, "yes"}, + {"access_attr_used_for_allow", PW_TYPE_STRING_PTR, offsetof(ldap_instance,default_allow), NULL, "yes"}, {"do_xlat", PW_TYPE_BOOLEAN, offsetof(ldap_instance,do_xlat), NULL, "yes"}, {NULL, -1, 0, NULL, NULL} @@ -338,6 +339,7 @@ static int ldap_xlat(void *,REQUEST *, char *, char *,int, RADIUS_ESCAPE_STRING); static LDAP *ldap_connect(void *instance, const char *, const char *, int, int *); static int read_mappings(ldap_instance* inst); +static int ldap_evalpermissions(ldap_instance *, char *, LDAP_CONN *, char *, int); static inline int ldap_get_conn(LDAP_CONN *conns,LDAP_CONN **ret,void *instance) { @@ -407,6 +409,33 @@ } #endif + /* Validate the parameter, and make the first char lower-case */ + if (inst->default_allow == NULL) { + inst->default_allow = strdup("yes"); + if (inst->default_allow == NULL) { + radlog(L_ERR, "rlm_ldap: Could not allocate memory. Aborting."); + free(inst); + return -1; + } + } + else if (!strcasecmp(inst->default_allow, "yes")) { + inst->default_allow[0] = 'y'; + inst->search_parent = 0; + } + else if (!strcasecmp(inst->default_allow, "no")) { + inst->default_allow[0] = 'n'; + inst->search_parent = 0; + } + else if (!strcasecmp(inst->default_allow, "parent")) { + inst->default_allow[0] = 'p'; + inst->search_parent = 1; + } + else { + radlog(L_ERR, "rlm_ldap: unrecognized access_attr_used_for_allow value."); + free(inst); + return -1; + } + inst->timeout.tv_usec = 0; inst->net_timeout.tv_usec = 0; /* workaround for servers which support LDAPS but not START TLS */ @@ -744,6 +773,121 @@ return len; } + /* + * + * ldap_evalpermissions() + * Based on how the LDAP module has been configured, evaluate + * whether or not a particular object (user) has been granted + * authorization + * + * + */ + +static int +ldap_evalpermissions(ldap_instance *inst, char *basedn, LDAP_CONN *conn, char *user, int query_parent) +{ + char **vals; + int res; + int access_fate; + char *attrs[] = {NULL,NULL}; + LDAPMessage *result; + LDAPMessage *msg; + + + /* Quick sanity check */ + if ((inst == NULL) || (basedn == NULL) || (conn == NULL) || (inst->access_attr == NULL)) { + radlog(L_ERR, "rlm_ldap: unexpected NULL parameter passed to ldap_evalpermissions()"); + return RLM_MODULE_FAIL; + } + + DEBUG("rlm_ldap: Checking %s for access permission", basedn); + access_fate = RLM_MODULE_OK; + attrs[0] = inst->access_attr; + if ((res = perform_search(inst, conn, basedn, LDAP_SCOPE_BASE, NULL, attrs, &result)) != RLM_MODULE_OK) { + /* If we end up here, the basedn was supposed to be valid! Complain. */ + radlog(L_ERR, "rlm_ldap: base search unexpectedly failed"); + return RLM_MODULE_FAIL; + } + if ((msg = ldap_first_entry(conn->ld, result)) == NULL) { + DEBUG("rlm_ldap: ldap_first_entry() failed"); + ldap_msgfree(result); + return RLM_MODULE_FAIL; + } + + /* Does the access_attr exist? If so, we're done searching */ + if ((vals = ldap_get_values(conn->ld, msg, inst->access_attr)) != NULL) { + if (inst->default_allow[0] != 'n') { + DEBUG("rlm_ldap: checking if remote access for %s is allowed by %s", user, inst->access_attr); + if (!strncmp(vals[0], "FALSE", 5)) { + DEBUG("rlm_ldap: dialup access disabled"); + access_fate = RLM_MODULE_USERLOCK; + } + } + else { + /* default_allow == "no" */ + DEBUG("rlm_ldap: %s attribute exists - access denied by default", inst->access_attr); + access_fate = RLM_MODULE_USERLOCK; + } + ldap_value_free(vals); + ldap_msgfree(result); + + return access_fate; + } + else if (query_parent == 0) { + if (inst->default_allow[0] != 'n') { + /* default_allow is set to "yes" or "parent" */ + DEBUG("rlm_ldap: no %s attribute found - access denied by default", inst->access_attr); + access_fate = RLM_MODULE_USERLOCK; + } + ldap_msgfree(result); + + return access_fate; + } + + /* + * If we reach here, default_allow is set to "parent", + * and the access_attr was not defined on the object. So we + * need to search higher in the LDAP tree for the attribute, + * or deny access if we reach the top without finding the + * attribute lower in the tree. + */ + + ldap_msgfree(result); + + /* + * We've reached the top of the LDAP tree. The access_attr was + * not found. Return an "access denied" result. + */ + if (*basedn == '\0') { + DEBUG("rlm_ldap: no %s attribute found in tree search on %s - access denied by default", + inst->access_attr, user); + return RLM_MODULE_USERLOCK; + } + + /* + * Determine the next higher object in the LDAP tree, and + * recursively search starting with that. + * + * A ',' is the separator between tree levels, correct? + */ + while ((*basedn != '\0') && !(*basedn == ',')) { + /* This is to step over 'escaped' characters */ + if (*basedn == '\\') + basedn++; + + if (*basedn != '\0') + basedn++; + } + + /* Step over the comma... */ + if (*basedn != '\0') + basedn++; + + /* Query the parent object */ + return ldap_evalpermissions(inst, basedn, conn, user, 0); +} + + /* * ldap_groupcmp(). Implement the Ldap-Group == "group" filter */ @@ -1132,48 +1276,25 @@ * given username */ pairadd(&request->packet->vps, pairmake("Ldap-UserDn", user_dn, T_OP_EQ)); - ldap_memfree(user_dn); - /* Remote access is controled by attribute of the user object */ if (inst->access_attr) { - if ((vals = ldap_get_values(conn->ld, msg, inst->access_attr)) != NULL) { - if (inst->default_allow){ - DEBUG("rlm_ldap: checking if remote access for %s is allowed by %s", request->username->strvalue, inst->access_attr); - if (!strncmp(vals[0], "FALSE", 5)) { - DEBUG("rlm_ldap: dialup access disabled"); - snprintf(module_fmsg,sizeof(module_fmsg),"rlm_ldap: Access Attribute denies access"); - module_fmsg_vp = pairmake("Module-Failure-Message", module_fmsg, T_OP_EQ); - pairadd(&request->packet->vps, module_fmsg_vp); - ldap_msgfree(result); - ldap_value_free(vals); - ldap_release_conn(conn_id,inst->conns); - return RLM_MODULE_USERLOCK; - } - ldap_value_free(vals); - } - else{ - DEBUG("rlm_ldap: %s attribute exists - access denied by default", inst->access_attr); - snprintf(module_fmsg,sizeof(module_fmsg),"rlm_ldap: Access Attribute denies access"); - module_fmsg_vp = pairmake("Module-Failure-Message", module_fmsg, T_OP_EQ); - pairadd(&request->packet->vps, module_fmsg_vp); - ldap_msgfree(result); - ldap_value_free(vals); - ldap_release_conn(conn_id,inst->conns); - return RLM_MODULE_USERLOCK; - } - } else { - if (inst->default_allow){ - DEBUG("rlm_ldap: no %s attribute - access denied by default", inst->access_attr); + if ((res = ldap_evalpermissions(inst, user_dn, conn, request->username->strvalue, + inst->search_parent)) != RLM_MODULE_OK) { + ldap_memfree(user_dn); + ldap_msgfree(result); + ldap_release_conn(conn_id,inst->conns); + if (res == RLM_MODULE_USERLOCK) { + snprintf(module_fmsg,sizeof(module_fmsg),"rlm_ldap: Access Attribute denies access"); module_fmsg_vp = pairmake("Module-Failure-Message", module_fmsg, T_OP_EQ); pairadd(&request->packet->vps, module_fmsg_vp); - ldap_msgfree(result); - ldap_release_conn(conn_id,inst->conns); - return RLM_MODULE_USERLOCK; + return res; } + return RLM_MODULE_FAIL; } } + ldap_memfree(user_dn); /* * Check for the default profile entry. If it exists then add the @@ -1742,6 +1863,8 @@ free((char *) inst->access_attr); if (inst->profile_attr) free((char *) inst->profile_attr); + if (inst->default_allow) + free((char *) inst->default_allow); if (inst->conns){ int i=0; From freeradius-devel@lists.freeradius.org Fri Mar 19 02:19:37 2004 From: freeradius-devel@lists.freeradius.org (Michael Richardson) Date: Thu, 18 Mar 2004 21:19:37 -0500 Subject: (no subject) Message-ID: <9030.1079662777@marajade.sandelman.ottawa.on.ca> Alan, I was looking at warnings in rlm_eap, and I think this is what was meant: === cd /corp/projects/nic.at/radiusd/src/modules/rlm_eap/libeap/ === /usr/bin/cvs diff -u eapcommon.c Index: eapcommon.c =================================================================== RCS file: /source/radiusd/src/modules/rlm_eap/libeap/eapcommon.c,v retrieving revision 1.4 diff -u -r1.4 eapcommon.c --- eapcommon.c 26 Feb 2004 19:04:29 -0000 1.4 +++ eapcommon.c 19 Mar 2004 02:19:12 -0000 @@ -131,7 +131,7 @@ snprintf(buffer, buflen, "%d", type); return buffer; - } else if ((eap_types[type] >= '0') && (eap_types[type] <= '9')) { + } else if ((*eap_types[type] >= '0') && (*eap_types[type] <= '9')) { /* * Prefer the dictionary name, if it exists. */ === Exit status: 1 I also cleaned up lots of signed/unsigned warnings on loop variables. -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ From freeradius-devel@lists.freeradius.org Fri Mar 19 08:59:28 2004 From: freeradius-devel@lists.freeradius.org (Wolfgang Hottgenroth) Date: Fri, 19 Mar 2004 09:59:28 +0100 Subject: Missing free() in rlm_dbm? Message-ID: Hi, I've asked this question on the users list few days ago but noticed the existence of this devel list just today. Certainly this question better belongs to this audience. I have copied and tweaked the module rlm_dbm to support Bernstein's CDB as backend. Wasn't hard and seems to work, I've just "emulated" dbm_open, dbm_fetch and dbm_close. But I'm wondering whether there is a free() call missing in the original rlm_dbm.c. The manpage of dbm_fetch states that the dptr is allocated using malloc and the dbm (or gdbm or ndbm) will not free it but the programmer is responsible to free it on its own: To search for some data: content = gdbm_fetch ( dbf, key ) Dbf is the pointer returned by gdbm_open. Key is the key data. If the dptr element of the return value is NULL, no data was found. Otherwise the return value is a pointer to the found data. The storage space for the dptr element is allocated using malloc(3C). Gdbm does not automatically free this data. It is the programmer's responsibility to free this storage when it is no longer needed. Now, I see the dbm_fetch (d = dbm_fetch(...), then a lot of userparse(), pairmove(), pairfree(). But if I've learned correctly from lib/valuepair.c, attribute names and values will be copied from the string supplied to userparse(). And then, finally, I see no free(d.dptr). Is it actually missing or am I off the track? Thanks, Wolfgang From freeradius-devel@lists.freeradius.org Fri Mar 19 09:02:41 2004 From: freeradius-devel@lists.freeradius.org (Automatic cvs log generator) Date: Fri, 19 Mar 2004 03:02:41 -0600 (CST) Subject: Automatic report from sources (radiusd) between 18.03.2004 - 19.03.2004 GMT Message-ID: <20040319090241.C4E4F77460@webhost1.starnetusa.net> CVS log entries from 18.03.2004 (Thu) 09:00:01 - 19.03.2004 (Fri) 09:00:01 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/src/modules/rlm_attr_rewrite/rlm_attr_rewrite.c; Revisions: 1.20, 1.19 Author: mcr File: radiusd/src/tests/eapsim-03/eapsim-cooked.txt; Revisions: 1.5 File: radiusd/src/tests/eapsim-04/eapsim-cooked.txt; Revisions: 1.3 File: radiusd/src/tests/eapsim-05/eapsim-cooked.txt; Revisions: 1.2 File: radiusd/src/tests/eapsim-06/eapsim-cooked.txt; Revisions: 1.2 File: radiusd/src/tests/eapsim-03/eapsim-out.txt; Revisions: 1.5 File: radiusd/src/tests/eapsim-05/eapsim-in.txt; Revisions: 1.2 File: radiusd/src/tests/eapsim-05/eapsim-out.txt; Revisions: 1.2 File: radiusd/src/tests/eapsim-06/eapsim-out.txt; Revisions: 1.2 File: radiusd/src/tests/eapsim-03/users-example.txt; Revisions: 1.4 File: radiusd/src/tests/eapsim-03/eapsim-sanitize.sed; Revisions: 1.2 File: radiusd/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c; Revisions: 1.20 File: radiusd/src/modules/rlm_eap/libeap/eapcommon.c; Revisions: 1.5 File: radiusd/src/tests/eapsim-05/eapsim-raw.txt; Revisions: 1.2 File: radiusd/src/tests/eapsim-06/eapsim-raw.txt; Revisions: 1.2 File: radiusd/src/modules/rlm_eap/types/rlm_eap_ttls/ttls.c; Revisions: 1.16 File: radiusd/src/modules/rlm_eap/state.c; Revisions: 1.10 File: radiusd/src/modules/rlm_eap/types/rlm_eap_sim/rlm_eap_sim.c; Revisions: 1.12 Author: pnixon File: radiusd/src/billing/pgsql-voip.conf; Revisions: 1.8, 1.7, 1.6 File: radiusd/src/billing/README; Revisions: 1.5, 1.4, 1.3 File: radiusd/src/billing/cisco_h323_db_schema-postgres.sql; Revisions: 1.11, 1.10, 1.9, 1.8 ===================================================== Combined list of identical log entries ===================================================== Description: signed/unsigned fixes. also put () around one expression, since it looks like it was not meant to be default precedence. Modified files: File: radiusd/src/modules/rlm_eap/state.c; Revision: 1.10; Date: 2004/03/19 02:22:16; Author: mcr; Lines: (+4 -4) File: radiusd/src/modules/rlm_eap/libeap/eapcommon.c; Revision: 1.5; Date: 2004/03/19 02:22:19; Author: mcr; Lines: (+3 -3) File: radiusd/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c; Revision: 1.20; Date: 2004/03/19 02:22:20; Author: mcr; Lines: (+2 -2) File: radiusd/src/modules/rlm_eap/types/rlm_eap_ttls/ttls.c; Revision: 1.16; Date: 2004/03/19 02:22:23; Author: mcr; Lines: (+2 -2) ------------------------------- Description: Changed StopTelephony column h323RemoteAddress from BOOL to INET to fix compatibility problems between tables Modified files: File: radiusd/src/billing/cisco_h323_db_schema-postgres.sql; Revision: 1.8; Date: 2004/03/18 13:00:18; Author: pnixon; Lines: (+1 -1) File: radiusd/src/billing/pgsql-voip.conf; Revision: 1.6; Date: 2004/03/18 13:00:18; Author: pnixon; Lines: (+1 -1) ------------------------------- Description: Change CiscoNASPort from BOOL to Varchar(1) to fix compatibility problems Modified files: File: radiusd/src/billing/cisco_h323_db_schema-postgres.sql; Revision: 1.9; Date: 2004/03/18 14:30:36; Author: pnixon; Lines: (+1 -1) File: radiusd/src/billing/pgsql-voip.conf; Revision: 1.7; Date: 2004/03/18 14:30:36; Author: pnixon; Lines: (+1 -1) ------------------------------- Description: as a result of incrementing the EAP-id each time, the cryptographic results have changed. Modified files: File: radiusd/src/tests/eapsim-03/eapsim-cooked.txt; Revision: 1.5; Date: 2004/03/19 02:21:08; Author: mcr; Lines: (+27 -87) File: radiusd/src/tests/eapsim-03/eapsim-out.txt; Revision: 1.5; Date: 2004/03/19 02:21:08; Author: mcr; Lines: (+27 -87) File: radiusd/src/tests/eapsim-03/eapsim-sanitize.sed; Revision: 1.2; Date: 2004/03/19 02:21:09; Author: mcr; Lines: (+11 -0) File: radiusd/src/tests/eapsim-03/users-example.txt; Revision: 1.4; Date: 2004/03/19 02:21:09; Author: mcr; Lines: (+12 -0) File: radiusd/src/tests/eapsim-04/eapsim-cooked.txt; Revision: 1.3; Date: 2004/03/19 02:21:10; Author: mcr; Lines: (+54 -87) File: radiusd/src/tests/eapsim-05/eapsim-cooked.txt; Revision: 1.2; Date: 2004/03/19 02:21:12; Author: mcr; Lines: (+16 -88) File: radiusd/src/tests/eapsim-05/eapsim-in.txt; Revision: 1.2; Date: 2004/03/19 02:21:12; Author: mcr; Lines: (+0 -2) File: radiusd/src/tests/eapsim-05/eapsim-out.txt; Revision: 1.2; Date: 2004/03/19 02:21:12; Author: mcr; Lines: (+42 -123) File: radiusd/src/tests/eapsim-05/eapsim-raw.txt; Revision: 1.2; Date: 2004/03/19 02:21:12; Author: mcr; Lines: (+63 -135) File: radiusd/src/tests/eapsim-06/eapsim-cooked.txt; Revision: 1.2; Date: 2004/03/19 02:21:14; Author: mcr; Lines: (+30 -31) File: radiusd/src/tests/eapsim-06/eapsim-out.txt; Revision: 1.2; Date: 2004/03/19 02:21:14; Author: mcr; Lines: (+30 -31) File: radiusd/src/tests/eapsim-06/eapsim-raw.txt; Revision: 1.2; Date: 2004/03/19 02:21:14; Author: mcr; Lines: (+71 -72) ===================================================== Log entries ===================================================== Description: Fix spelling error Modified files: File: radiusd/src/billing/README; Revision: 1.5; Date: 2004/03/18 21:03:55; Author: pnixon; Lines: (+2 -2) ------------------------------- Description: update ID tag Modified files: File: radiusd/src/billing/README; Revision: 1.4; Date: 2004/03/18 21:03:14; Author: pnixon; Lines: (+1 -1) ------------------------------- Description: Update the documentation to make it easier to understand. Include info about VSA configs on Cisco Modified files: File: radiusd/src/billing/README; Revision: 1.3; Date: 2004/03/18 20:26:00; Author: pnixon; Lines: (+24 -13) ------------------------------- Description: Add alternate index as a comment to support stupid cisco SIP softswitches Modified files: File: radiusd/src/billing/cisco_h323_db_schema-postgres.sql; Revision: 1.11; Date: 2004/03/18 21:04:43; Author: pnixon; Lines: (+7 -0) ------------------------------- Description: Change all CalledID and CallingID fields to VARCHAR(80) to support Cisco CSPS (SIP Softswitch) which has stupidly long strings in the form of "sip:001212223304@csps.domain.com>;tag=5963C650-1BD". WooHoo.. We now support SIP billing as well as H323 :-) Modified files: File: radiusd/src/billing/cisco_h323_db_schema-postgres.sql; Revision: 1.10; Date: 2004/03/18 14:37:02; Author: pnixon; Lines: (+8 -8) ------------------------------- Description: Change config name from "sql" to "pgsql-voip" to allow loading alongside an existing sql config Modified files: File: radiusd/src/billing/pgsql-voip.conf; Revision: 1.8; Date: 2004/03/18 18:27:36; Author: pnixon; Lines: (+1 -1) ------------------------------- Description: Don't de-reference proxy when asked to look at proxy reply, and vice-versa Modified files: File: radiusd/src/modules/rlm_attr_rewrite/rlm_attr_rewrite.c; Revision: 1.20; Date: 2004/03/18 15:56:50; Author: aland; Lines: (+4 -4) ------------------------------- Description: No proxy packet or proxy reply, don't do anything Modified files: File: radiusd/src/modules/rlm_attr_rewrite/rlm_attr_rewrite.c; Revision: 1.19; Date: 2004/03/18 15:39:13; Author: aland; Lines: (+6 -2) ------------------------------- Description: increment the EAP-id on each stage of the transaction. Modified files: File: radiusd/src/modules/rlm_eap/types/rlm_eap_sim/rlm_eap_sim.c; Revision: 1.12; Date: 2004/03/19 02:20:35; Author: mcr; Lines: (+36 -2) ===================================================== Summary of modified files ===================================================== File: radiusd/src/billing/README Revisions: 1.5, 1.4, 1.3 Authors: pnixon (+2 -2), pnixon (+1 -1), pnixon (+24 -13) ------------------------------- File: radiusd/src/billing/cisco_h323_db_schema-postgres.sql Revisions: 1.11, 1.10, 1.9, 1.8 Authors: pnixon (+7 -0), pnixon (+8 -8), pnixon (+1 -1), pnixon (+1 -1) ------------------------------- File: radiusd/src/billing/pgsql-voip.conf Revisions: 1.8, 1.7, 1.6 Authors: pnixon (+1 -1), pnixon (+1 -1), pnixon (+1 -1) ------------------------------- File: radiusd/src/modules/rlm_attr_rewrite/rlm_attr_rewrite.c Revisions: 1.20, 1.19 Authors: aland (+4 -4), aland (+6 -2) ------------------------------- File: radiusd/src/modules/rlm_eap/libeap/eapcommon.c Revisions: 1.5 Authors: mcr (+3 -3) ------------------------------- File: radiusd/src/modules/rlm_eap/state.c Revisions: 1.10 Authors: mcr (+4 -4) ------------------------------- File: radiusd/src/modules/rlm_eap/types/rlm_eap_sim/rlm_eap_sim.c Revisions: 1.12 Authors: mcr (+36 -2) ------------------------------- File: radiusd/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c Revisions: 1.20 Authors: mcr (+2 -2) ------------------------------- File: radiusd/src/modules/rlm_eap/types/rlm_eap_ttls/ttls.c Revisions: 1.16 Authors: mcr (+2 -2) ------------------------------- File: radiusd/src/tests/eapsim-03/eapsim-cooked.txt Revisions: 1.5 Authors: mcr (+27 -87) ------------------------------- File: radiusd/src/tests/eapsim-03/eapsim-out.txt Revisions: 1.5 Authors: mcr (+27 -87) ------------------------------- File: radiusd/src/tests/eapsim-03/eapsim-sanitize.sed Revisions: 1.2 Authors: mcr (+11 -0) ------------------------------- File: radiusd/src/tests/eapsim-03/users-example.txt Revisions: 1.4 Authors: mcr (+12 -0) ------------------------------- File: radiusd/src/tests/eapsim-04/eapsim-cooked.txt Revisions: 1.3 Authors: mcr (+54 -87) ------------------------------- File: radiusd/src/tests/eapsim-05/eapsim-cooked.txt Revisions: 1.2 Authors: mcr (+16 -88) ------------------------------- File: radiusd/src/tests/eapsim-05/eapsim-in.txt Revisions: 1.2 Authors: mcr (+0 -2) ------------------------------- File: radiusd/src/tests/eapsim-05/eapsim-out.txt Revisions: 1.2 Authors: mcr (+42 -123) ------------------------------- File: radiusd/src/tests/eapsim-05/eapsim-raw.txt Revisions: 1.2 Authors: mcr (+63 -135) ------------------------------- File: radiusd/src/tests/eapsim-06/eapsim-cooked.txt Revisions: 1.2 Authors: mcr (+30 -31) ------------------------------- File: radiusd/src/tests/eapsim-06/eapsim-out.txt Revisions: 1.2 Authors: mcr (+30 -31) ------------------------------- File: radiusd/src/tests/eapsim-06/eapsim-raw.txt Revisions: 1.2 Authors: mcr (+71 -72) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl From freeradius-devel@lists.freeradius.org Fri Mar 19 10:25:39 2004 From: freeradius-devel@lists.freeradius.org (Andrei Koulik) Date: Fri, 19 Mar 2004 13:25:39 +0300 Subject: Missing free() in rlm_dbm? In-Reply-To: References: Message-ID: <13469493396.20040319132539@sci-nnov.ru> I plan remake the rlm_dbm module to remove database specified routines to standalone library. This library will provide independent interface to work with associative (key-value) database. I think it is good idea to make that library is available for all modules (system-wide) and configure once in main script. It is not need to free memory after call dbm_fetch function (FreeBSD) I think it is specified for gdbm implementation. Friday, March 19, 2004, 11:59:28 AM, Wolfgang Hottgenroth wrote: WH> Hi, WH> I've asked this question on the users list few days ago but noticed WH> the existence of this devel list just today. Certainly this question WH> better belongs to this audience. WH> I have copied and tweaked the module rlm_dbm to support Bernstein's WH> CDB as backend. Wasn't hard and seems to work, I've just "emulated" WH> dbm_open, dbm_fetch and dbm_close. WH> But I'm wondering whether there is a free() call missing in the WH> original rlm_dbm.c. The manpage of dbm_fetch states that the dptr is WH> allocated using malloc and the dbm (or gdbm or ndbm) will not free it WH> but the programmer is responsible to free it on its own: WH> To search for some data: WH> content =3D gdbm_fetch ( dbf, key ) WH> Dbf is the pointer returned by gdbm_open. Key is the key WH> data. WH> If the dptr element of the return value is NULL, no data was WH> found. Otherwise the return value is a pointer to the found WH> data. The storage space for the dptr element is allocated WH> using malloc(3C). Gdbm does not automatically free this WH> data. It is the programmer's responsibility to free this WH> storage when it is no longer needed. WH> Now, I see the dbm_fetch (d =3D dbm_fetch(...), then a lot of userpar= se(), pairmove(), WH> pairfree(). But if I've learned correctly from lib/valuepair.c, WH> attribute names and values will be copied from the string supplied to WH> userparse(). WH> And then, finally, I see no free(d.dptr). Is it actually missing or a= m WH> I off the track? WH> Thanks, WH> Wolfgang WH> -=20 WH> List info/subscribe/unsubscribe? See WH> http://www.freeradius.org/list/devel.html --=20 Andrei Koulik. System administrator, Sandy Info Ltd. (ISP), Nizhny Novgorod, Russia From freeradius-devel@lists.freeradius.org Fri Mar 19 14:12:29 2004 From: freeradius-devel@lists.freeradius.org (Kostas Kalevras) Date: Fri, 19 Mar 2004 16:12:29 +0200 (EET) Subject: Patch for rlm_ldap - access_attr_used_for_allow enhancement In-Reply-To: <20040318190205.GA30374@mesastate.edu> References: <20040318190205.GA30374@mesastate.edu> Message-ID: <20040319130025.D36464@ajax.noc.ntua.gr> On Thu, 18 Mar 2004, Daniel Carroll wrote: > Hello, > > Are ehnancements to Freeradius still being accepted, or are bugfixes > the only submissions being considered until FreeRadius 1.0.0 is released? > > > The following patch extends the semantics of access_attr_used_for_allow. > The default behaviour is the same (when it's set to "no" or "yes"), but > the new setting ("parent") will make the server query the parent container > for access_attr if it isn't defined in the user's object. The default > value remains the same ("yes"). This patch also updates the documentation > to describe the new setting. > > The motivation for this patch is that it allows adminstrators in Novell > Netware shops to swap out Novell's radius server for FreeRadius without > needing to restructure data in NDS (Novell's Directory Service -- which > can be "exported" to LDAP) to get the same behaviour under FreeRadius. Could you give more details on that? Why is it necessary to add such a feature? What's the problem with setting access_attr_used_for_allow to 'no' and adding a FALSE access attribute only to the entries you want to lock? As for the patch itself read forward: > > This patch is similar to one that I submitted a little over a year > ago (against freeradius-0.8.1), except that: > - This is a diff against the CVS version of freeradius from two or > three days ago. > - The objection to the prior patch was that it could recursively > search to the top of the LDAP tree, looking for the first > occurrence of access_attr. This version checks only the user > object itself, and then the container object if > access_attr_used_for_allow is set to "parent" and the user > object doesn't have access_attr set. > > If it helps at all, I've been running on the the old patch (from a > year ago) for about a year now without problems. The new patch > below I am currently using without problems as well, but it has > been in production for only a few days. > > Thanks! > > - Dan (Daniel Carroll - Mesa State College) > > > > diff -ru freeradius-cvs20040316/doc/rlm_ldap build-fr/doc/rlm_ldap > --- freeradius-cvs20040316/doc/rlm_ldap Wed Dec 3 07:32:42 2003 > +++ build-fr/doc/rlm_ldap Thu Mar 18 11:34:05 2004 > @@ -144,19 +144,27 @@ > # > # profile_attribute = "radiusProfileDn" > > -# access_attr_used_for_allow: Define if the access attribute (described > -# below) will be used to allow access (meaning if it exists then user > -# remote access will be allowed) or to deny access. default: yes - used > -# to allow access > +# access_attr_used_for_allow: no/yes/parent > +# Define if the access attribute (described below) will be used to allow > +# access (meaning if it exists then user remote access will be allowed) > +# or to deny access. > +# > +# default: yes - used to allow access > > -# access_attr: if attribute is specified, module checks for its > -# existance in user object. If access_attr_used_for_allow is set to > -# yes: If it exists the user is allowed to get remote access. If it > -# exists and is set to FALSE the user is denied remote access. If it > -# does not exist user is denied remote access by default if > -# access_attr_used_for_allow is set to no: If it exists the user is > -# denied remote access. If it does not exist user is allowed remote > -# access. > +# access_attr: if this attribute is specified, the module checks for its > +# existance in the user object. > +# If access_attr_used_for_allow is set to no: > +# If access_attr does not exist user is allowed remote access. > +# If access_attr exists the user is denied remote access. > +# If access_attr_used_for_allow is set to yes: > +# If access_attr does not exist user is denied remote access. > +# If access_attr exists and is set to FALSE, the user is denied > +# remote access. > +# If access_attr exists the user is allowed remote access. > +# If access_attr_used_for_allow is set to parent: > +# Similar to access_attr_used_for_allow = yes, except > +# that the container object is checked for access_attr > +# if it isn't set in the user or profile object. > # > # default: NULL - don't check for the attribute > > diff -ru freeradius-cvs20040316/src/modules/rlm_ldap/rlm_ldap.c build-fr/src/modules/rlm_ldap/rlm_ldap.c > --- freeradius-cvs20040316/src/modules/rlm_ldap/rlm_ldap.c Sun Feb 29 06:55:08 2004 > +++ build-fr/src/modules/rlm_ldap/rlm_ldap.c Thu Mar 18 10:40:23 2004 > @@ -251,9 +251,10 @@ > int num_conns; > int do_comp; > int do_xlat; > - int default_allow; > int failed_conns; > int is_url; > + int search_parent; > + char *default_allow; > char *login; > char *password; > char *filter; > @@ -320,7 +321,7 @@ > {"ldap_debug", PW_TYPE_INTEGER, offsetof(ldap_instance,ldap_debug), NULL, "0x0000"}, > {"ldap_connections_number", PW_TYPE_INTEGER, offsetof(ldap_instance,num_conns), NULL, "5"}, > {"compare_check_items", PW_TYPE_BOOLEAN, offsetof(ldap_instance,do_comp), NULL, "no"}, > - {"access_attr_used_for_allow", PW_TYPE_BOOLEAN, offsetof(ldap_instance,default_allow), NULL, "yes"}, > + {"access_attr_used_for_allow", PW_TYPE_STRING_PTR, offsetof(ldap_instance,default_allow), NULL, "yes"}, > {"do_xlat", PW_TYPE_BOOLEAN, offsetof(ldap_instance,do_xlat), NULL, "yes"}, > > {NULL, -1, 0, NULL, NULL} > @@ -338,6 +339,7 @@ > static int ldap_xlat(void *,REQUEST *, char *, char *,int, RADIUS_ESCAPE_STRING); > static LDAP *ldap_connect(void *instance, const char *, const char *, int, int *); > static int read_mappings(ldap_instance* inst); > +static int ldap_evalpermissions(ldap_instance *, char *, LDAP_CONN *, char *, int); > > static inline int ldap_get_conn(LDAP_CONN *conns,LDAP_CONN **ret,void *instance) > { > @@ -407,6 +409,33 @@ > } > #endif > > + /* Validate the parameter, and make the first char lower-case */ > + if (inst->default_allow == NULL) { > + inst->default_allow = strdup("yes"); > + if (inst->default_allow == NULL) { > + radlog(L_ERR, "rlm_ldap: Could not allocate memory. Aborting."); > + free(inst); > + return -1; > + } > + } > + else if (!strcasecmp(inst->default_allow, "yes")) { > + inst->default_allow[0] = 'y'; > + inst->search_parent = 0; > + } > + else if (!strcasecmp(inst->default_allow, "no")) { > + inst->default_allow[0] = 'n'; > + inst->search_parent = 0; > + } > + else if (!strcasecmp(inst->default_allow, "parent")) { > + inst->default_allow[0] = 'p'; > + inst->search_parent = 1; > + } > + else { > + radlog(L_ERR, "rlm_ldap: unrecognized access_attr_used_for_allow value."); > + free(inst); > + return -1; > + } Why can't all these checks go to ldap_instantiate? I don't really like running them each time we need to find an ldap connection. That's why ldap_get_conn is small and inline, to run quickly. > + > inst->timeout.tv_usec = 0; > inst->net_timeout.tv_usec = 0; > /* workaround for servers which support LDAPS but not START TLS */ > @@ -744,6 +773,121 @@ > return len; > } > > + /* > + * > + * ldap_evalpermissions() > + * Based on how the LDAP module has been configured, evaluate > + * whether or not a particular object (user) has been granted > + * authorization > + * > + * > + */ > + > +static int > +ldap_evalpermissions(ldap_instance *inst, char *basedn, LDAP_CONN *conn, char *user, int query_parent) > +{ > + char **vals; > + int res; > + int access_fate; > + char *attrs[] = {NULL,NULL}; > + LDAPMessage *result; > + LDAPMessage *msg; > + > + > + /* Quick sanity check */ > + if ((inst == NULL) || (basedn == NULL) || (conn == NULL) || (inst->access_attr == NULL)) { > + radlog(L_ERR, "rlm_ldap: unexpected NULL parameter passed to ldap_evalpermissions()"); > + return RLM_MODULE_FAIL; > + } > + > + DEBUG("rlm_ldap: Checking %s for access permission", basedn); > + access_fate = RLM_MODULE_OK; > + attrs[0] = inst->access_attr; > + if ((res = perform_search(inst, conn, basedn, LDAP_SCOPE_BASE, NULL, attrs, &result)) != RLM_MODULE_OK) { > + /* If we end up here, the basedn was supposed to be valid! Complain. */ > + radlog(L_ERR, "rlm_ldap: base search unexpectedly failed"); > + return RLM_MODULE_FAIL; > + } > + if ((msg = ldap_first_entry(conn->ld, result)) == NULL) { > + DEBUG("rlm_ldap: ldap_first_entry() failed"); > + ldap_msgfree(result); > + return RLM_MODULE_FAIL; > + } The way you 've implemented the function you always add an extra unneeded search for the user dn on ldap_evalpermissions first run if I understand it correctly. That's not efficient. > + > + /* Does the access_attr exist? If so, we're done searching */ > + if ((vals = ldap_get_values(conn->ld, msg, inst->access_attr)) != NULL) { > + if (inst->default_allow[0] != 'n') { > + DEBUG("rlm_ldap: checking if remote access for %s is allowed by %s", user, inst->access_attr); > + if (!strncmp(vals[0], "FALSE", 5)) { > + DEBUG("rlm_ldap: dialup access disabled"); > + access_fate = RLM_MODULE_USERLOCK; > + } > + } > + else { > + /* default_allow == "no" */ > + DEBUG("rlm_ldap: %s attribute exists - access denied by default", inst->access_attr); > + access_fate = RLM_MODULE_USERLOCK; > + } > + ldap_value_free(vals); > + ldap_msgfree(result); > + > + return access_fate; > + } > + else if (query_parent == 0) { > + if (inst->default_allow[0] != 'n') { > + /* default_allow is set to "yes" or "parent" */ > + DEBUG("rlm_ldap: no %s attribute found - access denied by default", inst->access_attr); > + access_fate = RLM_MODULE_USERLOCK; > + } > + ldap_msgfree(result); > + > + return access_fate; > + } > + > + /* > + * If we reach here, default_allow is set to "parent", > + * and the access_attr was not defined on the object. So we > + * need to search higher in the LDAP tree for the attribute, > + * or deny access if we reach the top without finding the > + * attribute lower in the tree. > + */ > + > + ldap_msgfree(result); > + > + /* > + * We've reached the top of the LDAP tree. The access_attr was > + * not found. Return an "access denied" result. > + */ > + if (*basedn == '\0') { > + DEBUG("rlm_ldap: no %s attribute found in tree search on %s - access denied by default", > + inst->access_attr, user); > + return RLM_MODULE_USERLOCK; > + } > + > + /* > + * Determine the next higher object in the LDAP tree, and > + * recursively search starting with that. > + * > + * A ',' is the separator between tree levels, correct? > + */ > + while ((*basedn != '\0') && !(*basedn == ',')) { > + /* This is to step over 'escaped' characters */ > + if (*basedn == '\\') > + basedn++; > + > + if (*basedn != '\0') > + basedn++; > + } > + > + /* Step over the comma... */ > + if (*basedn != '\0') > + basedn++; > + > + /* Query the parent object */ > + return ldap_evalpermissions(inst, basedn, conn, user, 0); > +} > + > + > /* > * ldap_groupcmp(). Implement the Ldap-Group == "group" filter > */ > @@ -1132,48 +1276,25 @@ > * given username > */ > pairadd(&request->packet->vps, pairmake("Ldap-UserDn", user_dn, T_OP_EQ)); > - ldap_memfree(user_dn); > - > > /* Remote access is controled by attribute of the user object */ > if (inst->access_attr) { > - if ((vals = ldap_get_values(conn->ld, msg, inst->access_attr)) != NULL) { > - if (inst->default_allow){ > - DEBUG("rlm_ldap: checking if remote access for %s is allowed by %s", request->username->strvalue, inst->access_attr); > - if (!strncmp(vals[0], "FALSE", 5)) { > - DEBUG("rlm_ldap: dialup access disabled"); > - snprintf(module_fmsg,sizeof(module_fmsg),"rlm_ldap: Access Attribute denies access"); > - module_fmsg_vp = pairmake("Module-Failure-Message", module_fmsg, T_OP_EQ); > - pairadd(&request->packet->vps, module_fmsg_vp); > - ldap_msgfree(result); > - ldap_value_free(vals); > - ldap_release_conn(conn_id,inst->conns); > - return RLM_MODULE_USERLOCK; > - } > - ldap_value_free(vals); > - } > - else{ > - DEBUG("rlm_ldap: %s attribute exists - access denied by default", inst->access_attr); > - snprintf(module_fmsg,sizeof(module_fmsg),"rlm_ldap: Access Attribute denies access"); > - module_fmsg_vp = pairmake("Module-Failure-Message", module_fmsg, T_OP_EQ); > - pairadd(&request->packet->vps, module_fmsg_vp); > - ldap_msgfree(result); > - ldap_value_free(vals); > - ldap_release_conn(conn_id,inst->conns); > - return RLM_MODULE_USERLOCK; > - } > - } else { > - if (inst->default_allow){ > - DEBUG("rlm_ldap: no %s attribute - access denied by default", inst->access_attr); > + if ((res = ldap_evalpermissions(inst, user_dn, conn, request->username->strvalue, > + inst->search_parent)) != RLM_MODULE_OK) { > + ldap_memfree(user_dn); > + ldap_msgfree(result); > + ldap_release_conn(conn_id,inst->conns); > + if (res == RLM_MODULE_USERLOCK) { > + > snprintf(module_fmsg,sizeof(module_fmsg),"rlm_ldap: Access Attribute denies access"); > module_fmsg_vp = pairmake("Module-Failure-Message", module_fmsg, T_OP_EQ); > pairadd(&request->packet->vps, module_fmsg_vp); > - ldap_msgfree(result); > - ldap_release_conn(conn_id,inst->conns); > - return RLM_MODULE_USERLOCK; > + return res; > } > + return RLM_MODULE_FAIL; > } > } > + ldap_memfree(user_dn); > > /* > * Check for the default profile entry. If it exists then add the > @@ -1742,6 +1863,8 @@ > free((char *) inst->access_attr); > if (inst->profile_attr) > free((char *) inst->profile_attr); > + if (inst->default_allow) > + free((char *) inst->default_allow); > if (inst->conns){ > int i=0; > > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html > -- Kostas Kalevras Network Operations Center kkalev@noc.ntua.gr National Technical University of Athens, Greece Work Phone: +30 210 7721861 'Go back to the shadow' Gandalf From freeradius-devel@lists.freeradius.org Fri Mar 19 15:55:59 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Fri, 19 Mar 2004 10:55:59 -0500 Subject: Warnings (was Re: (no subject) ) In-Reply-To: Your message of "Thu, 18 Mar 2004 21:19:37 EST." <9030.1079662777@marajade.sandelman.ottawa.on.ca> Message-ID: <20040319155559.C204F16FDF@mail.nitros9.org> Michael Richardson wrote: > Alan, I was looking at warnings in rlm_eap, and I think this is what was > meant: ... Yup. > I also cleaned up lots of signed/unsigned warnings on loop variables. OK. Alan DeKok. From freeradius-devel@lists.freeradius.org Fri Mar 19 16:41:14 2004 From: freeradius-devel@lists.freeradius.org (Daniel Carroll) Date: Fri, 19 Mar 2004 09:41:14 -0700 Subject: Patch for rlm_ldap - access_attr_used_for_allow enhancement In-Reply-To: <20040319130025.D36464@ajax.noc.ntua.gr> References: <20040318190205.GA30374@mesastate.edu> <20040319130025.D36464@ajax.noc.ntua.gr> Message-ID: <20040319164114.GA7641@mesastate.edu> On Fri, 19 Mar 2004, Kostas Kalevras wrote: > > On Thu, 18 Mar 2004, Daniel Carroll wrote: > > > [ ... ] > > > > The motivation for this patch is that it allows adminstrators in Novell > > Netware shops to swap out Novell's radius server for FreeRadius without > > needing to restructure data in NDS (Novell's Directory Service -- which > > can be "exported" to LDAP) to get the same behaviour under FreeRadius. > > Could you give more details on that? Why is it necessary to add such > a feature? Because I would like to be able to use FreeRadius as a drop-in replacement for Novell's radius server. It allows for a smoother transition between radius servers, and if there are problems with one type of radius server, the admin can easily switch to the other server without making extensive updates/changes to the LDAP tree. Unless one of the goals the FreeRadius project is to avoid feature creep, I think it would be beneficial from the standpoint of making the server more flexible by supporting additional ldap tree semantics. > What's the problem with setting access_attr_used_for_allow > to 'no' and adding a FALSE access attribute only to the entries you > want to lock? I have two reasons: I am unaware of any automated tools that exist for converting an LDAP tree from the 'Novell' style to one of the two styles that FreeRadius uses. Converting an LDAP tree with over 300+ containers and 6000+ user objects is likely to be tedius. The second reason is that it makes the system more prone to security mistakes: When accounts are created that should not have access through the dialups, the admin creating the account has to remember to add the access_attr and set it to FALSE. Failure to do so means that the account can be used for access when it was never intended for that purpose. Granted, accounts that fall into this category are a minority, but that means that mistakes are more likely because these accounts are handled/created only occasionally. > As for the patch itself read forward: > > > > > [ ... ] > > > > diff -ru freeradius-cvs20040316/src/modules/rlm_ldap/rlm_ldap.c build-fr/src/modules/rlm_ldap/rlm_ldap.c > > --- freeradius-cvs20040316/src/modules/rlm_ldap/rlm_ldap.c Sun Feb 29 06:55:08 2004 > > +++ build-fr/src/modules/rlm_ldap/rlm_ldap.c Thu Mar 18 10:40:23 2004 > > [ ... ] > > @@ -338,6 +339,7 @@ > > static int ldap_xlat(void *,REQUEST *, char *, char *,int, RADIUS_ESCAPE_STRING); > > static LDAP *ldap_connect(void *instance, const char *, const char *, int, int *); > > static int read_mappings(ldap_instance* inst); > > +static int ldap_evalpermissions(ldap_instance *, char *, LDAP_CONN *, char *, int); > > > > static inline int ldap_get_conn(LDAP_CONN *conns,LDAP_CONN **ret,void *instance) > > { > > @@ -407,6 +409,33 @@ > > } > > #endif > > > > + /* Validate the parameter, and make the first char lower-case */ > > + if (inst->default_allow == NULL) { > > + inst->default_allow = strdup("yes"); > > + if (inst->default_allow == NULL) { > > + radlog(L_ERR, "rlm_ldap: Could not allocate memory. Aborting."); > > + free(inst); > > + return -1; > > + } > > + } > > + else if (!strcasecmp(inst->default_allow, "yes")) { > > + inst->default_allow[0] = 'y'; > > + inst->search_parent = 0; > > + } > > + else if (!strcasecmp(inst->default_allow, "no")) { > > + inst->default_allow[0] = 'n'; > > + inst->search_parent = 0; > > + } > > + else if (!strcasecmp(inst->default_allow, "parent")) { > > + inst->default_allow[0] = 'p'; > > + inst->search_parent = 1; > > + } > > + else { > > + radlog(L_ERR, "rlm_ldap: unrecognized access_attr_used_for_allow value."); > > + free(inst); > > + return -1; > > + } > > > Why can't all these checks go to ldap_instantiate? I don't really like running > them each time we need to find an ldap connection. That's why ldap_get_conn is > small and inline, to run quickly. These checks are in ldap_instantiate(), not ldap_get_conn(). > > [ ... ] > > > > +static int > > +ldap_evalpermissions(ldap_instance *inst, char *basedn, LDAP_CONN *conn, char *user, int query_parent) > > +{ > > + char **vals; > > + int res; > > + int access_fate; > > + char *attrs[] = {NULL,NULL}; > > + LDAPMessage *result; > > + LDAPMessage *msg; > > + > > + > > + /* Quick sanity check */ > > + if ((inst == NULL) || (basedn == NULL) || (conn == NULL) || (inst->access_attr == NULL)) { > > + radlog(L_ERR, "rlm_ldap: unexpected NULL parameter passed to ldap_evalpermissions()"); > > + return RLM_MODULE_FAIL; > > + } > > + > > + DEBUG("rlm_ldap: Checking %s for access permission", basedn); > > + access_fate = RLM_MODULE_OK; > > + attrs[0] = inst->access_attr; > > + if ((res = perform_search(inst, conn, basedn, LDAP_SCOPE_BASE, NULL, attrs, &result)) != RLM_MODULE_OK) { > > + /* If we end up here, the basedn was supposed to be valid! Complain. */ > > + radlog(L_ERR, "rlm_ldap: base search unexpectedly failed"); > > + return RLM_MODULE_FAIL; > > + } > > + if ((msg = ldap_first_entry(conn->ld, result)) == NULL) { > > + DEBUG("rlm_ldap: ldap_first_entry() failed"); > > + ldap_msgfree(result); > > + return RLM_MODULE_FAIL; > > + } > > The way you 've implemented the function you always add an extra > unneeded search for the user dn on ldap_evalpermissions first run if > I understand it correctly. That's not efficient. It is an extra 'search', in the sense that the information is retrieved twice; however, in ldap_evalpermissions() only LDAP_SCOPE_BASE searches are used. If this is an issue, I can re-write the patch to remove the additional LDAP base search. Would you consider a patch that does that? Thanks. - Dan From freeradius-devel@lists.freeradius.org Fri Mar 19 17:24:11 2004 From: freeradius-devel@lists.freeradius.org (Kostas Kalevras) Date: Fri, 19 Mar 2004 19:24:11 +0200 (EET) Subject: Patch for rlm_ldap - access_attr_used_for_allow enhancement In-Reply-To: <20040319164114.GA7641@mesastate.edu> References: <20040318190205.GA30374@mesastate.edu> <20040319130025.D36464@ajax.noc.ntua.gr> <20040319164114.GA7641@mesastate.edu> Message-ID: <20040319190832.E57044@ajax.noc.ntua.gr> On Fri, 19 Mar 2004, Daniel Carroll wrote: > On Fri, 19 Mar 2004, Kostas Kalevras wrote: > > > > On Thu, 18 Mar 2004, Daniel Carroll wrote: > > > > > [ ... ] > > > > > > The motivation for this patch is that it allows adminstrators in Novell > > > Netware shops to swap out Novell's radius server for FreeRadius without > > > needing to restructure data in NDS (Novell's Directory Service -- which > > > can be "exported" to LDAP) to get the same behaviour under FreeRadius. > > > > Could you give more details on that? Why is it necessary to add such > > a feature? > > Because I would like to be able to use FreeRadius as a drop-in > replacement for Novell's radius server. It allows for a smoother > transition between radius servers, and if there are problems with > one type of radius server, the admin can easily switch to the other > server without making extensive updates/changes to the LDAP tree. > > Unless one of the goals the FreeRadius project is to avoid feature > creep, I think it would be beneficial from the standpoint of making > the server more flexible by supporting additional ldap tree semantics. I am reluctant to bloat the ldap module even more just to accomodate the way that a vendor has decided to implement it's own radius/ldap implementation. You could open a bug report with the patch, it could probably be added in the contrib section but i wouldn't like adding it to the module code. rlm_ldap has 31 configuration directives and is 64KB. The next module in size is rlm_sql.c with 36KB. I think it has grown large enough. > > > What's the problem with setting access_attr_used_for_allow > > to 'no' and adding a FALSE access attribute only to the entries you > > want to lock? > > I have two reasons: > I am unaware of any automated tools that exist for converting > an LDAP tree from the 'Novell' style to one of the two styles that > FreeRadius uses. Converting an LDAP tree with over 300+ containers > and 6000+ user objects is likely to be tedius. There are plenty of radius vendors out there. rlm_ldap.c is not the place to place compatibility code to cope with their schema/structure decisions. > The second reason is that it makes the system more prone to > security mistakes: When accounts are created that should not have > access through the dialups, the admin creating the account has to > remember to add the access_attr and set it to FALSE. Failure to > do so means that the account can be used for access when it was > never intended for that purpose. Granted, accounts that fall > into this category are a minority, but that means that mistakes > are more likely because these accounts are handled/created only > occasionally. If they are supposed to be locked it seems a logical requirement to lock them. > > > As for the patch itself read forward: > > > > > > > > [ ... ] > > > > > > diff -ru freeradius-cvs20040316/src/modules/rlm_ldap/rlm_ldap.c build-fr/src/modules/rlm_ldap/rlm_ldap.c > > > --- freeradius-cvs20040316/src/modules/rlm_ldap/rlm_ldap.c Sun Feb 29 06:55:08 2004 > > > +++ build-fr/src/modules/rlm_ldap/rlm_ldap.c Thu Mar 18 10:40:23 2004 > > > [ ... ] > > > @@ -338,6 +339,7 @@ > > > static int ldap_xlat(void *,REQUEST *, char *, char *,int, RADIUS_ESCAPE_STRING); > > > static LDAP *ldap_connect(void *instance, const char *, const char *, int, int *); > > > static int read_mappings(ldap_instance* inst); > > > +static int ldap_evalpermissions(ldap_instance *, char *, LDAP_CONN *, char *, int); > > > > > > static inline int ldap_get_conn(LDAP_CONN *conns,LDAP_CONN **ret,void *instance) > > > { > > > @@ -407,6 +409,33 @@ > > > } > > > #endif > > > > > > + /* Validate the parameter, and make the first char lower-case */ > > > + if (inst->default_allow == NULL) { > > > + inst->default_allow = strdup("yes"); > > > + if (inst->default_allow == NULL) { > > > + radlog(L_ERR, "rlm_ldap: Could not allocate memory. Aborting."); > > > + free(inst); > > > + return -1; > > > + } > > > + } > > > + else if (!strcasecmp(inst->default_allow, "yes")) { > > > + inst->default_allow[0] = 'y'; > > > + inst->search_parent = 0; > > > + } > > > + else if (!strcasecmp(inst->default_allow, "no")) { > > > + inst->default_allow[0] = 'n'; > > > + inst->search_parent = 0; > > > + } > > > + else if (!strcasecmp(inst->default_allow, "parent")) { > > > + inst->default_allow[0] = 'p'; > > > + inst->search_parent = 1; > > > + } > > > + else { > > > + radlog(L_ERR, "rlm_ldap: unrecognized access_attr_used_for_allow value."); > > > + free(inst); > > > + return -1; > > > + } > > > > > > Why can't all these checks go to ldap_instantiate? I don't really like running > > them each time we need to find an ldap connection. That's why ldap_get_conn is > > small and inline, to run quickly. > > These checks are in ldap_instantiate(), not ldap_get_conn(). You 're right sorry. > > > > [ ... ] > > > > > > +static int > > > +ldap_evalpermissions(ldap_instance *inst, char *basedn, LDAP_CONN *conn, char *user, int query_parent) > > > +{ > > > + char **vals; > > > + int res; > > > + int access_fate; > > > + char *attrs[] = {NULL,NULL}; > > > + LDAPMessage *result; > > > + LDAPMessage *msg; > > > + > > > + > > > + /* Quick sanity check */ > > > + if ((inst == NULL) || (basedn == NULL) || (conn == NULL) || (inst->access_attr == NULL)) { > > > + radlog(L_ERR, "rlm_ldap: unexpected NULL parameter passed to ldap_evalpermissions()"); > > > + return RLM_MODULE_FAIL; > > > + } > > > + > > > + DEBUG("rlm_ldap: Checking %s for access permission", basedn); > > > + access_fate = RLM_MODULE_OK; > > > + attrs[0] = inst->access_attr; > > > + if ((res = perform_search(inst, conn, basedn, LDAP_SCOPE_BASE, NULL, attrs, &result)) != RLM_MODULE_OK) { > > > + /* If we end up here, the basedn was supposed to be valid! Complain. */ > > > + radlog(L_ERR, "rlm_ldap: base search unexpectedly failed"); > > > + return RLM_MODULE_FAIL; > > > + } > > > + if ((msg = ldap_first_entry(conn->ld, result)) == NULL) { > > > + DEBUG("rlm_ldap: ldap_first_entry() failed"); > > > + ldap_msgfree(result); > > > + return RLM_MODULE_FAIL; > > > + } > > > > The way you 've implemented the function you always add an extra > > unneeded search for the user dn on ldap_evalpermissions first run if > > I understand it correctly. That's not efficient. > > It is an extra 'search', in the sense that the information is retrieved > twice; however, in ldap_evalpermissions() only LDAP_SCOPE_BASE searches > are used. If this is an issue, I can re-write the patch to remove the > additional LDAP base search. Would you consider a patch that does that? Every extra ldap operation is big issue. I would like your patch to keep the current behaviour unchanged and only perform more operations if it is configured to do that. > > Thanks. > > - Dan > > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html > -- Kostas Kalevras Network Operations Center kkalev@noc.ntua.gr National Technical University of Athens, Greece Work Phone: +30 210 7721861 'Go back to the shadow' Gandalf From freeradius-devel@lists.freeradius.org Fri Mar 19 17:57:20 2004 From: freeradius-devel@lists.freeradius.org (Adrian Pavlykevych) Date: Fri, 19 Mar 2004 19:57:20 +0200 Subject: Patch for rlm_ldap - access_attr_used_for_allow enhancement In-Reply-To: <20040319164114.GA7641@mesastate.edu> References: <20040318190205.GA30374@mesastate.edu> <20040319130025.D36464@ajax.noc.ntua.gr> <20040319164114.GA7641@mesastate.edu> Message-ID: <405B3480.9080807@polynet.lviv.ua> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel Carroll wrote: > On Fri, 19 Mar 2004, Kostas Kalevras wrote: > >>On Thu, 18 Mar 2004, Daniel Carroll wrote: >> >> >>>[ ... ] >>> >>>The motivation for this patch is that it allows adminstrators in Novell >>>Netware shops to swap out Novell's radius server for FreeRadius without >>>needing to restructure data in NDS (Novell's Directory Service -- which >>>can be "exported" to LDAP) to get the same behaviour under FreeRadius. >> >>Could you give more details on that? Why is it necessary to add such >>a feature? > > > Because I would like to be able to use FreeRadius as a drop-in > replacement for Novell's radius server. It allows for a smoother > transition between radius servers, and if there are problems with > one type of radius server, the admin can easily switch to the other > server without making extensive updates/changes to the LDAP tree. > > Unless one of the goals the FreeRadius project is to avoid feature > creep, I think it would be beneficial from the standpoint of making > the server more flexible by supporting additional ldap tree semantics. Well, we've been in this position before, but I also don't think that totally mimicking Novell Radius schema is good thing to do. I was already suggested removing access_attr directive and code altogether, and use comparison against specified LDAP attribute in users file. This suggestion was considered bad for ease of use for FreeRADIUS adopters, but it makes FreeRADIUS configuration more consistent: i.e. data retrieval was handled by one type of modules (ldap,sql,...) and rules definition by others (users, ...). I think, it would even keep people thoughts from direction of suggesting more and more complicated authorization checks into rlm_ldap, instead more improvements would be proposed to rule language, etc. But this is just my opinion. >>What's the problem with setting access_attr_used_for_allow >>to 'no' and adding a FALSE access attribute only to the entries you >>want to lock? > > > I have two reasons: > I am unaware of any automated tools that exist for converting > an LDAP tree from the 'Novell' style to one of the two styles that > FreeRadius uses. Converting an LDAP tree with over 300+ containers > and 6000+ user objects is likely to be tedius. You don't need to do that, see below > The second reason is that it makes the system more prone to > security mistakes: When accounts are created that should not have > access through the dialups, the admin creating the account has to > remember to add the access_attr and set it to FALSE. Failure to > do so means that the account can be used for access when it was > never intended for that purpose. Granted, accounts that fall > into this category are a minority, but that means that mistakes > are more likely because these accounts are handled/created only > occasionally. You can use Ldap-Group in users file to globally control RADIUS access. So the only modification to the tree, will be adding all your authorized users in NDS to some new group and configure rlm_ldap to use this group membership in addition to access_attr. We are using this approach at our University and it works very well. Hope it helps, - -- Adrian Pavlykevych -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) iD8DBQFAWzSGdWQndLibxtARAu9IAKDQRIFjipnFxTrzn0O2qhn0r6S3JACgtM71 5fvtunRTKsoSkFOv+warMOE= =aMD8 -----END PGP SIGNATURE----- From freeradius-devel@lists.freeradius.org Fri Mar 19 22:26:24 2004 From: freeradius-devel@lists.freeradius.org (Daniel Carroll) Date: Fri, 19 Mar 2004 15:26:24 -0700 Subject: Patch for rlm_ldap - access_attr_used_for_allow enhancement In-Reply-To: <20040319190832.E57044@ajax.noc.ntua.gr> References: <20040318190205.GA30374@mesastate.edu> <20040319130025.D36464@ajax.noc.ntua.gr> <20040319164114.GA7641@mesastate.edu> <20040319190832.E57044@ajax.noc.ntua.gr> Message-ID: <20040319222624.GA21078@mesastate.edu> On Fri, 19 Mar 2004, Kostas Kalevras wrote: > > > [ ... ] > > I am reluctant to bloat the ldap module even more just to accomodate > the way that a vendor has decided to implement it's own radius/ldap > implementation. You could open a bug report with the patch, it could > probably be added in the contrib section but i wouldn't like adding > it to the module code. rlm_ldap has 31 configuration directives and > is 64KB. The next module in size is rlm_sql.c with 36KB. I think it > has grown large enough. Ok. (This is getting off-thread and is largely irrelevant, but the total source-code size in two or three of the other modules is larger than that in rlm_ldap--those modules just have the code spread over several files.) In terms of a "bug report", will this message qualify? I did a quick look through the docs and through Google and didn't see anything on exlicit about the format for a bug report. I've attached an updated patch to this message that removes the one extra ldap search. In terms of the future, doing something like Adrian Pavlykev has suggested in another message (removing the access_attr from the radiusd.conf file and moving it to the users file) would make me happy as long as there is a way to specify that attributes can be "inherited" implicitly from the parent container. From working with Novell's NDS, I've found inheritance to be a very useful way to manage access to resources. and as such have a relatively strong bias for it. > > > What's the problem with setting access_attr_used_for_allow > > > to 'no' and adding a FALSE access attribute only to the entries you > > > want to lock? > > > > [ ... ] > > The second reason is that it makes the system more prone to > > security mistakes: When accounts are created that should not have > > access through the dialups, the admin creating the account has to > > remember to add the access_attr and set it to FALSE. Failure to > > do so means that the account can be used for access when it was > > never intended for that purpose. Granted, accounts that fall > > into this category are a minority, but that means that mistakes > > are more likely because these accounts are handled/created only > > occasionally. > > If they are supposed to be locked it seems a logical requirement to > lock them. Yes, but the issue that concerns me is human oversight: the admin forgetting that he needs to go in and set the access_attr to FALSE. In my situation, the structure/semantics of the LDAP tree mitigates this, because new user objects should almost always inherit this setting from the parent container. Below is the modified patch. It has been compiled and tested and is in production use at my site now. Thanks. - Dan diff -ur freeradius-cvs20040316/doc/rlm_ldap freeradius-modified/doc/rlm_ldap --- freeradius-cvs20040316/doc/rlm_ldap Wed Dec 3 07:32:42 2003 +++ freeradius-modified/doc/rlm_ldap Thu Mar 18 11:34:05 2004 @@ -144,19 +144,27 @@ # # profile_attribute = "radiusProfileDn" -# access_attr_used_for_allow: Define if the access attribute (described -# below) will be used to allow access (meaning if it exists then user -# remote access will be allowed) or to deny access. default: yes - used -# to allow access +# access_attr_used_for_allow: no/yes/parent +# Define if the access attribute (described below) will be used to allow +# access (meaning if it exists then user remote access will be allowed) +# or to deny access. +# +# default: yes - used to allow access -# access_attr: if attribute is specified, module checks for its -# existance in user object. If access_attr_used_for_allow is set to -# yes: If it exists the user is allowed to get remote access. If it -# exists and is set to FALSE the user is denied remote access. If it -# does not exist user is denied remote access by default if -# access_attr_used_for_allow is set to no: If it exists the user is -# denied remote access. If it does not exist user is allowed remote -# access. +# access_attr: if this attribute is specified, the module checks for its +# existance in the user object. +# If access_attr_used_for_allow is set to no: +# If access_attr does not exist user is allowed remote access. +# If access_attr exists the user is denied remote access. +# If access_attr_used_for_allow is set to yes: +# If access_attr does not exist user is denied remote access. +# If access_attr exists and is set to FALSE, the user is denied +# remote access. +# If access_attr exists the user is allowed remote access. +# If access_attr_used_for_allow is set to parent: +# Similar to access_attr_used_for_allow = yes, except +# that the container object is checked for access_attr +# if it isn't set in the user or profile object. # # default: NULL - don't check for the attribute diff -ur freeradius-cvs20040316/src/modules/rlm_ldap/rlm_ldap.c freeradius-modified/src/modules/rlm_ldap/rlm_ldap.c --- freeradius-cvs20040316/src/modules/rlm_ldap/rlm_ldap.c Sun Feb 29 06:55:08 2004 +++ freeradius-modified/src/modules/rlm_ldap/rlm_ldap.c Fri Mar 19 13:38:55 2004 @@ -251,9 +251,10 @@ int num_conns; int do_comp; int do_xlat; - int default_allow; int failed_conns; int is_url; + int search_parent; + char *default_allow; char *login; char *password; char *filter; @@ -320,7 +321,7 @@ {"ldap_debug", PW_TYPE_INTEGER, offsetof(ldap_instance,ldap_debug), NULL, "0x0000"}, {"ldap_connections_number", PW_TYPE_INTEGER, offsetof(ldap_instance,num_conns), NULL, "5"}, {"compare_check_items", PW_TYPE_BOOLEAN, offsetof(ldap_instance,do_comp), NULL, "no"}, - {"access_attr_used_for_allow", PW_TYPE_BOOLEAN, offsetof(ldap_instance,default_allow), NULL, "yes"}, + {"access_attr_used_for_allow", PW_TYPE_STRING_PTR, offsetof(ldap_instance,default_allow), NULL, "yes"}, {"do_xlat", PW_TYPE_BOOLEAN, offsetof(ldap_instance,do_xlat), NULL, "yes"}, {NULL, -1, 0, NULL, NULL} @@ -338,6 +339,7 @@ static int ldap_xlat(void *,REQUEST *, char *, char *,int, RADIUS_ESCAPE_STRING); static LDAP *ldap_connect(void *instance, const char *, const char *, int, int *); static int read_mappings(ldap_instance* inst); +static int ldap_evalpermissions(ldap_instance *, LDAPMessage *, char *, LDAP_CONN *, char *, int); static inline int ldap_get_conn(LDAP_CONN *conns,LDAP_CONN **ret,void *instance) { @@ -407,6 +409,33 @@ } #endif + /* Validate the parameter, and make the first char lower-case */ + if (inst->default_allow == NULL) { + inst->default_allow = strdup("yes"); + if (inst->default_allow == NULL) { + radlog(L_ERR, "rlm_ldap: Could not allocate memory. Aborting."); + free(inst); + return -1; + } + } + else if (!strcasecmp(inst->default_allow, "yes")) { + inst->default_allow[0] = 'y'; + inst->search_parent = 0; + } + else if (!strcasecmp(inst->default_allow, "no")) { + inst->default_allow[0] = 'n'; + inst->search_parent = 0; + } + else if (!strcasecmp(inst->default_allow, "parent")) { + inst->default_allow[0] = 'p'; + inst->search_parent = 1; + } + else { + radlog(L_ERR, "rlm_ldap: unrecognized access_attr_used_for_allow value."); + free(inst); + return -1; + } + inst->timeout.tv_usec = 0; inst->net_timeout.tv_usec = 0; /* workaround for servers which support LDAPS but not START TLS */ @@ -744,6 +773,121 @@ return len; } +/* + * + * ldap_evalpermissions() + * Based on how the LDAP module has been configured, evaluate + * whether or not a particular object (user) has been granted + * authorization + * + * + */ + +static int +ldap_evalpermissions(ldap_instance *inst, LDAPMessage *msg, char *basedn, LDAP_CONN *conn, char *user, int query_parent) +{ + char **vals; + int res; + int access_fate; + char *attrs[] = {NULL,NULL}; + LDAPMessage *result; + + + /* Quick sanity check */ + if ((inst == NULL) || (basedn == NULL) || (conn == NULL) || (inst->access_attr == NULL) || (msg == NULL)) { + radlog(L_ERR, "rlm_ldap: unexpected NULL parameter passed to ldap_evalpermissions()"); + return RLM_MODULE_FAIL; + } + + DEBUG("rlm_ldap: Checking %s for access permission", basedn); + access_fate = RLM_MODULE_OK; + + /* Does the access_attr exist? If so, we're done searching */ + if ((vals = ldap_get_values(conn->ld, msg, inst->access_attr)) != NULL) { + if (inst->default_allow[0] != 'n') { + DEBUG("rlm_ldap: checking if remote access for %s is allowed by %s", user, inst->access_attr); + if (!strncmp(vals[0], "FALSE", 5)) { + DEBUG("rlm_ldap: dialup access disabled"); + access_fate = RLM_MODULE_USERLOCK; + } + } + else { + /* default_allow == "no" */ + DEBUG("rlm_ldap: %s attribute exists - access denied by default", inst->access_attr); + access_fate = RLM_MODULE_USERLOCK; + } + ldap_value_free(vals); + + return access_fate; + } + else if (query_parent == 0) { + if (inst->default_allow[0] != 'n') { + /* default_allow is set to "yes" or "parent" */ + DEBUG("rlm_ldap: no %s attribute found - access denied by default", inst->access_attr); + access_fate = RLM_MODULE_USERLOCK; + } + + return access_fate; + } + + /* + * If we reach here, default_allow is set to "parent", + * and the access_attr was not defined on the object. So we + * need to search higher in the LDAP tree for the attribute, + * or deny access if we reach the top without finding the + * attribute lower in the tree. + * + */ + + /* + * If we've reached the top of the LDAP tree, The access_attr was + * not found. Return "access denied". + */ + if (*basedn == '\0') { + DEBUG("rlm_ldap: no %s attribute found in tree search on %s - access denied by default", + inst->access_attr, user); + return RLM_MODULE_USERLOCK; + } + + /* + * Determine the next higher object in the LDAP tree, and + * recursively search starting with that. + * + * A ',' is the separator between tree levels, correct? + */ + while ((*basedn != '\0') && !(*basedn == ',')) { + /* This is to step over 'escaped' characters */ + if (*basedn == '\\') + basedn++; + + if (*basedn != '\0') + basedn++; + } + + /* Step over the comma... */ + if (*basedn != '\0') + basedn++; + + attrs[0] = inst->access_attr; + if ((res = perform_search(inst, conn, basedn, LDAP_SCOPE_BASE, NULL, attrs, &result)) != RLM_MODULE_OK) { + /* If we end up here, the basedn was supposed to be valid! Complain. */ + radlog(L_ERR, "rlm_ldap: base search unexpectedly failed"); + return RLM_MODULE_FAIL; + } + if ((msg = ldap_first_entry(conn->ld, result)) == NULL) { + DEBUG("rlm_ldap: ldap_first_entry() failed"); + ldap_msgfree(result); + return RLM_MODULE_FAIL; + } + + /* Query the parent object */ + access_fate = ldap_evalpermissions(inst, msg, basedn, conn, user, 0); + + ldap_msgfree(result); + return access_fate; +} + + /* * ldap_groupcmp(). Implement the Ldap-Group == "group" filter */ @@ -1132,48 +1276,25 @@ * given username */ pairadd(&request->packet->vps, pairmake("Ldap-UserDn", user_dn, T_OP_EQ)); - ldap_memfree(user_dn); - /* Remote access is controled by attribute of the user object */ if (inst->access_attr) { - if ((vals = ldap_get_values(conn->ld, msg, inst->access_attr)) != NULL) { - if (inst->default_allow){ - DEBUG("rlm_ldap: checking if remote access for %s is allowed by %s", request->username->strvalue, inst->access_attr); - if (!strncmp(vals[0], "FALSE", 5)) { - DEBUG("rlm_ldap: dialup access disabled"); - snprintf(module_fmsg,sizeof(module_fmsg),"rlm_ldap: Access Attribute denies access"); - module_fmsg_vp = pairmake("Module-Failure-Message", module_fmsg, T_OP_EQ); - pairadd(&request->packet->vps, module_fmsg_vp); - ldap_msgfree(result); - ldap_value_free(vals); - ldap_release_conn(conn_id,inst->conns); - return RLM_MODULE_USERLOCK; - } - ldap_value_free(vals); - } - else{ - DEBUG("rlm_ldap: %s attribute exists - access denied by default", inst->access_attr); - snprintf(module_fmsg,sizeof(module_fmsg),"rlm_ldap: Access Attribute denies access"); - module_fmsg_vp = pairmake("Module-Failure-Message", module_fmsg, T_OP_EQ); - pairadd(&request->packet->vps, module_fmsg_vp); - ldap_msgfree(result); - ldap_value_free(vals); - ldap_release_conn(conn_id,inst->conns); - return RLM_MODULE_USERLOCK; - } - } else { - if (inst->default_allow){ - DEBUG("rlm_ldap: no %s attribute - access denied by default", inst->access_attr); + if ((res = ldap_evalpermissions(inst, msg, user_dn, conn, request->username->strvalue, + inst->search_parent)) != RLM_MODULE_OK) { + ldap_memfree(user_dn); + ldap_msgfree(result); + ldap_release_conn(conn_id,inst->conns); + if (res == RLM_MODULE_USERLOCK) { + snprintf(module_fmsg,sizeof(module_fmsg),"rlm_ldap: Access Attribute denies access"); module_fmsg_vp = pairmake("Module-Failure-Message", module_fmsg, T_OP_EQ); pairadd(&request->packet->vps, module_fmsg_vp); - ldap_msgfree(result); - ldap_release_conn(conn_id,inst->conns); - return RLM_MODULE_USERLOCK; + return res; } + return RLM_MODULE_FAIL; } } + ldap_memfree(user_dn); /* * Check for the default profile entry. If it exists then add the @@ -1742,6 +1863,8 @@ free((char *) inst->access_attr); if (inst->profile_attr) free((char *) inst->profile_attr); + if (inst->default_allow) + free((char *) inst->default_allow); if (inst->conns){ int i=0; From freeradius-devel@lists.freeradius.org Sat Mar 20 21:38:08 2004 From: freeradius-devel@lists.freeradius.org (Alexander M. Pravking) Date: Sun, 21 Mar 2004 00:38:08 +0300 Subject: xlat question In-Reply-To: <20040313160936.C4FA716FDF@mail.nitros9.org> References: <1079129968.3805.21.camel@enterprise.utdallas.edu> <20040313160936.C4FA716FDF@mail.nitros9.org> Message-ID: <20040320213808.GF48678@dyatel.antar.bryansk.ru> On Sat, Mar 13, 2004 at 11:09:36AM -0500, Alan DeKok wrote: > In other news, we should probably get rid of ``, and just xlat all > double-quoted strings... Btw, Alan, INTEGER attributes are now always being looked up against dictionary unless the value looks like numeric. It's probably a good time to start consider Integer-Attr = "%{Some-Calculations}" as an ordinary value, not as a dictionary value representation... -- Fduch M. Pravking From freeradius-devel@lists.freeradius.org Mon Mar 22 16:45:46 2004 From: freeradius-devel@lists.freeradius.org (Wolfgang Hottgenroth) Date: Mon, 22 Mar 2004 17:45:46 +0100 Subject: Was: Missing free() in rlm_dbm, Now: offering help Message-ID: <86ad286dad.wl@imhotep.home.hottis.intern> Hi, good idea, indeed. Do you already have a plan when you like to do this? Would you mind if I offer some help here, since I need the CDB support now (I already implemented it by copying and modifying the rlm_dbm code) and I'm able to work on it now. And I will also need the CDB in another module which I have to implement shortly, so this moving of the database code in a standalone library would be a benefit for me there. Wolfgang > Date: Fri, 19 Mar 2004 13:25:39 +0300 > From: Andrei Koulik > To: Wolfgang Hottgenroth > Subject: Re: Missing free() in rlm_dbm? > Reply-To: freeradius-devel@lists.freeradius.org > > > I plan remake the rlm_dbm module to remove database specified routines > to standalone library. This library will provide independent interface > to work with associative (key-value) database. I think it is good idea > to make that library is available for all modules (system-wide) and > configure once in main script. > > It is not need to free memory after call dbm_fetch function (FreeBSD) > I think it is specified for gdbm implementation. From freeradius-devel@lists.freeradius.org Mon Mar 22 17:12:19 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Mon, 22 Mar 2004 12:12:19 -0500 (EST) Subject: http://www.freeradius.org/business/ Message-ID: <200403221712.i2MHCJp20710@newgiles.nitros9.org> There are companies that do FreeRADIUS consulting work. For people with CVS access, please do: cvs -d :pserver:user@cvs.freeradius.org:/source checkout freeradius-www Edit business/index.html, to add: Company name, URL One-sentence summary of services. cvs commit business/index.html Please don't edit anything else in the tree. I'll wait a week or so for people to update it, and then link to it from the main page. Alan DeKok. From freeradius-devel@lists.freeradius.org Tue Mar 23 15:41:44 2004 From: freeradius-devel@lists.freeradius.org (Oswin Ondarza) Date: Tue, 23 Mar 2004 10:41:44 -0500 Subject: Using FreeRadius for a HotSpot with a PrePaid Billing System Message-ID: <039b01c410ed$59514b50$7f01a8c0@terainspiron> This is a multi-part message in MIME format. ------=_NextPart_000_0398_01C410C3.6F86D130 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi everyone, I am trying to build a Hotspot system using FreeRADIUS, I have a = Colubris CN3000 NAS and it works great with the FreeRADIUS, but now I = need a billing system integrated to the FreeRADIUS so users when enter = the hotspot can pay with credit card using the explorer/mozilla to get = access or to get login information. I would like to build a complete open source solution, so the only = prepaid billing system open source that I have found thar "could" be = intergrated with the FreeRADIUS is "FreeSide" = (http://www.sisd.com/freeside/) but I haven't tried it yet, I would = like to hear a little about this before doing it. So, any Opinion ? Suggestions ? is anybody tryng the same solution = ??? I hope someone can help me, Thanks in advance !!! Oswin. ------=_NextPart_000_0398_01C410C3.6F86D130 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi everyone,
 
I am trying to  build a = Hotspot=20 system using FreeRADIUS,  I have a Colubris CN3000 NAS  = and it=20 works great with the FreeRADIUS, but now I need a billing system = integrated to=20 the FreeRADIUS  so  users when enter the hotspot can pay = with=20 credit card using the explorer/mozilla  to get  = access or to=20 get  login information.
 
I would like to build a complete open = source=20 solution, so the only prepaid billing system open source that I have = found thar=20 "could" be intergrated with the FreeRADIUS is   = "FreeSide"  =20 (http://www.sisd.com/freeside/)=  =20 but I haven't tried it yet, I would like to hear a little about this = before=20 doing it.
 
 
So, any Opinion ? Suggestions = ?   is=20 anybody tryng  the same solution ???
 
 
I hope someone can help = me,
 
Thanks in advance !!!
 
Oswin.
 
------=_NextPart_000_0398_01C410C3.6F86D130-- From freeradius-devel@lists.freeradius.org Tue Mar 23 22:37:00 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Tue, 23 Mar 2004 17:37:00 -0500 (EST) Subject: Regular expression matching & substitution Message-ID: <200403232237.i2NMb0927989@newgiles.nitros9.org> In the "users" file: DEFAULT User-Name =~ ^(.*)@(.*)$", Stripped-User-Name := `%{1}`, Realm := `%{2}` I think this will now work... After a little more testing, it can be documented for a wider audience. Alan DeKok. From freeradius-devel@lists.freeradius.org Wed Mar 24 04:45:29 2004 From: freeradius-devel@lists.freeradius.org (Ruslan A Dautkhanov) Date: Wed, 24 Mar 2004 11:45:29 +0700 Subject: ippool & SQL In-Reply-To: <20040323201820.589.qmail@mail.ruralnetwork.net> References: <20040323201820.589.qmail@mail.ruralnetwork.net> Message-ID: <40611269.5020407@scn.ru> This is a cryptographically signed message in MIME format. --------------ms090107090800040808040209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit scott@ruralnetwork.net wrote: >> Hello ! >> Some ppls post to this list this stuf. That version is works pretty >> fine, >> very stable, BUT(!) it's ugly since use differrent pools of SQL DB >> connections >> for each(!) IP-pool! So, for example, if you have 4 IP-pools and >> standart >> SQL db-pool with 10 connections, than you have 10 * (1+4) = 50 db >> connections. >> I have rewritted it - my module use standart pool of DB connections - >> you >> need only 10 connections now. If you have interest in this, I can >> post URL >> where my version of module sql_ippool lives. We use it in >> productional environment >> for an one year with hard load without any problems. >> -- >> best regards, >> Ruslan A Dautkhanov rusland@scn.ru > > > Hi Ruslan, > I saw your posting above to the freeside-devel mailing list - via the > list archive. I haven't yet subscribed to the list, but I'd be > grateful if you could post a link to your file to the list as I'd be > interesting in downloading it and giving it a try. > Regards, > Scott Langley > scott@ruralnetwork.net > Systems Administrator > Rural Network Services Hello ! This version located here: ftp://rd.ranetka.ru/pub/sql-ip-pool/rlm_sqlippool.tar.gz . It's very stable, robust version, works well for all our needs (ip allocation for dialup, campus clients, currently allocating ips for 5 ippools simul-ly). It's works with CVS version after 0.9.0, but no reasons why it can't work with current CVS.. Just unpack it to the src/modules directory, run echo rlm_sqlippool >> src/modules/stable and rebuild your radiusd. After this you should edit your sqlippools.conf, sqlippool.sqls, radiusd.conf. The last one should have lines like this: 1. $INCLUDE ${confdir}/sqlippools.conf 2. accounting { ... sqlippool_maincampus #name of your sqlippool_8180 #sqlippool instances defined in sqlippools.conf ... ... 3. post-auth { ... sqlippool_maincampus #name of your sqlippool_8180 #sqlippool instances defined in sqlippools.conf ... ... Full my version of sqlippool.sqls and example version of sqlippools.conf I posted to ftp://rd.ranetka.ru/pub/sql-ip-pool/ . HTH. Of course, you have to create radippool table in your database. Here is my version for PostgreSQL one: isbs=# \d radippool Table "public.radippool" Column | Type | Modifiers --------------------+--------------------------------+----------------------------------------------------------- id | integer | not null default nextval('public.radippool_id_seq'::text) pool_name | text | not null ip_address | inet | nas_ip_address | text | not null nas_port | integer | not null calling_station_id | text | not null expiry_time | timestamp(0) without time zone | not null Indexes: "radippool_pkey" primary key, btree (id) "radippool_ip_address_key" unique, btree (ip_address) "radippool_nasipaddr_calling" btree (nas_ip_address, calling_station_id) "radippool_nasipaddr_port" btree (nas_ip_address, nas_port) "radippool_poolname_expire" btree (pool_name, expiry_time) "radippool_poolname_ipaadr" btree (pool_name, ip_address) Btw, I have in plans to release next version of this module, which keeps in radippool username and realm also and which will _tries_ to allocate a same IP to user, when it'll login next time, just like Cisco ippools do. "Tries" because IP, that was allocated to this user can currently be occuppied by another user, obviously. -- best regards, Ruslan A Dautkhanov rusland@scn.ru --------------ms090107090800040808040209 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII3TCC AskwggIyoAMCAQICAwsqlzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDMxMTE4MDQxNjMzWhcNMDQxMTE3MDQxNjMz WjBAMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR0wGwYJKoZIhvcNAQkBFg5y dXNsYW5kQHNjbi5ydTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAfBajdRPJx JFT8qNAYO209TK56UQ8vaBplFOLkdMOxcCbTsV9TROHjzV2/+qKdNohjJruzJazvP1Y0N8yj E8qtlI72uAGJfImWF0zUL+2Q9m0KOjImoLbns9SDvsIgnQgPgv5dd5xuPJdWhJOrv4cThBkB tJtGI3w8mQz6o8MH+SC7w+U6QsAwXd0dqtOdXDiyW6Uj1jvXkUYgOJj/kefDmwze6baOpgji TWk2XW1gkVWzO2XNp5pzeg79xLm60jeXlyFXDMvdmTCmYhLB2UfH5L5dOVUV7DWjEurH0vVB L2DVYibnTeQYBh7T/nsMQWjF2TUZRwrOXWvEY7Zz14MCAwEAAaMrMCkwGQYDVR0RBBIwEIEO cnVzbGFuZEBzY24ucnUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCgU3RLfxTR /SO3oLGk7mKb8cCT2uqYLusdywSiDh4xmc5tBe+u5p9gBatKz8dB9dU+6Ey/aaxfhRa5QWj+ K0DT/BvTNENp5QNH0/ff0vGwg4OYuW0FX0T5d9W8fJr3hORydS7lsxBQD5sFe0Olp8slfRnR y+wKCXs2SHCgyQOwujCCAskwggIyoAMCAQICAwsqlzANBgkqhkiG9w0BAQQFADBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDMxMTE4MDQxNjMz WhcNMDQxMTE3MDQxNjMzWjBAMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR0w GwYJKoZIhvcNAQkBFg5ydXNsYW5kQHNjbi5ydTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAMAfBajdRPJxJFT8qNAYO209TK56UQ8vaBplFOLkdMOxcCbTsV9TROHjzV2/+qKd NohjJruzJazvP1Y0N8yjE8qtlI72uAGJfImWF0zUL+2Q9m0KOjImoLbns9SDvsIgnQgPgv5d d5xuPJdWhJOrv4cThBkBtJtGI3w8mQz6o8MH+SC7w+U6QsAwXd0dqtOdXDiyW6Uj1jvXkUYg OJj/kefDmwze6baOpgjiTWk2XW1gkVWzO2XNp5pzeg79xLm60jeXlyFXDMvdmTCmYhLB2UfH 5L5dOVUV7DWjEurH0vVBL2DVYibnTeQYBh7T/nsMQWjF2TUZRwrOXWvEY7Zz14MCAwEAAaMr MCkwGQYDVR0RBBIwEIEOcnVzbGFuZEBzY24ucnUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0B AQQFAAOBgQCgU3RLfxTR/SO3oLGk7mKb8cCT2uqYLusdywSiDh4xmc5tBe+u5p9gBatKz8dB 9dU+6Ey/aaxfhRa5QWj+K0DT/BvTNENp5QNH0/ff0vGwg4OYuW0FX0T5d9W8fJr3hORydS7l sxBQD5sFe0Olp8slfRnRy+wKCXs2SHCgyQOwujCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcN AQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNv bTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYD VQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkV cI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMG A1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZy ZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJp dmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIX oUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggM7MIIDNwIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIDCyqXMAkGBSsOAwIaBQCgggGnMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA0MDMyNDA0NDUzMFowIwYJKoZIhvcNAQkEMRYEFG98FHOycrJFr0Cf /bd74yXbKnxDMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFr MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLKpcw egYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg SXNzdWluZyBDQQIDCyqXMA0GCSqGSIb3DQEBAQUABIIBAIRGg5i1hFK2WhDKuM6E4ZDt7qct DcR4tv08mF3lNUtQpweYQvgR/E/29vcswrEsshl9zoXDkLnbdQK1jWTqFDeZzqwBSBOyLNSM mWhpO5o39a7bEN6ycX1uIbUWwKENsvCf7htkaDLoL8/Xj03RehdTwHQ13BR380zbCQqIg3Z3 KUfRlVDC7IgKf/55T1GmG/XLqP8apl9+6Kext/9akw6VXxmgdVVL4aBWuC2FsGCLOu6b4iEG sTUyhUNd9K9yHFbTG0sHfI1XyVXyCLFgq897v6QEyfO8/jWDui/5Y2Ycjr2s0dWKtSY55Sne X8lOSJWNk+QHEkmHQphKlVPZyzcAAAAAAAA= --------------ms090107090800040808040209-- From freeradius-devel@lists.freeradius.org Wed Mar 24 09:02:48 2004 From: freeradius-devel@lists.freeradius.org (Automatic cvs log generator) Date: Wed, 24 Mar 2004 03:02:48 -0600 (CST) Subject: Automatic report from sources (radiusd) between 23.03.2004 - 24.03.2004 GMT Message-ID: <20040324090248.3852D77460@webhost1.starnetusa.net> CVS log entries from 23.03.2004 (Tue) 09:00:01 - 24.03.2004 (Wed) 09:00:01 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/src/main/xlat.c; Revisions: 1.69 File: radiusd/src/main/valuepair.c; Revisions: 1.57 File: radiusd/src/include/request_list.h; Revisions: 1.8 File: radiusd/src/include/radiusd.h; Revisions: 1.153 ===================================================== Combined list of identical log entries ===================================================== Description: Preliminary support for xlat's of regex results: %{1}, %{2}, etc. Modified files: File: radiusd/src/include/radiusd.h; Revision: 1.153; Date: 2004/03/23 22:14:24; Author: aland; Lines: (+3 -1) File: radiusd/src/main/xlat.c; Revision: 1.69; Date: 2004/03/23 22:14:24; Author: aland; Lines: (+29 -2) ===================================================== Log entries ===================================================== Description: Include prototype for rl_add_proxy Modified files: File: radiusd/src/include/request_list.h; Revision: 1.8; Date: 2004/03/23 22:08:37; Author: aland; Lines: (+2 -1) ------------------------------- Description: For '=~', add the matching sub-strings to the request, as %{0}, %{1}, %{2}, etc. Modified files: File: radiusd/src/main/valuepair.c; Revision: 1.57; Date: 2004/03/23 22:19:31; Author: aland; Lines: (+50 -5) ===================================================== Summary of modified files ===================================================== File: radiusd/src/include/radiusd.h Revisions: 1.153 Authors: aland (+3 -1) ------------------------------- File: radiusd/src/include/request_list.h Revisions: 1.8 Authors: aland (+2 -1) ------------------------------- File: radiusd/src/main/valuepair.c Revisions: 1.57 Authors: aland (+50 -5) ------------------------------- File: radiusd/src/main/xlat.c Revisions: 1.69 Authors: aland (+29 -2) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl From freeradius-devel@lists.freeradius.org Wed Mar 24 15:03:34 2004 From: freeradius-devel@lists.freeradius.org (Pugnaloni Federico) Date: Wed, 24 Mar 2004 16:03:34 +0100 Subject: MySQL accounting and Cisco-AVPair Message-ID: <35E044CAD856D3119384204C4F4F502044FCCF@sittserver> Hi, i'm using FreeRADIUS Version 0.9.3on FreeBSD 4.9 i'm using with a Cisco PIX to AAA internet access it works fine, but i need to store the Cisco-AVPair ip protocol info in radacct SQL table. As i can see in the detail accounting freeradius store Cisco-AVPair info -snip- Cisco-AVPair = "ip:source-ip=192.168.0.127" Cisco-AVPair = "ip:source-port=4051" Cisco-AVPair = "ip:destination-ip=10.10.10.1" Cisco-AVPair = "ip:destination-port=23" -snip but i cannot store this info on sql I've tried to modify sql.conf as is: accounting_stop_query_alt = "INSERT into ${acct_table2} (RadAcctId, AcctSessionId... AcctStopDelay) values('', '%{Acct-Session-Id}', '%{Acct-Unique-Session-Id}', '%{SQL-User-Name}', '%{Realm}', '%{NAS-IP-Address}', '%{NAS-Port}'... '%{Cisco-AVPair}', '%{Cisco-AVPair}'..}')" but it returns only the first instance of Cisco-AVPair ("ip:source-ip=192.168.0.127") how can i store all the values? i've seen something about vsa_hack, but it seems works only with h323... -- Federico Pugnaloni From freeradius-devel@lists.freeradius.org Wed Mar 24 16:21:34 2004 From: freeradius-devel@lists.freeradius.org (Rok Papez) Date: Wed, 24 Mar 2004 17:21:34 +0100 Subject: simple_authentication in rlm_ldap Message-ID: <4061B58E.70307@arnes.si> Hello! I've added a simple_authentication to rlm_ldap when users are to be authenticated without searching the LDAP directory. This is a security feature. If user can bind to LDAP with his credentials, let him pass, otherwise fail him. This should also reduce the load on LDAP server significantly since it doesn't have to perform any searches. ldap_get_conn()/ldap_release_conn() do just locking and connection slot allocation. That's OK. But why is actual connection established in perform_search() with a call to ldap_connect(). It also seems a bit out of place to perform a rlm_bind() there. Wouldn't it be better to do: ldap_get_conn() ldap_establish_conn() ldap_bind() perform_search() ldap_unbind() ldap_release_conn() It seems ldap_bind() can be called recursively, if so, one could call ldap_establish_conn() only on first connection. --- src/modules/rlm_ldap/rlm_ldap.c.orig 2004-03-24 10:12:41.000000000 +0100 +++ src/modules/rlm_ldap/rlm_ldap.c 2004-03-24 16:54:30.000000000 +0100 @@ -251,6 +251,7 @@ int num_conns; int do_comp; int do_xlat; + int simple_authentication; /* authenticate user when simple bind is successfull, no search */ int default_allow; int failed_conns; int is_url; @@ -322,6 +323,7 @@ {"compare_check_items", PW_TYPE_BOOLEAN, offsetof(ldap_instance,do_comp), NULL, "no"}, {"access_attr_used_for_allow", PW_TYPE_BOOLEAN, offsetof(ldap_instance,default_allow), NULL, "yes"}, {"do_xlat", PW_TYPE_BOOLEAN, offsetof(ldap_instance,do_xlat), NULL, "yes"}, + {"simple_authentication", PW_TYPE_BOOLEAN, offsetof(ldap_instance,simple_authentication), NULL, "no"}, {NULL, -1, 0, NULL, NULL} }; @@ -1419,6 +1421,51 @@ DEBUG("rlm_ldap: login attempt by \"%s\" with password \"%s\"", request->username->strvalue, request->password->strvalue); + /* + * Simple authentication checks username/pass just by binding + * to the LDAP directory. No search is performed. + */ + if (inst->simple_authentication) { + char dn[MAX_FILTER_STR_LEN]; + int res; + + radlog (L_ERR, "rlm_ldap: Attempting simple authentication.\n"); + if (!radius_xlat(dn, sizeof(dn), inst->login, + request, NULL)) { + radlog (L_ERR, "rlm_ldap: unable to create base DN.\n"); + return RLM_MODULE_INVALID; + } + + if ((conn_id = ldap_get_conn(inst->conns,&conn,inst)) == -1){ + radlog(L_ERR, "rlm_ldap: All ldap connections are in use"); + return RLM_MODULE_FAIL; + } + + if (!conn->bound || conn->ld == NULL) { + DEBUG2("rlm_ldap: attempting LDAP reconnection"); + if (conn->ld) { + DEBUG2("rlm_ldap: closing existing LDAP connection"); + ldap_unbind_s(conn->ld); + } + /* connect also does a bind */ + if ((conn->ld = ldap_connect(instance, dn, request->password->strvalue, 1, &res)) == NULL) { + radlog(L_ERR, "rlm_ldap: (re)connection attempt failed"); + conn->failed_conns++; + return (RLM_MODULE_FAIL); + } + conn->bound = 1; + conn->failed_conns = 0; + } + -- Lep pozdrav, Rok Papez. From freeradius-devel@lists.freeradius.org Wed Mar 24 18:13:42 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Wed, 24 Mar 2004 13:13:42 -0500 Subject: PATCH -- Static linking issue, rlm_sql/drivers In-Reply-To: Your message of "Tue, 16 Mar 2004 12:59:50 +0100." <4056EC36.40507@arnes.si> Message-ID: <20040324181343.A4466170FA@mail.nitros9.org> Rok Papez wrote: > Has anyone had time to look at this ? It's actualy a trivial > patch... Should it be done in some other way ? Rather than add linking of SQL sub-module, you've deleted the ability to link EAP sub-modules. I've added a similar patch which permits both. Alan DeKok. From freeradius-devel@lists.freeradius.org Wed Mar 24 18:46:52 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Wed, 24 Mar 2004 13:46:52 -0500 Subject: Patch to radiusd.c In-Reply-To: Your message of "Mon, 23 Feb 2004 21:53:36 +0100." <403A6850.3040108@buelow-masiak.de> Message-ID: <20040324184652.C6A06170BB@mail.nitros9.org> Martin Seine wrote: > Just stepped again in a flaw in radiusd.c: First are the > commandline-Parameters processed and afterwards the configfile. That's so -d works. As for the command-line parameters which conflict with the config files, the easiest thing to do is to delete the command-line parameters. Alan DeKok. From freeradius-devel@lists.freeradius.org Wed Mar 24 19:08:33 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Wed, 24 Mar 2004 14:08:33 -0500 Subject: xlat question In-Reply-To: Your message of "Sun, 21 Mar 2004 00:38:08 +0300." <20040320213808.GF48678@dyatel.antar.bryansk.ru> Message-ID: <20040324190833.3DA94170BB@mail.nitros9.org> "Alexander M. Pravking" wrote: > Btw, Alan, INTEGER attributes are now always being looked up against > dictionary unless the value looks like numeric. It's probably a good > time to start consider Integer-Attr = "%{Some-Calculations}" as an > ordinary value, not as a dictionary value representation... Once we get dynamic expansion of double-quoted strings, we will get that for free. Alan DeKok. From freeradius-devel@lists.freeradius.org Thu Mar 25 08:29:46 2004 From: freeradius-devel@lists.freeradius.org (Rok Papez) Date: Thu, 25 Mar 2004 09:29:46 +0100 Subject: CVS-2004-02-26 fails to build, patch attached Was: PATCH -- Static linking issue, rlm_sql/drivers In-Reply-To: <20040324181343.A4466170FA@mail.nitros9.org> References: <20040324181343.A4466170FA@mail.nitros9.org> Message-ID: <4062987A.60602@arnes.si> Hello Alan. Alan DeKok wrote: > Rok Papez wrote: > >>Has anyone had time to look at this ? It's actualy a trivial >>patch... Should it be done in some other way ? > I've added a similar patch which permits both. I've tested your changes and they don't work here (build breaks): gcc -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -DOPENSSL_NO_KRB5 -Wall -D_GNU_SOURCE -g -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -W -Wredundant-decls -Wundef -I../include -DHOSTINFO=\"\" -DRADIUSD_VERSION=\"1.0.0-pre0\" -c mainconfig.c gmake[4]: *** No rule to make target `../modules/*/drivers/rlm_eap_md5/rlm_eap_md5.la', needed by `radiusd'. Stop. gmake[4]: Leaving directory `/usr/home/rok/radiusd-20040326/src/main' gmake[3]: *** [common] Error 1 gmake[3]: Leaving directory `/usr/home/rok/radiusd-20040326/src' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/usr/home/rok/radiusd-20040326/src' gmake[1]: *** [common] Error 1 gmake[1]: Leaving directory `/usr/home/rok/radiusd-20040326' make: *** [all] Error 2 It is nice that you've seperated the MODULES and SUBMODULES. However it seems you forgot to update the "echo" line after checking for a lib file (and vice verse). This patch fixes these typos: --- src/main/Makefile.in.orig 2004-03-25 08:04:18.000000000 +0100 +++ src/main/Makefile.in 2004-03-25 08:19:05.000000000 +0100 @@ -39,10 +39,10 @@ # MODULE_LIBS += $(shell for x in $(MODULES);do test -f ../modules/$$x/$$x.la && echo -dlpreopen ../modules/$$x/$$x.la;done) MODULE_LIBS += $(shell for x in $(SUB_MODULES);do test -f ../modules/*/types/$$x/$$x.la && echo -dlpreopen ../modules/*/types/$$x/$$x.la;done) -MODULE_LIBS += $(shell for x in $(SUB_MODULES);do test -f ../modules/*/drivers/$$x/$$x.la && echo -dlpreopen ../modules/*/types/$$x/$$x.la;done) +MODULE_LIBS += $(shell for x in $(SUB_MODULES);do test -f ../modules/*/drivers/$$x/$$x.la && echo -dlpreopen ../modules/*/drivers/$$x/$$x.la;done) MODULE_OBJS += $(shell for x in $(MODULES);do test -f ../modules/$$x/$$x.la && echo ../modules/$$x/$$x.la;done) MODULE_OBJS += $(shell for x in $(SUB_MODULES);do test -f ../modules/*/types/$$x/$$x.la && echo ../modules/*/types/$$x/$$x.la;done) -MODULE_OBJS += $(shell for x in $(SUB_MODULES);do test -f ../modules/*/types/$$x/$$x.la && echo ../modules/*/drivers/$$x/$$x.la;done) +MODULE_OBJS += $(shell for x in $(SUB_MODULES);do test -f ../modules/*/drivers/$$x/$$x.la && echo ../modules/*/drivers/$$x/$$x.la;done) endif LIBS += -lradius $(SNMP_LIBS) ================================================================================ > > > Rather than add linking of SQL sub-module, you've deleted the > ability to link EAP sub-modules. I must have missed something, where did I delete the linking of EAP sub modules ? This patch works for me and I'm using MySQL sql sub-module and EAP TLS and TTLS sub-modules :/. --- src/main/Makefile.in.orig 2004-03-12 15:50:55.000000000 +0100 +++ src/main/Makefile.in 2004-03-12 15:51:44.000000000 +0100 @@ -31,14 +31,17 @@ # MODULES += rlm_eap_md5 rlm_eap_leap rlm_eap_tls rlm_eap_ttls rlm_eap_sim MODULES += rlm_eap_peap rlm_eap_mschapv2 rlm_eap_gtc +MODULES += rlm_sql_db2 rlm_sql_freetds rlm_sql_iodbc rlm_sql_mysql rlm_sql_oracle rlm_sql_postgresql rlm_sql_sybase rlm_sql_unixodbc ifneq ($(OPENSSL_LIBS),) LIBS += -L$(OPENSSL_LIBS) -L../modules/rlm_eap/libeap -leap -lcrypto -lssl -lcrypto -lssl endif # MODULE_LIBS += $(shell for x in $(MODULES);do test -f ../modules/$$x/$$x.la && echo -dlpreopen ../modules/$$x/$$x.la;done) -MODULE_LIBS += $(shell for x in $(MODULES);do test -f ../modules/*/types/$$x/$$x.la && echo -dlpreopen ../modules/*/types/$$x/$$x.la;done) MODULE_OBJS += $(shell for x in $(MODULES);do test -f ../modules/$$x/$$x.la && echo ../modules/$$x/$$x.la;done) +MODULE_LIBS += $(shell for x in $(MODULES);do test -f ../modules/*/types/$$x/$$x.la && echo -dlpreopen ../modules/*/types/$$x/$$x.la;done) MODULE_OBJS += $(shell for x in $(MODULES);do test -f ../modules/*/types/$$x/$$x.la && echo ../modules/*/types/$$x/$$x.la;done) +MODULE_LIBS += $(shell for x in $(MODULES);do test -f ../modules/*/drivers/$$x/$$x.la && echo -dlpreopen ../modules/*/drivers/$$x/$$x.la;done) +MODULE_OBJS += $(shell for x in $(MODULES);do test -f ../modules/*/drivers/$$x/$$x.la && echo ../modules/*/drivers/$$x/$$x.la;done) endif LIBS += -lradius $(SNMP_LIBS) It seems you've mistaken the line reordering for a removal. I've done becouse it is easier to read (less prone to errors). -- Lep pozdrav, Rok Papez. From freeradius-devel@lists.freeradius.org Thu Mar 25 09:02:49 2004 From: freeradius-devel@lists.freeradius.org (Automatic cvs log generator) Date: Thu, 25 Mar 2004 03:02:49 -0600 (CST) Subject: Automatic report from sources (radiusd) between 24.03.2004 - 25.03.2004 GMT Message-ID: <20040325090249.5A0B77745B@webhost1.starnetusa.net> CVS log entries from 24.03.2004 (Wed) 09:00:01 - 25.03.2004 (Thu) 09:00:02 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/src/main/Makefile.in; Revisions: 1.26, 1.25 File: radiusd/raddb/Makefile; Revisions: 1.8 Author: pnixon File: radiusd/src/billing/cisco_h323_db_schema-postgres.sql; Revisions: 1.13, 1.12 File: radiusd/share/dictionary.cisco; Revisions: 1.12, 1.11 ===================================================== Log entries ===================================================== Description: Install eap.conf, too Modified files: File: radiusd/raddb/Makefile; Revision: 1.8; Date: 2004/03/25 03:28:47; Author: aland; Lines: (+1 -1) ------------------------------- Description: Some new Cisco VASs Modified files: File: radiusd/share/dictionary.cisco; Revision: 1.12; Date: 2004/03/25 08:49:05; Author: pnixon; Lines: (+5 -1) ------------------------------- Description: Add new VSAs for CISCO SIP PROXY SERVER as defined at http://www.cisco.com/en/US/products/sw/voicesw/ps2157/products_administration_guide_chapter09186a00800c7944.html Modified files: File: radiusd/share/dictionary.cisco; Revision: 1.11; Date: 2004/03/25 08:22:26; Author: pnixon; Lines: (+13 -1) ------------------------------- Description: update strip_dot function to return NULL if it receives a blank string Modified files: File: radiusd/src/billing/cisco_h323_db_schema-postgres.sql; Revision: 1.13; Date: 2004/03/24 14:50:33; Author: pnixon; Lines: (+12 -9) ------------------------------- Description: Change H323DisconnectCause from VARCHAR(2) to VARCHAR(20) because CSPS sends cause names instead of cause codes. Modified files: File: radiusd/src/billing/cisco_h323_db_schema-postgres.sql; Revision: 1.12; Date: 2004/03/24 13:56:28; Author: pnixon; Lines: (+2 -2) ------------------------------- Description: Better linking of sub-modules, and added support for static linking of SQL sub-modules Modified files: File: radiusd/src/main/Makefile.in; Revision: 1.26; Date: 2004/03/24 18:09:36; Author: aland; Lines: (+9 -5) ------------------------------- Description: Added extra LCRYPT, for systems which have problems linking otherwise (hello Interix) Modified files: File: radiusd/src/main/Makefile.in; Revision: 1.25; Date: 2004/03/24 18:06:28; Author: aland; Lines: (+2 -2) ===================================================== Summary of modified files ===================================================== File: radiusd/raddb/Makefile Revisions: 1.8 Authors: aland (+1 -1) ------------------------------- File: radiusd/share/dictionary.cisco Revisions: 1.12, 1.11 Authors: pnixon (+5 -1), pnixon (+13 -1) ------------------------------- File: radiusd/src/billing/cisco_h323_db_schema-postgres.sql Revisions: 1.13, 1.12 Authors: pnixon (+12 -9), pnixon (+2 -2) ------------------------------- File: radiusd/src/main/Makefile.in Revisions: 1.26, 1.25 Authors: aland (+9 -5), aland (+2 -2) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl From freeradius-devel@lists.freeradius.org Thu Mar 25 12:33:01 2004 From: freeradius-devel@lists.freeradius.org (Rok Papez) Date: Thu, 25 Mar 2004 13:33:01 +0100 Subject: Automatic report from sources (radiusd) between 24.03.2004 - 25.03.2004 GMT In-Reply-To: <20040325090249.5A0B77745B@webhost1.starnetusa.net> References: <20040325090249.5A0B77745B@webhost1.starnetusa.net> Message-ID: <4062D17D.50000@arnes.si> Hello! Automatic cvs log generator wrote: > Description: > Better linking of sub-modules, and added support for static > linking of SQL sub-modules > Modified files: > File: radiusd/src/main/Makefile.in; Revision: 1.26; > Date: 2004/03/24 18:09:36; Author: aland; Lines: (+9 -5) As noted in previous mail, compile fails, this is the fix: [rok@krkotnik rok]$ cat static_sql_driver_fix2.diff --- src/main/Makefile.in.orig 2004-03-25 08:04:18.000000000 +0100 +++ src/main/Makefile.in 2004-03-25 08:19:05.000000000 +0100 @@ -39,10 +39,10 @@ # MODULE_LIBS += $(shell for x in $(MODULES);do test -f ../modules/$$x/$$x.la && echo -dlpreopen ../modules/$$x/$$x.la;done) MODULE_LIBS += $(shell for x in $(SUB_MODULES);do test -f ../modules/*/types/$$x/$$x.la && echo -dlpreopen ../modules/*/types/$$x/$$x.la;done) -MODULE_LIBS += $(shell for x in $(SUB_MODULES);do test -f ../modules/*/drivers/$$x/$$x.la && echo -dlpreopen ../modules/*/types/$$x/$$x.la;done) +MODULE_LIBS += $(shell for x in $(SUB_MODULES);do test -f ../modules/*/drivers/$$x/$$x.la && echo -dlpreopen ../modules/*/drivers/$$x/$$x.la;done) MODULE_OBJS += $(shell for x in $(MODULES);do test -f ../modules/$$x/$$x.la && echo ../modules/$$x/$$x.la;done) MODULE_OBJS += $(shell for x in $(SUB_MODULES);do test -f ../modules/*/types/$$x/$$x.la && echo ../modules/*/types/$$x/$$x.la;done) -MODULE_OBJS += $(shell for x in $(SUB_MODULES);do test -f ../modules/*/types/$$x/$$x.la && echo ../modules/*/drivers/$$x/$$x.la;done) +MODULE_OBJS += $(shell for x in $(SUB_MODULES);do test -f ../modules/*/drivers/$$x/$$x.la && echo ../modules/*/drivers/$$x/$$x.la;done) endif LIBS += -lradius $(SNMP_LIBS) -- Lep pozdrav, Rok Papez. From freeradius-devel@lists.freeradius.org Thu Mar 25 15:30:50 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Thu, 25 Mar 2004 10:30:50 -0500 Subject: CVS-2004-02-26 fails to build, patch attached Was: PATCH -- Static linking issue, rlm_sql/drivers In-Reply-To: Your message of "Thu, 25 Mar 2004 09:29:46 +0100." <4062987A.60602@arnes.si> Message-ID: <20040325153050.1037316DF5@mail.nitros9.org> Rok Papez wrote: > I've tested your changes and they don't work here (build breaks): OK, I've fixed it, thanks. Alan DeKok. From freeradius-devel@lists.freeradius.org Thu Mar 25 17:38:48 2004 From: freeradius-devel@lists.freeradius.org (Kostas Kalevras) Date: Thu, 25 Mar 2004 19:38:48 +0200 (EET) Subject: simple_authentication in rlm_ldap In-Reply-To: <4061B58E.70307@arnes.si> References: <4061B58E.70307@arnes.si> Message-ID: <20040325193438.O71182@ajax.noc.ntua.gr> On Wed, 24 Mar 2004, Rok Papez wrote: > Hello! > > I've added a simple_authentication to rlm_ldap when > users are to be authenticated without searching the > LDAP directory. This is a security feature. If user > can bind to LDAP with his credentials, let him pass, > otherwise fail him. > This should also reduce the load on LDAP server > significantly since it doesn't have to perform any > searches. The patch is not needed. If you set Ldap-UserDN before authentication then rlm_ldap will use that and perform user authentication. So you only need to do something like this is the users file: DEFAULT Auth-Type := LDAP, Ldap-UserDN := "uid=%{User-Name},ou=people,dc=comapny,dc=com" > > ldap_get_conn()/ldap_release_conn() do just locking > and connection slot allocation. That's OK. But why > is actual connection established in perform_search() > with a call to ldap_connect(). It also seems a bit > out of place to perform a rlm_bind() there. Because we keep a connection pool and it seems the logical place for connection maintainance. > > Wouldn't it be better to do: > ldap_get_conn() > ldap_establish_conn() > ldap_bind() > perform_search() > ldap_unbind() That means that you open a new connection for each user authorization? Not good > ldap_release_conn() > > It seems ldap_bind() can be called recursively, > if so, one could call ldap_establish_conn() only > on first connection. > > --- src/modules/rlm_ldap/rlm_ldap.c.orig 2004-03-24 10:12:41.000000000 +0100 > +++ src/modules/rlm_ldap/rlm_ldap.c 2004-03-24 16:54:30.000000000 +0100 > @@ -251,6 +251,7 @@ > int num_conns; > int do_comp; > int do_xlat; > + int simple_authentication; /* authenticate user when simple bind is successfull, no search */ > int default_allow; > int failed_conns; > int is_url; > @@ -322,6 +323,7 @@ > {"compare_check_items", PW_TYPE_BOOLEAN, offsetof(ldap_instance,do_comp), NULL, "no"}, > {"access_attr_used_for_allow", PW_TYPE_BOOLEAN, offsetof(ldap_instance,default_allow), NULL, "yes"}, > {"do_xlat", PW_TYPE_BOOLEAN, offsetof(ldap_instance,do_xlat), NULL, "yes"}, > + {"simple_authentication", PW_TYPE_BOOLEAN, offsetof(ldap_instance,simple_authentication), NULL, "no"}, > > {NULL, -1, 0, NULL, NULL} > }; > @@ -1419,6 +1421,51 @@ > DEBUG("rlm_ldap: login attempt by \"%s\" with password \"%s\"", > request->username->strvalue, request->password->strvalue); > > + /* > + * Simple authentication checks username/pass just by binding > + * to the LDAP directory. No search is performed. > + */ > + if (inst->simple_authentication) { > + char dn[MAX_FILTER_STR_LEN]; > + int res; > + > + radlog (L_ERR, "rlm_ldap: Attempting simple authentication.\n"); > + if (!radius_xlat(dn, sizeof(dn), inst->login, > + request, NULL)) { > + radlog (L_ERR, "rlm_ldap: unable to create base DN.\n"); > + return RLM_MODULE_INVALID; > + } > + > + if ((conn_id = ldap_get_conn(inst->conns,&conn,inst)) == -1){ > + radlog(L_ERR, "rlm_ldap: All ldap connections are in use"); > + return RLM_MODULE_FAIL; > + } > + > + if (!conn->bound || conn->ld == NULL) { > + DEBUG2("rlm_ldap: attempting LDAP reconnection"); > + if (conn->ld) { > + DEBUG2("rlm_ldap: closing existing LDAP connection"); > + ldap_unbind_s(conn->ld); > + } > + /* connect also does a bind */ > + if ((conn->ld = ldap_connect(instance, dn, request->password->strvalue, 1, &res)) == NULL) { > + radlog(L_ERR, "rlm_ldap: (re)connection attempt failed"); > + conn->failed_conns++; > + return (RLM_MODULE_FAIL); > + } > + conn->bound = 1; > + conn->failed_conns = 0; > + } > + > > -- > Lep pozdrav, > Rok Papez. > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html > -- Kostas Kalevras Network Operations Center kkalev@noc.ntua.gr National Technical University of Athens, Greece Work Phone: +30 210 7721861 'Go back to the shadow' Gandalf From freeradius-devel@lists.freeradius.org Thu Mar 25 17:56:48 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Thu, 25 Mar 2004 12:56:48 -0500 (EST) Subject: We should release 1.0. Message-ID: <200403251756.i2PHumN05348@newgiles.nitros9.org> It's been too long since 0.9. We need to release 1.0. Any objections? I've out of the country next week, and won't be able to answer email then, but let's target the end of April for at least a pre-release. Alan DeKok. From freeradius-devel@lists.freeradius.org Thu Mar 25 17:58:48 2004 From: freeradius-devel@lists.freeradius.org (Gustavo A. Lozano) Date: Thu, 25 Mar 2004 12:58:48 -0500 Subject: We should release 1.0. In-Reply-To: <200403251756.i2PHumN05348@newgiles.nitros9.org> References: <200403251756.i2PHumN05348@newgiles.nitros9.org> Message-ID: <1080237528.1251.5.camel@Grissom.noldata.com> I think a single piece of documentation must be made before the 1.0 milestone. All the bunch of doc files contains no order for the newbie. Regards Gustavo On Thu, 2004-03-25 at 12:56, Alan DeKok wrote: > It's been too long since 0.9. We need to release 1.0. > > Any objections? > > I've out of the country next week, and won't be able to answer email > then, but let's target the end of April for at least a pre-release. > > Alan DeKok. > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html -- Gustavo A. Lozano Noldata Corporation glozano@noldata.com Calle 46 No. 40-19 CTO Bogota D.C. Colombia Noldata Corporation http://noldata.com I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones. Albert Einstein From freeradius-devel@lists.freeradius.org Thu Mar 25 18:05:39 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Thu, 25 Mar 2004 13:05:39 -0500 Subject: We should release 1.0. In-Reply-To: Your message of "Thu, 25 Mar 2004 12:58:48 EST." <1080237528.1251.5.camel@Grissom.noldata.com> Message-ID: <20040325180540.037F716DF5@mail.nitros9.org> "Gustavo A. Lozano" wrote: > I think a single piece of documentation must be made before the 1.0 > milestone. Ok... when will you have that done? Alan DeKok. From freeradius-devel@lists.freeradius.org Thu Mar 25 18:41:00 2004 From: freeradius-devel@lists.freeradius.org (Gustavo A. Lozano) Date: Thu, 25 Mar 2004 13:41:00 -0500 Subject: We should release 1.0. In-Reply-To: <20040325180540.037F716DF5@mail.nitros9.org> References: <20040325180540.037F716DF5@mail.nitros9.org> Message-ID: <1080240060.1251.16.camel@Grissom.noldata.com> Hahaha!! Better than a single person building a monolitic document I think we should define a documentation standard, so every single author can put his own piece under that standard and then a monolitic release will be very easy. As example if Mr Nice Guy is the author of the rlm_nice_module, then he must write the doc under some structure common to everybody: Module Name: rlm_nice_module Objective of the Module: Use the Nice database for accounting purposes. Release history for the module: Instructions to build-link the module: Software Reqs Step by Step instructions Configuration of the module Description of every section in the radius config Detailed explanation of every single line of configuration Example scenario: Known problems and resolutions: Author of the module and documentation: After that, may be somebody can raise the hand and say Ok I will the documentation Manager, I will build the monolitic manual after everybody conforms the sections as the standard says. So, if no one have anything to correct, change, reject, lets build the sample template for every chapter as I suggest and lets start conforming the general sections.... After that may be I will raise my hand and say: Hey! here is the 1.0 Official FreeRadius guide. Something from the project, not another oreilly book. Regards On Thu, 2004-03-25 at 13:05, Alan DeKok wrote: > "Gustavo A. Lozano" wrote: > > I think a single piece of documentation must be made before the 1.0 > > milestone. > > Ok... when will you have that done? > > Alan DeKok. > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html -- Gustavo A. Lozano Noldata Corporation glozano@noldata.com Calle 46 No. 40-19 CTO Bogota D.C. Colombia Noldata Corporation http://noldata.com I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones. Albert Einstein From freeradius-devel@lists.freeradius.org Thu Mar 25 19:05:12 2004 From: freeradius-devel@lists.freeradius.org (Chris Parker) Date: Thu, 25 Mar 2004 13:05:12 -0600 Subject: We should release 1.0. In-Reply-To: <1080240060.1251.16.camel@Grissom.noldata.com> References: <20040325180540.037F716DF5@mail.nitros9.org> <1080240060.1251.16.camel@Grissom.noldata.com> Message-ID: <6.0.3.0.2.20040325130447.037a7a60@mail.starnetusa.net> At 12:41 PM 3/25/2004, Gustavo A. Lozano wrote: >Hahaha!! > >Better than a single person building a monolitic document I think we >should define a documentation standard, so every single author can put >his own piece under that standard and then a monolitic release will be >very easy. You mean like the man pages? -Chris -- \\\|||/// \ StarNet Inc. \ Chris Parker \ ~ ~ / \ Wholesale Internet \ Director, Engineering | @ @ | \ http://www.starnetusa.net \ (847) 963-0116 oOo---(_)---oOo--\------------------------------------------------------ \ Outpace the Competition - http://www.getmespeed.com From freeradius-devel@lists.freeradius.org Thu Mar 25 19:31:16 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Thu, 25 Mar 2004 14:31:16 -0500 Subject: We should release 1.0. In-Reply-To: Your message of "Thu, 25 Mar 2004 13:41:00 EST." <1080240060.1251.16.camel@Grissom.noldata.com> Message-ID: <20040325193116.66A6A16DF5@mail.nitros9.org> "Gustavo A. Lozano" wrote: > Better than a single person building a monolitic document I think we > should define a documentation standard, so every single author can put > his own piece under that standard "man" pages. Chris started on a number of man pages. There are more modules in the "doc" directory which should be turned into "man" pages. Alan DeKok. From freeradius-devel@lists.freeradius.org Thu Mar 25 20:06:28 2004 From: freeradius-devel@lists.freeradius.org (Wolfgang Hottgenroth) Date: Thu, 25 Mar 2004 21:06:28 +0100 Subject: Contribute module rlm_cdb Message-ID: Hi, I like to contribute a module rlm_cdb I've implemented, closely derived from Andrei's rlm_dbm module and which we are using in a project with a huge amount of users (about 1,000,000). The module uses Bernstein's CDB as backend. I invite you to have a look: http:/www.hottis.de/freeradius Comments are most welcome. Cheers, Wolfgang From freeradius-devel@lists.freeradius.org Thu Mar 25 21:05:23 2004 From: freeradius-devel@lists.freeradius.org (Gustavo A. Lozano) Date: Thu, 25 Mar 2004 16:05:23 -0500 Subject: We should release 1.0. In-Reply-To: <20040325193116.66A6A16DF5@mail.nitros9.org> References: <20040325193116.66A6A16DF5@mail.nitros9.org> Message-ID: <1080248722.1244.2.camel@Grissom.noldata.com> Dont think so. Most software has manpages and a manual, and both are different... On Thu, 2004-03-25 at 14:31, Alan DeKok wrote: > "Gustavo A. Lozano" wrote: > > Better than a single person building a monolitic document I think we > > should define a documentation standard, so every single author can put > > his own piece under that standard > > "man" pages. > > Chris started on a number of man pages. There are more modules in > the "doc" directory which should be turned into "man" pages. > > Alan DeKok. > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html -- Gustavo A. Lozano Noldata Corporation glozano@noldata.com Calle 46 No. 40-19 CTO Bogota D.C. Colombia Noldata Corporation http://noldata.com I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones. Albert Einstein From freeradius-devel@lists.freeradius.org Thu Mar 25 21:17:32 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Thu, 25 Mar 2004 16:17:32 -0500 Subject: We should release 1.0. In-Reply-To: Your message of "Thu, 25 Mar 2004 16:05:23 EST." <1080248722.1244.2.camel@Grissom.noldata.com> Message-ID: <20040325211732.7A24D16DF5@mail.nitros9.org> "Gustavo A. Lozano" wrote: > Most software has manpages and a manual, and both are different... We need both. Right now, we don't have "man" pages for many modules. "Man" pages are a priority over a manual. For a simple manual, the RADIUS book is sufficient. Alan DeKok. From freeradius-devel@lists.freeradius.org Thu Mar 25 21:37:41 2004 From: freeradius-devel@lists.freeradius.org (Paul Hampson) Date: Fri, 26 Mar 2004 08:37:41 +1100 Subject: We should release 1.0. In-Reply-To: <200403251756.i2PHumN05348@newgiles.nitros9.org> Message-ID: > From: Alan DeKok > Sent: Friday, 26 March 2004 4:57 AM > It's been too long since 0.9. We need to release 1.0. > Any objections? > I've out of the country next week, and won't be able to answer email > then, but let's target the end of April for at least a pre-release. I'm down with that. I was just thinking about it myself, actually. Well, shall we consider April to be a month of developer-stabilisation? Less worry about missing features, and instead hunt your most and least favorite bugs. And write documentation. And update the ChangeLog with things you've done and forgotten to document. (I'll see if I can find time to cruise through the CVS commit history for any missing gems as well.) And get people to build things on the weirdest architectures they can. This means you, OpenBSD! :-) If we're happy with this, we need to post to the -users list, reminding people of bugzilla, and to go report things there. This includes things like unclear/absent documentation which would otherwise just become a complaint on the list. (I suspect... :-) On the topic of Bugzilla, maybe we should go through and mark things that won't be done before 1.0.0 (difficult features or whatever) with 'LATER'? Alternatively, make that "We need to release 1.0.0" dependant on any other show-stopping bugs... (Assuming we get nasty bugs people have failed to report...) If we branch for -pre1 on May first. (Or so) We can hopefully ship a -pre every week, with final release of 1.0.0 at the beginning of June. This'll give us four weeks of user testing... Obviously it has to be flexible. :-) (I must say I'd hoped to autoconf2.5-ise the build system for 1.0.0 but I won't have time to do that sort of hackery until June anyway, so right after 1.0.0 ships seems like a good time to do it. That way if things get broken, people can use 1.0.0 without losing functionality.) -- Paul "TBBle" Hampson Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@PObox.Com On a sidewalk near Portland State University someone wrote `Trust Jesus', and someone else wrote `But Cut the Cards'. From freeradius-devel@lists.freeradius.org Thu Mar 25 22:01:45 2004 From: freeradius-devel@lists.freeradius.org (Michael Griego) Date: Thu, 25 Mar 2004 16:01:45 -0600 Subject: We should release 1.0. In-Reply-To: References: Message-ID: <1080252105.30962.61.camel@enterprise.utdallas.edu> Paul's schedule sounds great to me. -- --Mike ----------------------------------- Michael Griego Wireless LAN Project Manager The University of Texas at Dallas From freeradius-devel@lists.freeradius.org Fri Mar 26 02:39:44 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Thu, 25 Mar 2004 21:39:44 -0500 Subject: We should release 1.0. In-Reply-To: Your message of "Fri, 26 Mar 2004 08:37:41 +1100." Message-ID: <20040326023944.E88DE16DF5@mail.nitros9.org> "Paul Hampson" wrote: > Well, shall we consider April to be a month of developer-stabilisation? Sounds good to me. > (I'll see if I can find time to cruise through the CVS commit history > for any missing gems as well.) I think I've done most of that. > If we're happy with this, we need to post to the -users list, reminding > people of bugzilla, and to go report things there. This includes things > like unclear/absent documentation which would otherwise just become a > complaint on the list. (I suspect... :-) As release coordinator, I think hat's a great idea for you to do. :) Also, the "credits.html" file on the web page needs to be edited to look pretty. > On the topic of Bugzilla, maybe we should go through and mark things > that won't be done before 1.0.0 (difficult features or whatever) with > 'LATER'? Alternatively, make that "We need to release 1.0.0" dependant > on any other show-stopping bugs... (Assuming we get nasty bugs people > have failed to report...) Yes. The problem is that most bugs are listed against 2-3 people. > If we branch for -pre1 on May first. (Or so) We can hopefully ship a > -pre every week, with final release of 1.0.0 at the beginning of June. > This'll give us four weeks of user testing... Obviously it has to be > flexible. :-) This plan should be included on any post to -users. > (I must say I'd hoped to autoconf2.5-ise the build system for 1.0.0 > but I won't have time to do that sort of hackery until June anyway, > so right after 1.0.0 ships seems like a good time to do it. That way > if things get broken, people can use 1.0.0 without losing functionality.) Yuck. Leave autoconf weirdness for later. Alan DeKok. From freeradius-devel@lists.freeradius.org Fri Mar 26 06:24:49 2004 From: freeradius-devel@lists.freeradius.org (Paul Hampson) Date: Fri, 26 Mar 2004 17:24:49 +1100 Subject: Preparation for 1.0.0 release of FreeRADIUS Message-ID: OK, the good news is we're well on track. For the month of April, the developers of FreeRADIUS will be focussing on stabilisation and bug-fixing of FreeRADIUS to prepare for releasing version 1.0.0. What we would like you, the users, to do be diligent in reporting bugs into Bugzilla (http://bugs.freeradius.org) so we know what problems you're having. We're particularly focussed on bugs in the current CVS snapshots ftp://ftp.freeradius.org/pub/radius/CVS-snapshots/ until we start the 1.0.0 pre-release cycle. If all goes well, we will branch freeradius 1.0.0 at the beginning of May, and produce a series of 1.0.0-preX releases for _everyone_ to hammer upon, even those terrified of CVS snapshots. I'm hoping to post Debian i386 packages of the various -preX versions, to make it easy for everyone to test against. Presumably someone will knock up packages for any other packaging systems around. Again if all goes well, we will go through four prereleases in four weeks and release 1.0.0 at the beginning of June. So, here's a summary timeline: Now Users report bugs. Brave ("willing to compile") users test CVS Snapshots. Beginning of May CVS branch for FreeRADIUS 1.0 is created. FreeRADIUS 1.0.0-pre0 is released, packages are created, and users are encouraged to _really_ hammer upon it. This means you, users of esoteric systems! As bugs are fixed, -pre1 and such are released. Beginning of June, barring unforseen circumstances FreeRADIUS 1.0.0 ships! This version comes under strict version management, and new and interesting features go into CVS HEAD again, for brave ("willing to compile") users to play with. So, that's the plan. What, you wanted bad news to with the good news? Sorry, I haven't got = any. :-) -- Paul "TBBle" Hampson Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@PObox.Com On a sidewalk near Portland State University someone wrote `Trust Jesus', and someone else wrote `But Cut the Cards'. From freeradius-devel@lists.freeradius.org Fri Mar 26 07:28:02 2004 From: freeradius-devel@lists.freeradius.org (Malcolm Caldwell) Date: Fri, 26 Mar 2004 16:58:02 +0930 Subject: regex broken in current cvs Message-ID: <1080286081.5419.13.camel@localhost.localdomain> Hello, regex is broken in current cvs. The problem is the code that substitutes %{0} %{1} etc is called even if no matches are found. On my redhat system the structure that has the offsets etc for the matches is not valid if there were no matches. The following patch fixes this for me. (All that was needed was an if( arround the substitution code.) Index: valuepair.c =================================================================== RCS file: /source/radiusd/src/main/valuepair.c,v retrieving revision 1.57 diff -u -r1.57 valuepair.c --- valuepair.c 23 Mar 2004 22:19:31 -0000 1.57 +++ valuepair.c 26 Mar 2004 07:23:16 -0000 @@ -369,43 +369,48 @@ 16, rxmatch, 0); regfree(®); - /* - * Add %{0}, %{1}, etc. - */ - for (i = 0; i < 16; i++) { - char *p; - char buffer[sizeof(check_item->strvalue)]; + if (compare==0) { /* - * -1 is end of matching. + * Add %{0}, %{1}, etc. */ - if (rxmatch[i].rm_so == -1) break; + for (i = 0; i < 16; i++) { + char *p; + char buffer[sizeof(check_item->strvalue)]; + + /* + * -1 is end of matching. + */ + if (rxmatch[i].rm_so == -1) break; - /* - * Copy substring into buffer. - */ - memcpy(buffer, - auth_item->strvalue + rxmatch[i].rm_so, - rxmatch[i].rm_eo); - buffer[rxmatch[i].rm_eo] = '\0'; - - /* - * Copy substring, and add it to - * the request. - * - * Note that we don't check - * for out of memory, which is - * the only error we can get... - */ - p = strdup(buffer); - request_data_add(request, - request, - REQUEST_DATA_REGEX | i, - p, free); + /* + * Copy substring into buffer. + */ + memcpy(buffer, + auth_item->strvalue + rxmatch[i].rm_so, + rxmatch[i].rm_eo); + buffer[rxmatch[i].rm_eo] = '\0'; + + /* + * Copy substring, and add it to + * the request. + * + * Note that we don't check + * for out of memory, which is + * the only error we can get... + */ + p = strdup(buffer); + request_data_add(request, + request, + REQUEST_DATA_REGEX | i, + p, free); + } + + } else { + result = -1; } - } - if (compare != 0) result = -1; break; + } case T_OP_REG_NE: regcomp(®, (char *)check_item->strvalue, REG_EXTENDED|REG_NOSUB); From freeradius-devel@lists.freeradius.org Fri Mar 26 09:02:46 2004 From: freeradius-devel@lists.freeradius.org (Automatic cvs log generator) Date: Fri, 26 Mar 2004 03:02:46 -0600 (CST) Subject: Automatic report from sources (radiusd) between 25.03.2004 - 26.03.2004 GMT Message-ID: <20040326090246.922DC7745D@webhost1.starnetusa.net> CVS log entries from 25.03.2004 (Thu) 09:00:02 - 26.03.2004 (Fri) 09:00:01 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/man/man5/rlm_expr.5; Revisions: 1.2 File: radiusd/configure.in; Revisions: 1.196 File: radiusd/man/man5/rlm_always.5; Revisions: 1.2 File: radiusd/man/man5/rlm_acct_unique.5; Revisions: 1.3, 1.2 File: radiusd/man/man5/rlm_detail.5; Revisions: 1.2 File: radiusd/doc/rlm_mschap; Revisions: 1.7 File: radiusd/man/man5/rlm_unix.5; Revisions: 1.2 File: radiusd/doc/ChangeLog; Revisions: 1.48 File: radiusd/src/main/Makefile.in; Revisions: 1.27 File: radiusd/doc/rlm_expr; Revisions: 1.3 File: radiusd/src/main/request_list.c; Revisions: 1.30 File: radiusd/doc/rlm_acct_unique; Revisions: 1.4 File: radiusd/doc/rlm_always; Revisions: 1.2 File: radiusd/configure; Revisions: 1.93 File: radiusd/doc/rlm_detail; Revisions: 1.10 File: radiusd/doc/rlm_unix; Revisions: 1.2 File: radiusd/man/man5/rlm_mschap.5; Revisions: 1.2 Author: phampson File: radiusd/raddb/oraclesql.conf; Revisions: 1.3 File: radiusd/man/man5/rlm_sql.5; Revisions: 1.2 File: radiusd/doc/ChangeLog; Revisions: 1.47 File: radiusd/src/billing/pgsql-voip.conf; Revisions: 1.9 File: radiusd/man/man8/radiusd.8; Revisions: 1.9 File: radiusd/raddb/mssql.conf; Revisions: 1.6 File: radiusd/raddb/sql.conf; Revisions: 1.36 File: radiusd/src/modules/rlm_sql/rlm_sql.c; Revisions: 1.124 File: radiusd/raddb/postgresql.conf; Revisions: 1.15 File: radiusd/src/modules/rlm_sql/conf.h; Revisions: 1.18 ===================================================== Combined list of identical log entries ===================================================== Description: We now have a man page Modified files: File: radiusd/doc/rlm_detail; Revision: 1.10; Date: 2004/03/25 19:23:03; Author: aland; Lines: (+0 -0) File: radiusd/man/man5/rlm_detail.5; Revision: 1.2; Date: 2004/03/25 19:23:04; Author: aland; Lines: (+27 -15) ------------------------------- Description: Add accounting_update_query_alt to rlm_sql, to catch lost start packets earlier than the eventual stop packet. Modified files: File: radiusd/doc/ChangeLog; Revision: 1.47; Date: 2004/03/25 11:33:07; Author: phampson; Lines: (+2 -1) File: radiusd/man/man5/rlm_sql.5; Revision: 1.2; Date: 2004/03/25 11:31:17; Author: phampson; Lines: (+3 -1) File: radiusd/raddb/mssql.conf; Revision: 1.6; Date: 2004/03/25 11:31:17; Author: phampson; Lines: (+5 -1) File: radiusd/raddb/oraclesql.conf; Revision: 1.3; Date: 2004/03/25 11:31:18; Author: phampson; Lines: (+5 -1) File: radiusd/raddb/postgresql.conf; Revision: 1.15; Date: 2004/03/25 11:31:18; Author: phampson; Lines: (+14 -0) File: radiusd/raddb/sql.conf; Revision: 1.36; Date: 2004/03/25 11:31:18; Author: phampson; Lines: (+5 -1) File: radiusd/src/billing/pgsql-voip.conf; Revision: 1.9; Date: 2004/03/25 11:31:18; Author: phampson; Lines: (+2 -0) File: radiusd/src/modules/rlm_sql/conf.h; Revision: 1.18; Date: 2004/03/25 11:31:18; Author: phampson; Lines: (+1 -0) File: radiusd/src/modules/rlm_sql/rlm_sql.c; Revision: 1.124; Date: 2004/03/25 11:31:18; Author: phampson; Lines: (+28 -8) ------------------------------- Description: We now have man pages Modified files: File: radiusd/doc/rlm_always; Revision: 1.2; Date: 2004/03/25 19:17:30; Author: aland; Lines: (+0 -0) File: radiusd/doc/rlm_expr; Revision: 1.3; Date: 2004/03/25 19:25:37; Author: aland; Lines: (+1 -1) File: radiusd/doc/rlm_mschap; Revision: 1.7; Date: 2004/03/25 21:22:28; Author: aland; Lines: (+0 -0) File: radiusd/doc/rlm_unix; Revision: 1.2; Date: 2004/03/25 21:11:57; Author: aland; Lines: (+0 -0) File: radiusd/man/man5/rlm_always.5; Revision: 1.2; Date: 2004/03/25 19:17:30; Author: aland; Lines: (+36 -2) File: radiusd/man/man5/rlm_expr.5; Revision: 1.2; Date: 2004/03/25 19:25:37; Author: aland; Lines: (+31 -10) File: radiusd/man/man5/rlm_mschap.5; Revision: 1.2; Date: 2004/03/25 21:22:28; Author: aland; Lines: (+53 -3) File: radiusd/man/man5/rlm_unix.5; Revision: 1.2; Date: 2004/03/25 21:11:57; Author: aland; Lines: (+12 -8) ------------------------------- Description: Interix requires -D_ALL_SOURCE, for reasons known only to them. Modified files: File: radiusd/configure; Revision: 1.93; Date: 2004/03/25 18:01:13; Author: aland; Lines: (+142 -136) File: radiusd/configure.in; Revision: 1.196; Date: 2004/03/25 18:01:13; Author: aland; Lines: (+12 -1) ===================================================== Log entries ===================================================== Description: Updates Modified files: File: radiusd/doc/ChangeLog; Revision: 1.48; Date: 2004/03/25 17:13:40; Author: aland; Lines: (+15 -2) ------------------------------- Description: We now have a man page. Updates should go there Modified files: File: radiusd/doc/rlm_acct_unique; Revision: 1.4; Date: 2004/03/25 19:08:04; Author: aland; Lines: (+0 -0) ------------------------------- Description: More updates Modified files: File: radiusd/man/man5/rlm_acct_unique.5; Revision: 1.3; Date: 2004/03/25 19:14:36; Author: aland; Lines: (+11 -1) ------------------------------- Description: A bit of updates Modified files: File: radiusd/man/man5/rlm_acct_unique.5; Revision: 1.2; Date: 2004/03/25 19:07:31; Author: aland; Lines: (+13 -6) ------------------------------- Description: Document -v option. Modified files: File: radiusd/man/man8/radiusd.8; Revision: 1.9; Date: 2004/03/25 11:38:35; Author: phampson; Lines: (+3 -0) ------------------------------- Description: Corrected typos, where 'test -f' didn't match 'echo' Modified files: File: radiusd/src/main/Makefile.in; Revision: 1.27; Date: 2004/03/25 15:23:49; Author: aland; Lines: (+3 -3) ------------------------------- Description: Made rbtree code handling for proxying request live. Chris Brotsos says that it's slower, but ~8 seconds over 50K requests, which is negligible. Having proper locking allows us to handle ID's on proxy packets better. Modified files: File: radiusd/src/main/request_list.c; Revision: 1.30; Date: 2004/03/25 17:05:55; Author: aland; Lines: (+28 -95) ===================================================== Summary of modified files ===================================================== File: radiusd/configure Revisions: 1.93 Authors: aland (+142 -136) ------------------------------- File: radiusd/configure.in Revisions: 1.196 Authors: aland (+12 -1) ------------------------------- File: radiusd/doc/ChangeLog Revisions: 1.48, 1.47 Authors: aland (+15 -2), phampson (+2 -1) ------------------------------- File: radiusd/doc/rlm_acct_unique Revisions: 1.4 Authors: aland (+0 -0) ------------------------------- File: radiusd/doc/rlm_always Revisions: 1.2 Authors: aland (+0 -0) ------------------------------- File: radiusd/doc/rlm_detail Revisions: 1.10 Authors: aland (+0 -0) ------------------------------- File: radiusd/doc/rlm_expr Revisions: 1.3 Authors: aland (+1 -1) ------------------------------- File: radiusd/doc/rlm_mschap Revisions: 1.7 Authors: aland (+0 -0) ------------------------------- File: radiusd/doc/rlm_unix Revisions: 1.2 Authors: aland (+0 -0) ------------------------------- File: radiusd/man/man5/rlm_acct_unique.5 Revisions: 1.3, 1.2 Authors: aland (+11 -1), aland (+13 -6) ------------------------------- File: radiusd/man/man5/rlm_always.5 Revisions: 1.2 Authors: aland (+36 -2) ------------------------------- File: radiusd/man/man5/rlm_detail.5 Revisions: 1.2 Authors: aland (+27 -15) ------------------------------- File: radiusd/man/man5/rlm_expr.5 Revisions: 1.2 Authors: aland (+31 -10) ------------------------------- File: radiusd/man/man5/rlm_mschap.5 Revisions: 1.2 Authors: aland (+53 -3) ------------------------------- File: radiusd/man/man5/rlm_sql.5 Revisions: 1.2 Authors: phampson (+3 -1) ------------------------------- File: radiusd/man/man5/rlm_unix.5 Revisions: 1.2 Authors: aland (+12 -8) ------------------------------- File: radiusd/man/man8/radiusd.8 Revisions: 1.9 Authors: phampson (+3 -0) ------------------------------- File: radiusd/raddb/mssql.conf Revisions: 1.6 Authors: phampson (+5 -1) ------------------------------- File: radiusd/raddb/oraclesql.conf Revisions: 1.3 Authors: phampson (+5 -1) ------------------------------- File: radiusd/raddb/postgresql.conf Revisions: 1.15 Authors: phampson (+14 -0) ------------------------------- File: radiusd/raddb/sql.conf Revisions: 1.36 Authors: phampson (+5 -1) ------------------------------- File: radiusd/src/billing/pgsql-voip.conf Revisions: 1.9 Authors: phampson (+2 -0) ------------------------------- File: radiusd/src/main/Makefile.in Revisions: 1.27 Authors: aland (+3 -3) ------------------------------- File: radiusd/src/main/request_list.c Revisions: 1.30 Authors: aland (+28 -95) ------------------------------- File: radiusd/src/modules/rlm_sql/conf.h Revisions: 1.18 Authors: phampson (+1 -0) ------------------------------- File: radiusd/src/modules/rlm_sql/rlm_sql.c Revisions: 1.124 Authors: phampson (+28 -8) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl From freeradius-devel@lists.freeradius.org Fri Mar 26 16:19:10 2004 From: freeradius-devel@lists.freeradius.org (Alan DeKok) Date: Fri, 26 Mar 2004 11:19:10 -0500 Subject: regex broken in current cvs In-Reply-To: Your message of "Fri, 26 Mar 2004 16:58:02 +0930." <1080286081.5419.13.camel@localhost.localdomain> Message-ID: <20040326161910.B45B016DF5@mail.nitros9.org> Malcolm Caldwell wrote: > The problem is the code that substitutes %{0} %{1} etc is called even if > no matches are found. On my redhat system the structure that has the > offsets etc for the matches is not valid if there were no matches. Ok.. > The following patch fixes this for me. (All that was needed was an if( > arround the substitution code.) It has another issue, too. If you do a regex compare with 4 returned values, and a later one with 2, the existing code still leaves %{3} and %{4} around. They should be deleted. The easiest way to fix both problems is a ~10 line patch, inside of the loop. I'll commit something in a little while. Alan DeKok. From freeradius-devel@lists.freeradius.org Sat Mar 27 09:02:46 2004 From: freeradius-devel@lists.freeradius.org (Automatic cvs log generator) Date: Sat, 27 Mar 2004 03:02:46 -0600 (CST) Subject: Automatic report from sources (radiusd) between 26.03.2004 - 27.03.2004 GMT Message-ID: <20040327090246.B9CFA774E5@webhost1.starnetusa.net> CVS log entries from 26.03.2004 (Fri) 09:00:01 - 27.03.2004 (Sat) 09:00:02 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/src/main/xlat.c; Revisions: 1.70 File: radiusd/src/main/valuepair.c; Revisions: 1.58 File: radiusd/doc/variables.txt; Revisions: 1.12 ===================================================== Combined list of identical log entries ===================================================== Description: Allow only 0..8. When we have a new match, delete all references to old matches. If we didn't have a match, don't reference the rxmatch array, and delete all references to old matches Modified files: File: radiusd/src/main/valuepair.c; Revision: 1.58; Date: 2004/03/26 16:16:11; Author: aland; Lines: (+21 -6) File: radiusd/src/main/xlat.c; Revision: 1.70; Date: 2004/03/26 16:16:11; Author: aland; Lines: (+4 -4) ===================================================== Log entries ===================================================== Description: Documented %{0} etc. Modified files: File: radiusd/doc/variables.txt; Revision: 1.12; Date: 2004/03/26 19:18:17; Author: aland; Lines: (+23 -2) ===================================================== Summary of modified files ===================================================== File: radiusd/doc/variables.txt Revisions: 1.12 Authors: aland (+23 -2) ------------------------------- File: radiusd/src/main/valuepair.c Revisions: 1.58 Authors: aland (+21 -6) ------------------------------- File: radiusd/src/main/xlat.c Revisions: 1.70 Authors: aland (+4 -4) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl From freeradius-devel@lists.freeradius.org Sun Mar 28 17:26:54 2004 From: freeradius-devel@lists.freeradius.org (Kevin Bonner) Date: Sun, 28 Mar 2004 11:26:54 -0500 Subject: Preparation for 1.0.0 release of FreeRADIUS In-Reply-To: References: Message-ID: <200403281126.56528.keb@pa.net> =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Any plan to remove the deprecated files (clients, naslist, naspasswd, realm= s)=20 for the 1.0.0 version, or is that scheduled for sometime later? Kevin Bonner =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAZvzO/9i/ml3OBYMRAonrAJwIiIg3Z3/LQENlDjfUosyrJURpqwCff0dj hwfq69NCCTLDAaH3E4t+iNw=3D =3D/XU5 =2D----END PGP SIGNATURE----- From freeradius-devel@lists.freeradius.org Sun Mar 28 23:11:27 2004 From: freeradius-devel@lists.freeradius.org (Paul Hampson) Date: Mon, 29 Mar 2004 08:11:27 +1000 Subject: Preparation for 1.0.0 release of FreeRADIUS In-Reply-To: <200403281126.56528.keb@pa.net> References: <200403281126.56528.keb@pa.net> Message-ID: <20040328221127.GA30392@yurika.videohost.com.au> On Sun, Mar 28, 2004 at 11:26:54AM -0500, Kevin Bonner wrote: > Any plan to remove the deprecated files (clients, naslist, naspasswd, realms) > for the 1.0.0 version, or is that scheduled for sometime later? Post 1.0.0. Pretty much the moment we branch, I expect. -- Paul "TBBle" Hampson, on an alternate email client From freeradius-devel@lists.freeradius.org Tue Mar 30 00:42:17 2004 From: freeradius-devel@lists.freeradius.org (Peter Nixon) Date: Tue, 30 Mar 2004 02:42:17 +0300 Subject: Preparation for 1.0.0 release of FreeRADIUS In-Reply-To: <20040328221127.GA30392@yurika.videohost.com.au> References: <200403281126.56528.keb@pa.net> <20040328221127.GA30392@yurika.videohost.com.au> Message-ID: <200403300242.18713.listuser@peternixon.net> =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 29 March 2004 01:11, Paul Hampson wrote: > On Sun, Mar 28, 2004 at 11:26:54AM -0500, Kevin Bonner wrote: > > Any plan to remove the deprecated files (clients, naslist, naspasswd, > > realms) for the 1.0.0 version, or is that scheduled for sometime later? > > Post 1.0.0. Pretty much the moment we branch, I expect. Sound reasonable to me. Version 1.0 should support "old" style radius still= =2E. =2D --=20 Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAaLRZAcdsUt9pJjwRAlUwAKCWeZ69M3hVmhJvlY4a7mSG4vXiWgCgzgAo 6jbhKgo3Qi0rHUJd52x0Qd0=3D =3Dgug+ =2D----END PGP SIGNATURE----- From freeradius-devel@lists.freeradius.org Tue Mar 30 01:09:33 2004 From: freeradius-devel@lists.freeradius.org (Peter Nixon) Date: Tue, 30 Mar 2004 03:09:33 +0300 Subject: MySQL accounting and Cisco-AVPair In-Reply-To: <35E044CAD856D3119384204C4F4F502044FCCF@sittserver> References: <35E044CAD856D3119384204C4F4F502044FCCF@sittserver> Message-ID: <200403300309.35279.listuser@peternixon.net> =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 24 March 2004 17:03, Pugnaloni Federico wrote: > Hi, > i'm using FreeRADIUS Version 0.9.3on FreeBSD 4.9 > i'm using with a Cisco PIX to AAA internet access > it works fine, but i need to store the Cisco-AVPair ip protocol info in > radacct SQL table. > > As i can see in the detail accounting freeradius store Cisco-AVPair info > > -snip- > Cisco-AVPair =3D "ip:source-ip=3D192.168.0.127" > Cisco-AVPair =3D "ip:source-port=3D4051" > Cisco-AVPair =3D "ip:destination-ip=3D10.10.10.1" > Cisco-AVPair =3D "ip:destination-port=3D23" > -snip > > but i cannot store this info on sql > I've tried to modify sql.conf as is: > > accounting_stop_query_alt =3D "INSERT into ${acct_table2} (RadAcctId, > AcctSessionId... AcctStopDelay) values('', '%{Acct-Session-Id}', > '%{Acct-Unique-Session-Id}', '%{SQL-User-Name}', '%{Realm}', > '%{NAS-IP-Address}', '%{NAS-Port}'... '%{Cisco-AVPair}', > '%{Cisco-AVPair}'..}')" > > but it returns only the first instance of Cisco-AVPair > ("ip:source-ip=3D192.168.0.127") > > how can i store all the values? > > i've seen something about vsa_hack, but it seems works only with h323... Alan, I think this needs to be added to the dictionary to work properly, bu= t=20 does FreeRADIUS support dictionary values with colon (:) in them? http://cisco.com/en/US/products/sw/secursw/ps2086/products_user_guide_chapt= er09186a0080102172.html#1657 Vendor-Specific 26 Allows vendors to support their own extended attributes. The Cisco RADIUS=20 implementation supports one vendor-specific option using the format=20 recommended in the specification. The Cisco vendor-ID is 9, and the support= ed=20 option is vendor-type 1, cisco-avpair. The value is a string of the format: protocol:attribute sep value protocol is a value of the Cisco protocol attribute for a particular type o= f=20 authorization. Attribute and value are an appropriate AV pair defined in th= e=20 Cisco TACACS+ specification, and "sep" is "=3D" for mandatory attributes an= d=20 "*" for optional attributes. This allows the full set of TACACS+=20 authorization features to be used for RADIUS. The following is an example: cisco-avpair=3D "ip:addr-pool=3Dfirst" cisco-avpair=3D "shell:priv-lvl=3D15" The first example causes the Cisco multiple named IP address pools feature = to=20 be activated during IP authorization (during PPP IPCP address assignment).= =20 The second example causes a user of a device-hosted administrative session = to=20 have immediate access to EXEC commands. =2D --=20 Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAaLq9AcdsUt9pJjwRAlAiAKCtt+MeU4KrPDRuCdb5RSxdG0iMIQCgt3aQ DpNYwNF67vMDkv12eSKwGM0=3D =3DlzyG =2D----END PGP SIGNATURE----- From freeradius-devel@lists.freeradius.org Tue Mar 30 00:41:17 2004 From: freeradius-devel@lists.freeradius.org (Peter Nixon) Date: Tue, 30 Mar 2004 02:41:17 +0300 Subject: We should release 1.0. In-Reply-To: References: Message-ID: <200403300241.25681.listuser@peternixon.net> =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 25 March 2004 23:37, Paul Hampson wrote: > > From: Alan DeKok > > Sent: Friday, 26 March 2004 4:57 AM > > > > It's been too long since 0.9. We need to release 1.0. > > > > Any objections? > > > > I've out of the country next week, and won't be able to answer email > > then, but let's target the end of April for at least a pre-release. > > I'm down with that. I was just thinking about it myself, actually. > > Well, shall we consider April to be a month of developer-stabilisation? > > Less worry about missing features, and instead hunt your most and > least favorite bugs. And write documentation. And update the > ChangeLog with things you've done and forgotten to document. Luckily I have recently had someone pay for me to spend some time working o= n=20 the VoIP accounting configs. I have committed a bunch of cleanups and suppo= rt=20 for Cisco SIP gear as well as H323 gear. I am hoping to clean up the docs=20 some more before 1.0 also but it will depend on my work schedule. I few SuSE build script updates from the upcoming SuSE 9.1 need to be=20 committed this week also. Thanks goes to the guys at SuSE. You know who you= =20 are :-) > (I'll see if I can find time to cruise through the CVS commit history > for any missing gems as well.) > > And get people to build things on the weirdest architectures they > can. This means you, OpenBSD! :-) If I have time I shall try to build it on some OSX boxes I have at my dispo= sal=20 currently. > If we're happy with this, we need to post to the -users list, reminding > people of bugzilla, and to go report things there. This includes things > like unclear/absent documentation which would otherwise just become a > complaint on the list. (I suspect... :-) > > On the topic of Bugzilla, maybe we should go through and mark things > that won't be done before 1.0.0 (difficult features or whatever) with > 'LATER'? Alternatively, make that "We need to release 1.0.0" dependant > on any other show-stopping bugs... (Assuming we get nasty bugs people > have failed to report...) > > If we branch for -pre1 on May first. (Or so) We can hopefully ship a > -pre every week, with final release of 1.0.0 at the beginning of June. > This'll give us four weeks of user testing... Obviously it has to be > flexible. :-) > > (I must say I'd hoped to autoconf2.5-ise the build system for 1.0.0 > but I won't have time to do that sort of hackery until June anyway, > so right after 1.0.0 ships seems like a good time to do it. That way > if things get broken, people can use 1.0.0 without losing functionality.) Pity. I would be nice to have the whole build system work on current versio= ns=20 of Linux.. Oh well :-( =2D --=20 Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAaLQjAcdsUt9pJjwRAnvqAKD0sm7biwldgCcDDU9iP9N412UHzQCdHjdg tWbuyJdO3sFO6gP6n2VYqEE=3D =3DiSMo =2D----END PGP SIGNATURE----- From freeradius-devel@lists.freeradius.org Tue Mar 30 03:59:41 2004 From: freeradius-devel@lists.freeradius.org (freeradius-devel@lists.freeradius.org) Date: Tue, 30 Mar 2004 02:59:41 GMT Subject: '%{NAS-Port}' vs. NASPortId INTEGER Message-ID: <20040330025941.19213.qmail@mail.ruralnetwork.net> I believe I have found some code that needs to be updated to reflect that NAS-Port is not necessarily an integer. Specifically, using rlm_sql with a Postgresql 7.4.1 backend and the Freeradius 20040327 snapshot, an administrative login to a Livingston Portmaster 2e sends accounting packets to freeradius with a empty NASPortID value. As of Postgresql 7.4.0, trying to insert an empty value into an integer field throws an error. (Older versions of Postgresql would automagically insert a 0 instead.) Here is the log: postgres[7475]: [905-1] ERROR: invalid input syntax for integer: "" postgres[7475]: [905-2] STATEMENT: INSERT into radacct ^I^I(AcctSessionId, AcctUniqueId, UserName, Realm, NASIPAddress, NASPortId, NASPortType, postgres[7475]: [905-3] AcctStartTime, AcctAuthentic,^I^IConnectInfo_start, CalledStationId, CallingStationId, ServiceType, FramedProtocol, postgres[7475]: [905-4] FramedIPAddress, AcctStartDelay) ^I^Ivalues('41000008', '04d75732c2c3d0fd', 'admin', '', '66.232.94.250', ^I^I'', '', (now() - postgres[7475]: [905-5] '0'::interval), 'Local', '', ^I^I'', '', 'Administrative-User', '', ^I^INULLIF('', '')::inet, '0') postgres[7475]: [906-1] DEBUG: AbortCurrentTransaction postgres[30710]: [904-1] DEBUG: child process (PID 7475) exited with exit code 0 If I modify the definition of the NASPortId field for the raddct table in the db_postgresql.sql file from: NASPortId INTEGER, to: NASPortId VARCHAR(32), the problme seems to go away and freeradius continues to work normally. The other database drivers for freeradius also define NASPortId as an integer. -- Scott Langley scott@ruralnetwork.net Systems AdministratorNASPortId Rural Network Services From freeradius-devel@lists.freeradius.org Tue Mar 30 06:13:59 2004 From: freeradius-devel@lists.freeradius.org (Matthew Schumacher) Date: Mon, 29 Mar 2004 20:13:59 -0900 Subject: '%{NAS-Port}' vs. NASPortId INTEGER In-Reply-To: <20040330025941.19213.qmail@mail.ruralnetwork.net> References: <20040330025941.19213.qmail@mail.ruralnetwork.net> Message-ID: <40690217.3080801@aptalaska.net> Scott, If you change your data type then you are inserting a null value into your database. It is generally much better to use a value for 0 or null. If you use %{NAS-Port:-0} then it will use %{NAS-Port} except when it is missing where it will use 0 as the default. HTH, schu scott@ruralnetwork.net wrote: > I believe I have found some code that needs to be updated to reflect > that NAS-Port is not necessarily an integer. > Specifically, using rlm_sql with a Postgresql 7.4.1 backend and the > Freeradius 20040327 snapshot, an administrative login to a Livingston > Portmaster 2e sends accounting packets to freeradius with a empty > NASPortID value. As of Postgresql 7.4.0, trying to insert an empty > value into an integer field throws an error. (Older versions of > Postgresql would automagically insert a 0 instead.) > Here is the log: > postgres[7475]: [905-1] ERROR: invalid input syntax for integer: "" > postgres[7475]: [905-2] STATEMENT: INSERT into radacct > ^I^I(AcctSessionId, AcctUniqueId, UserName, Realm, NASIPAddress, > NASPortId, NASPortType, > postgres[7475]: [905-3] AcctStartTime, > AcctAuthentic,^I^IConnectInfo_start, CalledStationId, CallingStationId, > ServiceType, FramedProtocol, > postgres[7475]: [905-4] FramedIPAddress, AcctStartDelay) > ^I^Ivalues('41000008', '04d75732c2c3d0fd', 'admin', '', '66.232.94.250', > ^I^I'', '', (now() - > postgres[7475]: [905-5] '0'::interval), 'Local', '', ^I^I'', '', > 'Administrative-User', '', ^I^INULLIF('', '')::inet, '0') > postgres[7475]: [906-1] DEBUG: AbortCurrentTransaction > postgres[30710]: [904-1] DEBUG: child process (PID 7475) exited with > exit code 0 > If I modify the definition of the NASPortId field for the raddct table > in the db_postgresql.sql file > from: > NASPortId INTEGER, > to: > NASPortId VARCHAR(32), > the problme seems to go away and freeradius continues to work normally. > The other database drivers for freeradius also define NASPortId as an > integer. > -- > Scott Langley > scott@ruralnetwork.net > Systems AdministratorNASPortId > Rural Network Services > > - List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/devel.html > From freeradius-devel@lists.freeradius.org Tue Mar 30 08:04:32 2004 From: freeradius-devel@lists.freeradius.org (Malcolm Caldwell) Date: Tue, 30 Mar 2004 16:34:32 +0930 Subject: regex broken in current cvs In-Reply-To: <1080286081.5419.13.camel@localhost.localdomain> References: <1080286081.5419.13.camel@localhost.localdomain> Message-ID: <1080630272.6341.4.camel@localhost.localdomain> Alan's change still does not fix things properly: I get a segfault on the case where the regex fails compleatly eg DEFAULT User-Name =~ "^s[0-9]+$" When receiving a request with User-Name of "fred" segfaults. On line fix. diff -u -r1.58 valuepair.c --- valuepair.c 26 Mar 2004 16:16:11 -0000 1.58 +++ valuepair.c 30 Mar 2004 06:59:09 -0000 @@ -380,7 +380,7 @@ * Didn't match: delete old * match, if it existed. */ - if ((compare == 0) || + if ((compare != 0) || (rxmatch[i].rm_so == -1)) { p = request_data_get(request, request, REQUEST_DATA_REGEX | i); From freeradius-devel@lists.freeradius.org Tue Mar 30 16:20:27 2004 From: freeradius-devel@lists.freeradius.org (=?iso-8859-1?q?Aurelien=20Magniez?=) Date: Tue, 30 Mar 2004 17:20:27 +0200 (CEST) Subject: Problem of c++ module instantiation Message-ID: <20040330152028.83534.qmail@web40406.mail.yahoo.com> Hi, I'm working on a new EAP method and the latest snapshot of FreeRadius. In this context, I would like to use C++ for many reasons. I found an old thread (http://lists.cistron.nl/pipermail/freeradius-devel/2003-September/005877.html) which gives a patch in order to use a C++ module. I also modified the following files, ie adding (if defined(__cplusplus)....) : eap.h eap_types.h rlm_eap.h The compilation and the linking phase is ok. I have the rlm_eap_psk.la file. But when I launch radius, I have the following message : Failed to link ... : file not found (but the file is in the right directory) I'm not sure that I did all the required modifications in order to manage c++ module. Thanks for your help. Aurelien Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout ! Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/ Dialoguez en direct avec vos amis grâce à Yahoo! Messenger !Téléchargez Yahoo! Messenger sur http://fr.messenger.yahoo.com From freeradius-devel@lists.freeradius.org Wed Mar 31 09:32:57 2004 From: freeradius-devel@lists.freeradius.org (=?iso-8859-1?Q?Pascal_S=E9guy?=) Date: Wed, 31 Mar 2004 10:32:57 +0200 Subject: Problem of c++ module instantiation References: <20040330152028.83534.qmail@web40406.mail.yahoo.com> Message-ID: <002301c416fa$dac42820$05ca10ac@chinook> ----- Original Message -----=20 From: "Aurelien Magniez" To: Sent: Tuesday, March 30, 2004 5:20 PM Subject: Problem of c++ module instantiation > > The compilation and the linking phase is ok. I have > the rlm_eap_psk.la file. > > But when I launch radius, I have the following message > : Failed to link ... : file not found > (but the file is in the right directory) I have written many modules in C++ with this patch (on FreeBSD 4x). Be shure to "make install" in your modules/rlm_... directory. --- Pascal S=E9guy From freeradius-devel@lists.freeradius.org Wed Mar 31 11:13:45 2004 From: freeradius-devel@lists.freeradius.org (Wolfgang Hottgenroth) Date: Wed, 31 Mar 2004 12:13:45 +0200 Subject: Modification of rlm_cdb module Message-ID: Hi, I've slightly modified the rlm_cdb module (which I like to contribute). All directly CDB related code was separated into an extra module (rlm_cdbaccess), which provides no functionality directly usable through the radiusd.con but only functions to be used by other modules. (Just like rlm_expr, as far as I can see ...) This rlm_cdbaccess is self-contained, all required source files and headers to read the CDB are included, following the proposal by Bernstein. It just must be added to the modules section without any configuration and to the instantiate section. The usage of the rlm_cdb has not changed, just the build process. Since rlm_cdbaccess is self-contained and rlm_cdb only uses rlm_cdbaccess no configure is required, just make. The code, documentation for both modules and a patch to be applied against 0.9.3 is available at http://www.hottis.de/freeradius Once again I invite you to have a look. Could you give me some advice what I have to do to get this into the 'official' FreeRADIUS source tree? Thanks, Wolfgang From freeradius-devel@lists.freeradius.org Wed Mar 31 13:19:15 2004 From: freeradius-devel@lists.freeradius.org (Paul Hampson) Date: Wed, 31 Mar 2004 22:19:15 +1000 Subject: Modification of rlm_cdb module In-Reply-To: References: Message-ID: <20040331121914.GA27434@yurika.videohost.com.au> On Wed, Mar 31, 2004 at 12:13:45PM +0200, Wolfgang Hottgenroth wrote: > I've slightly modified the rlm_cdb module (which I like to contribute). > All directly CDB related code was separated into an extra module > (rlm_cdbaccess), which provides no functionality directly usable > through the radiusd.con but only functions to be used by other > modules. (Just like rlm_expr, as far as I can see ...) > This rlm_cdbaccess is self-contained, all required source files and > headers to read the CDB are included, following the proposal by > Bernstein. > It just must be added to the modules section without any configuration > and to the instantiate section. > The usage of the rlm_cdb has not changed, just the build > process. Since rlm_cdbaccess is self-contained and rlm_cdb only uses > rlm_cdbaccess no configure is required, just make. > The code, documentation for both modules and a patch to be applied > against 0.9.3 is available at http://www.hottis.de/freeradius > Once again I invite you to have a look. > Could you give me some advice what I have to do to get this into the > 'official' FreeRADIUS source tree? The first piece of advice would be to create a patch against CVS Head, since the people who're most likely to test it are those who're building CVS Head builds every so often. Does your patch also update the config files and documentation (as appropriate?) I'm not totally up on CDB, I'm guessing it's something like DBM/GDBM? Would it make sense to abstract the DBM backend from the front end, so we can have rlm_dbm which has backends for DBM, GDBM and CDB? (Like rlm_sql is) Also, what is the license of CDB? I'd prefer to use a shared library if such is common. If I recall correctly, DJ Bernstein releases software that is not compatible with the GPL, so there's prolly a thorny license issue here. The other thing I can suggest is to convince someone else to use it. Once we have some good testimonials, it'll have a shot at going into CVS. If it's not too intrusive, and it comes together before mid-April, you _might_ (that's _might_. Entirely at the whimsy of the developers. :-) make into the 1.0.0 release. Just some thoughts. I've no time to review the code myself this week. -- Paul "TBBle" Hampson, on an alternate email client. From freeradius-devel@lists.freeradius.org Wed Mar 31 14:17:34 2004 From: freeradius-devel@lists.freeradius.org (Wolfgang Hottgenroth) Date: Wed, 31 Mar 2004 15:17:34 +0200 Subject: Modification of rlm_cdb module In-Reply-To: <20040331121914.GA27434@yurika.videohost.com.au> References: <20040331121914.GA27434@yurika.videohost.com.au> Message-ID: At Wed, 31 Mar 2004 22:19:15 +1000, Paul Hampson wrote: > > On Wed, Mar 31, 2004 at 12:13:45PM +0200, Wolfgang Hottgenroth wrote: > > I've slightly modified the rlm_cdb module (which I like to contribute). > > [...] > > Could you give me some advice what I have to do to get this into the > > 'official' FreeRADIUS source tree? > > The first piece of advice would be to create a patch against CVS Head, > [...] Thank you for that advice. I will provide a patch against CVS HEAD soon. No problem at all, since only files are added (expect raddb/experimental.conf). config (experimental.conf) is patched too, documentation is also provided, using the 'template' posted to this list by Gustavo few days ago. The patch will also add this documentation files. manpages are currently not available. > I'm not totally up on CDB, I'm guessing it's something like DBM/GDBM? > > Would it make sense to abstract the DBM backend from the front end, > so we can have rlm_dbm which has backends for DBM, GDBM and CDB? > (Like rlm_sql is) It is something like that indeed and that kind of abstraction makes definitely sense. Although I would like it a bit different: rlm_sql has its drivers below in the directory hierarchy. I've separated the cdb access code into its own module since I'll come with another module also using cdb files soon and this one should share code with the current rlm_cdb. So, what I would like to have these associative database drivers with an abstraction layer on top on the "main" module level (I mean: in src/modules), reachable for more than one other module. > Also, what is the license of CDB? I'd prefer to use a shared library > if such is common. If I recall correctly, DJ Bernstein releases > software that is not compatible with the GPL, so there's prolly a > thorny license issue here. Well. GPL is it definitely not. I've re-read it multiple times, since I also don't want to get in conflict with Bernstein when putting this stuff on my webpage and what I understood is: the tarball and the build environment may be use and distributed unmodified but the source code is in the public domain. Doesn't this mean: 'take it and do what you like with it'? This is also what I've understood from the docs of the freecdb Debian package and the FreeBSD cdb port. > The other thing I can suggest is to convince someone else to use it. > Once we have some good testimonials, it'll have a shot at going into Well. I'll try. Ah: it compiles and works without problems on Linux, FreeBSD, Solaris 6 and Solaris 8. For my employer we are using this modules in a project with about 500,000 accounts. Thanks so far, Wolfgang From freeradius-devel@lists.freeradius.org Wed Mar 31 22:16:25 2004 From: freeradius-devel@lists.freeradius.org (D greene) Date: Wed, 31 Mar 2004 21:16:25 +0000 Subject: freeradius and cygwin - install errors Message-ID: Hello all, First thanks to those for finally getting it to compile w/o errors under cygwin w/o patches! (I'm using latest snapshot 3-31-04) However I did notice that although there were no errors the following modules weren't built: rlm_krb5, rlm_ldap, rlm_pam And I'm having problems with "make install" with the following modules: rlm_dbm: install-sh -c -m 755 rlm_dbm_parser /usr/local/bin cp: `rlm_dbm_parser' and `/usr/local/bin/#inst.2372#' are the same file rlm_eap: install-sh -c -m 755 radeapclient /usr/local/bin cp: `radeapclient' and `/usr/local/bin/#inst.1508#' are the same file rlm_ippool: install-sh -c -m 755 rlm_ippool_tool /usr/local/bin cp: `rlm_ippool_tool' and `/usr/local/bin/#inst.3452#' are the same file rlm_mschap: install-sh -c -m 755 smbencrypt /usr/local/bin cp: `smbencrypt' and `/usr/local/bin/#inst.3304#' are the same file thanks, dgreene _________________________________________________________________ MSN Toolbar provides one-click access to Hotmail from any Web page – FREE download! http://toolbar.msn.com/go/onm00200413ave/direct/01/