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 following message: 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 How reproducible: 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 remote.radius.server Actual results: radiusd die Additional info: 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.