Kostas Zorbadelos wrote:
By 'debugging mode' I guess you are referring to radiusd -xxx or
something is that correct? Could this affect the authentication
service for our customers?
Use radiusd -X, and no, it won't affect service.
I was thinking
something in the lines of changing the
Kostas Zorbadelos wrote:
we are talking about a setup that services tens of thousands of
requests (hundreds per second maybe). If I am not mistaking radiusd -X
will run freeradius in
single threaded mode. In our normal mode of operation freeradius has
65 threads servicing requests. Won't
On Fri, Feb 23, 2007 at 10:23:50AM -0500, Dennis Skinner wrote:
Kostas Zorbadelos wrote:
radiusd -X confirms that the configuration is correct, however I have
this problem behaviour in large scale. My initial suspitions go to the
proxying code to be honest, but I need to take a good look to
My greetings to the list.
We have deployed a large setup using freeradius 1.1.3 in a proxy
configuration in front of FUNK radius. During the day we have about
150.000 concurrent DSL users online. Our setup takes the
access-request from the NAS, checks whether the user has any other
active
Hi,
active sessions and if he is allowed to have a session the request is
proxied to the FUNK server that performs the actual authentication. So
the setup is a classical proxy setup. This policy decision of whether
whoah. steady on there. this is not a
On Fri, Feb 23, 2007 at 02:49:57PM +, [EMAIL PROTECTED] wrote:
Hi,
active sessions and if he is allowed to have a session the request is
proxied to the FUNK server that performs the actual authentication. So
the setup is a classical proxy setup. This policy decision of whether
Kostas Zorbadelos wrote:
radiusd -X confirms that the configuration is correct, however I have
this problem behaviour in large scale. My initial suspitions go to the
proxying code to be honest, but I need to take a good look to grasp
it.
I would try running the production radius in
7 matches
Mail list logo
