freeradius-client "radius_timeout" and freeradius-client vs freeradius-server
Hello list, during development of a radius test client using freeradius-client library I stumbled across line 317 in sendserver.c from CVS HEAD: result = poll(&pfd, 1, timeout * 1000000); This line came with revision 1.26 where select() was rewritten with poll(). The timeout value for poll however is in milliseconds not in microseconds so that timeout will be 1000 times higher than configured in the radiusclient.conf. As the bug seems to be in the code since November 2008 I wonder if freeradius-client is the right way to go for a radius client or if one should use the freeradius-server libraries to build a client? Or is the right way to go the 1.1.6 release downloadable on the homepage - unfortunately this release does not have the patches from Alex Massover regarding seqfile and thread safety. Rgds, Stefan
Stefan Karss wrote:
This line came with revision 1.26 where select() was rewritten with poll(). The timeout value for poll however is in milliseconds not in microseconds so that timeout will be 1000 times higher than configured in the radiusclient.conf.
That needs fixing.
As the bug seems to be in the code since November 2008 I wonder if freeradius-client is the right way to go for a radius client or if one should use the freeradius-server libraries to build a client? Or is the right way to go the 1.1.6 release downloadable on the homepage - unfortunately this release does not have the patches from Alex Massover regarding seqfile and thread safety.
The CVS source has the fixes. We'll apply a few more, and release a 1.1.7 soon. Alan DeKok.
Alan, so you say the way to go is stick with the radius-client library instead of "abusing" the radius-server code? Rgds, Stefan On Tue, Mar 23, 2010 at 4:17 PM, Alan DeKok <aland@deployingradius.com>wrote:
Stefan Karss wrote:
This line came with revision 1.26 where select() was rewritten with poll(). The timeout value for poll however is in milliseconds not in microseconds so that timeout will be 1000 times higher than configured in the radiusclient.conf.
That needs fixing.
As the bug seems to be in the code since November 2008 I wonder if freeradius-client is the right way to go for a radius client or if one should use the freeradius-server libraries to build a client? Or is the right way to go the 1.1.6 release downloadable on the homepage - unfortunately this release does not have the patches from Alex Massover regarding seqfile and thread safety.
The CVS source has the fixes. We'll apply a few more, and release a 1.1.7 soon.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
right way to go the 1.1.6 release downloadable on the homepage - unfortunately this release does not have the patches from Alex Massover regarding seqfile and thread safety.
The CVS source has the fixes. We'll apply a few more, and release a 1.1.7 soon.
Alan DeKok.
[Alex] Hi, I'm aware of one more memory leak in thread per request scenario. It's in lib/ip_utils.c, if new thread created for every radius request, tmphostbuf is not freed. The easiest fix that I'm using currently is: -static __thread char *tmphostbuf=NULL; +static __thread char tmphostbuf[HOSTBUF_SIZE]; and getting rid of realloc(). This way tmphostbuf is automatically freed, but if gethostby*_r() returns ERANGE we have a trouble. For me HOSTBUF_SIZE=2048 always works :) As far as I understood 8192 "ought to be enough for anybody" :) because of internal implementation of gethostby*_r. The question is if such fix is good enough to be applied, if yes I'll provide a patch. If no, other option is adopting utils from misc.c from freeradius server code instead of ip_utils.c, but it will require rewriting some interfaces. This probably is the cleanest option. This mail was sent via Mail-SeCure System.
participants (3)
-
Alan DeKok -
Alex Massover -
Stefan Karss