May 2011 - Freeradius-Devel - lists.freeradius.org

[PATCH] return notfound from rlm_sql
by Dmitry Borodaenko 04 May '11

04 May '11

Greetings, The attached patch makes rlm_sql return RLM_MODULE_NOTFOUND when no rows were affected by the accounting queries, and modifies acct.c and modcall.c to recognize notfound as a valid accounting return status. As far as I can tell, this patch shouldn't affect any existing configurations which don't expect notfound for accounting packets. The scenario where this is useful is a staged migration from a legacy Radius platform to a new FreeRadius setup. During migration phase, new users are created in the new database, existing users are gradually moved from the old database to the new one. Users existing in the new database are handled locally, auth and acct packets for users that weren't migrated yet are proxied to the legacy platform. To make use of the attached patch in such scenario, accounting INSERT queries in dialup.conf are changed into: INSERT ... SELECT <same set of values> FROM radcheck WHERE username = '%{SQL-User-Name}' ORDER BY id LIMIT 1 In the server configuration, invocation of rlm_sql is followed by: if(notfound) { update control { Proxy-To-Realm = legacy } updated } -- Dmitry Borodaenko

2 1

GIT Log for 2011-05-03 23:33 GMT
by aland＠deployingradius.com 03 May '11

03 May '11

commit 011f6ade913284030efa607dca1e71d9a6e6cc84 Author: Alan T. DeKok <aland(a)freeradius.org> Date: Tue May 3 17:39:11 2011 +0200 Added "proto" to listener_find_byipaddr This allows the control socket interface to show stats for both UDP and TCP sockets Files changed: src/include/radiusd.h | 3 ++- src/main/command.c | 2 +- src/main/listen.c | 39 ++++++++++++++++++++------------------- src/main/stats.c | 3 ++- 4 files changed, 25 insertions(+), 22 deletions(-) ====================================================================== commit dff62aa1314ed3879ceb27ebd5730f9eec6fbc22 Author: Alan T. DeKok <aland(a)freeradius.org> Date: Tue May 3 16:51:18 2011 +0200 Track and show stats by socket IP/port Files changed: src/main/command.c | 109 +++++++++++++++++++++++++++++++++------------------ src/main/stats.c | 9 ++++ 2 files changed, 79 insertions(+), 39 deletions(-) ====================================================================== commit 1d5f7c5522fd6d8d6657c24a687a5ab6ee08bcec Author: Alan T. DeKok <aland(a)freeradius.org> Date: Tue May 3 16:35:03 2011 +0200 Keep stats for incoming/outgoing sockets, too Files changed: src/main/process.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) ====================================================================== commit baad4f67ea3130c6b347f3706918306e8d9ddfc6 Author: Alan T. DeKok <aland(a)freeradius.org> Date: Tue May 3 15:14:25 2011 +0200 Added stats for "last packet seen from X" Files changed: src/include/stats.h | 1 + src/main/command.c | 1 + src/main/process.c | 28 +++++++++++++++++++++++++++- src/main/stats.c | 8 ++++---- 4 files changed, 33 insertions(+), 5 deletions(-) ====================================================================== commit 8ba9f00f55a992bb7fbb0a3f79281210a0ae5bab Author: Alan T. DeKok <aland(a)freeradius.org> Date: Tue May 3 09:23:41 2011 +0200 Don't decode attributes if there's no secret This is really a bug in the caller, but it's a reasonable change to make. Files changed: src/lib/radius.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) ======================================================================

1 0

PEAP-MSCHAP question.
by Makarand Pradhan 03 May '11

03 May '11

Hi All, Hope all of you are having a nice day. This is my first post on this list, so kindly overlook any novice mistakes. I am facing a problem while working with freeradius. The description of the problem and a probable solution is given below: Problem Scenario: I work on a router. I am working on PEAP with default_eap_type=mschapv2. On the router, I am a tunnel exchanging packets with the port on one side and the radius server on the other. rad_decode is used to get the EAP attributes coming from the server, so that they can be sent to the port which is being authenticated. While invoking rad_decode, the secret is set to NULL. This causes a trap while trying to decode Microsoft specific attributes as dictionary.microsoft says the key should be encrypted. ATTRIBUTE MS-MPPE-Send-Key 16 octets encrypt=2 ATTRIBUTE MS-MPPE-Recv-Key 17 octets encrypt=2 Resolution: To resolve this issue, I had to add a NULL ptr check in radius.c, function data2vp. diff -Naur radius.c.orig radius.c --- radius.c.orig 2011-05-02 17:19:33.988204676 -0400 +++ radius.c 2011-05-02 17:21:29.528702423 -0400 @@ -2242,7 +2242,7 @@ /* * Decrypt the attribute. */ - switch (vp->flags.encrypt) { + switch (vp->flags.encrypt && (NULL != secret)) { /* * User-Password */ I would highly appreciate your opinions regarding the issue. If this resolution is not acceptable, then kindly let me know alternatives that would be acceptable. Warm Rgds, Makarand. -- NOTICE OF CONFIDENTIALITY: ------------------------------------------- This e-mail and any attachments may contain confidential and privileged information. If you are not the intended recipient, please notify the sender immediately by return e-mail and delete this e-mail and any copies. Any dissemination or use of this information by a person other than the intended recipient is unauthorized and may be illegal.

2 2

GIT Log for 2011-05-02 23:33 GMT
by aland＠deployingradius.com 02 May '11

02 May '11

commit b053273ae44dd9e26d355befddedf3ce64675beb Author: Alan T. DeKok <aland(a)freeradius.org> Date: Mon May 2 14:47:16 2011 +0200 Use built-in "offsetof" Look for "stddef.h", and if found, include it in the various configure checks. Also use it at run time. acinclude.m4 | 3 +++ configure | 19 +++++++++++++++++-- configure.in | 1 + src/include/autoconf.h.in | 3 +++ src/include/missing.h | 4 ++++ 5 files changed, 28 insertions(+), 2 deletions(-)

1 0

Re: fr_packet_cmp again
by Josip Almasi 02 May '11

02 May '11

Josip Almasi wrote: > Alan DeKok wrote: >> >> Grab the "master" branch. See http://git.freeradius.org for >> instructions. The internal state machine has been *completely* >> re-written so that it's sane. If the bug still exists there, I'll be >> shocked. > > Will try. Died 7 mins after with Error: ASSERT FAILED threads.c[423]: request->magic == REQUEST_MAGIC :/ Started with -s, segfault in libfreeradius-radius-3.0.0.so. Dang its still there!:)))) -------------------------- Program received signal SIGSEGV, Segmentation fault. fr_packet_cmp (a=0xda9130, b=0x6e6f6b7369050d5b) at packet.c:141 141 if (a->sockfd < b->sockfd) return -1; #0 fr_packet_cmp (a=0xda9130, b=0x6e6f6b7369050d5b) at packet.c:141 #1 0x00007ffff7bc0adb in list_find (ht=0x841840, data=0x7fffffffe158) at hash.c:191 #2 fr_hash_table_find (ht=0x841840, data=0x7fffffffe158) at hash.c:454 #3 0x00007ffff7bc0b29 in fr_hash_table_finddata (ht=<value optimized out>, data=<value optimized out>) at hash.c:484 #4 0x00007ffff7bd067a in fr_packet_list_find (pl=<value optimized out>, request=0xda9130) at packet.c:577 #5 0x0000000000428203 in request_receive (listener=0x858090, packet=0xda9130, client=0x7a3050, fun=0x407f60 <rad_accounting>) at process.c:1181 #6 0x0000000000415bb2 in acct_socket_recv (listener=0x858090) at listen.c:1382 #7 0x00000000004295ca in event_socket_handler (xel=<value optimized out>, fd=<value optimized out>, ctx=0x858090) at process.c:3125 #8 0x00007ffff7bd141b in fr_event_loop (el=0x841e00) at event.c:413 #9 0x000000000041d334 in main (argc=<value optimized out>, argv=<value optimized out>) at radiusd.c:412 (gdb) print a=0xda9130 $1 = (const RADIUS_PACKET *) 0xda9130 (gdb) print $1->sockfd $2 = 9 (gdb) print b=0x6e6f6b7369050d5b $3 = (const RADIUS_PACKET *) 0x6e6f6b7369050d5b (gdb) print $3->sockfd Cannot access memory at address 0x6e6f6b7369050d5b -------------------------- Still running another instance of 1.2.11 under valgrind memtest, some 3M packets later it's still fine. Could it be some sort of timing issue, i.e. I have faster box than you so you cant reproduce it? FTR I have 16 cores, 4 x Xeon 2.8 GHz. BTW I like what I saw in 3, response time under heavy load is way better. Regards...

4 10