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.