November 2006 - Freeradius-Devel - lists.freeradius.org

Reemission bug in multi-threaded mode - FreeRADIUS does not wake up properly
by Chaigneau Nicolas 12 Jan '07

12 Jan '07

FreeRADIUS 1.1.3 - Reemission bug in multi-threaded mode - FreeRADIUS does not wake up properly When receiving a request to proxy, FreeRADIUS should wake up in (at most) the proxied request retransmission delay parameter. This does not work. Note that in the case of the NAS reemitting the request, the problem does not appear, because when receiving new requests, FreeRADIUS wakes up and process its request list. The problem happens when a request is received, the request has to be proxied, but the NAS does not reemit (and no other request is received by FreeRADIUS from any NAS). The "wake up" delay is then set to 31 (probably max_request_time + 1) seconds instead of 5 (retry_delay), as we can see in debug mode: rad_recv: Accounting-Request packet from host *****:16384, id=233, length=53 Mon Nov 6 15:11:57 2006 : Debug: --- Walking the entire request list --- Mon Nov 6 15:11:57 2006 : Debug: Thread 4 got semaphore Mon Nov 6 15:11:57 2006 : Debug: Waking up in 31 seconds... Mon Nov 6 15:11:57 2006 : Debug: Thread 4 handling request 3, (1 handled so far) The behaviour is the same in normal (non debug) mode : the proxy server does only receive the request once, thus FreeRADIUS is not reemitting. In function refresh_request of file request_list.c, we should pass in the following condition : if (request->proxy && !request->proxy_reply) { ... (ie, request unfinished, but has been proxied and we are waiting for response from proxy server) It seems the condition is not met, so the next condition (ie, request unfinished but no proxy) is fulfilled. Thus, FreeRADIUS computes the time difference with: difference = (request->timestamp + mainconfig.max_request_time) - info->now; If FreeRADIUS is launched in single-thread mode (-X), the problem does not occur. It seems that "request->proxy" is 0 when the condition is tested, thus, FreeRADIUS considers there is no proxy outstanding for this request. From what I understand, when receiving a request, the thread that handles the list of requests wakes up, process its list and goes back to sleep. This thread finishes its work *before* the thread handling the request has proxied the request. This is the cause of the problem described above. Any hint as how to fix this ? (the problem is not critical: it appears on a test environment but will not happen in production, as a RADIUS server receives lots of requests) Should I log this in bugzilla ? Thanks. Best regards, Nicolas. ___________________________________________________________________________ Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international. Téléchargez sur http://fr.messenger.yahoo.com

3 2

rlm_dbm build error in CVS head
by Peter Nixon 30 Nov '06

30 Nov '06

Somewhere between freeradius-snapshot-20061014 and freeradius-snapshot-20061127 someone appears to have broken rlm_dbm (Yep. I've been busy and didn't get around to updating my snapshot rpms for over a month :-) The same error occurs on all SUSE versions from 9 through to 10.2 beta. Making all in rlm_dbm... gmake[6]: Entering directory `/usr/src/packages/BUILD/freeradius-snapshot-20061127/src/modules/rlm_dbm' /usr/src/packages/BUILD/freeradius-snapshot-20061127/libtool --mode=compile gcc -fmessage-length=0 -D_FORTIFY_SOURCE=2 -O2 -fno-strict-aliasing -DLDAP_DEPRECATED -fPIC -fstack-protector -I/usr/src/packages/BUILD/freeradius-snapshot-20061127/src -DHAVE_NDBM_H -c rlm_dbm.c mkdir .libs gcc -fmessage-length=0 -D_FORTIFY_SOURCE=2 -O2 -fno-strict-aliasing -DLDAP_DEPRECATED -fPIC -fstack-protector -I/usr/src/packages/BUILD/freeradius-snapshot-20061127/src -DHAVE_NDBM_H -c rlm_dbm.c -fPIC -DPIC -o .libs/rlm_dbm.o rlm_dbm.c: In function 'sm_parse_user': rlm_dbm.c:179: warning: assignment discards qualifiers from pointer target type rlm_dbm.c:213: warning: passing argument 2 of 'paircompare' discards qualifiers from pointer target type gcc -fmessage-length=0 -D_FORTIFY_SOURCE=2 -O2 -fno-strict-aliasing -DLDAP_DEPRECATED -fPIC -fstack-protector -I/usr/src/packages/BUILD/freeradius-snapshot-20061127/src -DHAVE_NDBM_H -c rlm_dbm.c -o rlm_dbm.o >/dev/null 2>&1 /usr/src/packages/BUILD/freeradius-snapshot-20061127/libtool --mode=link gcc -release 2.0.0-pre0 \ -module -export-dynamic -o rlm_dbm.la \ -rpath /usr/lib64/freeradius rlm_dbm.lo rlm_dbm.c /usr/src/packages/BUILD/freeradius-snapshot-20061127/src/lib/libradius.la \ -lndbm -lnsl -lresolv -lpthread gcc -shared .libs/rlm_dbm.o -Wl,--rpath -Wl,/usr/src/packages/BUILD/freeradius-snapshot-20061127/src/lib/.libs -Wl,--rpath -Wl,/usr/lib64/freeradius /usr/src/packages/BUILD/freeradius-snapshot-20061127/src/lib/.libs/libradius.so -lndbm -lnsl -lresolv -lpthread -Wl,-soname -Wl,rlm_dbm-2.0.0-pre0.so -o .libs/rlm_dbm-2.0.0-pre0.so (cd .libs && rm -f rlm_dbm.so && ln -s rlm_dbm-2.0.0-pre0.so rlm_dbm.so) ar cru .libs/rlm_dbm.a rlm_dbm.o ranlib .libs/rlm_dbm.a creating rlm_dbm.la (cd .libs && rm -f rlm_dbm.la && ln -s ../rlm_dbm.la rlm_dbm.la) /usr/src/packages/BUILD/freeradius-snapshot-20061127/libtool --mode=compile gcc -fmessage-length=0 -D_FORTIFY_SOURCE=2 -O2 -fno-strict-aliasing -DLDAP_DEPRECATED -fPIC -fstack-protector -I/usr/src/packages/BUILD/freeradius-snapshot-20061127/src -DHAVE_NDBM_H -c rlm_dbm_parser.c gcc -fmessage-length=0 -D_FORTIFY_SOURCE=2 -O2 -fno-strict-aliasing -DLDAP_DEPRECATED -fPIC -fstack-protector -I/usr/src/packages/BUILD/freeradius-snapshot-20061127/src -DHAVE_NDBM_H -c rlm_dbm_parser.c -fPIC -DPIC -o .libs/rlm_dbm_parser.o rlm_dbm_parser.c: In function 'storecontent': rlm_dbm_parser.c:165: warning: assignment discards qualifiers from pointer target type gcc -fmessage-length=0 -D_FORTIFY_SOURCE=2 -O2 -fno-strict-aliasing -DLDAP_DEPRECATED -fPIC -fstack-protector -I/usr/src/packages/BUILD/freeradius-snapshot-20061127/src -DHAVE_NDBM_H -c rlm_dbm_parser.c -o rlm_dbm_parser.o >/dev/null 2>&1 /usr/src/packages/BUILD/freeradius-snapshot-20061127/libtool --mode=link gcc \ -o rlm_dbm_parser rlm_dbm_parser.lo ../../lib/libradius.la -lndbm -lnsl -lresolv -lpthread gcc -o .libs/rlm_dbm_parser .libs/rlm_dbm_parser.o ../../lib/.libs/libradius.so -lndbm -lnsl -lresolv -lpthread -Wl,--rpath -Wl,/usr/lib64/freeradius ../../lib/.libs/libradius.so: undefined reference to `recvfromto' ../../lib/.libs/libradius.so: undefined reference to `sendfromto' ../../lib/.libs/libradius.so: undefined reference to `udpfromto_init' collect2: ld returned 1 exit status gmake[6]: *** [rlm_dbm_parser] Error 1 gmake[6]: Leaving directory `/usr/src/packages/BUILD/freeradius-snapshot-20061127/src/modules/rlm_dbm' gmake[5]: *** [common] Error 2 gmake[5]: Leaving directory `/usr/src/packages/BUILD/freeradius-snapshot-20061127/src/modules' gmake[4]: *** [all] Error 2 gmake[4]: Leaving directory `/usr/src/packages/BUILD/freeradius-snapshot-20061127/src/modules' gmake[3]: *** [common] Error 2 gmake[3]: Leaving directory `/usr/src/packages/BUILD/freeradius-snapshot-20061127/src' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/usr/src/packages/BUILD/freeradius-snapshot-20061127/src' gmake[1]: *** [common] Error 2 gmake[1]: Leaving directory `/usr/src/packages/BUILD/freeradius-snapshot-20061127' make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.35808 (%build) -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc

3 4

Automatic report from sources (radiusd) between 29.11.2006 - 30.11.2006 GMT
by Automatic cvs log generator 30 Nov '06

30 Nov '06

CVS log entries from 29.11.2006 (Wed) 09:00:00 - 30.11.2006 (Thu) 09:00:01 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/doc/ChangeLog; Revisions: 1.57.2.31.2.30 File: radiusd/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c; Revisions: 1.38, 1.21.4.12 ===================================================== Log entries ===================================================== Description: Added recent notes Modified files: File: radiusd/doc/ChangeLog; Revision: 1.57.2.31.2.30; Date: 2006/11/30 00:33:08; Author: aland; Lines: (+18 -7) ------------------------------- Description: Workarounds for Vista Modified files: File: radiusd/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c; Revision: 1.38; Date: 2006/11/29 23:01:11; Author: aland; Lines: (+11 -2) ------------------------------- Description: Vista workarounds Modified files: File: radiusd/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c; Revision: 1.21.4.12; Date: 2006/11/29 22:59:48; Author: aland; Lines: (+7 -2) ===================================================== Summary of modified files ===================================================== File: radiusd/doc/ChangeLog Revisions: 1.57.2.31.2.30 Authors: aland (+18 -7) ------------------------------- File: radiusd/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c Revisions: 1.38, 1.21.4.12 Authors: aland (+11 -2), aland (+7 -2) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0

Automatic report from sources (radiusd) between 28.11.2006 - 29.11.2006 GMT
by Automatic cvs log generator 29 Nov '06

29 Nov '06

CVS log entries from 28.11.2006 (Tue) 09:00:02 - 29.11.2006 (Wed) 09:00:00 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/share/dictionary.erx; Revisions: 1.17, 1.9.4.6 File: radiusd/src/lib/radius.c; Revisions: 1.192 File: radiusd/share/dictionary.nomadix; Revisions: 1.8, 1.4.2.1.2.2 File: radiusd/share/dictionary.waverider; Revisions: 1.6, 1.4.2.3 File: radiusd/src/main/radclient.c; Revisions: 1.72.2.1.2.6 File: radiusd/share/dictionary.redback; Revisions: 1.13, 1.7.2.1.2.2 File: radiusd/share/dictionary.ascend; Revisions: 1.21, 1.11.2.1.2.2 ===================================================== Combined list of identical log entries ===================================================== Description: Updated names so that upper/lower case matches. Patch from Daniel Larsson Modified files: File: radiusd/share/dictionary.ascend; Revision: 1.11.2.1.2.2; Date: 2006/11/28 18:24:24; Author: aland; Lines: (+3 -3) File: radiusd/share/dictionary.erx; Revision: 1.9.4.6; Date: 2006/11/28 18:24:25; Author: aland; Lines: (+3 -3) File: radiusd/share/dictionary.nomadix; Revision: 1.4.2.1.2.2; Date: 2006/11/28 18:24:26; Author: aland; Lines: (+3 -3) File: radiusd/share/dictionary.redback; Revision: 1.7.2.1.2.2; Date: 2006/11/28 18:24:26; Author: aland; Lines: (+7 -7) File: radiusd/share/dictionary.waverider; Revision: 1.4.2.3; Date: 2006/11/28 18:24:26; Author: aland; Lines: (+33 -33) ------------------------------- Description: Updated names so that upper/lower case matches. Patch from Daniel Larsson Modified files: File: radiusd/share/dictionary.ascend; Revision: 1.21; Date: 2006/11/28 18:24:02; Author: aland; Lines: (+3 -3) File: radiusd/share/dictionary.erx; Revision: 1.17; Date: 2006/11/28 18:24:03; Author: aland; Lines: (+3 -3) File: radiusd/share/dictionary.nomadix; Revision: 1.8; Date: 2006/11/28 18:24:03; Author: aland; Lines: (+3 -3) File: radiusd/share/dictionary.redback; Revision: 1.13; Date: 2006/11/28 18:24:03; Author: aland; Lines: (+7 -7) File: radiusd/share/dictionary.waverider; Revision: 1.6; Date: 2006/11/28 18:24:03; Author: aland; Lines: (+33 -33) ===================================================== Log entries ===================================================== Description: If less than 4 bytes are read, tell the caller that 0 bytes were read If the MSG_PEEK'd length says that the packet is less than the RADIUS header length, tell the caller that 0 bytes were read. If the MSG_PEEK'd length says that the packet is more than the allowed RFC maximum of 4k, tell the caller that more than 4K was read, but do NOT allocate memory for the packet. rad_recv() takes care of catching these cases, and returns a descriptive error to the caller. In all 3 cases, recvmsg() is called to read a few bytes of data from the packet. The kernel takes care of deciding that the packet was read, and discards the rest of the data. Modified files: File: radiusd/src/lib/radius.c; Revision: 1.192; Date: 2006/11/28 19:08:41; Author: aland; Lines: (+40 -8) ------------------------------- Description: Print out more information about bad packets Modified files: File: radiusd/src/main/radclient.c; Revision: 1.72.2.1.2.6; Date: 2006/11/28 18:59:50; Author: aland; Lines: (+5 -4) ===================================================== Summary of modified files ===================================================== File: radiusd/share/dictionary.ascend Revisions: 1.21, 1.11.2.1.2.2 Authors: aland (+3 -3), aland (+3 -3) ------------------------------- File: radiusd/share/dictionary.erx Revisions: 1.17, 1.9.4.6 Authors: aland (+3 -3), aland (+3 -3) ------------------------------- File: radiusd/share/dictionary.nomadix Revisions: 1.8, 1.4.2.1.2.2 Authors: aland (+3 -3), aland (+3 -3) ------------------------------- File: radiusd/share/dictionary.redback Revisions: 1.13, 1.7.2.1.2.2 Authors: aland (+7 -7), aland (+7 -7) ------------------------------- File: radiusd/share/dictionary.waverider Revisions: 1.6, 1.4.2.3 Authors: aland (+33 -33), aland (+33 -33) ------------------------------- File: radiusd/src/lib/radius.c Revisions: 1.192 Authors: aland (+40 -8) ------------------------------- File: radiusd/src/main/radclient.c Revisions: 1.72.2.1.2.6 Authors: aland (+5 -4) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0

Cosmetics in dictionary files
by Daniel Larsson 28 Nov '06

28 Nov '06

Hi, I was playing around with pyrad, a RADIUS library for python, and encountered some problems with the dictionary files. Its parser is case sensitive, and it turned out some attributes and their corresponding VALUE definitions differed in case, so I took the liberty to "fix" this. If nothing else, for cosmetic reasons. Patch is against HEAD in CVS.

3 3

Freeradius, EAP-TTLS and eDirectory
by Mariano Morano 28 Nov '06

28 Nov '06

Hi all, We are working in a RFP and one of the customer's requirement is that we must support EAP-TTLS with Freeradius integrated with eDirectory as back-end. We were reading the Novell documentation and at the Novell page, there appears "How to integrate Novell® eDirectoryTM 8.7.1 or later with FreeRADIUS 1.0.2 on wards to allow wireless authentication for eDirectory users." and it not mentions EAP-TTLS (only EAP-TLS) SO, Some questions: 1) First, can we use Freeradius with EAP-TTLS and eDirectory as back end ? 2) if we can waht version of freeradius should we use ? 3) Ca someone send us information about how do that? I would appreciate any help ASAP Thanks in advance.

1 0

Automatic report from sources (radiusd) between 27.11.2006 - 28.11.2006 GMT
by Automatic cvs log generator 28 Nov '06

28 Nov '06

CVS log entries from 27.11.2006 (Mon) 09:00:01 - 28.11.2006 (Tue) 09:00:02 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/src/lib/valuepair.c; Revisions: 1.114 File: radiusd/src/lib/dict.c; Revisions: 1.95 File: radiusd/src/modules/rlm_digest/rlm_digest.c; Revisions: 1.5.4.6 ===================================================== Log entries ===================================================== Description: VALUEs can only be defined for BYTE, SHORT, and INTEGER Modified files: File: radiusd/src/lib/dict.c; Revision: 1.95; Date: 2006/11/27 18:52:51; Author: aland; Lines: (+19 -7) ------------------------------- Description: Simplify parsing of byte/short/string, based on a patch by Krzysztof Oledzki Modified files: File: radiusd/src/lib/valuepair.c; Revision: 1.114; Date: 2006/11/27 18:43:06; Author: aland; Lines: (+23 -26) ------------------------------- Description: Pull -r1.23 -> -r1.24 from CVS head Modified files: File: radiusd/src/modules/rlm_digest/rlm_digest.c; Revision: 1.5.4.6; Date: 2006/11/27 20:44:19; Author: aland; Lines: (+10 -4) ===================================================== Summary of modified files ===================================================== File: radiusd/src/lib/dict.c Revisions: 1.95 Authors: aland (+19 -7) ------------------------------- File: radiusd/src/lib/valuepair.c Revisions: 1.114 Authors: aland (+23 -26) ------------------------------- File: radiusd/src/modules/rlm_digest/rlm_digest.c Revisions: 1.5.4.6 Authors: aland (+10 -4) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0

Execute sql inside other modules
by Desarrollo C/C++ 27 Nov '06

27 Nov '06

Hi, I'm writing a module on accounting section that write UserName and SessionTime in other table, and I need to run same sql statament inserts or select, but I don't understant how I can do it inside a module. Can any help me? I think that I need to use radius_xlat function, same body give me an example? Thanks Toto

2 1

RE: Two requests shortly after each other
by Alexander Schrab 27 Nov '06

27 Nov '06

Sorry for bugging you, discovered that the identifyer was the same (even if the content was different). The random function that generates it (in junipers libradius) was seeded by the time in seconds which led to the same result from random in several packages if sent very quickly. /Alex > -----Original Message----- > From: > freeradius-devel-bounces+alexander.schrab=axis.com(a)lists.freer > adius.org > [mailto:freeradius-devel-bounces+alexander.schrab=axis.com@lis > ts.freeradius.org] On Behalf Of Alexander Schrab > Sent: den 27 november 2006 14:08 > To: FreeRadius developers mailing list > Subject: Two requests shortly after each other > > > Hi, > > Is this some sort of anti-DoS-feature? > > I send one request with a username/password pair and get a > sucessfull reply. Then I send another with different > username/password directly after the first one. This request > should result in a different reply, but I get a duplicate of > the old reply: > > --------------------------------- > radius_xlat: 'User' > Sending Access-Accept of id 144 to 10.92.163.211 port 3079 > Reply-Message = "User" > Finished request 2 > Going to the next request > --- Walking the entire request list --- > Waking up in 6 seconds... > rad_recv: Access-Request packet from host 10.92.163.211:3079, > id=144, length=53 Sending duplicate reply to client > localhost:3079 - ID: 144 Re-sending Access-Accept of id 144 > to 10.92.163.211 port 3079 Waking up in 6 seconds... > --------------------------------- > > /Alex > > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/devel.html >

1 0

Two requests shortly after each other
by Alexander Schrab 27 Nov '06

27 Nov '06

Hi, Is this some sort of anti-DoS-feature? I send one request with a username/password pair and get a sucessfull reply. Then I send another with different username/password directly after the first one. This request should result in a different reply, but I get a duplicate of the old reply: --------------------------------- radius_xlat: 'User' Sending Access-Accept of id 144 to 10.92.163.211 port 3079 Reply-Message = "User" Finished request 2 Going to the next request --- Walking the entire request list --- Waking up in 6 seconds... rad_recv: Access-Request packet from host 10.92.163.211:3079, id=144, length=53 Sending duplicate reply to client localhost:3079 - ID: 144 Re-sending Access-Accept of id 144 to 10.92.163.211 port 3079 Waking up in 6 seconds... --------------------------------- /Alex

1 0