- Freeradius-Devel - lists.freeradius.org

undefined symbol: mysql_next_result
by 박지연 03 Aug '07

03 Aug '07

2 1

Automatic report from sources (radiusd) between 01.08.2007 - 02.08.2007 GMT
by Automatic cvs log generator 02 Aug '07

02 Aug '07

CVS log entries from 01.08.2007 (Wed) 08:00:00 - 02.08.2007 (Thu) 08:00:00 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/src/main/evaluate.c; Revisions: 1.24 ===================================================== Log entries ===================================================== Description: Mash operators so that the "detail" module (among others) gets '=' rather than ':=', etc. Modified files: File: radiusd/src/main/evaluate.c; Revision: 1.24; Date: 2007/08/01 15:45:34; Author: aland; Lines: (+11 -2) ===================================================== Summary of modified files ===================================================== File: radiusd/src/main/evaluate.c Revisions: 1.24 Authors: aland (+11 -2) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0

updating avp lists with unlang and operators
by Stephan Jaeger 01 Aug '07

01 Aug '07

Hi, if i overwrite an avp in the preacct section like update request { User-Name := "foobar" } and i have a "detail" instance in the acct section, the line that is written to the detail log is "User-Name := foobar" instead of "User-Name = foobar" I guess the problem lies in my_pairmove() in evaluate.c (line 774). The avp is copied from the src avp list to the dst avp list and the operator is not touched. Maybe the operator in the dst list should default to "=" if the list is "reply" or "request"? Another solution might be to alter rlm_detail to always use the "=" operator when printing out avp's. What do you think? Stephan Jaeger -- Stephan Jaeger <stephan.jaeger(a)ewetel.de> EWE TEL GmbH

2 3

EAP-SIM Failed in Authentication
by Pramila A 01 Aug '07

01 Aug '07

Hi, I have installed Free Radius Client/Server. I just would like to use SIM Authentication. I have Modified the Conf file accordingly. Brought up the Radius server successfully and when I try to bring the client with command line arguments radeapclient -x localhost auth testing123 <eapsim-in.txt where the eapsim-in.txt there under tests/eapsim03 directory. Client sending the Message, but it is failed in the Server saying that no RAND attributes and cannot initiate sim authentication. Where client is receiving the Access Reject Message. Please guide me what format I have to use to initiate SIM Authentication. Here is the eapsim-in.txt file looks like: User-Name = "eapsim" NAS-IP-Address = marajade.sandelman.ottawa.on.ca EAP-Code = Response EAP-Type-Identity = "eapsim" Message-Authenticator = 0 NAS-Port = 0 EAP-Sim-Rand1 = 0xabcd1234abcd1234abcd1234abcd1234 EAP-Sim-Rand2 = 0xbcd1234abcd1234abcd1234abcd1234a EAP-Sim-Rand3 = 0xcd1234abcd1234abcd1234abcd1234ab EAP-Sim-Sres1 = 0x1234abcd EAP-Sim-Sres2 = 0x234abcd1 EAP-Sim-Sres3 = 0x34abcd12 EAP-Sim-KC1 = 0x0011223344556677 EAP-Sim-KC2 = 0x1021324354657687 EAP-Sim-KC3 = 0x30415263748596a7 Thanks & Regards Pramila ============================================================================================================================ Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at <a href="http://www.techmahindra.com/Disclaimer.html">http://www.techmahindra.com/Disclaimer.html</a> externally and <a href="http://tim.techmahindra.com/Disclaimer.html">http://tim.techmahindra.com/Disclaimer.html</a> internally within Tech Mahindra. ============================================================================================================================

1 0

freeradius and snmp on 64 bit architectures
by Thomas Woerner 01 Aug '07

01 Aug '07

Hello, we have problems here with freeradius and snmp on 64 bit architectures. I have analyzed the code for snmp interaction and found some type problems. I made a patch, which corrects the type problems and the snmp handshake is now working without any problem, but trying to get information from freeradius over snmp is not working, yet. But I do not find the problem. Maybe someone of you can help me with this. I have attached the patch. Thanks, Thomas -- Thomas Woerner Software Engineer Phone: +49-711-96437-310 Red Hat GmbH Fax : +49-711-96437-111 Hauptstaetterstr. 58 Email: Thomas Woerner <twoerner(a)redhat.com> D-70178 Stuttgart Web : http://www.redhat.de/

1 0

Automatic report from sources (radiusd) between 31.07.2007 - 01.08.2007 GMT
by Automatic cvs log generator 01 Aug '07

01 Aug '07

CVS log entries from 31.07.2007 (Tue) 08:00:01 - 01.08.2007 (Wed) 08:00:00 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/src/main/evaluate.c; Revisions: 1.23 ===================================================== Log entries ===================================================== Description: Allow !~ to work, too Modified files: File: radiusd/src/main/evaluate.c; Revision: 1.23; Date: 2007/07/31 13:30:10; Author: aland; Lines: (+6 -6) ===================================================== Summary of modified files ===================================================== File: radiusd/src/main/evaluate.c Revisions: 1.23 Authors: aland (+6 -6) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0

Unlang, regex problem
by Stephan Jäger 01 Aug '07

01 Aug '07

Hello, there seems to be a problem with Unlang, !~ does not work as expected. if ("%{User-Name}" =~ /foobar/) { } works: Mon Jul 30 14:14:14 2007 : Debug: >>> CALLING EVALUATE "%{User-Name}" =~ /foobar/) Mon Jul 30 14:14:14 2007 : Debug: >>> LOOKING AT "%{User-Name}" =~ /foobar/) Mon Jul 30 14:14:14 2007 : Debug: >>> 24:%{User-Name} 17 23:foobar Mon Jul 30 14:14:14 2007 : Debug: >>> EVALUATE 0 ::):: Mon Jul 30 14:14:14 2007 : Debug: >>> AT EOL2a Mon Jul 30 14:14:14 2007 : Debug: >>> EVALUATE RETURNED ::):: Mon Jul 30 14:14:14 2007 : Debug: >>> AT EOL but: if ("%{User-Name}" !~ /foobar/) { } does not work: Mon Jul 30 14:15:07 2007 : Debug: >>> CALLING EVALUATE "%{User-Name}" ! ~ /foobar/) Mon Jul 30 14:15:07 2007 : Debug: >>> LOOKING AT "%{User-Name}" ! ~ /foobar/) Mon Jul 30 14:15:07 2007 : Debug: >>> I0 24:%{User-Name} Mon Jul 30 14:15:07 2007 : Debug: >>> EVALUATE 0 ::!~ /foobar/):: Mon Jul 30 14:15:07 2007 : Debug: >>> AT EOL2a Mon Jul 30 14:15:07 2007 : Debug: >>> EVALUATE RETURNED ::!~ /foobar/):: Mon Jul 30 14:15:07 2007 : Error: Unexpected trailing text at: ! ~ /foobar/) You can work around this with: if (!"%{User-Name}" =~ /foobar/) { } But i guess the other way should work too. Regards Stephan Jaeger -- Stephan Jäger <stephan.jaeger(a)ewetel.de>

4 5

Adding run-time-access (RTA) to FreeRadius
by Bob Smith 31 Jul '07

31 Jul '07

Awhile ago the FreeRADIUS mailing list had a thread on how to remove the practical necessity of SIGHUP to load a new configuration. I am the author of the Run-Time-Access (RTA) library, the "crazy SQL scheme" that Alan mentioned in the thread. I caught part of the thread and asked Alan if he'd like me to add RTA to part of FreeRADIUS, in particular, to the RADCLIENT list. This rather long email is a report to Alan and to the other FreeRADIUS developers on that effort. This report has a little bit of background on RTA, an executive summary, answers to questions in the thread, some comments on what would be required, and finally, links to a working demo. RTA BACKGROUND In 1993 I helped found a company now called Venturi Wireless. We made a compression server for sale to the cellular wireless carriers. In order to avoid the then near religious wars between Solaris and Windows NT we chose to build a compression "appliance" (based on Linux). Our first user interface used HTML directly in the compression server (like CUPS does/did). This web interface was little more than a editor on top of a config file and we restarted the server when a use hit the Commit button. Customers demanded an SNMP interface, so we added that directly into the server too. Then they wanted a command line interface and we knew we were in trouble. The backdrop to this was the constant complaints about restarting the server for even relatively minor configuration changes. We eventually decided to break all user interfaces away from the server and use a common protocol that would let many UIs talk to the server while it was running and able to do on-the-fly config changes, and get lots of status and statistics from from the server in real-time. We considered the Hayes AT command set but we settled on a text-based, SQL type interface over TCP. The Venturi Wireless solution worked but had many shortcomings and after I left the company I wrote RTA to overcome those shortcoming. If multiple, run-time interfaces for configuration, status, and statistics are of value to you, then read on. If you think the users of FreeRADIUS are going to remain happy with root access, 'vi' and 'SIGHUP', then you can skip to the next message in your InBox. EXECUTIVE SUMMARY I believe it will be straightforward but somewhat tedious to add RTA to the FreeRADIUS server. There are two issues to be resolve up front - updates to the data in FreeRADIUS are not thread safe, and if you have UI driven configuration changes, you can not keep the human readable file formats now in use. Please note that neither of these issue are tied to the API used to access the configuration; they are tied to FreeRADIUS itself and updating its configuration while FreeRADIUS continues to run. FREQUENTLY ASKED QUESTIONS (from the "HUP handling: a thought" thread) You might like http://linuxfocus.org/English/May2004/article338.shtml as a quick introduction to RTA. Scanning it may answer more questions than are covered below. 1) Does the replace SIGHUP ? It does not need to but, yes, it can. That is, you can still restart on SIGHUP but shouldn't ever _need_ to use SIGHUP. 2) Would root access and 'vi' still be required? The hope is that FreeRADIUS would become an appliance without ever requiring root access or vi after the initial installation. To do this, every config parameter in FreeRADIUS would have to be mapped to an RTA accessible table. (straightforward but tedious) 3) Use Webmin for the web interface! You can do this but under the covers you're still editing the config files and sending a SIGHUP. Webmin, as good as it is, does nothing to solve the SNMP and CLI problems. 4) RTA is not thread safe! While true, I don't think this is the issue. RTA is an API for other programs to access your data. Would you ask that the Hayes AT command set be thread safe? Of course not. I think the real issue is that FreeRADIUS is not thread safe for configuration updates. This is why you have to let all the threads die before doing the restart on SIGHUP. The FreeRADIUS databases themselves are not thread save to asynchronous updates. I do not have a good answer for this. SQLite is thread-safe but, like all ACID databases, is not at all "lite". You could remove thread support but that would cause no end of developer turmoil. (For what it's worth, I'll be happy to make RTA thread safe if it helps.) 5) Does RTA support transactions? No. Again compare it to an AT command set used to manage a modem. It is only an API. It _is_ atomic at the row. level. That is, updates to rows fail or succeed on the whole row, and failed updates return the row it its original state. 6) RTA has too many dependencies! Actually RTA only requires libc (if I recall correctly). Your user interface programs will require the PostgreSQL client library. BTW: using PostgreSQL means your UIs can be written in C, C++, PHP, Java, Perl, Ruby...on and on.... 7) We've put too much effort into our config file syntax to give them up. This is not really an RTA issue; it is an issue for any scheme to allow dynamic configuration updates. Yes, you _could_ have the server try to write the config back to disk int the same human-readable format, but you'd be crazy to try. The simple truth is that if you're going to have dynamic configuration updates, then you're eventually going to have to give up the human-readable config files. (BTW: Yes, RTA saves its configuration tables as a series of (human readable, vi editable) SQL statements. This reduces code and bugs since the same parser for the API is used to parse the config files. Think of all the config parsing code you could take out of FreeRADIUS!) 8) SQL is too CPU intensive for use in FreeRADIUS. We haven't found that to be the case. For one thing, the SQL parser in RTA is a lex/yacc state machine, but, more importantly, RTA is only invoked when the user wants to update a configuration or view some statistic. Relative to the overall CPU load, these bursts of user-initiated CPU activity are negligible. 9) RTA is useless without INSERT and DELETE. This has long been a criticism of RTA. While there are simple ways around this most people still expect INSERT and DELETE for tables where the data is stored as a linked-list or other editable structure. I've had a difficult time getting people to see RTA as an API and *not* as a database. Adding INSERT and DELETE will make this task all the more difficult. That said, I've recently been convinced that adding INSERT and DELETE for tables with dynamically allocated rows would be a good thing. Sigh... INSERT and DELETE will be in the next release of RTA. 10) We can not live with RTA's hard coded limits. I'm not sure I understand this one entirely. There is an upper bound on the number of tables and an upper bound on the number of rows but these are high enough not to not cause a problem for FreeRADIUS (and they're easy to change). The rest of the hard coded limits are for things like the string length for the name of a column or table, things that reasonably should have some limit. Let know the specifics and I'll think about how to make them soft limits. 11) My users like 'vi' and copying config files. This should be the heart of the debate. If you or your users really want vi and human readable files then you should forget about RTA, FUSE, or any of the alternatives. I can answer questions about RTA but I can not help with this fundamental question. ADDING RTA TO FreeRADIUS Giving up on human-readable config files, while emotionally difficult, will happen over time. The bigger problem is whether to give up on threads or to make all updates of configuration tables thread safe. If you choose to continue looking at RTA, then I'd suggest that you start with an inventory of all of the configuration data and try to map that data into tables with columns and row. BTW: typically an RTA "row" is an instance of a C data structure, a "table" is an array or linked-list of those structures, and a "column" corresponds to a single member of the data structure. While doing the above inventory be sure add in all the status and statistics that make sense. Relatively low CPU-cost access to status and statistics is one of the best parts of RTA. A WORKING DEMO It's not much but I added RTA to FreeRADIUS as far as the RADCLIENT structure is concerned. I had to modify radiusd.c to add the RTA library calls and I modified the RADCLIENT structure to make it easier for you to see the changes. (In retrospect I probably should not have touched RADCLIENT.) All of the RTA code is in use_rta.c. The files are at: http://www.linuxappliancedesign.com/projects/rad/use_rta.c http://www.linuxappliancedesign.com/projects/rad/radiusd.c http://www.linuxappliancedesign.com/projects/rad/radiusd.h RTA include a generic table editor. The table editor is to RTA tables what vi is to text files -- a simple way to view and change them. The table editor is _not_ meant to be the final user interface. You can view and edit the RADCLIENT table in the demo server here: http://www.linuxappliancedesign.com/projects/rad/rta_apps.html Be warned that this version of RTA does not have INSERT and DELETE so to add a new row you have to fill in the single blank row there and to delete a row you have to clear our the ipaddr column. I will remain on this mailing list to answer question until the end of the week. At the end of the week I'll remove myself from the mailing list and shut down the demo server. (If you reply to this email would you mind not quoting the whole thing? Instead, please quote just the section relevant to your comment or questions.) thanks, Bob Smith

2 2

rlm_sql, read_groups
by Stephan Jaeger 28 Jul '07

28 Jul '07

Hello, In revision 1.157 of "src/modules/rlm_sql/rlm_sql.c" the config variable "read_groups" was removed, but is still documented in the example config "raddb/sql.conf" and also used in rlm_authorize() (rlm_sql.c, line 958): if (!inst->config->read_groups) dofallthrough = fallthrough(reply_tmp); Was that by accident or did i again miss something? I really don't like the idea to have half a million "Fall-Through = yes" entries in the radcheck table ;) Regards Stephan Jaeger -- Stephan Jaeger <stephan.jaeger(a)ewetel.de> EWE TEL GmbH

3 2

Automatic report from sources (radiusd) between 27.07.2007 - 28.07.2007 GMT
by Automatic cvs log generator 28 Jul '07

28 Jul '07

CVS log entries from 27.07.2007 (Fri) 08:00:01 - 28.07.2007 (Sat) 08:00:00 GMT ===================================================== Summary by authors ===================================================== Author: nbk File: radiusd/src/modules/rlm_sql/rlm_sql.c; Revisions: 1.171 ===================================================== Log entries ===================================================== Description: Fix the read_groups directive. Modified files: File: radiusd/src/modules/rlm_sql/rlm_sql.c; Revision: 1.171; Date: 2007/07/27 09:55:13; Author: nbk; Lines: (+4 -2) ===================================================== Summary of modified files ===================================================== File: radiusd/src/modules/rlm_sql/rlm_sql.c Revisions: 1.171 Authors: nbk (+4 -2) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0