January 2007 - Freeradius-Devel - lists.freeradius.org

Automatic report from sources (radiusd) between 18.01.2007 - 19.01.2007 GMT
by Automatic cvs log generator 19 Jan '07

19 Jan '07

CVS log entries from 18.01.2007 (Thu) 09:00:00 - 19.01.2007 (Fri) 09:00:00 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/doc/rlm_sqlcounter; Revisions: 1.3.6.3 File: radiusd/raddb/radiusd.conf.in; Revisions: 1.188.2.4.2.15 ===================================================== Combined list of identical log entries ===================================================== Description: Remove old text, and clarify other text Modified files: File: radiusd/doc/rlm_sqlcounter; Revision: 1.3.6.3; Date: 2007/01/18 14:01:20; Author: aland; Lines: (+23 -45) File: radiusd/raddb/radiusd.conf.in; Revision: 1.188.2.4.2.15; Date: 2007/01/18 14:01:19; Author: aland; Lines: (+6 -1) ===================================================== Log entries ===================================================== ===================================================== Summary of modified files ===================================================== File: radiusd/doc/rlm_sqlcounter Revisions: 1.3.6.3 Authors: aland (+23 -45) ------------------------------- File: radiusd/raddb/radiusd.conf.in Revisions: 1.188.2.4.2.15 Authors: aland (+6 -1) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0

Need help
by Abhinay Sinha 18 Jan '07

18 Jan '07

Hi, I am developing a billing package for ISPs. I am trying to use the freeradius server, but my problem is that my database schemas are complex and won't be working with the available modules. That means I will have to develop a custom module for my software and compile it with freeradius. My problem is that if I do that, it won't be compatible with general RADIUS servers and I'll have to provide the software with freeradius server and my module. So will it mean that I'll have to keep my software GPL, since I am using and distributing freeradius and also it contains mysql server, or can I distribute my software commercially? Kindly help me and tell me what can be done regarding the same? Thanks in advance. Abhinay

5 25

segfault when mysql server is unreachable for period of time
by Joe Maimon 17 Jan '07

17 Jan '07

Anyone else run into this?

2 2

cancelling requests due to max_request_time
by Frank Cusack 16 Jan '07

16 Jan '07

request_list.c around line 574, calling pthread_cancel() on the thread handling a timed out request is a bad idea. It can leave resources hanging, like a locked mutex for ownership of an ldap file descriptor. In order for pthread_cancel() to be a good idea, most modules would need to take care to disable cancellation while they hold resources open, and/or set cancellation handlers to clean them up. That's a lot of work and there's a lot of room for bugs there. But I can't think of a better approach. You don't want to let threads just run to completion and waste resources. -frank

2 5

RE: Need help
by Alexander Schrab 15 Jan '07

15 Jan '07

> But you're right, that's too much work. I'll update the > "digest" module so that that much work is no longer necessary. Speaking of which, has anyone any updated info on the RFC4590 status? /Alex

2 1

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

Automatic report from sources (radiusd) between 09.01.2007 - 11.01.2007 GMT
by Automatic cvs log generator 11 Jan '07

11 Jan '07

CVS log entries from 09.01.2007 (Tue) 09:00:01 - 11.01.2007 (Thu) 09:00:00 GMT ===================================================== Summary by authors ===================================================== Author: pnixon File: radiusd/src/modules/rlm_sqlippool/rlm_sqlippool.c; Revisions: 1.15, 1.3.2.4 ===================================================== Combined list of identical log entries ===================================================== Description: teach sqlippool to report if it allocated and IP or not via return code. Closed bug 414 Modified files: File: radiusd/src/modules/rlm_sqlippool/rlm_sqlippool.c; Revision: 1.15; Date: 2007/01/10 16:06:42; Author: pnixon; Lines: (+3 -3) File: radiusd/src/modules/rlm_sqlippool/rlm_sqlippool.c; Revision: 1.3.2.4; Date: 2007/01/10 16:07:18; Author: pnixon; Lines: (+3 -3) ===================================================== Log entries ===================================================== ===================================================== Summary of modified files ===================================================== File: radiusd/src/modules/rlm_sqlippool/rlm_sqlippool.c Revisions: 1.15, 1.3.2.4 Authors: pnixon (+3 -3), pnixon (+3 -3) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0

rlm_sql_firebird in freeradius 1.1.4
by Vitaly Bodzhgua 10 Jan '07

10 Jan '07

Hello, rlm_sql_firebird module in freeradius 1.1.4 should not be used because of some serious bugs. I posted fixes on http://bugs.freeradius.org/show_bug.cgi?id=378, but they were did not issued. So if someone brave enough to take a risk of using or testing this module, he should download last source code files from this attachment http://bugs.freeradius.org/showattachment.cgi?attach_id=186. For a future, if this module will be continued in the freeradius project, how I can post changes or fixes for it?

2 1

Automatic report from sources (radiusd) between 08.01.2007 - 09.01.2007 GMT
by Automatic cvs log generator 09 Jan '07

09 Jan '07

CVS log entries from 08.01.2007 (Mon) 09:00:01 - 09.01.2007 (Tue) 09:00:01 GMT ===================================================== Summary by authors ===================================================== Author: pnixon File: radiusd/src/modules/rlm_sql/drivers/rlm_sql_postgresql/sql_postgresql.c; Revisions: 1.52, 1.51 File: radiusd/src/modules/rlm_sqlippool/rlm_sqlippool.c; Revisions: 1.14 File: radiusd/raddb/Makefile; Revisions: 1.15 ===================================================== Combined list of identical log entries ===================================================== Description: Fix Bug 413 sqlippool_query1 freeing results too early Cleanup a bunch of other rubbish including a memory leak in sql_postgresql.c Modified files: File: radiusd/src/modules/rlm_sql/drivers/rlm_sql_postgresql/sql_postgresql.c; Revision: 1.52; Date: 2007/01/09 01:58:18; Author: pnixon; Lines: (+45 -42) File: radiusd/src/modules/rlm_sqlippool/rlm_sqlippool.c; Revision: 1.14; Date: 2007/01/09 01:58:18; Author: pnixon; Lines: (+18 -37) ===================================================== Log entries ===================================================== Description: Someone added attrs.access_reject and attrs.accounting_response to radiusd.conf but forgot to add them to the Makefile creating a broken install. Modified files: File: radiusd/raddb/Makefile; Revision: 1.15; Date: 2007/01/08 19:19:49; Author: pnixon; Lines: (+3 -2) ------------------------------- Description: in case of a non-SQL_DOWN fatal error that occurs on the postgresql database server the function incorrectly returns 0 instead of -1 Modified files: File: radiusd/src/modules/rlm_sql/drivers/rlm_sql_postgresql/sql_postgresql.c; Revision: 1.51; Date: 2007/01/08 16:14:53; Author: pnixon; Lines: (+3 -5) ===================================================== Summary of modified files ===================================================== File: radiusd/raddb/Makefile Revisions: 1.15 Authors: pnixon (+3 -2) ------------------------------- File: radiusd/src/modules/rlm_sql/drivers/rlm_sql_postgresql/sql_postgresql.c Revisions: 1.52, 1.51 Authors: pnixon (+45 -42), pnixon (+3 -5) ------------------------------- File: radiusd/src/modules/rlm_sqlippool/rlm_sqlippool.c Revisions: 1.14 Authors: pnixon (+18 -37) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0

sql module, postgresql driver
by FreeRadius Devel 08 Jan '07

08 Jan '07

hello, in case of a fatal error that occurs on the postgresql database server the sql accounting module returns "ok" so the "redundancy" feature of freeradius does not work. in file src/modules/rlm_sql/drivers/rlm_sql_postgresql/sql_postgresql.c, function sql_check_error I see that for non "SQL_DOWN" errors it returns 0, should it be -1 ? a non zero value ? thanks, Razvan Radu ::: radiusd -X ::: ====================================================== rlm_sql (sql): Reserving sql socket id: 4 rlm_sql_postgresql: Status: PGRES_FATAL_ERROR rlm_sql_postgresql: Error relation "bbb" does not exist rlm_sql_postgresql: Postgresql Fatal Error: [42P01] Accured!! rlm_sql_postgresql: Postgresql Fatal Error: [UNDEFINED TABLE] Occured!! rlm_sql (sql): Released sql socket id: 4 modcall[accounting]: module "sql" returns ok for request 351 modcall: group returns ok for request 351 modcall: group accounting returns ok for request 351 ======================================================

2 2