>>> Our radius-server timeout is high enough: 4 minutes. Once again: I >>> suppose that what freeradius thinks of as "Received conflicting packet >>> ..." are rather a bit delayed packets normally treated as "Discarding >>> conflicting packet ...", i.e. they arrive at freeradius in maybe 1.01+ >>> second after the first request, but freeradius drops the current >>> request >>> instead of the new one. Soon I'm gonna rebuild freeradius with changed >>> tv_sec and check that. >> >> huh? do you not understand the basic context of this issue? if the NAS >> has sent a repeat RADIUS packet then it means that the original packet >> has already been timed out and the NAS should NOT accept an 'accept' >> response >> on that original packet. > Please see the comment from the code snippet in src/main/event.c in my > original posting. Some duplicate packets might arrive after 1 sec. by a > slight margin, even though they logically are whatever that > special-cased conditional was designed to handle.
1 second? Freeradius keeps track of duplicates for 5 minutes by default. That is if processing has been completed. But in your case requests are still being processed 4 minutes after NAS sent them (if that is your retry interval on the NAS as you claim - default is usually 2 minutes). That is why it gave up on them and sent a new request. How do you think that adjusting that 1 second interval is going to help *your* case??? Stop hacking the server and start looking at your perl code. Do you really need to use it for authentication? Can you get all the data in authorize script and let freeradius default modules do the authentication (that can speed things up quite a bit)? Can you get (some of) the data using freeradius sql/ldap/whatever modules instead? Ivan Kalik Kalik Informatika ISP - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
