Alan DeKok wrote:
Philip Molter wrote:
Attached is a patch that fixes the issue. Given the way that freeradius
checks for the ability to write to the logfile, it should perform like
the latter (in my testing, it does exactly that).
The patch does a couple of things:
1) properly handles
Alan DeKok wrote:
c) response_window being hit now does nothing other than start
the zombie period. The first request that causes this is NOT
rejected. The old behavior can still be configured if desired.
How does this change affect accounting handling? Does the request now
fail over
John Dennis wrote:
There are various strategies to assure the newly created log file has
the right ownership:
* drop privileges prior to calling fopen()
* call chown() after fclose() at the exit of the logging call.
* pre-create the file if necessary very early during start up.
I think the lat
John Dennis wrote:
FWIW, in our RPM's we force the creation of the radius.log file with
ownership radiusd:radiusd at installation time before the server even runs.
If you don't force the creation of the file with the right ownership
then I think the issue revolves around when a log message is
On Jul 16, 2009, at 4:03 AM, a.l.m.bu...@lboro.ac.uk wrote:
Hi,
Is this a known bug? Is there a workaround other than creating the
file
by hand and setting its ownership before starting freeradius?
?? how are you starting this server - the file/directory should be
radiusd:radiusd
and
With freeradius 2.1.6, I have a configuration such as this in my
radiusd.conf file:
user = radiusd
group = radiusd
When I start up radiusd for the first time, the radius.log file gets
created with 0640 permissions, owned by root:radiusd, instead of
radiusd:radiusd. This doesn't prevent the R
On Jul 12, 2009, at 1:58 AM, Alan DeKok wrote:
Philip Molter wrote:
b) makes the post_proxy_fail_handler optional on a pool-by-pool basis
If the early "reject" is wrong, it might be best to just delete it.
Sites with a small number of home servers will sti
On Jul 11, 2009, at 3:55 PM, Ivan Kalik wrote:
I think that you are going about it the wrong way. You wont proxy to
pretend that home server has not gone down. How about this - instead
of a
group of stand-alone load-balanced home servers create a (true) high
availability cluster. If your home s
On Jul 11, 2009, at 2:23 PM, Alan DeKok wrote:
Philip Molter wrote:
I did try that. It did not do what I was attempting to do.
Hmm... "it didn't work".
I apologize I was not more specific. The retransmits kept getting
sent to the same failed home server rather than
On Jul 11, 2009, at 12:14 PM, Ivan Kalik wrote:
I'm not using RADIUS as a backend for ISP gear. I am using a RADIUS
proxy to serve requests for service software, and when false failures
come back, customers get error boxes in their software and contact
our
support angry that our authenticat
On Jul 11, 2009, at 10:15 AM, Alan DeKok wrote:
I think there's a fundamental disconnect here. I'm trying to explain
that RADIUS is an imperfect protocol. You're trying to find ways of
configuring FreeRADIUS to be work around those imperfections.
My suggestions are:
1) realize that RADIUS
On Jul 10, 2009, at 5:23 PM, Ivan Kalik wrote:
Yes, this is the configuration I'm currently running, and it's not
working for me. I have a radclient sending a request, retrying 10
times
on a 5-second timer, and after 10 retries, it still hasn't gotten a
response. After the second retry, th
On Jul 11, 2009, at 2:14 AM, Alan DeKok wrote:
Philip Molter wrote:
Yes, this is the configuration I'm currently running, and it's not
working for me. I have a radclient sending a request, retrying 10
times
on a 5-second timer, and after 10 retries, it still hasn't go
Alan DeKok wrote:
Philip Molter wrote:
Thanks for your patience with this. I'm migrating from an old RADIUS
platform that supports this behavior to freeradius, and I'm just trying
to make sure I get everything working.
What behavior? Failover from one home server to another?
Alan and Ivan,
Thanks for your patience with this. I'm migrating from an old RADIUS
platform that supports this behavior to freeradius, and I'm just trying
to make sure I get everything working.
Ivan Kalik wrote:
rad_recv: Access-Request packet from host 127.0.0.1 port 39091, id=56,
length=
Ivan Kalik wrote:
Yeah,that's what I'm doing. The problem is that the retries are not
being sent to a different home server (or any home server). They are
being dropped as retransmits because internally, freeradius is
tracking that no reply was sent to them earlier. I have tried
treaking clean
On Jul 10, 2009, at 4:05 AM, Ivan Kalik wrote:
I'm trying to setup a robust RADIUS authentication proxy. All this
radius will do is proxy all auth requests to a set of four backend
RADIUS handlers. I have a 2.1.6 server that I've configured with
four
home_server entries and one home_server_
Hi,
I'm trying to setup a robust RADIUS authentication proxy. All this
radius will do is proxy all auth requests to a set of four backend
RADIUS handlers. I have a 2.1.6 server that I've configured with four
home_server entries and one home_server_pool that load-balances across
the four
18 matches
Mail list logo
