We're continuing to develop the server, so I'd like to clarify the policy around releases. Version 2.2.x: Long term stable release. No new features. Minor bug fixes. The goal is long-term stability. We will maintain it 2-3 years. Version 3.0.x: Version 3 stable release Minor new features Focus on bug fixes and stability Will maintain it for 4-5 years Version 3.1: unstable new development Major new features Major re-architecture of the server core Which version should you use? That depends on what you have now, and what you need: * basic RADIUS and running 1.x: UPGRADE NOW * basic RADIUS and running version 2: should use 2.2.x * need better "unlang", error checking, SNMP triggers, RadSec: 3.0.x * experimental new work: bleeding edge 3.1. Arran and I have started announcing new features to this list, as the features are implemented. We'll keep doing that for the 3.1 branch. And probably stop doing new features in 3.0. We've had issues with 3.0 stability (sorry). A good part of that was problems with talloc. The documentation says one thing, but the code does something else. So that made life difficult for a while. The work of the last few months has made 3.0.4 very stable. The bug fixes for 3.0.5 are minor, and ensure that all of the "corner cases" are handled correctly. Now that we have a stable version of 3.0, we can start re-working the "master" branch for 3.1. We have a long list of new features, many of which require re-architecture. We don't want to break 3.0, so those features require a new version. Alan DeKok.
Hi Alan, On Sun, Nov 9, 2014 at 3:47 PM, Alan DeKok wrote:
We're continuing to develop the server, so I'd like to clarify the policy around releases.
Version 2.2.x: Long term stable release.
No new features. Minor bug fixes. The goal is long-term stability. We will maintain it 2-3 years.
Is there a 'known limitation' page which reflects behavior changes between version 2.x and 3.x? I am asking as I spent many hours last weened to figure out why a given case was failing with v3.x while it succeeded with v2.x (latest git). The case was with a proprietary NAS device authenticating via MSCHAP-2 protocol when the password contains a UTF-8 multi-byte character such as €, £, я, א, etc (locally with MYSQL back end - not via ntlm_auth). After lots of debugs (including dumping nt-hashes from windows server and testing with MS radius) it appears that v3.x was actually correct (the NT-hash matched what I was expecting). The reason the NAS worked only with v2.x was because it was doing the conversion as if the password was plain ASCII similar to the way it is done in FR v2.x: https://github.com/FreeRADIUS/freeradius-server/blob/v2.x.x/src/modules/rlm_... Compare to FR v3: https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/src/modules/rlm_... I tried to look up information on this difference in behavior but with no luck so maybe it could be nice to state such changes in behavior somewhere (even correct changes which aren't ported back). Apologize if this comment isn't appropriate. Thank you, Isaac B.
Isaac Boukris wrote:
Is there a 'known limitation' page which reflects behavior changes between version 2.x and 3.x?
Mostly in the ChangeLog.
I am asking as I spent many hours last weened to figure out why a given case was failing with v3.x while it succeeded with v2.x (latest git).
The case was with a proprietary NAS device authenticating via MSCHAP-2 protocol when the password contains a UTF-8 multi-byte character such as €, £, я, א, etc (locally with MYSQL back end - not via ntlm_auth).
Which is a good area for problems.
After lots of debugs (including dumping nt-hashes from windows server and testing with MS radius) it appears that v3.x was actually correct (the NT-hash matched what I was expecting).
Yes.
The reason the NAS worked only with v2.x was because it was doing the conversion as if the password was plain ASCII similar to the way it is done in FR v2.x: https://github.com/FreeRADIUS/freeradius-server/blob/v2.x.x/src/modules/rlm_... Compare to FR v3: https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/src/modules/rlm_...
Yes. The old code was wrong.
I tried to look up information on this difference in behavior but with no luck so maybe it could be nice to state such changes in behavior somewhere (even correct changes which aren't ported back).
Feel free to update the Wiki with a summary of the ChangeLong.
Apologize if this comment isn't appropriate.
Noting bugs is fine. But a community project depends on the *community* for work, too. The Wiki is there for a reason. I wish more people would update it. Alan DeKok.
Hi Alan, On Tue, Nov 11, 2014 at 11:32 PM, Alan DeKok wrote:
Isaac Boukris wrote:
Is there a 'known limitation' page which reflects behavior changes between version 2.x and 3.x?
Mostly in the ChangeLog.
Noted - thanks!
I tried to look up information on this difference in behavior but with no luck so maybe it could be nice to state such changes in behavior somewhere (even correct changes which aren't ported back).
Feel free to update the Wiki with a summary of the ChangeLong.
Currently I'm not sure to be well qualified as my understanding in FR is quite limited to specific areas (and I don't know much in GIT). I couldn't find this change in the ChangeLog although I think I found the commit: https://github.com/FreeRADIUS/freeradius-server/commit/cdd3c5dc7bbb2c8b5a230... I'd speculate there might be other NAS with the same issue so it could be a good idea to mention it in the ChangeLog. Specifically the assumption that the source password is UTF-8 which could not always be the case. Thanks once more, Isaac B.
participants (2)
-
Alan DeKok -
Isaac Boukris