Arran Cudbard-Bell wrote: > No, that'll get you the timestamp of when the packet was read back into the > server. The only way to calculate the original received timestamp is to write > the original Acct-Delay-Time into a custom > attribute (say Acct-Delay-Time-Orig), subtract that from the current > Acct-Delay-Time, then that from the current UNIX timestamp.
The detail file reader creates/updates the Acct-Delay-Time based on how long the packet has been sitting in the "detail" file. There's no need to update it manually. > Yeah it's a pretty common setup, we do it too. One thing you have to watch > out for is packets with fatal errors. Where the remote accounting server > never acknowledged receipt of the packet, so it > gets stuck in an infinite loop in the proxying queue. > > I haven't figured out how to solve this properly with the current setup, so > it'd be good to see some discussion on list about it. Hmm... it should continue sending a packet from the detail file until the upstream server has responded. It shouldn't write packets to the detail file if they've been read from the detail file. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
