When an access-reject is being delayed due to the configuration of reject_delay, is the server core in any way aware of that? 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?
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.
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.
On 2010-07-13, at 9:02 AM, Ben Wiechman wrote:
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?
The solution to this is to implement it at the NAS level so that it doesn't hammer out your radius servers. I know Juniper supports it and we have it implemented. I just can't seem to find the documentation for it at the moment though...
participants (3)
-
Alan DeKok -
Ben Wiechman -
Gabriel Blanchard