contributions to client
Alan DeKok
aland at deployingradius.com
Wed Apr 21 17:55:24 CEST 2010
Lewis Adam-VNQM87 wrote:
> while I cannot offer any advice, I am in a similar situation in that I
> am trying to get the client code to work and am fixing problems (e.g.
> missing Message-authenticator and support for CHAP) as I find them.
That would be much appreciated.
> Maybe those in charge can offer some guidelines about the direction the
> client code is going in.
Minor fixes, as contributed by the community.
> As I see it, freeRADIUS has 2 different and unrelated solutions for
> providing client functionality.
> 1. freeradius-client
> 2. radclient which is provided as part of freeradius-server
Hmm... radclient is little more than a wrapper around
libfreeradius-radius. *That* library provides all of the functionality
of the server && radclient for sending && receiving packets.
> As freeradius-client seems to offer a more complete client
> implementation, I have found myself using it as a base and then grafting
> on fixes from (what looks like) the more recent radclient.
I'm not sure what that means. The libfreeradius-radius code inside of
freeradius-server is *much* more capable than freeradius-client. It
handles multiple packets from one source port, multiple source ports,
VSAs, etc.
> There are many differences between the underlying mechanisms and
> structures used by the 2 code bases which makes porting that much more
> time-consuming.
The two code bases are *completely* independent. I'm not sure they
could be integrated without massively changing either API.
> So, is there a plan for freeradius-client or at least a preferred
> direction? Is there an aim to make the code bases more consistent?
> Radclient definitely seems to have some useful ideas that could be
> re-used.
My preference would be to add minor features to freeradius-client.
Moving to "git" would make this MUCH easier, as patches could be quickly
sent back & forth.
I think maintaining a BSD licensed client is beneficial. It's already
used in a number of projects, so changing it now would be bad.
Alan DeKok.
More information about the Freeradius-Devel
mailing list