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

buffered-sql patch
by Ben Wiechman 05 Feb '10

05 Feb '10

Minor update to the detail filename to make it consistent with the example in decoupled-accounting. Ben

1 0

GIT Log for 2010-02-05 00:33 GMT
by aland＠deployingradius.com 04 Feb '10

04 Feb '10

commit 30c03d55e0e587777b043174c78b76461ba4bde5 Author: Alan T. DeKok <aland(a)freeradius.org> Date: Thu Feb 4 18:09:22 2010 +0100 Fixes to build without TCP Files changed: src/lib/packet.c | 9 +++++++++ src/main/client.c | 6 +----- src/main/event.c | 17 +++++++++++++++-- 3 files changed, 25 insertions(+), 7 deletions(-) ====================================================================== commit fc8b4513c6dc367339651663c0ce2db1f04691ce Author: Alan T. DeKok <aland(a)freeradius.org> Date: Thu Feb 4 08:50:37 2010 +0100 Added note on global CA Files changed: raddb/eap.conf | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) ====================================================================== commit efa03059b2be34253a3ada47f00b12216bbdbe38 Author: Alan T. DeKok <aland(a)freeradius.org> Date: Thu Feb 4 08:45:12 2010 +0100 Make MS-CHAP call xlat on NT-Hash and LM-Password This moves the "expand variable" code to the correct place. Files changed: src/modules/rlm_mschap/rlm_mschap.c | 29 +++++++++++++++++++++++------ src/modules/rlm_pap/rlm_pap.c | 7 +++---- 2 files changed, 26 insertions(+), 10 deletions(-) ====================================================================== commit 98292c0e3010bd9123a8afbea04ba80edce3e5c8 Author: Alan T. DeKok <aland(a)freeradius.org> Date: Sat Jan 23 10:08:55 2010 +0100 in pairmake_any(), value may be NULL Files changed: src/lib/valuepair.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) ====================================================================== commit e0308aed7c6537d26b6c7a3bced88370c0baa8be Author: Alan T. DeKok <aland(a)freeradius.org> Date: Sat Jan 23 09:05:21 2010 +0100 As posted to the list Files changed: share/dictionary | 1 + share/dictionary.wichorus | 16 ++++++++++++++++ 2 files changed, 17 insertions(+), 0 deletions(-) ====================================================================== commit 7fe7b2acf923345f8893c034a0d2cf3a19d54f45 Author: Alan T. DeKok <aland(a)freeradius.org> Date: Fri Jan 22 13:40:30 2010 +0100 Added more 'const', and changed stats to %u Some tests showed that the stats went over 2^31... and then they went negative Files changed: src/modules/frs_control/frs_control.c | 32 ++++++++++++++++---------------- 1 files changed, 16 insertions(+), 16 deletions(-) ====================================================================== commit 1eb5a9f3fd373a5758209d093b33f229b2613072 Author: Alan T. DeKok <aland(a)freeradius.org> Date: Fri Jan 22 13:40:16 2010 +0100 Added more 'const' Files changed: src/include/conffile.h | 8 ++++---- src/main/conffile.c | 10 +++++----- 2 files changed, 9 insertions(+), 9 deletions(-) ====================================================================== commit 21a4dcaebba1596c3eb67e2a629c28883ede11a0 Author: Alan T. DeKok <aland(a)freeradius.org> Date: Fri Jan 22 10:41:46 2010 +0100 Set flag CORRECTLY for resumed session Files changed: src/modules/rlm_eap/libeap/eap_tls.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) ====================================================================== commit 595657f053d7ceb5bb34c96156ed1f9279fbb05c Author: Alan T. DeKok <aland(a)freeradius.org> Date: Thu Jan 21 11:37:21 2010 +0100 Add statistics for detail listeners, too Files changed: src/include/detail.h | 3 + src/modules/frs_control/frs_control.c | 69 +++++++++++++++++++++++++++++++++ src/modules/frs_detail/frs_detail.c | 10 +++++ 3 files changed, 82 insertions(+), 0 deletions(-) ====================================================================== commit 174f0f675c30b9e50831f8e86029307b0625e621 Author: Alan T. DeKok <aland(a)freeradius.org> Date: Thu Feb 4 08:59:53 2010 +0100 Check for allocation failure Files changed: src/main/util.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) ====================================================================== commit 4c18f64d826006a452aff6ef18a8904d88d534c2 Author: Alan T. DeKok <aland(a)freeradius.org> Date: Thu Feb 4 08:57:26 2010 +0100 Print the request number on every log line. Files changed: src/main/log.c | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-) ====================================================================== commit b4093cf1fb4d8fd09b7bbafae8838a5368c93b99 Author: Alan T. DeKok <aland(a)freeradius.org> Date: Thu Feb 4 08:55:43 2010 +0100 More useful errors track total number of open sockets, and print "too many sockets" if there are too many Files changed: src/lib/packet.c | 18 ++++++++++++++++-- 1 files changed, 16 insertions(+), 2 deletions(-) ======================================================================

1 0

Re: [trivial PATCH 11/22] [extern.h] eliminate build warnings
by WANG Tinggong 04 Feb '10

04 Feb '10

Frank Cusack wrote: >This applies to patches 11-16. > >Having these be individual unrelated patches is very annoying. It's >very difficult to review because the change in prototype is not in >the same change as the change to the functions. So I haven't done >a thorough job, but for once I am going to blame the author instead >of my own laziness. > >This just looks like churn to me. You change the types of vars from >char to unsigned char, but then cast them back when they are used. > >In at least 2 cases where I caught it, the change in var type is >incorrect and you are just making a trivial change without understanding >the effects other than to quiet the compiler on your system. Yes, that is my original intention. I clone the branch and compile it, after my compiler show warnings to me, i just submit these patches without a moment's thought and it's too impetuous. > >There may be at least one change that was correct, and that would only >have been the case if a radius structure member changed its signedness. >Because of the difficulty of reviewing the changes I'm not going >to try to go back and pick out where I thought that might have >been the case. > >I have in the past been extremely diligent about not having any >compiler warnings so I'm surprised that rlm_otp is generating any >noise. There must be one member in a radius struct somewhere that >changed and that is filtering down. In my opinion, a compiler warning may led to a potentional bug, for example, int a = -1; unsigned int b = 1; (a > b) ? printf("yes") : printf("no"); then compiler tell us "warning: comparison between signed and unsigned", if we ignore it, then -1 > 1, that's not expected. so i'm accustomed to fix all warning. thanks for your review! Tinggong

2 1

pam_radius_auth on Mac OS 10.6.2 - patch attached
by Stefan Winter 04 Feb '10

04 Feb '10

Hi, to my own surprise, I got pam_radius_auth 1.3.17 compiled and running on Mac OS X 10.6.2. It needed some minor source code changes and guesswork in the Makefile. I've attached a patch which shows the difference. The new Makefile will then have a new target make mac Please review the patch - especially where entropy in the random number generater is reduced. Greetings, Stefan Winter

3 6

Build error with -DWITHOUT_TCP
by WANG Tinggong 04 Feb '10

04 Feb '10

Hi all, After add -DWITHOUT_TCP flag in src/main/Makefile: CFLAGS += -DWITHOUT_TCP I got an error: client.c: In function 'client_find_old': client.c:498: error: too few arguments to function 'client_find' I fixed it with a patch below and compiled it again, more errors show up. event.c:635: warning: no previous prototype for 'revive_home_server' event.c:853: warning: no previous prototype for 'mark_home_server_dead' event.c: In function 'event_new_fd': event.c:3453: error: 'rad_listen_t' has no member named 'count' event.c:3455: error: 'remove_all_requests' undeclared (first use in this function) event.c:3455: error: (Each undeclared identifier is reported only once event.c:3455: error: for each function it appears in.) event.c:3458: error: 'rad_listen_t' has no member named 'count' event.c:3465: error: 'rad_listen_t' has no member named 'count' event.c:3483: error: 'rad_listen_t' has no member named 'count' event.c:3486: error: 'remove_all_proxied_requests' undeclared (first use in this function) event.c:3488: error: 'rad_listen_t' has no member named 'count' event.c:3544: error: 'rad_listen_t' has no member named 'count' event.c:3560: error: 'rad_listen_t' has no member named 'count' event.c:3582: error: 'listen_socket_t' has no member named 'ev' event.c:3600: error: 'rad_listen_t' has no member named 'count' event.c:3636: error: 'listen_socket_t' has no member named 'ev' event.c:3636: error: 'listen_socket_t' has no member named 'ev' event.c: In function 'handle_signal_self': event.c:3732: error: 'tcp_socket_lifetime' undeclared (first use in this function) event.c:3737: error: 'tcp_socket_idle_timeout' undeclared (first use in this function) event.c:3741: error: 'listen_socket_t' has no member named 'ev' make: *** [event.lo] Error 1 I've fetched the newest stable tree, what's wrong? Here is the patch for client.c:498: error: too few arguments to function 'client_find' thanks Tinggong --- diff --git a/src/main/client.c b/src/main/client.c index 247ce1d..596b09e 100644 --- a/src/main/client.c +++ b/src/main/client.c @@ -489,14 +489,17 @@ RADCLIENT *client_find(const RADCLIENT_LIST *clients, /* * Old wrapper for client_find */ +#ifdef WITH_TCP RADCLIENT *client_find_old(const fr_ipaddr_t *ipaddr) { - return client_find(root_clients, ipaddr -#ifdef WITH_TCP - , IPPROTO_UDP -#endif - ); + return client_find(root_clients, ipaddr, IPPROTO_TCP); +} +#else +RADCLIENT *client_find_old(const fr_ipaddr_t *ipaddr) +{ + return client_find(root_clients, ipaddr, IPPROTO_UDP); } +#endif static struct in_addr cl_ip4addr; static struct in6_addr cl_ip6addr; -- 1.6.0.6

2 2

Re: [trivial PATCH 01/22] [libradius.h] eliminate build warnings
by WANG Tinggong 04 Feb '10

04 Feb '10

>WANG Tinggong wrote: >> Alan DeKok wrote: >>> Many of the rest are minor, and have no impact other than messages >>> when building. i.e. these are low priority items. >> Agree! But i have a question, as a user, what's your opion about a program >> producing warning messages? > > As I said, they are minor. > > I would rather have minor warning messages than hacks to "fix" them. >Any fix should be the *correct* fix, and not simple changes just to stop >the warnings. > Yes, you are right! I apologize for the "fix". Tinggong

1 0

Re: [trivial PATCH 01/22] [libradius.h] eliminate build warnings
by WANG Tinggong 04 Feb '10

04 Feb '10

Alan DeKok wrote: > > Here's my review: > > Patches 01, (and related) > 19, 20 > - Don't put changes to a function prototype in a *separate* patch > from changes to the source file. This breaks the build. > > Patches 11, 12, 13, 14, 15, 16 > - OTP code. I'll let Frank review them. > > Patches 05, 06, 07, 08, 10, > - adding function prototypes to remove warnings is good. > But they belong in a header file, not in a C file. > > Many of the rest are minor, and have no impact other than messages >when building. i.e. these are low priority items. Agree! But i have a question, as a user, what's your opion about a program producing warning messages? thanks for your review! Tinggong

2 1

freeradius-client sequence file replacement
by Alex Massover 04 Feb '10

04 Feb '10

Hello, I made a patch that adds fast locking mechanisms instead of seq file for freeradius-client. This patch is based on putting the sequence number in the shared memory. Two approaches used to do a mutual exclusion for shared memory: a) GCC builtin atomic memory access (only on Intel) b) POSIX named semaphore Fallback: c) If nothing of the above available it fallbacks to a sequence file locks. Originally I did it against radiusclient-ng, but looks that freeradius-client is a correct place. The patch works for freeradius-client 1.1.6 as well. Here's a patch and more detailed description: http://developer.berlios.de/patch/?func=detailpatch&patch_id=2810&group_id=… -- Best Regards, Alex Massover VoIP R&D TL Jajah Inc. This mail was sent via Mail-SeCure System.

2 9

xlat failure in 2.1.8 (worked in 2.1.6)
by Stefan Winter 04 Feb '10

04 Feb '10

Hi, after an upgrade from 2.1.6+ (a GIT version shortly after 2.1.6) to 2.1.8, we see failed mschap xlat on some exotic passwords. After some tests, we think that either the space character (" ") or the single quote ("'") cause xlat to fail. The basic use scenario is a mySQL DB backend which pulls a NT-Hash for the user. Input is PAP, so rlm_pap calls xlat:NT-Hash for the input, and then returns with the log message that mschap xlat failed. I've traced down the code in rlm_pap (no changes between the two versions), rlm_mschap (only unrelated changes), and main/xlat.c. xlat.c seems to have had a *major* revision in between. For the moment, I rolled back to 2.1.6+ (and had to give up on the "do_not_respond feature, sigh) but it would sure be nice if this worked again :-/. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473

2 3

rlm_wimax - add support for RRQ-HA-MN
by Ben Wiechman 03 Feb '10

03 Feb '10

Attached patch does two things: Removes MN-FA key generation. These keys are generated at the authenticator not the AAA so this is not needed. Adds support to generate the RRQ-MN-HA key. I am left with two questions. First - I dug but haven't fully tracked down whether there is any validity checking on the IP addresses that arrive in the request packets. When testing this by dumping the RRQ-HA-IP address directly into the config file with unlang I can see that invalid IP addresses are not accepted. Are similar checks performed on packets off the wire and where? Second - is a question of placement of the RRQ-MN-HA generation code. These attributes are only needed for CMIP when the MN does not know the IP address of the HA during network entry. Is it better to generate the appropriate key whenever the RRQ-HA-IP is seen (at the potential expense of generating this key if the MN is using PMIP yet somehow the RRQ-HA-IP shows up in the request packet as well), or either moving the generation of the RRQ-MN-HA keys to the appropriate sections of the switch where the MN-HA keys are generated or adding an additional check to the generation block to ensure that the appropriate MIP Technology is being used. Ben Wiechman

1 1