On Oct 25, 2018, at 6:10 AM, CALMELS, Thierry (SOGETI REGIONS SAS) <thierry.calmels.external@airbus.com> wrote:
We have currently a new infrastucture using freeRadius 3 (freeradius-3.0.13-8.) on RHEL7.5.
Upgrade to 3.0.17. Or, to the v3.0.x branch on GitHub, which will be 3.0.18 real soon now.
The infrastructure implements in front a layer “PROXY RADIUS” (not based on proxy.conf usage) allowing to forward requests either to a service RADIUS A or a service RADIUS B depending on the type of OTP.
You implemented your own proxy logic? That's not recommended...
Service A handles/valids OTP A Service B handles/valids OTP B
The infrastructure works as expected.
However when a service disruption occurs on service B, the PROXY RADIUS is no longer able to forward the requests to service A.
The PROXY is in a state stuck with the below error messages.
Thu Oct 25 08:14:11 2018 : Error: Unresponsive child for request 5735, in component authenticate module perl Thu Oct 25 08:14:13 2018 : WARNING: (5735) WARNING: Module rlm_perl became unblocked :::::: Thu Oct 25 09:41:25 2018 : Error: Unresponsive child for request 5791, in component authenticate module perl Thu Oct 25 09:41:53 2018 : WARNING: (5783) WARNING: Module rlm_perl became unblocked
How can we manage this kind of errors?
Stop doing blocking IO in your Perl script.
Is there some parameters to release connections.
That would be up to your Perl script. FreeRADIUS has no idea what that script does, and cannot get the script to release connections.
I'm assuming the error indicates some sort of timeout in communication between rlm_perl and service B. Assuming this is a timeout-related error, what is an acceptable processing time?
See RFC 5080. RADIUS packets should be retransmitted for up to 30 seconds. It's not clear why you're using custom proxy logic. As you see, it can cause severe errors. Why not just use the normal proxying built into the server? It can do everything you need, and it won't have these kind of problems. Alan DeKok.