RE: contributions to client
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
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.
participants (2)
-
Alan DeKok -
Lewis Adam-VNQM87