4.0-alpha

After a long and complex journey, the FreeRADIUS team is happy to announce that we have released 4.0-alpha.

The online documentation has upgrade instructions.

We do not recommend that everyone upgrade to v4, because of a hopeful belief that "4 is better than 3". This release is still alpha, and it is not a final 4.0 release. Some features may or may not work. Some features are missing. We will announce a full-featured 4.0 release at some point in the future.

However, for people who need the features of v4, it may be worth understanding the limitations of v4, and then perhaps using it. We have been running earlier versions of v4 in production for many years. It has proven to be stable, useful, and in many ways significantly better than v3.

For people who do try v4, please be aware that this is an Open Source project. Our time is limited. We cannot respond to all feature requests. We do not know when the features missing from v4 will be added back in. If you want the final version of v4 to be released more quickly, then we suggest contributing code or documentation. Even bug reports and documentation updates are very useful, and are much appreciated.

Availability

4.0-alpha tarballs can be downloaded from the FreeRADIUS FTP mirror.

The source is also available on GitHub.

As usual, Network RADIUS are providing pre-built packages for common Linux distributions. See the instructions on the Network RADIUS web site.

Changes

There are too many changes from v3 to list all of them here. Instead, we will give some highlights.

We now have automatically generated documentation. There is full reference documentation for the Unlang policy language, including for all keywords. All configuration files are fully documented, and are converted to cross-referenced HTML.

The server core is now fully asynchronous. This means that the old error message of child is blocked is much less likely to happen. It also means that the server can handle more packets per second than v3, with the same hardware.

All protocols are now fully supported as top-level concepts. The server no longer just does RADIUS,and a bit of DHCPv4 which pretends to be RADIUS. It now does RADIUS, DHCPv4, DHCPv6, TACACS+, and many more. All protocols are supported natively, in the same binary, at the same time. That is, the server has had all of the hard-coded RADIUS portions removed. It is now a protocol-agnostic policy engine, with a large number of supported protocols.

Adding a new protocol is a small amount of work. For example, the entire DHCPv4 portion of the server is about 2,000 lines of code (plus option definitions). Yet in that limited code space, we support all DHCP options, and storing IP address in SQL, Redis, LDAP, or any other supported database.

Many of the attributes have been renamed. We recognize that this change will cause all policies and database entries to change, but it was necessary in order to fully support the new features. The dictionaries now support complex structures and bit fields. Where it used to be difficult (or impossible) to support complex data formats, such support is now trivial.

The configuration files now support complex expressions in conditions and attribute editing, natively. There is no longer a need to use %{expr:...} everywhere. Just use math, as in &foo = 1 + 2.

The dynamic expansion syntax has changed. The old %{foo:...} function syntax has changed to %foo(...), which is much clearer. Expansions how support math: &Reply-Message = "1 + 2 = %{1 + 2}". Alternation (%{...:-...}) has been replaced by in-place "short-circuit" logical OR / AND as with key = %{&Stripped-User-Name || &User-Name}.

The configuration files are similar to v3, but are not the same. However, any concepts will still be recognizable to users of v3. In most cases, the work to port a v3 configuration to v4 will be minimal. Some of the 25 year-old history of "backwards compatibility" has been removed, and clearer names are used everywhere. Many new features have been added which make the server easier to understand, and easier to use.

The Good News

The server now supports the following protocols natively. That is, all of these protocols can be used in the same binary, at the same time.

RADIUS	Of course.
DHCPv4	This is now fully supported as a native protocol, and is not "faked out" by pretending it is RADIUS.
DHCPv6	All DHCPv6 options are supported. The DHPv6 group nesting was a major contributor to the delay in v4.
TACACS+	Full support for TACACS+.
cron	Simplistic cron jobs can be schedule to perform time-based actions.

The Bad News

This is an "alpha" release. It may crash, and certain feature sets are limited, as noted below.

RADIUS	RADIUS/TLS (RadSec) is not supported. PEAP, TTLS, EAP-FAST, and TEAP are not supported.
DHCPv4	Relaying has limited support.
DHCPv6	Relaying has limited support.
TACACS+	There are a large number of "odd" TACACS+ implementations. We have not tested interoperability with them all.
cron	There is limited support for adding and deleting cron timers "on the fly".

Guidance for Operating System Packagers

We do not recommend that operating systems or Linux distributions create their own packages for 4.0-alpha. Our experience has been that packaging an "alpha" release will result in confused and upset users. Some people will install it due to the belief that "it's stable because it is packaged". They will then discover that it is an alpha release, and will run into issues.

Please don't create issues for your users: wait for a full and officially supported 4.0 release.

Why did it take so long?

This release is not just a major version change from v3, it is a major step forward in functionality. The simplest explanation is the following summaries, taken from sloccount:

$ cd freeradius-server-3.2.x
$ sloccount .
...
Total Physical Source Lines of Code (SLOC)                = 136,014
Development Effort Estimate, Person-Years (Person-Months) = 34.78 (417.32)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         = 2.06 (24.76)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 16.86

Whereas for v4, we have:

$ cd freeradius-server-4.0.0-alpha
$ sloccount .
...
Total Physical Source Lines of Code (SLOC)                = 358,688
Development Effort Estimate, Person-Years (Person-Months) = 96.27 (1,155.22)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         = 3.04 (36.45)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 31.69

That is, v4 is more than double the size of v3 in lines of code. It is likely that by the time we add the rest of the functionality missing from v3, then the v4 code base will be pretty much triple the size of v3.

Another major cause for the delay is that no one is working full-time on the code base. The above estimate is 3 years with 30+ developers, for about 100 engineering-years of effort. So we believe that have done well for 10 years, and 5 part-time developers, for much less than 50 engineering years of effort.

Contributors

The following list gives the main FreeRADIUS contributors and their roles. There are also many other contibutors who submitted patches, feature requests, documentation updates, etc. Those are too many people to list in detail.

Alan DeKok	Project Leader.
Arran Cudbard-Bell	v4 architect.
Matthew Newton	Release manager.
Nick Porter	Contributor, LDAP cleanups.
Terry Burton	Contributor, SQL cleanups.
Jorge Periera	Contributor