rihad wrote: > Trying for the third time: Do you have any intention of reading the messages here?
> there are many, many requests of the > "Discarding conflicting packet" kind, which for one reason or another > are dupped by our Cisco NASes in under one second (see the code). And > there are many, many lines of the "Received conflicting packet" fame > (see the code). If (as you say) the NAS is sending a conflicting packet within 1 second of the first one, then the NAS is broken. It SHOULD wait 5 seconds for the old request to time out, before sending a new one that re-uses the same IP/port/Id. Take your NAS, and throw it in the garbage. Buy a real NAS that implements RADIUS. > Now, it can be logically deduced that a big part of the > latter are indeed of the former type (because none of the NASes have > timeouts as low as 2-5 seconds). What I'd really love is for freeradius > to stop killing the current request after receiving a dup 2-5 seconds > apart. That won't solve anything. This has been explained to you. Did you understand the explanation, or are you simply ignoring it? > It's no problem for me to patch and rebuild freeradius myself, I > just thought it wouldn't be fair not to share that idea with others. Thanks. And we shared our opinions... and you told us we were wrong. >> 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? >> > > The rlm_perl authorization/accounting is dealing with traffic shaping, > so I'd rather fix this freeradius' shortcoming. That response completely ignores the question. Did you understand it? Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
