aland at deployingradius.com
Tue Jul 13 15:41:28 CEST 2010
Ben Wiechman wrote:
> When an access-reject is being delayed due to the configuration of
> reject_delay, is the server core in any way aware of that?
Yes. The reject_delay is enforced by the server core.
> Problem: misbehaving clients that are not valid making many, many repeated
> network entry attempts in quick succession. Receiving a repeat request from
> the client appears to be causing a "discarding duplicate request" entry in
> the logs. Is there a (simple...) way to identify if a response is being
> delayed and update the discarding dups log entry accordingly?
Hmm... OK. The simplest thing to do would be to simply discard the
packet *without* logging it if it was marked as a delayed reject.
If the reject is delayed for only a second, most clients *shouldn't*
retransmit quickly. If they do, they're seriously broken. They need to
implement the RFC5080 client retransmission algorithm.
But the "discarding duplicate" request message is printed *only* when
the server is still processing the request, and hasn't decided to reject
it yet. When "reject_delay" is being applied, there is *no* log message
by default. See src/main/event.c, look for "discarding duplicate request".
It seems that the issue is one of the following:
- the server is slow
- i.e. slow DB
- or slow proxying
- the client is too fast
- retransmitting multiple times a second
More information about the Freeradius-Devel