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