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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
