- Freeradius-Devel - lists.freeradius.org

SQL inserts for accounting data
by Russell McConnachie 23 Jan '07

23 Jan '07

Hello, I am having a problem with my accounting section of my radiusd.conf configuration file. It seems if I have more than one directive such as 'sql' and then a second sql insert of accouting data called 'acme-packets' it caused the radiusd daemon to crash with a glibc pointer error. radiusd[26843]: segfault at 00000000000000b0 rip 00000032fa747edd rsp 0000000051818be0 error 4 radiusd[27894]: segfault at 0000000000000000 rip 00000032fa743550 rsp 000000005e02ccf0 error 4 radiusd[27917] trap invalid operand rip:38fd5306c8 rsp:409fc298 error:0 radiusd[28224]: segfault at 00000000000000b0 rip 00000032fa747edd rsp 0000000043c02be0 error 4 radiusd[28257]: segfault at 00000000000000b0 rip 00000032fa747edd rsp 0000000045004be0 error 4 radiusd[28285]: segfault at 0000000000000294 rip 00000032fa744f10 rsp 00000000413fecf8 error 4 -- CUT -- # # Log traffic to an SQL database. # # See "Accounting queries" in sql.conf # Temporary commented out because it is causing problems, it # seems # there can only be one instance of a SQL query/update per # "action". # action: (authentication, accounting, pre-processing....) sql # Cisco VoIP specific bulk accounting # pgsql-voip # Acme Packets bulk accounting acme-packets -- CUT -- sql acme-packets { ... accounting_start_query = "INSERT INTO radsbcacct_start(acct_status_type, nas_ip_address, nas_port, acct_session_id, \ acme_session_ingress_callid, acme_session_egress_callid, acme_session_protocol_type, \ calling_station_id, called_station_id, h323_setup_time, h323_connect_time, \ acme_session_egress_realm, acme_session_ingress_realm, acme_flowid_fs1_f, \ acme_flowtype_fs1_f, acme_flow_in_realm_fs1_f, acme_flow_in_src_addr_fs1_f, \ acme_flow_in_src_port_fs1_f, acme_flow_in_dst_addr_fs1_f, acme_flow_in_dst_port_fs1_f, \ acme_flow_out_realm_fs1_f, acme_flow_out_src_addr_fs1_f, acme_flow_out_src_port_fs1_f, \ acme_flow_out_dst_addr_fs1_f, acme_flow_out_dst_port_fs1_f, \ acme_flowid_fs2_f, acme_flowtype_fs2_f, acme_flow_in_realm_fs2_f, acme_flow_in_src_addr_fs2_f, \ acme_flow_in_src_port_fs2_f, acme_flow_in_dst_addr_fs2_f, acme_flow_in_dst_port_fs2_f, \ acme_flow_out_realm_fs2_f, acme_flow_out_src_addr_fs2_f, acme_flow_out_src_port_fs2_f, \ acme_flow_out_dst_addr_fs2_f, acme_flow_out_dst_port_fs2_f, client_ip_address, \ acct_unique_session_id) VALUES \ ('%{Acct-Status-Type}', '%{NAS-IP-Address}', %{NAS-Port}, '%{Acct-Session-Id}', '%{Acme-Session-Ingress-CallId}', '%{Acme-Session-Egress-CallId}', '%{Acme-Session-Protocol-Type}', '%{Calling-Station-Id}', '%{Called-Station-Id}', '%{h323-setup-time}', '%{h323-connect-time}', '%{Acme-Session-Egress-Realm}', '%{Acme-Session-Ingress-Realm}', '%{Acme-FlowID_FS1_F}', '%{Acme-FlowType_FS1_F}', '%{Acme-Flow-In-Realm_FS1_F}', '%{Acme-Flow-In-Src-Addr_FS1_F}', %{Acme-Flow-In-Src-Port_FS1_F}, '%{Acme-Flow-In-Dst-Addr_FS1_F}', %{Acme-Flow-In-Dst-Port_FS1_F}, '%{Acme-Flow-Out-Realm_FS1_F}', '%{Acme-Flow-Out-Src-Addr_FS1_F}', %{Acme-Flow-Out-Src-Port_FS1_F}, '%{Acme-Flow-Out-Dst-Addr_FS1_F}', %%{Acme-Flow-Out-Dst-Port_FS1_F}, '%{Acme-FlowID_FS1_F}', %'%{Acme-FlowType_FS1_F}', '%{Acme-Flow-In-Realm_FS1_F}', %'%{Acme-Flow-In-Src-Addr_FS1_F}', %{Acme-Flow-In-Src-Port_FS1_F}, %'%{Acme-Flow-In-Dst-Addr_FS1_F}', %{Acme-Flow-In-Dst-Port_FS1_F}, %'%{Acme-Flow-Out-Realm_FS1_F}', '%{Acme-Flow-Out-Src-Addr_FS1_F}', %%{Acme-Flow-Out-Src-Port_FS1_F}, '%{Acme-Flow-Out-Dst-Addr_FS1_F}', %%{Acme-Flow-Out-Dst-Port_FS1_F}, '%{Client-IP-Address}', %'%{Acct-Unique-Session-Id}')" ... } I know it is a huge query, but is it all of the accounting information which is sent to us by our SBC When both of these inserts are enabled I get a glibc pointer exception error. I am unable to regenerate the error right now being not many calls are being made and its not flooding the radius server with requests.

2 2

RADIUS Disconnect support
by Peter Nixon 23 Jan '07

23 Jan '07

Hi Guys I have been playing with (read: using in production) RADIUS disconnect support and I have a few ideas about how we can/should integrate it into FreeRADIUS server which I thought I would share with you all for your comments. Firstly let me explain how I am using it. I have the following defined: exec radsqlkill { wait = yes program = "/usr/local/bin/radsqlkill.pl %{Calling-Station-Id}" shell_escape = yes output = none packet_type = Access-Request } authorize { radsqlkill } Now, radsqlkill.pl is designed to kill any active sessions with a Disconnect packet based on info from the radacct table. It can be provided with a username, or in my case Calling-Station-Id. Basically this lets me do simultaneous use limiting but instead of rejecting the second login it disconnects the first and allows the second. I think that this functionality and more needs to be rolled into radiusd. Basically we need to be able to do the following things: 1) Receive a disconnect packet on port 1700 and check a shared secret (New listen type in radiusd.conf) 2) Query the radacct table to find disconnect attributes based on a supplied attributes (username, callingstationid etc) 3) Send disconnect packet(s) to NAS with a shared secret and return status Now the shared secret in 1) is different from the shared secret in 3). They are both NEW config options and need to be saved somewhere. I think to keep things simple 1) should be an additional option in each realm in proxy.conf (as Disconnect senders will _mostly_ correspond with home servers) and 3) should be an additional option in each client in clients.conf (as Disconnect receivers will _mostly_ correspond with client NAS) It is technically possible that we would want to allow disconnect packets from non home servers, and send them to NAS which are not clients (think where you have chained RADIUS proxies) but I think it will make things unnecessary complicated. What do others think? I think the 3 steps I have listed above will allow everyone to be able to do what they want with Disconnect packets. Basically in the situation where radius is acting as a proxy and you want to allow a home server to disconnect a user on a NAS client you will need all 3 steps (in order). To do what I am doing above with my perl script you will only need steps 2) and 3). People who want to generate disconnect attributes from arbitrary input (a script or custom module) will simply use 3). In all cases the module should look up the appropriate shared secret from the NAS table or clients.conf. Does anyone have anything to add to this? I plan to start implimenting this as I have time as my perl script causes a 500ms Authentication delay (mostly due to perl startup) which I would like to get rid of :-) Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc

2 2

Automatic report from sources (radiusd) between 22.01.2007 - 23.01.2007 GMT
by Automatic cvs log generator 23 Jan '07

23 Jan '07

CVS log entries from 22.01.2007 (Mon) 09:00:01 - 23.01.2007 (Tue) 09:00:00 GMT ===================================================== Summary by authors ===================================================== Author: pnixon File: radiusd/raddb/radiusd.conf.in; Revisions: 1.238, 1.237 ===================================================== Log entries ===================================================== Description: Update comments to correctly reflect which detail files contain User Passwords and additionally add an example "suppress" statement to each. Modified files: File: radiusd/raddb/radiusd.conf.in; Revision: 1.238; Date: 2007/01/23 02:00:06; Author: pnixon; Lines: (+11 -7) ------------------------------- Description: fix 2 minor typos in the comments Modified files: File: radiusd/raddb/radiusd.conf.in; Revision: 1.237; Date: 2007/01/22 16:51:27; Author: pnixon; Lines: (+3 -3) ===================================================== Summary of modified files ===================================================== File: radiusd/raddb/radiusd.conf.in Revisions: 1.238, 1.237 Authors: pnixon (+11 -7), pnixon (+3 -3) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0

checkrad cisco
by Joe Maimon 19 Jan '07

19 Jan '07

session_id doesnt appear to work, probably since my session ID's look like this 0/1/0/2.33_00000007 so snmpget doesnt work. But neither does snmpwalk -- without this patch. I dont know which is correct. --- /usr/sbin/checkrad 2006-12-14 02:22:21.000000000 -0500 +++ /usr/local/sbin/checkrad.deb 2007-01-19 06:48:25.000000000 @@ -401,7 +401,7 @@ if($login eq $ARGV[3]) { return 1; }else{ - $out=snmpwalk($ARGV[1],$pass,".iso.org.dod.internet.private.enterprises.9.10.19.1.3.1.1.3"); + $out=snmpwalk($ARGV[1],$pass,".iso.org.dod.internet.private.enterprises.9.9.150.1.1.3.1.2"); if($out=~/\"$ARGV[3]\"/){ return 1; }else{

2 1

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