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