- Freeradius-Devel - lists.freeradius.org

Automatic report from sources (radiusd) between 02.09.2006 - 03.09.2006 GMT
by Automatic cvs log generator 03 Sep '06

03 Sep '06

CVS log entries from 02.09.2006 (Sat) 08:00:00 - 03.09.2006 (Sun) 08:00:01 GMT ===================================================== Summary by authors ===================================================== Author: nbk File: radiusd/debian/freeradius.init; Revisions: 1.7 Author: pnixon File: radiusd/doc/rlm_ldap; Revisions: 1.40 File: radiusd/doc/ascend; Revisions: 1.3 File: radiusd/doc/ldap_howto.txt; Revisions: 1.6 ===================================================== Combined list of identical log entries ===================================================== Description: Minor doc cleanups Modified files: File: radiusd/doc/ascend; Revision: 1.3; Date: 2006/09/02 10:53:17; Author: pnixon; Lines: (+2 -2) File: radiusd/doc/ldap_howto.txt; Revision: 1.6; Date: 2006/09/02 10:53:17; Author: pnixon; Lines: (+2 -2) File: radiusd/doc/rlm_ldap; Revision: 1.40; Date: 2006/09/02 10:53:17; Author: pnixon; Lines: (+1 -1) ===================================================== Log entries ===================================================== Description: Rework the /var/run on tmpfs patch and print an error if for some reason /var/run is not writable. Modified files: File: radiusd/debian/freeradius.init; Revision: 1.7; Date: 2006/09/02 11:17:16; Author: nbk; Lines: (+6 -2) ===================================================== Summary of modified files ===================================================== File: radiusd/debian/freeradius.init Revisions: 1.7 Authors: nbk (+6 -2) ------------------------------- File: radiusd/doc/ascend Revisions: 1.3 Authors: pnixon (+2 -2) ------------------------------- File: radiusd/doc/ldap_howto.txt Revisions: 1.6 Authors: pnixon (+2 -2) ------------------------------- File: radiusd/doc/rlm_ldap Revisions: 1.40 Authors: pnixon (+1 -1) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0

RFC compliance in sanitizing Access-Reject responses
by Mike 02 Sep '06

02 Sep '06

All, First, thank you for an excellent server. Within a few hours we went from google-ing for a radius server to having a proxy up which does (almost) everything we needed to make a third party device/server learn many cool new tricks. Unfortunately last night I had to spend 3 hours (maybe "only" 3 hours, attesting to high code quality) in trying to figure out why Access-Reject messages were loosing all but the Reply-Message attribute. Eventually I did find, first a hint on the mailing lists, then the RFC, and then finally after quite a bit of digging, the code in util.c : case PW_AUTHENTICATION_REJECT: pairmove2(&vps, &(packet->vps), PW_EAP_MESSAGE); pairmove2(&vps, &(packet->vps), PW_MESSAGE_AUTHENTICATOR); pairmove2(&vps, &(packet->vps), PW_REPLY_MESSAGE); break; I would like to suggest at least two small changes to make freeradius an even better tool than it already is. The first is really simple and would take practically no work at all: can we please have a log message here that notifies the user of this operation when running with -X? This would have saved me most of the time I've spent digging through mailing lists and the rlm_attr_filter code, and allowed me to quickly find the above culprit. This is actually quite necessary, since any "detail" logs that can be inserted on the proxy reply path happily show all attributes - the attributes magically disappear right before packet is sent. The second request is also trivial to implement: make the above code configurable/optional. Yes, there is a great deal of strength and respect in supporting the RFC to the dot - and without a doubt, that should be the default out-of-the-box configuration. But not all devices are created equal - and in my case, as I'm sure in some others, useful information is passed in the Access-Reject message in attributes other than Reply-Message. Obviously this is not compliant - but all the devices I have are quite happy accepting those "extra" arguments, and a third party server is certainly very happy to send them. Making this code "optional" with a config file switch saves me from hacking the sources. Code change can be achieved simply by moving up case PW_AUTHENTICATION_REJECT: above the default: case and wrapping the 4 line body (including break;) inside of an if statement, so this change is also quite triviail. The third "request" or "option" perhaps, is a bit more complex. I would propose that the above code is actually a hack to comply with RFC, and that the appropriate mechanism of accomplishing this effect is through an appropriate set of attribute filters (enabled by default). This would require extending the attr_filters module to consider the request/response type being filtered. The default configuration can point out the RFC in the comments and filter out everything with the three exceptions. This of course allows for maximal flexibility, while still respecting the standard in the default configuration. I think this one is quite a bit more work, so I do not put too many hopes into it, but I figured I would throw it out on the table. Again, thanks for a great server. The above "hickup" is hardly worth mentioning when compared to the overall experience we've had in setting up the proxy and getting it to do what we want.

3 7

RE: EAP-AKA authentication support
by Phaneuf, Brian 02 Sep '06

02 Sep '06

Re: Diffs in comments. I now see the create attachment link on the bug page which I did not notice before. Re: Configure script. This is the config script for rlm_eap_aka. When did a clean build, the make complained that it could not find it so I assumed that it was needed. It has been omitted in the patch that I just attached to the bug. Re: Radius.conf, I followed what I saw in the eap-sim tests. That is the only reason I included it at all. Since eap-aka and eap-sim do very similar things and I copied most of eap-sim to implement eap-aka, I though that is was the thing to do. Now I know that is it not. Are there additional changes you need? What if anything should I do with the radius.conf file in the patch? -----Original Message----- From: freeradius-devel-bounces+bphaneuf=reefpoint.com(a)lists.freeradius.org [mailto:freeradius-devel-bounces+bphaneuf=reefpoint.com@lists.freeradius .org] On Behalf Of Alan DeKok Sent: Friday, September 01, 2006 1:37 PM To: FreeRadius developers mailing list Subject: Re: EAP-AKA authentication support "Phaneuf, Brian" <bphaneuf(a)reefpoint.com> wrote: > Alan - I have updated the bugzilla entry with the new diffs that also > include the configure script in rlm_eap_aka that was missing from > before. Please don't put the diff's in the comments. Doing so makes it impossible to apply the patch. Add it as an attachment. And it's not necessary to include the 'configure' script. It can be generated from 'configure.in'. And I'm a little concerned about the whole-sale copy of radiusd.conf as an "example". Can you please add a separate attachment that is a diff of the stock radiusd.conf.in file, and the example you have. Adding an additional complete copy of radiusd.conf to the tree is a big problem. It means that now two copies have to be kept in sync, which is more work. It also means that the "example" you posted is configured for your local system, and is hard for others to use. I know there's already a copy of radiusd.conf in the src/eapsim-03 directory. That's a bad idea, and it should be fixed. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

3 2

Automatic report from sources (radiusd) between 01.09.2006 - 02.09.2006 GMT
by Automatic cvs log generator 02 Sep '06

02 Sep '06

CVS log entries from 01.09.2006 (Fri) 08:00:01 - 02.09.2006 (Sat) 08:00:00 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/src/main/modules.c; Revisions: 1.108, 1.107 File: radiusd/src/main/conffile.c; Revisions: 1.136 Author: nbk File: radiusd/redhat/freeradius.spec; Revisions: 1.21 Author: pnixon File: radiusd/raddb/Makefile; Revisions: 1.13 ===================================================== Log entries ===================================================== Description: It might be a good idea to actually INSTALL the new sql directory I created last night. Modified files: File: radiusd/raddb/Makefile; Revision: 1.13; Date: 2006/09/01 22:55:52; Author: pnixon; Lines: (+6 -1) ------------------------------- Description: If the Makefile installs into /usr/share/doc/freeradius-%{version}, and the %doc directives use relative [to build dir] paths, the Makefile-installed docs are removed. This is a quirk of rpm %doc behavior. In order to preserve the Makefile-installed docs, we have to install docs in the %install section rather than use %doc in the %files section. Modified files: File: radiusd/redhat/freeradius.spec; Revision: 1.21; Date: 2006/09/01 20:02:36; Author: nbk; Lines: (+16 -7) ------------------------------- Description: cf_section_read() is called from two places: 1: recursively for a new section 2: recursively for $INCLUDE In the second case, the things read from $INCLUDE must go into the current section... hence some pretty bad hacks to get that to work. It was always broken... but the recent changes to sql/sql*.conf highlighted it Modified files: File: radiusd/src/main/conffile.c; Revision: 1.136; Date: 2006/09/01 22:28:39; Author: aland; Lines: (+43 -21) ------------------------------- Description: All components and indices for module calling are now in a hash table, which means that we can put it into 'struct mainconfig', and handle HUP's better! Modified files: File: radiusd/src/main/modules.c; Revision: 1.108; Date: 2006/09/01 23:05:22; Author: aland; Lines: (+29 -39) ------------------------------- Description: Move the module lists to hash tables, which are simpler, and should help with later fixes Modified files: File: radiusd/src/main/modules.c; Revision: 1.107; Date: 2006/09/01 22:48:35; Author: aland; Lines: (+68 -51) ===================================================== Summary of modified files ===================================================== File: radiusd/raddb/Makefile Revisions: 1.13 Authors: pnixon (+6 -1) ------------------------------- File: radiusd/redhat/freeradius.spec Revisions: 1.21 Authors: nbk (+16 -7) ------------------------------- File: radiusd/src/main/conffile.c Revisions: 1.136 Authors: aland (+43 -21) ------------------------------- File: radiusd/src/main/modules.c Revisions: 1.108, 1.107 Authors: aland (+29 -39), aland (+68 -51) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0

RE: RPM packaging (was: Last set of changes for 1.1.3)
by Sandworm 01 Sep '06

01 Sep '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 29 August 2006 7:01 PM, Nicolas Baradakis wrote: > > Thanks for the explanation: I never used rpmbuild myself, so I didn't > know the detailed mechanisms. Then it appears deletion is not really > a problem. The only thing that is strange, is that you redo with > rpmbuild what the Makefile has already done. > The RPM build process does use the Makefile. It does a complete build and install, but does the install in the environment of the "build root", which has a usr, etc, bin, and so on. The built directory is then used to construct the packaged binary RPM (and source RPM, if requested). However, it needs to distinguish between different types of files. This is why files are tagged as "%doc", because these need to be located in what is designated as the documentation directory. So, regardless of the original directory that the Makefile installed them in, they get moved into the documentation directory, sort of relative to the way they are specified in the %doc directives. If you're interested, see "The %doc Directive" at http://www.rpm.org/max-rpm/s1-rpm-inside-files-list- directives.html. Regards SW -----BEGIN PGP SIGNATURE----- Note: This signature can be verified at https://www.hushtools.com/verify Version: Hush 2.5 wkYEARECAAYFAkT1SdEACgkQmw4BJyaatJ0eVgCgoM2ZJElpezgs821HUu6lfa1YUFgA oKWP1VLiIBUuZ3CXU3aiCZwQK74S =i+p9 -----END PGP SIGNATURE-----

3 3

RE: EAP-AKA authentication support
by Phaneuf, Brian 01 Sep '06

01 Sep '06

Thanks for the pointer! Alan - I have updated the bugzilla entry with the new diffs that also include the configure script in rlm_eap_aka that was missing from before. -----Original Message----- From: freeradius-devel-bounces+bphaneuf=reefpoint.com(a)lists.freeradius.org [mailto:freeradius-devel-bounces+bphaneuf=reefpoint.com@lists.freeradius .org] On Behalf Of Nicolas Baradakis Sent: Friday, September 01, 2006 11:43 AM To: FreeRadius developers mailing list Subject: Re: EAP-AKA authentication support Phaneuf, Brian wrote: > I am not a diff wiz. What order should my diff be done to remedy that > problem? See http://freeradius.org/radiusd/doc/DIFFS -- Nicolas Baradakis - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

2 1

RE: EAP-AKA authentication support
by Phaneuf, Brian 01 Sep '06

01 Sep '06

I am not a diff wiz. What order should my diff be done to remedy that problem? Would you like me to diff it again? Also, I just noticed that I am missing the configure file from the rlm_eap_aka directory in my submission. It is the same as it is in rlm_eap_sim but with aka replacing sim. -----Original Message----- From: freeradius-devel-bounces+bphaneuf=reefpoint.com(a)lists.freeradius.org [mailto:freeradius-devel-bounces+bphaneuf=reefpoint.com@lists.freeradius .org] On Behalf Of Alan DeKok Sent: Friday, September 01, 2006 10:20 AM To: FreeRadius developers mailing list Subject: Re: EAP-AKA authentication support "Phaneuf, Brian" <bphaneuf(a)reefpoint.com> wrote: > As I have never submitted code to FreeRADIUS before, I am unsure of what > the next step is. I've taken a quick look, and the code seems OK. My only complaint is that the patch is reversed... The diff contains the patch for moving from your version with EAP-AKA to the normal version, not the other way around. I expect that the EAP-AKA support can be added fairly soon. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

2 1

RE: EAP-AKA authentication support
by Phaneuf, Brian 01 Sep '06

01 Sep '06

I have just last week, implemented and submitted to an EAP-AKA implementation to FreeRADIUS's bugzilla database as suggested to my Alan DeKok. http://bugs.freeradius.org/show_bug.cgi?id=386 As I have never submitted code to FreeRADIUS before, I am unsure of what the next step is. -Brian -----Original Message----- From: freeradius-devel-bounces+bphaneuf=reefpoint.com(a)lists.freeradius.org [mailto:freeradius-devel-bounces+bphaneuf=reefpoint.com@lists.freeradius .org] On Behalf Of Carlos Parada Sent: Friday, September 01, 2006 7:05 AM To: freeradius-devel(a)lists.freeradius.org Subject: EAP-AKA authentication support Hi all, I was looking for freeradius in order be able to authenticate using EAP-AKA. However, correct me if I am wrong, there is still no implementation for that in latest 1.1.3 released version. Anybody knows if the EAP-AKA implementation is in the project roadmap? Has anybody else interest on that issue? Best Regards, Carlos Parada - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

2 1

EAP-AKA authentication support
by Carlos Parada 01 Sep '06

01 Sep '06

Hi all, I was looking for freeradius in order be able to authenticate using EAP-AKA. However, correct me if I am wrong, there is still no implementation for that in latest 1.1.3 released version. Anybody knows if the EAP-AKA implementation is in the project roadmap? Has anybody else interest on that issue? Best Regards, Carlos Parada

1 0

Re: Duplicate requests in a session
by Peter Nixon 01 Sep '06

01 Sep '06

Good question. Does anyone have anything against changing this? -Peter On Thu 31 Aug 2006 10:11, Santiago Balaguer García wrote: > Thanks James, I don't figure out to use primary key solves the problem of > duplicate keys. > I had in radacct as primary key <<radacctid>> but now I am going to have > <<acctuniqueid>>. > > This proble cause a new thread: why radacctid is the primary key of radacct > table instead od acctuniqueid? > > >From: James Wakefield <jamesw(a)deakin.edu.au> > >Reply-To: FreeRadius users mailing list > ><freeradius-users(a)lists.freeradius.org> > >To: FreeRadius users mailing list <freeradius-users(a)lists.freeradius.org> > >Subject: Re: Duplicate requests in a session > >Date: Wed, 30 Aug 2006 22:07:09 +1000 > > > >Santiago Balaguer García wrote: > >>Hi people, > >> > >>1) > >> In my activity I realize that when the conexion to Internet of a NAS is > >>NOT good (there are some reday in the DSL), the NAS send several Start > >>requests. My problen is my RADIUS server ask for all these requests and > >>they are inserted in my DB. So, when the user or the NAS finalize the > >>session and NAS sends Stop Request, the credit associates to the user > >>account is decremented several times. It happens so because I put a > >> trgger in my DB to decrement the user credit atomatically. > >> > >> Can I avoid the problem of inserting several times the start request? > >> If it is so, how?? > >> > >>2) Is it supposed that the value of acctsessionid and acctuniqueid in > >>radacct table are UNIQUE and they can not be duplicated ? > >> > >>Thanks, > >> Santiago > > > >Hi Santiago, > > > >Does your DBMS enforce primary key constraints? Do you have a primary key > >defined for your radacct table? If I recall correctly, MySQL by default > >doesn't, are you using MySQL? > > > >Cheers, > >-- > >James Wakefield, > >Unix Administrator, Information Technology Services Division > >Deakin University, Geelong, Victoria 3217 Australia. > > > >Phone: 03 5227 8690 International: +61 3 5227 8690 > >Fax: 03 5227 8866 International: +61 3 5227 8866 > >E-mail: james.wakefield(a)deakin.edu.au > >Website: http://www.deakin.edu.au > >- List info/subscribe/unsubscribe? See > >http://www.freeradius.org/list/users.html > > _________________________________________________________________ > Acepta el reto MSN Premium: Protección para tus hijos en internet. > Descárgalo y pruébalo 2 meses gratis. > http://join.msn.com?XAPID=1697&DI=1055&HL=Footer_mailsenviados_proteccionin >fantil > > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc

3 4