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

Automatic report from sources (radiusd) between 25.10.2006 - 27.10.2006 GMT
by Automatic cvs log generator 15 Nov '06

15 Nov '06

CVS log entries from 25.10.2006 (Wed) 08:00:01 - 27.10.2006 (Fri) 08:00:00 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c; Revisions: 1.36, 1.21.4.11 ===================================================== Combined list of identical log entries ===================================================== Description: Removed double free. This fixes bug #404 Modified files: File: radiusd/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c; Revision: 1.36; Date: 2006/10/26 17:12:49; Author: aland; Lines: (+1 -2) File: radiusd/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c; Revision: 1.21.4.11; Date: 2006/10/26 17:13:04; Author: aland; Lines: (+1 -2) ===================================================== Log entries ===================================================== ===================================================== Summary of modified files ===================================================== File: radiusd/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c Revisions: 1.36, 1.21.4.11 Authors: aland (+1 -2), aland (+1 -2) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

4 8

Re : Re : Bug on Accouting-Requests proxying
by Geoffroy Arnoud 02 Nov '06

02 Nov '06

> > Maybe can you explain us why it SHOULD NOT retransmit accounting packets? > Because the NAS will retransmit them. Having the proxying server > re-transmit them, too is unecessary. I agree on this. Nevertheless (correct me if I'm wrong), when FreeRADIUS acts as a proxy, it can be synchronous or asynchronous, right? We are developping a RADIUS proxy interconnecting many clients to many servers. We need to proxy both authentication and accounting requests. We need to set different timeout and retransmit per realm (customer request / patch under contruction). Using NAS restransmissions as you suggest supposes to be synchronous, but we need asynchronous behaviour (different TO / retries per realm - independant from the client). > If the server logs them locally, and then uses something like > "radrelay" to proxy them, then radrelay should take care of the > retransmits. Using radrelay may prove to be interesting, but was not considered useful because, at design time, we thought FreeRADIUS did respect RFC regarding retransmissions of accounting requests. Maybe in a future release of the project, we can think about using radrelay, but not for the moment. > > Our implementations of FreeRADIUS need to retransmit all types of packets > Why? For accounting requests, if retransmissions are not managed, this may result in billing issues for operators. Interconnection rules tell that if more than a number a accounting interim are missing, then it means that end-user session is over and that session can be terminated and billed. If session is not really terminated, this leads to a revenue loss. I hope that you understand the context and our concerns. Nevertheless, we are not in position to tell you what to do or not in the server, but we hope that such a modification (no proxy of accounting) will be marked as a major update of the server in the release notes. Best regards and thank you for your great opensource. Geof. ___________________________________________________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com

2 2

Re : Bug on Accouting-Requests proxying
by Geoffroy Arnoud 30 Oct '06

30 Oct '06

> The solution is simple. The server SHOULD NOT retransmit accounting > packets. I will delete the code in the next release. Maybe can you explain us why it SHOULD NOT retransmit accounting packets? Are you talking of not retransmiting at all - or computing a new ID for retransmitted packets? Can one think of a configuration parameter to activate/deactivate retransmission of accounting packets instead of completely removing the code? Our implementations of FreeRADIUS need to retransmit all types of packets, so I think we may remove Acct-Delay-Time attribute and submit a patch - even if the patch is not shipped in future releases. Geof. ___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com

2 1

post-auth module
by Manuel Sánchez Cuenca 30 Oct '06

30 Oct '06

Hello all. I have developed a freeradius module which I want to be executed only after a successful authentication, therefore I have put it in the post-auth section. But the problem is that the module is being execute two times. This is the freeradius log: ------------------------------------------------------------------------------------------- Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 8 rlm_eap: Request found, released from the list rlm_eap: EAP/mschapv2 rlm_eap: processing type mschapv2 rlm_eap: Freeing handler modcall[authenticate]: module "eap" returns ok for request 8 modcall: leaving group authenticate (returns ok) for request 8 Processing the post-auth section of radiusd.conf modcall: entering group post-auth for request 8 ********************************** rlm_my_module ********************************** * modcall[post-auth]: module "nassaml_authz" returns ok for request 8 modcall: leaving group post-auth (returns ok) for request 8 PEAP: Tunneled authentication was successful. rlm_eap_peap: SUCCESS modcall[authenticate]: module "eap" returns handled for request 8 modcall: leaving group authenticate (returns handled) for request 8 *Sending Access-Challenge *of id 0 to 155.54.205.100 port 2048 . . . rlm_eap_peap: EAPTLS_OK rlm_eap_peap: Session established. Decoding tunneled attributes. rlm_eap_peap: Received EAP-TLV response. rlm_eap_peap: Tunneled data is valid. rlm_eap_peap: Success rlm_eap: Freeing handler modcall[authenticate]: module "eap" returns ok for request 9 modcall: leaving group authenticate (returns ok) for request 9 Processing the post-auth section of radiusd.conf modcall: entering group post-auth for request 9 ********************************** rlm_my_module *********************************** El usuario para autenticar es [lolo] El servidor con el que comunicarnos es [155.54.205.229:5555] La decision ha sido: 1 modcall[post-auth]: module "nassaml_authz" returns ok for request 9 modcall: leaving group post-auth (returns ok) for request 9 *Sending Access-Accept* of id 0 to 155.54.205.100 port 2048 ------------------------------------------------------------------------------------------- I can't understand why, after execute the first time the post auth section, an access-challenge is sent, instead of an Access-Accept, such as in the second time this section is executed. Can anybody help me? Thanks in advance. -- ----------------------------- Manuel Sanchez Cuenca Departamento de Ingenieria de la Informacion y las Comunicaciones Facultad de Informatica. Universidad de Murcia Campus de Espinardo - 30080 Murcia (SPAIN) Tel.: +34-968-364644 Fax: +34-968-364151 email: msc(a)dif.um.es | manuelsc(a)um.es url: http://libra.inf.um.es/~lolo

1 0

Bug on Accouting-Requests proxying
by Geoffroy Arnoud 29 Oct '06

29 Oct '06

FreeRADIUS 1.1.3 bug - Accounting requests reemission by FreeRADIUS In file "main\request_list.c", function "refresh_request". In the case of an accounting request (request->proxy->code == PW_ACCOUNTING_REQUEST), FreeRADIUS adds to the proxied packet the attribute "Acct-Delay-Time" (or updates it, if it was present in previous emission) with value set to the time difference between current time and time of initial proxied request. According to RFC 2866, chapter 4.1 : "The Identifier field MUST be changed whenever the content of the Attributes field changes, and whenever a valid reply has been received for a previous request. For retransmissions where the contents are identical, the Identifier MUST remain unchanged. Note that if Acct-Delay-Time is included in the attributes of an Accounting-Request then the Acct-Delay-Time value will be updated when the packet is retransmitted, changing the content of the Attributes field and requiring a new Identifier and Request Authenticator." FreeRADIUS updates the content of the packet when reemitting the accounting request, but does not change the Identifier. Thus, those packets sent after the first one are *not* true reemissions. This is a problem to us. For instance, we have the following setup : A client (A) sending an accounting request to FreeRADIUS (B), which retransmits the request to a proxy FreeRADIUS server (C). FreeRADIUS C is slow to respond, so FreeRADIUS B reemits the request, with different packet attributes (Acct-Delay-Time added), but keeps the same identifier. FreeRADIUS C receives the second request, but discards it since it has the same identifier as the request currently being processed. FreeRADIUS C then decides to finally respond (to the first request). FreeRADIUS B receives this response, and verifies if the request (the reemission) and response match. They do not, thus FreeRADIUS B drops the response and logs an error. FreeRADIUS should either : - NOT add Acct-Delay-Time attribute in accounting reemissions, thus preserving the content of the attributes in the packet. - or, add an Acct-Delay-Time, but change the identifier and handle the proxied packet as a new request. The second solution seems overly complicated, because FreeRADIUS would have to handle the second proxied request as a completely new request, but would also have keep the first one, as the proxy server can respond to any of the reemissions. The first solution is very simple to correct: it simply involves removing the block "if (request->proxy->code == PW_ACCOUNTING_REQUEST) {" in function "refresh_request" of file "main\request_list.c". I don't know if Acct-Delay-Time attribute is really useful to someone, I've never seen it used in any implementation of a RADIUS server. Anyhow, it seems way too much hassle to correctly handle this attribute in accounting reemissions. If tehre is any any objection, we will develop a patch to remove Acct-Delay-Time and provide it soon. Best regards, Geoff. ___________________________________________________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com

2 1

FreeRadius module
by Manuel Sánchez Cuenca 26 Oct '06

26 Oct '06

Hello all. I'm interested in include an authorization module in freeradius which will be executed after an authentication success, but before send the success message to the AP and the user. Can anybody help me telling me how to create a new module for freeradius? Thanks in advance. -- ----------------------------- Manuel Sanchez Cuenca Departamento de Ingenieria de la Informacion y las Comunicaciones Facultad de Informatica. Universidad de Murcia Campus de Espinardo - 30080 Murcia (SPAIN) Tel.: +34-968-364644 Fax: +34-968-364151 email: msc(a)dif.um.es | manuelsc(a)um.es url: http://libra.inf.um.es/~lolo

2 1

Automatic report from sources (radiusd) between 23.10.2006 - 24.10.2006 GMT
by Automatic cvs log generator 24 Oct '06

24 Oct '06

CVS log entries from 23.10.2006 (Mon) 08:00:01 - 24.10.2006 (Tue) 08:00:01 GMT ===================================================== Summary by authors ===================================================== Author: fcusack File: radiusd/src/modules/rlm_otp/otp_mppe.h; Revisions: 1.1.2.3 File: radiusd/src/modules/rlm_otp/ident.h; Revisions: 1.1.2.2 File: radiusd/src/modules/rlm_otp/otp_radstate.c; Revisions: 1.4.2.4 File: radiusd/src/modules/rlm_otp/extern.h; Revisions: 1.1.2.3 File: radiusd/src/modules/rlm_otp/otp_rlm.c; Revisions: 1.19.2.12, 1.19.2.11 File: radiusd/src/modules/rlm_otp/otp_pw_valid.h; Revisions: 1.3, 1.1.2.4, 1.1.2.3 File: radiusd/src/modules/rlm_otp/otp_pwe.c; Revisions: 1.8.2.4 File: radiusd/src/modules/rlm_otp/otp_util.c; Revisions: 1.13.2.3 File: radiusd/doc/ChangeLog; Revisions: 1.75 File: radiusd/src/modules/rlm_otp/Makefile.in; Revisions: 1.9, 1.4.2.5 File: radiusd/src/modules/rlm_otp/otp_mppe.c; Revisions: 1.1.2.3 File: radiusd/raddb/otppasswd.sample; Revisions: 1.4.2.3 File: radiusd/raddb/otp.conf; Revisions: 1.4.2.3 File: radiusd/src/modules/rlm_otp/otp_pw_valid.c; Revisions: 1.5, 1.4, 1.1.2.7, 1.1.2.6, 1.1.2.5 File: radiusd/src/modules/rlm_otp/otp.h; Revisions: 1.28.2.8 ===================================================== Combined list of identical log entries ===================================================== Description: otp_putfd(): add disconnect arg, to allow just mutex release, avoiding fd leak in radiusd and otpd otp_verify(): otp_putfd(fdp, 0) on successful return, otp_putfd(fdp, 1) on 2 error return cases that we missed Modified files: File: radiusd/src/modules/rlm_otp/otp_pw_valid.c; Revision: 1.5; Date: 2006/10/24 04:02:37; Author: fcusack; Lines: (+15 -9) File: radiusd/src/modules/rlm_otp/otp_pw_valid.h; Revision: 1.3; Date: 2006/10/24 04:02:38; Author: fcusack; Lines: (+3 -3) ------------------------------- Description: import from HEAD: otp_putfd(): add disconnect arg, to allow just mutex release, avoiding fd leak in radiusd and otpd otp_verify(): otp_putfd(fdp, 0) on successful return, otp_putfd(fdp, 1) on 2 error return cases that we missed Modified files: File: radiusd/src/modules/rlm_otp/otp_pw_valid.c; Revision: 1.1.2.5; Date: 2006/10/24 04:38:04; Author: fcusack; Lines: (+15 -9) File: radiusd/src/modules/rlm_otp/otp_pw_valid.h; Revision: 1.1.2.3; Date: 2006/10/24 04:38:04; Author: fcusack; Lines: (+2 -2) ------------------------------- Description: import from HEAD prevent rcsid from being optimized out Modified files: File: radiusd/src/modules/rlm_otp/extern.h; Revision: 1.1.2.3; Date: 2006/10/24 05:15:45; Author: fcusack; Lines: (+4 -1) File: radiusd/src/modules/rlm_otp/ident.h; Revision: 1.1.2.2; Date: 2006/10/24 05:15:46; Author: fcusack; Lines: (+35 -0) File: radiusd/src/modules/rlm_otp/otp.h; Revision: 1.28.2.8; Date: 2006/10/24 05:15:46; Author: fcusack; Lines: (+3 -4) File: radiusd/src/modules/rlm_otp/otp_mppe.c; Revision: 1.1.2.3; Date: 2006/10/24 05:15:46; Author: fcusack; Lines: (+3 -2) File: radiusd/src/modules/rlm_otp/otp_mppe.h; Revision: 1.1.2.3; Date: 2006/10/24 05:15:46; Author: fcusack; Lines: (+4 -1) File: radiusd/src/modules/rlm_otp/otp_pw_valid.c; Revision: 1.1.2.7; Date: 2006/10/24 05:15:47; Author: fcusack; Lines: (+3 -2) File: radiusd/src/modules/rlm_otp/otp_pw_valid.h; Revision: 1.1.2.4; Date: 2006/10/24 05:15:47; Author: fcusack; Lines: (+4 -1) File: radiusd/src/modules/rlm_otp/otp_pwe.c; Revision: 1.8.2.4; Date: 2006/10/24 05:15:47; Author: fcusack; Lines: (+3 -2) File: radiusd/src/modules/rlm_otp/otp_radstate.c; Revision: 1.4.2.4; Date: 2006/10/24 05:15:48; Author: fcusack; Lines: (+3 -2) File: radiusd/src/modules/rlm_otp/otp_rlm.c; Revision: 1.19.2.12; Date: 2006/10/24 05:15:48; Author: fcusack; Lines: (+3 -2) File: radiusd/src/modules/rlm_otp/otp_util.c; Revision: 1.13.2.3; Date: 2006/10/24 05:15:48; Author: fcusack; Lines: (+3 -2) ===================================================== Log entries ===================================================== Description: document rlm_otp fd leak fix Modified files: File: radiusd/doc/ChangeLog; Revision: 1.75; Date: 2006/10/24 04:20:54; Author: fcusack; Lines: (+2 -1) ------------------------------- Description: typo Modified files: File: radiusd/raddb/otp.conf; Revision: 1.4.2.3; Date: 2006/10/24 04:34:24; Author: fcusack; Lines: (+1 -1) ------------------------------- Description: no longer used Modified files: File: radiusd/raddb/otppasswd.sample; Revision: 1.4.2.3; Date: 2006/10/24 04:33:53; Author: fcusack; Lines: (+0 -0) ------------------------------- Description: add new header ident.h Modified files: File: radiusd/src/modules/rlm_otp/Makefile.in; Revision: 1.9; Date: 2006/10/24 05:33:01; Author: fcusack; Lines: (+1 -1) ------------------------------- Description: import from HEAD add new header ident.h Modified files: File: radiusd/src/modules/rlm_otp/Makefile.in; Revision: 1.4.2.5; Date: 2006/10/24 05:36:08; Author: fcusack; Lines: (+1 -1) ------------------------------- Description: remove trailing "\n"s from some radlog() calls Modified files: File: radiusd/src/modules/rlm_otp/otp_pw_valid.c; Revision: 1.4; Date: 2006/10/24 03:19:06; Author: fcusack; Lines: (+10 -11) ------------------------------- Description: import from HEAD: remove trailing "\n" from some radlog() calls Modified files: File: radiusd/src/modules/rlm_otp/otp_pw_valid.c; Revision: 1.1.2.6; Date: 2006/10/24 04:40:58; Author: fcusack; Lines: (+10 -11) ------------------------------- Description: import from HEAD: s/bad state/bad radstate/ to be clear that it's not token state Modified files: File: radiusd/src/modules/rlm_otp/otp_rlm.c; Revision: 1.19.2.11; Date: 2006/10/24 04:45:13; Author: fcusack; Lines: (+8 -8) ===================================================== Summary of modified files ===================================================== File: radiusd/doc/ChangeLog Revisions: 1.75 Authors: fcusack (+2 -1) ------------------------------- File: radiusd/raddb/otp.conf Revisions: 1.4.2.3 Authors: fcusack (+1 -1) ------------------------------- File: radiusd/raddb/otppasswd.sample Revisions: 1.4.2.3 Authors: fcusack (+0 -0) ------------------------------- File: radiusd/src/modules/rlm_otp/Makefile.in Revisions: 1.9, 1.4.2.5 Authors: fcusack (+1 -1), fcusack (+1 -1) ------------------------------- File: radiusd/src/modules/rlm_otp/extern.h Revisions: 1.1.2.3 Authors: fcusack (+4 -1) ------------------------------- File: radiusd/src/modules/rlm_otp/ident.h Revisions: 1.1.2.2 Authors: fcusack (+35 -0) ------------------------------- File: radiusd/src/modules/rlm_otp/otp.h Revisions: 1.28.2.8 Authors: fcusack (+3 -4) ------------------------------- File: radiusd/src/modules/rlm_otp/otp_mppe.c Revisions: 1.1.2.3 Authors: fcusack (+3 -2) ------------------------------- File: radiusd/src/modules/rlm_otp/otp_mppe.h Revisions: 1.1.2.3 Authors: fcusack (+4 -1) ------------------------------- File: radiusd/src/modules/rlm_otp/otp_pw_valid.c Revisions: 1.5, 1.4, 1.1.2.7, 1.1.2.6, 1.1.2.5 Authors: fcusack (+15 -9), fcusack (+10 -11), fcusack (+3 -2), fcusack (+10 -11), fcusack (+15 -9) ------------------------------- File: radiusd/src/modules/rlm_otp/otp_pw_valid.h Revisions: 1.3, 1.1.2.4, 1.1.2.3 Authors: fcusack (+3 -3), fcusack (+4 -1), fcusack (+2 -2) ------------------------------- File: radiusd/src/modules/rlm_otp/otp_pwe.c Revisions: 1.8.2.4 Authors: fcusack (+3 -2) ------------------------------- File: radiusd/src/modules/rlm_otp/otp_radstate.c Revisions: 1.4.2.4 Authors: fcusack (+3 -2) ------------------------------- File: radiusd/src/modules/rlm_otp/otp_rlm.c Revisions: 1.19.2.12, 1.19.2.11 Authors: fcusack (+3 -2), fcusack (+8 -8) ------------------------------- File: radiusd/src/modules/rlm_otp/otp_util.c Revisions: 1.13.2.3 Authors: fcusack (+3 -2) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0

Identity problem and MSK, EMSK management
by kky 22 Oct '06

22 Oct '06

Hi ! i have 2 main problem, i've tried to find the solutions mostly in rfc's and googleing around but without results !! i hope the questions are not to stupid ... ; ) 1) i'm developing and auth module for eap where the real identity of the user is passed in the 3rd message ( in eap response identity there is a fictitious string "anonymous" ) so i had to add an if( .. ) statement in eap_start() that says something like that : if memcmp(request->username, "anonymous" ...) && eap type is the one i'm developing set attribute User-Name in request->username and in request->packet->vps to the real identity (found in the packet receved). And all goes well : rlm_sql finds the user in the db and gets all the attributes from radreply table , so i can access them from handler->request->reply->vps. The protocol continues but when a new response comes from the supplicant the NAS, i suppose, sets the attribute User-Name to "anonymous", is there a way to tell the NAS to change the value of User-Name to the correct one ?! the problem is that next messages will not get anymore the right user because the section above will set the User-Name to something without sense ... suggestions ? 2) the protocol derives also MSK and EMSK but i don't know where to put them ! i have seen that eap_sim_sendsuccess(EAP_HANDLER *handler) sets 2 proprietary valuepairs in handler->request->reply->vps (MS-MPPE-Recv-Key , MS-MPPE-Send-Key)... should i do something like this ? with which attribute should i tell the NAS for the keys ? Thank you ! kky

2 1

Automatic report from sources (radiusd) between 20.10.2006 - 21.10.2006 GMT
by Automatic cvs log generator 21 Oct '06

21 Oct '06

CVS log entries from 20.10.2006 (Fri) 08:00:01 - 21.10.2006 (Sat) 08:00:01 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/src/main/log.c; Revisions: 1.52 File: radiusd/src/include/libradius.h; Revisions: 1.124 File: radiusd/src/main/modcall.c; Revisions: 1.56 File: radiusd/src/lib/log.c; Revisions: 1.12 Author: pnixon File: radiusd/doc/examples/postgresql.sql; Revisions: 1.9 ===================================================== Combined list of identical log entries ===================================================== Description: fix stdarg.h Modified files: File: radiusd/src/include/libradius.h; Revision: 1.124; Date: 2006/10/20 18:41:11; Author: aland; Lines: (+2 -1) File: radiusd/src/lib/log.c; Revision: 1.12; Date: 2006/10/20 18:41:11; Author: aland; Lines: (+2 -3) File: radiusd/src/main/log.c; Revision: 1.52; Date: 2006/10/20 18:41:12; Author: aland; Lines: (+2 -3) File: radiusd/src/main/modcall.c; Revision: 1.56; Date: 2006/10/20 18:41:12; Author: aland; Lines: (+1 -2) ===================================================== Log entries ===================================================== Description: Cleanup Modified files: File: radiusd/doc/examples/postgresql.sql; Revision: 1.9; Date: 2006/10/20 15:14:03; Author: pnixon; Lines: (+7 -7) ===================================================== Summary of modified files ===================================================== File: radiusd/doc/examples/postgresql.sql Revisions: 1.9 Authors: pnixon (+7 -7) ------------------------------- File: radiusd/src/include/libradius.h Revisions: 1.124 Authors: aland (+2 -1) ------------------------------- File: radiusd/src/lib/log.c Revisions: 1.12 Authors: aland (+2 -3) ------------------------------- File: radiusd/src/main/log.c Revisions: 1.52 Authors: aland (+2 -3) ------------------------------- File: radiusd/src/main/modcall.c Revisions: 1.56 Authors: aland (+1 -2) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0

Enabling login of users who are not in the users database and yet whose certificates are still valid.
by Jenny Ngo Gui 21 Oct '06

21 Oct '06

I just like to ask if there any other alternative means to support this feature, without the need to remove the [DEFAULT Auth-Type := Reject] part of the users database? or is this necessary to support the login of users who are not in the users database and yet whose certificates are still valid...? Please do tell me if you have any other kind of implementation in mind for this feature, as it conflicts with the huntgroup restriction of users... Thank you!

1 0