FreeRADIUS 1.1.4 has been released
Version 1.1.4 has been released, with a few notable improvements. The server has been updated to be compatible with Microsoft Vista clients for 802.1x. This feature should prove to be of significant interest in many deployments. The "rlm_pap" module has been updated, which should make many configurations much simpler. A new attribute has been added, called Cleartext-Password. This attribute should be used to hold the "known good" password, where configurations previously had used the "User-Password" attribute. Historically, User-Password has been used both as the users password in the Access-Request packet, and also for the "known good" password in the servers configuration ("users" file or SQL database). Having two meanings for one attribute is problematic, so we have modified the server to separate the meanings of the two attributes. Existing configurations will not be affected by this change. However, we recommend that everyone reads the "README" and "man rlm_pap" documentation once the server is installed. The ChangeLog is included below: Feature improvements * Major enhancements to rlm_pap, that make "encryption_scheme" a think of the past. See "man rlm_pap" for details. * Added SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS flag to use work-arounds that enable Windows Vista clients to work. * Added preliminary code to support Firebird. (closes: #378) Use at your own risk! * Send MS-CHAP2-Success, which makes EAP-TTLS/MSCHAP work on more platforms. (closes: #402) * Add a new "reply-name" directive in rlm_sqlcounter to define the name of the reply attribute. (closes: #403) * Added more dictionaries and attributes (closes: #408, among others) * Print ntlm_auth failure reason in Module-Failure-Message (closes: #398) * radsqlrelay is able to get the DB password from a file instead of command line. (closes: #395) Bug fixes * Fix a parse error in the digest module, where malformed digest requests would result in the user being accepted. Oops... * VALUEs can only be defined for 'integer', to catch mistakes with setting VALUEs for type 'string'. * Better parsing of VALUE names, so that values starting with a digit work correctly. * Check return from malloc (closes: #407) * Fix a double free() in rlm_eap_tls.c (closes: #404) * Check return code of malloc() during initialization. (closes: #407) * Fix a corner case where the proxy port isn't set either in radiusd.conf or in proxy.conf. NOT in this release * Threading issues with SSL and EAP on some systems. * MS-CHAP UTF-8 fixes. We expect both those fixes to be in a future release. Alan DeKok. FreeRADIUS Project Leader -- Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Hi,
* Added preliminary code to support Firebird. (closes: #378) Use at your own risk!
unfortunately this new support breaks the building of the FreeRADIUS during the ./confugure stage if you dont have the required development libraries/headers present. currently the only work-around is the usual, 'blow it away' method which isnt too clean or friendly eg rm -rf src/modules/rlm_sql/drivers/rlm_sql_firebird other SQL modules fail elegantly when their dev parts are not present eg checking for oci.h... no configure: WARNING: oracle headers not found. Use --with-oracle-home-dir=<path>. configure: WARNING: sql submodule 'oracle' disabled configure: creating ./config.status config.status: creating Makefile alan
A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
* Added preliminary code to support Firebird. (closes: #378) Use at your own risk!
unfortunately this new support breaks the building of the FreeRADIUS during the ./confugure stage if you dont have the required development libraries/headers present. currently the only work-around is the usual, 'blow it away' method which isnt too clean or friendly eg
Argh. I'll release 1.1.5 to fix it. Serves me right for releasing something without a local desktop to do testing. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Santiago Balaguer García wrote:
But, this version does not still support that the existed realms in 'proxy.conf' file was in a DB.
It is useful for me, because I have a lot of roaming partners.
As always, patches are welcome. If you can't write a patch, there are a number of people and/or organizations who will be happy to accept contract work to create the patch. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Hello I try tu build debian package with the sources of freeradius 1.1.4 : That's work but i obtain debian package in 1.1.3 of freeradius : freeradius_1.1.3-0_i386.deb freeradius-ldap_1.1.3-0_i386.deb freeradius-mysql_1.1.3-0_i386.deb I suppose it is just an errror in the name. ph
Pierre-Henri Baraffe wrote:
I try tu build debian package with the sources of freeradius 1.1.4 : That's work but i obtain debian package in 1.1.3 of freeradius :
OK. It looks like the debian directory wasn't updated. We'll release 1.1.5 in a bit to address those issues. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Thu, Jan 01, 1970 at 12:00:00AM +0000, Alan DeKok wrote:
Version 1.1.4 has been released, with a few notable improvements.
Is there good reason for not updating rlm_perl? Version in 1.1.4 is "1.13.4.7 2006/04/27" (same as in 1.1.3 and 1.1.2), even though CVS contains version "1.45 2006/12/04" with some fixes / improvements. Are those changes considered unstable? Thanks for schedding some light on this. th.
Tomas Hoger wrote:
On Thu, Jan 01, 1970 at 12:00:00AM +0000, Alan DeKok wrote:
Version 1.1.4 has been released, with a few notable improvements.
Is there good reason for not updating rlm_perl? Version in 1.1.4 is "1.13.4.7 2006/04/27" (same as in 1.1.3 and 1.1.2), even though CVS contains version "1.45 2006/12/04" with some fixes / improvements. Are those changes considered unstable?
No, but the CVS head has a *huge* number of changes over 1.1.4. So rlm_perl is just one minor piece that hasn't been "upgraded". Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Mon 08 Jan 2007 16:19, Alan DeKok wrote:
Tomas Hoger wrote:
On Thu, Jan 01, 1970 at 12:00:00AM +0000, Alan DeKok wrote:
Version 1.1.4 has been released, with a few notable improvements.
Is there good reason for not updating rlm_perl? Version in 1.1.4 is "1.13.4.7 2006/04/27" (same as in 1.1.3 and 1.1.2), even though CVS contains version "1.45 2006/12/04" with some fixes / improvements. Are those changes considered unstable?
No, but the CVS head has a *huge* number of changes over 1.1.4. So rlm_perl is just one minor piece that hasn't been "upgraded".
Yep. rlm_sqlippool and rlm_sql_postgresql are 2 other modules which have huge changes in them.. Is it worth me spending some time tonight backporting them or should we just wait for 2.0? (sqlippool seems to be getting quite some interest of late) Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Peter Nixon wrote:
Yep. rlm_sqlippool and rlm_sql_postgresql are 2 other modules which have huge changes in them.. Is it worth me spending some time tonight backporting them or should we just wait for 2.0? (sqlippool seems to be getting quite some interest of late)
I think we should just wait for 2.0. I've been holding off on 2.0 for a number of reasons, but I think we're better off releasing it earlier rather than later. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Mon 08 Jan 2007 22:53, Alan DeKok wrote:
Peter Nixon wrote:
Yep. rlm_sqlippool and rlm_sql_postgresql are 2 other modules which have huge changes in them.. Is it worth me spending some time tonight backporting them or should we just wait for 2.0? (sqlippool seems to be getting quite some interest of late)
I think we should just wait for 2.0. I've been holding off on 2.0 for a number of reasons, but I think we're better off releasing it earlier rather than later.
I definitely agree. The blocker bugs that come to mind are the leak in radrelay (which u have provided a patch for and I have yet to find time to test properly) and the crash in threaded proxy mode (which I think you fixed recently.. again need to test..) I will test both of these things properly this week now that I have the postgresql and sqlipool issues out of the road. The other thing that comes to mind is the update to newer autotools... I am afraid someone else is going to have to take this one. Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
participants (6)
-
A.L.M.Buxey@lboro.ac.uk -
Alan DeKok -
Peter Nixon -
Pierre-Henri Baraffe -
Santiago Balaguer García -
Tomas Hoger