Removing attribute/vendor/type from valuepairs

Alan DeKok aland at deployingradius.com
Sun Feb 17 17:19:54 CET 2013


Arran Cudbard-Bell wrote:
> Alan has also rewritten the RADIUS protocol decoder to better support
> nested attributes, which should be fully supported before 3.0 is released.

  I think that makes 4 implementations of the decoder in the past 14
years.  Oh well, I'll get it right one of these days. :)

  For the record, the new decoder was written to support the WiMAX
"continued" and Extended "long" attributes.  It also came out of the
RADIUS data type draft I wrote:

http://tools.ietf.org/html/draft-dekok-radext-datatype

  So far, the code is again smaller, and easier to understand than the
previous decoder.

> Next week work will begin on integrating talloc. talloc is a hierachical
> memory allocator which can dramatically simplify memory management for
> trees of dynamically allocated objects. This is in preparation for
> adding request chaining* and nested TLVs.
> 
> As talloc is small (3K LoC)  we plan to bundle it with the server, and
> integrate it into the new build system in a similar way to jlibtool.
> 
> As always testing is appreciated.

  We're just in the process of running Coverity over the "master"
branch.  It hasn't been done for a while, so there are a number of
issues.  So far they seem to be mainly "leak memory on rare error
condition" kind of problem.  They're minor, but we're fixing them for
sanity reasons.

> * Initially this will be for proxying between multiple virtual servers
> internally, but will make it easier to implement request trees, where a
> single incoming request spawns multiple child requests.

  The current REQUEST structure has fields explicitly for proxying.
That is arguably wrong.  Those fields should be removed, and replaced
with parent/child relationships.  In the short term, it makes code
dealing with proxied packets a little more difficult.

  In the long term, it makes the server much more flexible.  As Arran
says, it allows for proxying between virtual servers.  This will be
near-zero-cost proxying.  And will allow much more fine-grained division
of policies.

  Alan DeKok.


More information about the Freeradius-Devel mailing list