Configurable timeout in rlm_exec

[Phil Mayers]

On 25/09/12 12:01, Philipp Hug wrote:
> Hi Phil,
>
>     That's not completely unreasonable, but be aware that the server
>     thread is entirely blocked whilst waiting for the exec to complete.
>     If all threads in the pool are blocked, you'll have serious problems.
>
>     Basically: 10 seconds is a long to wait, so waiting even longer...
>     I'm kind of curious what you're doing?
>
>
> Well, the script is waiting for user interaction to authorize the radius
> transaction. (which will take up to 2 minutes)

Woah. That's an *enormous* timeout.

With a thread pool of 32 threads, one authentication every 4 seconds 
will eventually eat all your threads.

> 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.

  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.


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!

Cheers,
Phil