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