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