Duplicate Acct-Status packets
Bogomolov Andrei
dum at clink.ru
Wed Apr 1 06:45:09 CEST 2009
Ivan, its interesting. Our NAS is linux pppoe-server with pppd last
version. Pppd retransmits Acct-Status in 10 seconds. Is it possible to
increase freeradius keep of tracking time, you talking about, from 5 to
15 seconds? Where is this place in configs/sources?
tnt at kalik.net wrote:
>> Unique will solve your problem but keep in mind that this will consume more
>> resources.
>>
>>
>
> That is not a very good solution. True, there will be only one insert in
> the table but if you make sql fail the insert, sql module will fail as
> will accounting, so no response will go back to the NAS. And it will
> send that accounting packet again and again and again ...
>
> Under normal circumstances one dropped response is not a problem. NAS
> tends to repeat unanswered accounting packets every 2 seconds, while
> freeradius keep the request on the list for 5 seconds. So you would need
> three consecutive dropped responses for duplicate to end up in the
> radacct table. If your network has such packet loss fiddling with
> accounting is least of your worries.
>
> But if if your NAS is retransmitting in intervals longer than 5 seconds
> you should fix that.
>
> Ivan Kalik
> Kalik Informatika ISP
>
>
>> On Tue, Mar 31, 2009 at 11:50 AM, Bogomolov Andrei <dum at clink.ru> wrote:
>>
>>
>>> I'm running freeradius-1.1.7: NAS server sends Acct-Status-Start
>>> packet, then freeradius processes it, and confirms with
>>> Acct-Status-Reply. But if the reply packet is lost due UDP-nature, NAS
>>> sends second Acct-Status-Start. In this situation I have two duplicate
>>> records in radacct table. How can I avoid this? Unique db-indexes, or
>>> better something else?
>>>
>>> -
>>> List info/subscribe/unsubscribe? See
>>> http://www.freeradius.org/list/users.html
>>>
>>>
>>
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>
>
More information about the Freeradius-Users
mailing list