Ben Wiechman wiechman.lists at
Tue Jul 13 16:31:57 CEST 2010

>   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.

That would be best, I agree.

>   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

I haven't entirely ruled out database issues. However the authentication
database is hosted locally and small enough so that it should remain
entirely in memory unless the record is on a dirty page or something. No

Reject_delay was configured at 1s, and I typically only saw this for auth
requests for non-existent clients on public wifi APs. Since configuring
reject_delay to 0 I have not seen a log entry, but that could be
happenstance as well. Given your statement about no logging I'm going to
dive back to the database. Not a major issue, more an annoyance and a check
for me to see if I need take a deeper look at the database.


More information about the Freeradius-Devel mailing list