Hi Heikki, 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. Regards Vangelis
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! > Heikki > _______________________________________________ radiator mailing list [email protected] http://lists.open.com.au/mailman/listinfo/radiator
