Alan DeKok wrote:
but aborting the current packet instead of
the new duplicate one can hardly be justified.
Nonsense. The duplicate one is an indication that the *NAS* has given
up on the first packet. Spending more time processing the "current"
packet is useless, because the NAS will ignore the Access-Accept for the
old packet.
Absurd. The Dell PowerEdge 2950 w/ 2 quad-cores cannot itself without
human intervention survive the "NAS attack" exactly due to having to
give up on hundreds of requests per second not replied to in under 1
second, evidenced by an almost equal presence of many "Discarding
conflicting packet" and "Received conflicting packet" lines in the log.
That is, not many (if any) of our "Receved ..." lines are due to what
could be considered a NAS timeout, and they should be treated like
"Discarding ...", that is, the new request should be dropped.
"Fixing" FreeRADIUS to spend more time processing useless requests
will only make the problem worse.
Please look at the line marked with ^^^ - it's where the error is logged
and the current request is aborted, unless it was caught earlier by
"Discarding conflicting packet", in which case the _new_ duplicate
request is aborted, which is more correct.
No. You do not understand how RADIUS works. The code will NOT be
changed to discard the new packet.
Perhaps someone more knowledgeable than you will be more able to assess
all points involved.
I propose that when.tv_sec be configurable in radiusd.conf, and not
hardcoded like that.
No. There is no reason to "fix" the server.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
