Red Hat Bugzilla – Bug 191724
radiusd die when remote server is unreachable and compiled with -fPIC
Last modified: 2008-03-12 01:51:17 EDT
Description of problem:
We use IPSec to secure communication between our RADIUS servers. In case of
problems with IPSec connection - e.g. racoon on remote server die, connection
can't be established and ping shows something like
sh-3.1$ ping remote.radius.server.com
connect: Resource temporarily unavailable
then radiusd became unstable. If in this situation tryes to contact
remote.radius.server.com (e.g. forward proxyed requests), than it dies with
Error: Assertion failed in request_list.c, line 1079
Version-Release number of selected component (if applicable):
I try FreeRadius 1.0.1 (on RHEL4), 1.0.5 (on FC5) with same results
Steps to Reproduce:
1. setup IPSec from local.radius.server to remote.radius.server
2. on local.radius.server start IPSec (ifup ipsec1), don't start/setup IPSec on
remote.radius.server, because we need to simulate problems with IPSec connection
3. start radius server on local.radius.server (configured to proxy "unknown"
realms to remote.radius.server)
4. make request to local.radius.server, that has to be proxyed to
When I recompiled FreeRadius without freeradius-1.0.0-pie.patch and without
export CFLAGS="$RPM_OPT_FLAGS -fpic", then it doesn't die in described situation.
After further investigation it seems that this problem is not directly related
to the compilation options. It has same behavior when I compile FreeRadius
without -fpic option (may be it take longer time before radius server die)
Please verify this with a package from FC-6 or newer. In the FC-6 and FC-7
testing trees, there are new packages: freeradius-1.1.7-2
transferred from Thomas Woerner to John Dennis, requested by Steve Grubb.
The information we've requested above is required in order
to review this problem report further and diagnose/fix the
issue if it is still present. Since there have not been any
updates to the report since thirty (30) days or more since we
requested additional information, we're assuming the problem
is either no longer present in the current Fedora release, or
that there is no longer any interest in tracking the problem.
Setting status to "INSUFFICIENT_DATA". If you still
experience this problem after updating to our latest Fedora
release and can provide the information previously requested,
please feel free to reopen the bug report.
Thank you in advance.