Thanks for the answer. So I guess as a workaround I should just
create a hook at the destination radius server that will change the
Acct-Delay-Time to 0 if it is a very large number.
On 25/1/2018 9:13 μμ, Heikki Vatiainen wrote:
> On 24.01.2018 17:07, Vangelis Kyriakakis wrote:
>> I have a RADIUS server which proxies RADIUS requests to another
>> RADIUS server (both RADIATOR servers).
>> Sometimes I see that the Acct-Delay-Time in the packet that is
>> proxied to the final server has a value of -1 and the final server
>> interprets this as Acct-Delay-Time = 4294967295.
> Looks like the result of converting -1 to an unsigned value.
> When radiusd reads a message from a socket it records the message's
> time stamp (seconds, microseconds) with call to
> Time::Hires::gettimeofday(). When it's just about to proxy the message
> forward, it will get current seconds with time().
> I suspect what you see is caused by rounding time() has to do and
> HiRes does not have to, or ntp or some other time synchronisation
> method adjusting the clock between the two time keeping events.
> I'll see that this gets fixed so that negative adjustment is never
> applied, no matter what the incoming Acct-Delay-Time is. This should
> ensure that Acct-Delay-Time never steps backwards.
> Thanks for reporting this!
radiator mailing list