PAM Module Patch and Feature

[Tomas Hoger]

On 3/24/07, Frank Cusack <fcusack at 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.