Ivan Kalik wrote:
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???
Trying for the third time: 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). 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. 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.
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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
