contributions to client

[Lewis Adam-VNQM87]

Hi,
 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.

Maybe those in charge can offer some guidelines about the direction the
client code is going in.

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

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.

There are many differences between the underlying mechanisms and
structures used by the 2 code bases which makes porting that much more
time-consuming.

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. 

Adam.

> Hi,
> PortaOne, Inc. uses freeradius-client in some our products. 
> We want to pass some of our changes to upstream.
> Which form is preferrable for this?
> - post a bug for each
> - post a patch for each to this list (LKML style)
> - post a description with link
> ?
> 
> Currently they are
> - add generating of Message-Authenticator (RFC3579)
> - switching from gethostbyname*() to getaddrinfo() (suitable 
> for all our
>   platforms and conforms to latter standards)
> - printing unknown attributes in response using special syntax
>   to aid in issue debugging, instead of dropping the whole response
> - generating correct error code in case of unparseable response
> - allow to differ source address and NAS-IP-Address in request
> - multiple servers in config file
> - remove endian check and macros as unused and conflicting
> - misc. fixes on compiler warnings