I'm not sure how the script could be blocking the server after it's already ran 
and returned the updated packet so the proxying can take place which does 
happen:

        • rlm_perl: Changing User-Name: legg...@yubiauth.mcs.example.com
        • rlm_perl: Added pair NAS-Port-Type = Virtual
        • rlm_perl: Added pair Service-Type = Authenticate-Only
        • rlm_perl: Added pair Auth-Type = System
        • rlm_perl: Added pair Calling-Station-Id = client.mcs.example.com
        • rlm_perl: Added pair User-Name = legg...@yubiauth.mcs.example.com
        • rlm_perl: Added pair User-Password = 654321
        • rlm_perl: Added pair NAS-Identifier = sshd
        • rlm_perl: Added pair Stripped-User-Name = leggett
        • rlm_perl: Added pair NAS-IP-Address = 192.168.6.203
        • rlm_perl: Added pair NAS-Port = 32448
        • rlm_perl: Added pair Ldap-UserDn = 
uid=leggett,ou=people,dc=mcs,dc=example,dc=com
        • Cached username is "legg...@yubiauth.mcs.example.com", list username 
is "legg...@yubiauth.mcs.example.com"
        • ++[get_domain] returns updated
        • [suffix] Looking up realm "yubiauth.mcs.example.com" for User-Name = 
"legg...@yubiauth.mcs.example.com"
        • [suffix] Found realm "yubiauth.mcs.example.com"
        • [suffix] Adding Stripped-User-Name = "leggett"
        • [suffix] Adding Realm = "yubiauth.mcs.example.com"
        • [suffix] Proxying request from user leggett to realm 
yubiauth.mcs.example.com
        • [suffix] Preparing to proxy authentication request to realm 
"yubiauth.mcs.example.com"
        • Cached username is "leggett", list username is 
"legg...@yubiauth.mcs.example.com"
        • ++[suffix] returns updated

The request packet then gets proxied off, comes back and this script is never 
called again. The same script gets called the same way on successful requests 
and this script is only called in the authorize phase. I've also tested that 
when one of the failure cases is reached (return RLM_MODULE_FAIL) that a fail 
packet is sent back to the client and no proxying ever takes place which is 
what I would expect.

The script is at http://pastebin.com/gB91jj8W.

On Jul 2, 2013, at 12:20 PM, Alan DeKok <al...@deployingradius.com> wrote:

> Ti Leggett wrote:
>> Tue Jul  2 10:39:04 2013 : Error: WARNING: Unresponsive child for request 0, 
>> in component <core> module <thread>
> 
>  Fix your scripts so that they don't block the server.
> 
>> The upstream server does get the request, send the reject back to the proxy 
>> and the proxy receives the reject but doesn't seem to send the reject back 
>> to the client. When the user types the password successfully everything 
>> works fine - the client gets an OK and none of the hung request errors show 
>> up.
> 
>  The default configuration doesn't have this issue.  Access-Requests
> can be proxied.  Access-Rejects can be returned through a proxy to a client.
> 
>> A debug log of one of these failed sessions is at 
>> http://pastebin.com/8n7snaBV. Any ideas what might be going on?
> 
>  The debug log shows nothing interesting.
> 
>  The most probable issue is that your scripts are blocking the server.
> Fix that.
> 
>  You can verify this by configuring a test system *without* your
> scripts.  Or a test user, which bypasses the scripts.  It will work.
> 
>  Alan DeKok.
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Reply via email to