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