On Mon, May 13, 2002 at 11:34:09AM -0400, Alan DeKok wrote: > Steve Langasek <[EMAIL PROTECTED]> wrote: > > Well, the irony is that our current monitoring system uses radclient > > from freeradius CVS to create the radius packets. It /looks/ like > > radclient is doing everything correctly to grab a random auth vector; > > nevertheless, at 3am the server is finding collisions with cached > > requests.
> Hmm... you might try changing the code to do:
> ...
> */
> if (req->data) {
> librad_md5_calc(req->data, req->daya,
> req->data_len);
> free(req->data);
> req->data = NULL;
> }
> Which makes the new request vector depend on a whole lot of things
> which change from packet to packet.
We have managed to eliminate the false alarms here; I'll share our
solution in case it suggests to you what the actual bug might have been.
When we migrated to freeradius 0.5, we also merged in many of the new
default radius.conf settings. A new block was added that contains:
security {
...
reject_delay = 1
}
telling the server to insert a one second delay before responding to
auth failures. It happens that, to avoid creating a real account with a
plaintext password stored on our monitoring server, we monitor by
looking for reject packets in response to bogus auth attempts.
Changing the above block to read 'reject_delay = 0' cleared up the
problem, and the monitoring server is now seeing valid replies at all
hours of the day.
At some point, I may set up another radius server to test against, to
see if the above code change has any effect. No time for that this
week, though...
Steve Langasek
postmodern programmer
msg05593/pgp00000.pgp
Description: PGP signature
