wiechman.lists at gmail.com
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
> 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
> it yet. When "reject_delay" is being applied, there is *no* log
> by default. See src/main/event.c, look for "discarding duplicate
> 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