On 3/24/07, Frank Cusack <fcusack@fcusack.com> wrote:
The radiusd.conf 'reject_delay' option. I always set this to 0.
Here's the really weird part. If I set reject_delay to 0, it works just like I expect. But if I set it to some value like 1, which is the default, it delays for about 30 seconds.
That sounds suspicously like the cleanup delay kicking in.
Right. Try changing value of max_request_time. It should affect time, after which you'll receive reject. However, I'm not sure, if reject received is "original reject" or "new" one generated due to hitting max_request_time. Or configure your client to retry after some time. If retry interval is greater than reject_delay, freeradius will send reject immediately. I guess that's the reason this issue is not noticed very often, since network devices are usually configured to retry after few seconds. You can experiment with radclient and various values of timeout (-t).
Unless I run radiusd with -X to see what's going on in which case it works as expected with a one second delay. I'll keep digging into the cause to see if it's something in my build or what.
Run radiusd -fxx. This problem only seem to appear in multi-threaded mode. Single threaded mode seems to work correctly.
It seems like if this was a common bug it would be reported by now, but I did a quick search for reject_delay in the bug database and didn't find anything. I'll see if I can figure it out.
That would be awesome.
It's possible that the reject_delay only recently broke.
Not really ;). Try searching mailing list archive. This issue has been reported several times. Usually with little or no response. Btw: Similar issue seems to affect proxy scheduler. If you set synchronous to no (which is default), you can set retry_delay and retry_count. However, those values will only be applied if client asks often enough. If retry_delay is set to 5 (default again) and client will send first retry after e.g. 15 seconds, freeradius will also retry after 15 seconds for the first time. Client's retries received before retry_delay are dropped. Is it a bug in event scheduling in multi-threaded mode or design decision to rely on clients' retries to trigger execution of pending events? th.