rihad wrote:
Sometimes when there are too many requests from a NAS, like right after rebooting it and thus breaking current sessions, etc., freeradius 2.1.3 under FreeBSD begins loggin many many lines like this after the NAS re-sends unanswered packets:
Error: Received conflicting packet from client 10.10.70.94 port 1646 - ID: 220 due to unfinished request 511166. Giving up on old request.
The system is too slow to answer requests.
I looked in src/main/event.c and found this code: ... Our authorization/accounting happens through rlm_perl and is written in Perl. Perhaps it's not fast enough to process many many requests in under 1 second (when.tv_sec),
No, it *is* too slow to process requests. Buy a faster machine, do load balancing, or fix your Perl script to run faster.
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. "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.
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.