We' just added EAP-AKA to the v4.0.x branch. This method is similar to EAP-SIM, and is mainly used in the telco industry, especially in WiFi hand-off. This work was sponsored by a telco who wishes to remain anonymous. We have another popular EAP method coming soon, too. The new EAP methods will not be available in version 2.x or version 3.0, as those are stable versions which have no new features. They will be available in the v4.0.x branch, which has other new features which the methods need. Alan DeKok.
Am 06.07.2016 um 14:59 schrieb Alan DeKok:
We' just added EAP-AKA to the v4.0.x branch. This method is similar to EAP-SIM, and is mainly used in the telco industry, especially in WiFi hand-off.
This work was sponsored by a telco who wishes to remain anonymous. Thanks to those who made that happen and the anonymous telco who sponsored it.
We have another popular EAP method coming soon, too. Cool, looking forward to that addition.
The new EAP methods will not be available in version 2.x or version 3.0, as those are stable versions which have no new features. They will be available in the v4.0.x branch, which has other new features which the methods need. Understandable, especially 2.x and 3.0, how about 3.1.x/3.2?
Is there a timeline where 3.2 is going to be tagged so that distributions and porters may start porting it for packaging? Though I'm pretty happy with the current state of v3.0.x builds by my needs but 3.0.12 hasn't yet been tagged. -- Mathieu
Used 3.1.x? If not then please do so. This will ensure that there are fewer unknown issues and this 3.2 can get out the door alan
Alan Buxey wrote:
Used 3.1.x? If not then please do so. This will ensure that there are fewer unknown issues and this 3.2 can get out the door
Hmm, I'm not sure whether that's a successful approach to really get people into testing. I'm currently updating openSUSE packages for each new FreeRADIUS release. Pulling a git version means more packaging work-arounds regarding correct package versions. Otherwise there will be a lot of trouble with package updates. So my strong personal preference would be that you follow the release-early-release-often paradigm. And I'm trying to keep up with releases. Just my 2 cents. Ciao, Michael.
On Jul 7, 2016, at 1:16 AM, Mathieu Simon (Lists) <matsimon.lists@simweb.ch> wrote:
Understandable, especially 2.x and 3.0, how about 3.1.x/3.2?
Honestly.. Arran and I have been discussing holding off on that. The issue is that we still have many, many, people running v2. And many people running v3 are using versions released 2-3 years ago. The main OS vendors upgrade "essential" packages quickly. Where "essential" means desktop games get updated much more regularly than FreeRADIUS. I'd like to have updated packages on packages.networkradius.com. But... even with automation, it's difficult to keep up to date with every single variant of every single OS out there.
Is there a timeline where 3.2 is going to be tagged so that distributions and porters may start porting it for packaging?
We don't have a fixed timeline. We're working on 4.0 now. If that makes good progress in the next few months, we might just release 4.0 in October, and skip 3.2 entirely. The reason is that it's just too confusing to have many versions available. Since OS vendors ship an old version of the server for ~5 years, there is a STRONG incentive to release new major versions only once every 3-5 years. Any more quickly than that, and we're stuck with people using version 2, 3.0, 3.2, and maybe 4.0 / 4.2. It's just too much. Instead, if we can get 4.0 in shape by October, we'll just release that. The main difference between 3 and 4 is that 4 will be much more asynchronous. In our preliminary tests, we can reduce the number of threads, and increase the performance of the server. A side benefit is that the internals of the server become *much* simpler. Which means it's easier for a small group of people to maintain / extend it.
Though I'm pretty happy with the current state of v3.0.x builds by my needs but 3.0.12 hasn't yet been tagged.
I've got to do that real soon now... There were a few issues reported that I want fixed before 3.0.12. And then I don't want to touch 3.0 any more. Alan DeKok.
Hi Alan (no thread-hijacking was intended, sorry about that) Am 07.07.2016 um 14:59 schrieb Alan DeKok: [...]
We're working on 4.0 now. If that makes good progress in the next few months, we might just release 4.0 in October, and skip 3.2 entirely.
Aha, ok so I might as well try keeping an eye on the 4.0.x branch :-)
The reason is that it's just too confusing to have many versions available. Since OS vendors ship an old version of the server for ~5 years, there is a STRONG incentive to release new major versions only once
every 3-5 years. Any more quickly than that, and we're stuck with people using version 2, 3.0, 3.2, and maybe 4.0 / 4.2. It's just too much. In case of those stable/enterprise distribution. Obviously they won't take care about FR release dates and simply pick what they got at a point and stick with it for 5-10y of their support timelines.
Instead, if we can get 4.0 in shape by October, we'll just release that. That would be great.
The main difference between 3 and 4 is that 4 will be much more asynchronous. In our preliminary tests, we can reduce the number of threads, and increase the performance of the server. A side benefit is that the internals of the server become *much* simpler. Definitely welcomes changes. I think what many admins shy away from is larger changes in configuration structure. (even it it's meaningful improvements ...)
If 4.x doesn't include too many changes transitions will be more smooth. Which means it's easier for a small group of people to maintain / extend it.
Though I'm pretty happy with the current state of v3.0.x builds by my needs but 3.0.12 hasn't yet been tagged.
I've got to do that real soon now... There were a few issues reported that I want fixed before 3.0.12.
OK, again for what I use it for, it seems pretty robust so props on that.
And then I don't want to touch 3.0 any more.
Whenever that final point arrives make it crystal clear. :-) -- Mathieu
On Jul 8, 2016, at 7:18 AM, Mathieu Simon (Lists) <matsimon.lists@simweb.ch> wrote:
In case of those stable/enterprise distribution. Obviously they won't take care about FR release dates and simply pick what they got at a point and stick with it for 5-10y of their support timelines.
Which means that we need to be careful about stable releases.
Definitely welcomes changes. I think what many admins shy away from is larger changes in configuration structure. (even it it's meaningful improvements ...)
I think we can make 4.0 mostly compatible with 3.x. The biggest change is to go to a simplified section naming: recv Access-Request { ... authorize stuff ... } send Access-Accept { ... post-auth stuff ... } This change means that the core of the server becomes *much* simpler. And yes, it breaks ~20 years of configuration. Sorry about that. :( But we should be able to come up with compatibility solutions, so people don't have to change too much.
If 4.x doesn't include too many changes transitions will be more smooth.
It looks to be pretty much like 3.x, except for the change noted above. There are many other changes under the hood, which don't show up as config changes.
Which means it's easier for a small group of people to maintain / extend it.
That's the goal.
I've got to do that real soon now... There were a few issues reported that I want fixed before 3.0.12. OK, again for what I use it for, it seems pretty robust so props on that.
Thanks.
And then I don't want to touch 3.0 any more. Whenever that final point arrives make it crystal clear. :-)
We've tried to make it clear for version 2. There are still tons of people using it. Alan DeKok.
Hi,
We' just added EAP-AKA to the v4.0.x branch. This method is similar to EAP-SIM, and is mainly used in the telco industry, especially in WiFi hand-off.
That should be AKA' not just AKA, right? Is AKA without the prime still in use? Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
On Jul 7, 2016, at 1:39 AM, Stefan Winter <stefan.winter@restena.lu> wrote:
That should be AKA' not just AKA, right? Is AKA without the prime still in use?
AKA is still in use. AKA' is a minor variation, so once people check that AKA works for them, AKA' is essentially cut / paste, and minor edits. Alan DeKok.
participants (5)
-
Alan Buxey -
Alan DeKok -
Mathieu Simon (Lists) -
Michael Ströder -
Stefan Winter