Rygl Aleš wrote:
I thought %S corrected by Acct-Delay-Time of course.
No. It's not.
Excuse me, but do not understand. From my point of view I do not see a reason for manipulating Acct-Delay-Time this way and replacing the original value from the request with a new one based on time needed for request processing.
Arran and I both explained it. If you still don't understand, there's really nothing more I can say.
If you keep original value, later on, when you query DB, it would be clear when the session started (Event-Timestamp) and how much was the session start packet delayed (Acct-Delay-Time).
The session start packet was delayed by the NAS, *and* by FreeRADIUS. If you want to store Acct-Delay-Time as received from the NAS, that's *completely different*. You will need to copy it to another attribute, say "Original-Acct-Delay-Time". The attribute Acct-Delay-Time has a pre-defined meaning. The server updates the Acct-Delay-Time because it's *required* in order to keep the same meaning. When you make Acct-Delay-Time mean something else... you're wrong.
Well, we would need to store it from diagnostic reasons. It indicates possible performance problems on the NAS.
No. Acct-Delay-Time has a pre-existing meaning. Don't change it.
Is there a way how to save the original Acct-Delay-Time to DB in buffered-sql mode?
Yes, copy it to another attribute before writing it to the detail file. Alan DeKok.