Configurable timeout in rlm_exec

Philipp Hug philipp at hug.cx
Tue Sep 25 14:08:47 CEST 2012


Hi again,


> Woah. That's an *enormous* timeout.
>
> With a thread pool of 32 threads, one authentication every 4 seconds will
> eventually eat all your threads.
>
> Well, we'd change the thread pool size according to our requirements.
But, it isn't a nice solution, I know that.



>
>  And in our proof of concept we're using a shell script with rlm_exec.
>>
>> If there's another way to achieve this. e.g. by letting freeradius
>> invoke the shell script like every 10s and check if the request is still
>> pending or already accepted or denied, that would also be an acceptable
>> solution.
>>
>
> I think you're going about this entirely the wrong way, personally.
>
> I can think of a couple of alternatives.
>
>  1. Just authenticate the user straight away - don't wait - but put them
> into a network with no access. Once the manual authorization is complete,
> send a CoA request to move the existing session into the "working" network.
> This should work on any NAS with CoA support, and is the "proper" RADIUS
> way to do it.
>

This could work in some cases, where the NAS supports Change-of-auth but
it's not really intuitive to the user as he'll not be notified when he's
moved to the "working" network.



>
>  2. More complex and error-prone - insert the authorization request into a
> SQL table and send an Access-Challenge with some attributes including
> State, and a "retry" delay. Have your NAS / the client "continue" at
> intervals of $retry, and keep sending Access-Challenge until the SQL row
> reads "accepted" or "rejected". This will only work if you have control of
> the NAS, and you'll have to implement the challenge sending/logic
> yourselves. Not a very clean solution.
>
>
We don't have control over which NAS are used. It should work with
different NAS implementations.

How about 3. (Similar to 2 but without Access-Challenge)
Instead of blocking we return immediatly, insert the request into an SQL
table but don't respond to the NAS.
The NAS is configured to retry every n seconds.
When the NAS retries we check if there's already a request and if yes, we
check if it already succeeded and we send a response back and if not we'll
ignore it again.


> What network protocol / NAS are you using here? I'd use CoA to solve this,
> if at all possible. 2 minute blocking timeouts on external "exec" are just
> crazy!
>
> We use for example a VPN gateway which uses Radius, but it should also
work with different NAS.

Philipp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20120925/91b61c5d/attachment.html>


More information about the Freeradius-Devel mailing list