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
Hmmm...
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 proxying. 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. Thanks.