<div class="gmail_quote"><div>Hi again,</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"></div>
Woah. That's an *enormous* timeout.<br>
<br>
With a thread pool of 32 threads, one authentication every 4 seconds will eventually eat all your threads.<div class="im"><br></div></blockquote><div>Well, we'd change the thread pool size according to our requirements.</div>
<div>But, it isn't a nice solution, I know that.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And in our proof of concept we're using a shell script with rlm_exec.<br>
<br>
If there's another way to achieve this. e.g. by letting freeradius<br>
invoke the shell script like every 10s and check if the request is still<br>
pending or already accepted or denied, that would also be an acceptable<br>
solution.<br>
</blockquote>
<br></div>
I think you're going about this entirely the wrong way, personally.<br>
<br>
I can think of a couple of alternatives.<br>
<br>
 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.<br>
</blockquote><div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
 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.<br>

<br></blockquote><div><br></div><div>We don't have control over which NAS are used. It should work with different NAS implementations.</div><div> </div><div>How about 3. (Similar to 2 but without Access-Challenge)</div>
<div>Instead of blocking we return immediatly, insert the request into an SQL table but don't respond to the NAS.</div><div>The NAS is configured to retry every n seconds.</div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
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!<br><br></blockquote><div>We use for example a VPN gateway which uses Radius, but it should also work with different NAS.</div>
<div><br></div><div>Philipp</div><div> </div></div>