- Freeradius-Devel - lists.freeradius.org

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 04 Feb '10

04 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

freeradius-client rc_avpair_log() function
by Alex Massover 03 Feb '10

03 Feb '10

Hi, AFAIU, rc_avpair_log() function in freeradius-client is not thread-safe, it uses a shared buffer (rh->ppbuf). So one can't have shared rc_handle if calling to rc_avpair_log() from different threads. Please tell me if that's correct and I'll make a simple patch changing: rc_avpair_log(rc_handle *rh, VALUE_PAIR *pair) to rc_avpair_log(rc_handle *rh, VALUE_PAIR *pair, char *buf, size_t l) This way a caller will provide a non-shared buffer. -- Best Regards, Alex Massover VoIP R&D TL Jajah Inc. This mail was sent via Mail-SeCure System.

2 3

Crashes in 2.1.8 when handling received auth packets
by John Morrissey 03 Feb '10

03 Feb '10

We recently upgraded from 2.0.4 to 2.1.8 and are now noticing occasional segfaults when handling received auth packets. Representative backtraces are below. In all cases, all threads are idle except one, which is receiving an auth packet. In the first case, auth_socket_recv() passes a NULL packet to received_request(), which is strange since auth_socket_recv() checks for that case immediately before. In the second case, received_request() gets a bogus pointer to the packet, apparently from rad_recv(). I'm always hesitant to trust backtraces from optimized binaries, but the code paths relative to the packet pointers being passed around are bizarre and strike me as stack or heap corruption. Any ideas? john Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f71e3b32ae0 (LWP 7677)] fr_packet_cmp (a=0x7f7179f94070, b=0x0) at packet.c:139 139 packet.c: No such file or directory. in packet.c Thread 161 (Thread 0x7f71067fc950 (LWP 12500)): #0 0x00007f71e2d5abd1 in sem_wait () from /lib/libpthread.so.0 No symbol table info available. #1 0x000000000041e1bc in request_handler_thread (arg=<value optimized out>) at threads.c:453 fun = (RAD_REQUEST_FUNP) 0x408a50 <rad_accounting> self = (THREAD_HANDLE *) 0x7f71d4a33ea0 #2 0x00007f71e2d54fc7 in start_thread () from /lib/libpthread.so.0 No symbol table info available. #3 0x00007f71e209f59d in clone () from /lib/libc.so.6 No symbol table info available. #4 0x0000000000000000 in ?? () No symbol table info available. [snip remaining idle request handler threads] Thread 1 (Thread 0x7f71e3b32ae0 (LWP 7677)): #0 fr_packet_cmp (a=0x7f7179f94070, b=0x0) at packet.c:139 rcode = <value optimized out> #1 0x00007f71e339fac4 in fr_hash_table_find (ht=0x8c1200, data=0x7fffc7ed1a30) at hash.c:191 key = <value optimized out> entry = <value optimized out> reversed = 3663427046 #2 0x00007f71e339fb09 in fr_hash_table_finddata (ht=0x7f7179f94070, data=0x0) at hash.c:491 node = <value optimized out> #3 0x00007f71e33ad4cb in fr_packet_list_find (pl=<value optimized out>, request=0x7f7179f94070) at packet.c:581 No locals. #4 0x0000000000427b49 in received_request (listener=0x15505d0, packet=0x0, prequest=0x5b0000, client=0x7f71e33b0fc0) at event.c:2775 packet_p = <value optimized out> request = (REQUEST *) 0x0 #5 0x0000000000415ac6 in auth_socket_recv (listener=0x15505d0, pfun=0x7fffc7ed1b98, prequest=0x7fffc7ed1b90) at listen.c:820 rcode = <value optimized out> code = 1 src_port = 21682 packet = (RADIUS_PACKET *) 0x7f7179f94070 fun = (RAD_REQUEST_FUNP) 0x409020 <rad_authenticate> client = (RADCLIENT *) 0xa9b4b0 src_ipaddr = {af = 2, ipaddr = {ip4addr = {s_addr = 1342711882}, ip6addr = {in6_u = {u6_addr8 = "J(\bP�*&�p\177\000\000�\001\\\001", u6_addr16 = {10314, 20488, 10976, 64550, 32624, 0, 448, 348}, u6_addr32 = {1342711882, 4230359776, 32624, 22806976}}}}} #6 0x0000000000422ffe in event_socket_handler (xel=<value optimized out>, fd=<value optimized out>, ctx=<value optimized out>) at event.c:3347 listener = (rad_listen_t *) 0x15505d0 fun = <value optimized out> request = <value optimized out> #7 0x00007f71e33ae766 in fr_event_loop (el=0x15c01c0) at event.c:412 i = 1 rcode = <value optimized out> maxfd = 21 when = {tv_sec = 1264965841, tv_usec = 427558} wake = <value optimized out> read_fds = {fds_bits = {524288, 0 <repeats 15 times>}} master_fds = {fds_bits = {3670024, 0 <repeats 15 times>}} #8 0x000000000041c377 in main (argc=1, argv=<value optimized out>) at radiusd.c:398 rcode = 22599360 argval = <value optimized out> spawn_flag = 1 dont_fork = 0 flag = <value optimized out> act = {__sigaction_handler = {sa_handler = 0x41c600 <sig_fatal>, sa_sigaction = 0x41c600 <sig_fatal>}, sa_mask = {__val = {0 <repeats 16 times>}}, sa_flags = 0, sa_restorer = 0} Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f90c1422ae0 (LWP 11822)] fr_packet_cmp (a=0x7f90213b6ee0, b=0x144) at packet.c:139 139 packet.c: No such file or directory. in packet.c Thread 162 (Thread 0x7f8f97fe6950 (LWP 12010)): #0 0x00007f90c064abd1 in sem_wait () from /lib/libpthread.so.0 No symbol table info available. #1 0x000000000041e1bc in request_handler_thread (arg=<value optimized out>) at threads.c:453 fun = (RAD_REQUEST_FUNP) 0x409020 <rad_authenticate> self = (THREAD_HANDLE *) 0x7f9050c65670 #2 0x00007f90c0644fc7 in start_thread () from /lib/libpthread.so.0 No symbol table info available. #3 0x00007f90bf98f59d in clone () from /lib/libc.so.6 No symbol table info available. #4 0x0000000000000000 in ?? () No symbol table info available. [snip remaining idle request handler threads] Thread 1 (Thread 0x7f90c1422ae0 (LWP 11822)): #0 fr_packet_cmp (a=0x7f90213b6ee0, b=0x144) at packet.c:139 rcode = <value optimized out> #1 0x00007f90c0c8fac4 in fr_hash_table_find (ht=0xf64ce0, data=0x7fff3e4a1110) at hash.c:191 key = <value optimized out> entry = <value optimized out> reversed = 1832451347 #2 0x00007f90c0c8fb09 in fr_hash_table_finddata (ht=0x7f90213b6ee0, data=0x144) at hash.c:491 node = <value optimized out> #3 0x00007f90c0c9d4cb in fr_packet_list_find (pl=<value optimized out>, request=0x7f90213b6ee0) at packet.c:581 No locals. #4 0x0000000000427b49 in received_request (listener=0xf623d0, packet=0x144, prequest=0x380000, client=0x7f90c0ca0fc0) at event.c:2775 packet_p = <value optimized out> request = (REQUEST *) 0x0 #5 0x0000000000415ac6 in auth_socket_recv (listener=0xf623d0, pfun=0x7fff3e4a1278, prequest=0x7fff3e4a1270) at listen.c:820 rcode = <value optimized out> code = 1 src_port = 49156 packet = (RADIUS_PACKET *) 0x7f90213b6ee0 fun = (RAD_REQUEST_FUNP) 0x409020 <rad_authenticate> client = (RADCLIENT *) 0x113b8e0 src_ipaddr = {af = 2, ipaddr = {ip4addr = {s_addr = 2061970506}, ip6addr = {in6_u = {u6_addr8 = "J,�z�\0259!\220\177\000\000 \220@", u6_addr16 = {11338, 31463, 5568, 8505, 32656, 0, 36896, 64}, u6_addr32 = {2061970506, 557389248, 32656, 4231200}}}}} #6 0x0000000000422ffe in event_socket_handler (xel=<value optimized out>, fd=<value optimized out>, ctx=<value optimized out>) at event.c:3347 listener = (rad_listen_t *) 0xf623d0 fun = <value optimized out> request = <value optimized out> #7 0x00007f90c0c9e766 in fr_event_loop (el=0xf5eab0) at event.c:412 i = 1 rcode = <value optimized out> maxfd = 21 when = {tv_sec = 1264551371, tv_usec = 36937} wake = <value optimized out> read_fds = {fds_bits = {524288, 0 <repeats 15 times>}} master_fds = {fds_bits = {3670024, 0 <repeats 15 times>}} #8 0x000000000041c377 in main (argc=1, argv=<value optimized out>) at radiusd.c:398 rcode = 29613264 argval = <value optimized out> spawn_flag = 1 dont_fork = 0 flag = <value optimized out> act = {__sigaction_handler = {sa_handler = 0x41c600 <sig_fatal>, sa_sigaction = 0x41c600 <sig_fatal>}, sa_mask = {__val = {0 <repeats 16 times>}}, sa_flags = 0, sa_restorer = 0} -- John Morrissey _o /\ ---- __o jwm(a)horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__

2 2

FreeRadius 2.1.8 at OpenBSD 4.0
by Denis Damico 03 Feb '10

03 Feb '10

> Hi, > I already could compile/install and run FreeRadius 2.1.7 at MacOS X > withou any problem. > Now I am trying to install FreeRadius 2.1.7( and 2.1.8) in a vmware > machine running OpenBSD version 4.0 ( in special a VMWare appliance > OAMP) > and I am getting the following error when run "make": > > make[4]: *** [dict.lo] Error 1 > make[4]: Leaving directory `/var/freeradius-server-2.1.8/src/lib' > make[3]: *** [common] Error 2 > make[3]: Leaving directory `/var/freeradius-server-2.1.8/src' > make[2]: *** [install] Error 2 > make[2]: Leaving directory `/var/freeradius-server-2.1.8/src' > make[1]: *** [common] Error 2 > make[1]: Leaving directory `/var/freeradius-server-2.1.8' > make: *** [install] Error 2 > > ( the full messages from ./configure and make are attached). > > Before to run "make" I needed to install the GNU make version 3.81. > I read the messages but could not detect the cause.Anyone can > help me on > that ? > > Thanks, > Denis > >

3 5

[trivial PATCH 12/22] [otp_mppe.c] eliminate build warnings
by Wang Tinggong 02 Feb '10

02 Feb '10

Signed-off-by: Wang Tinggong <wangtinggong(a)gmail.com> --- src/modules/rlm_otp/otp_mppe.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/modules/rlm_otp/otp_mppe.c b/src/modules/rlm_otp/otp_mppe.c index f31ef9f..c5a12c8 100644 --- a/src/modules/rlm_otp/otp_mppe.c +++ b/src/modules/rlm_otp/otp_mppe.c @@ -351,7 +351,7 @@ otp_mppe(REQUEST *request, otp_pwe_t pwe, const otp_option_t *opt, (2 * sizeof(mppe_key)) + 1]; #else /* 0 */ /* 0x ( ASCII(mppe_key) ) \0 */ - unsigned char mppe_key_string[2 + (2 * sizeof(MasterKey)) + 1]; + char mppe_key_string[2 + (2 * sizeof(MasterKey)) + 1]; #endif /* else !0 */ /* Generate the master session key. */ -- 1.6.0.6

4 9

[trivial PATCH 11/22] [extern.h] eliminate build warnings
by Wang Tinggong 02 Feb '10

02 Feb '10

Signed-off-by: Wang Tinggong <wangtinggong(a)gmail.com> --- src/modules/rlm_otp/extern.h | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/modules/rlm_otp/extern.h b/src/modules/rlm_otp/extern.h index 5fad0cb..0f1d6a3 100644 --- a/src/modules/rlm_otp/extern.h +++ b/src/modules/rlm_otp/extern.h @@ -66,8 +66,8 @@ typedef struct otp_option_t { void otp_mppe(REQUEST *, otp_pwe_t, const otp_option_t *, const char *); /* otp_pw_valid.c */ -extern int otp_pw_valid(REQUEST *, int, const char *, const otp_option_t *, - char []); +extern int otp_pw_valid(REQUEST *, int, const unsigned char *, + const otp_option_t *, char []); /* otp_radstate.c */ #define OTP_MAX_RADSTATE_LEN 2 + (OTP_MAX_CHALLENGE_LEN * 2 + 8 + 8 + 32)*2 + 1 @@ -82,9 +82,9 @@ extern void otp_pwe_init(void); extern otp_pwe_t otp_pwe_present(const REQUEST *); /* otp_util.c */ -extern void otp_get_random(char *, size_t); +extern void otp_get_random(unsigned char *, size_t); extern void otp_async_challenge(char [OTP_MAX_CHALLENGE_LEN + 1], int); -extern int otp_a2x(const char *, unsigned char *); +extern int otp_a2x(const unsigned char *, unsigned char *); extern void otp_x2a(const unsigned char *, size_t, char *); extern void _otp_pthread_mutex_init(pthread_mutex_t *, const pthread_mutexattr_t *, const char *); -- 1.6.0.6

3 2