Hello freeradius support team, We have currently a new infrastucture using freeRadius 3 (freeradius-3.0.13-8.) on RHEL7.5. 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. 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? Is there some parameters 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? Thanks, Thierry - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.
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.
participants (2)
-
Alan DeKok -
CALMELS, Thierry (SOGETI REGIONS SAS)