Acct-Delay-Time attribute in buffered-sql server mode

[Rygl Aleš]

On Saturday 04 of October 2014 15:23:20 Alan DeKok wrote:
>   I'm not sure what you're getting at.  Using Acct-Delay-Time is
> correct, because the packet has been delayed.  Otherwise, when there's
> no Event-Timestamp in the packet, it will assume that the session start
> time is the SQL insert time, not the packet receive time.
> 
>   Perhaps you could explain why you think it's wrong to update
> Acct-Delay-Time.
> 

Using (and updating) Acct-Delay-Time is correct when the request proxied and 
internal processing on the Radius server takes some time or there is a retry. 
If I use this file buffer for doing proxy then it makes sense of course. But I 
do not see the point updating it when the file is just being loaded to DB. 

IMHO it matters to store the DB record with correct timestamps (I can use 
there either Event-Timestamp or %S) and keep the original Acct-Delay-Time 
here.

Let's have following entry in the detail.work file:

Sun Oct  5 12:11:31 2014
        User-Name = "wap"
        Calling-Station-Id = "420609065063"
        NAS-IP-Address = 10.49.32.253
        Acct-Status-Type = Start
        NAS-Identifier = "tmcz-gw1"
        SN-Software-Version = "15.0 (54515)"
        Service-Type = Framed-User
        Framed-Protocol = GPRS-PDP-Context
        Event-Timestamp = "Oct  5 2014 12:11:21 CEST"
	Acct-Delay-Time = 10

In this case the %S is "Sun Oct  5 12:11:21 2014", The delay indicates that it 
is not on time. When I store it using %S for session start I have to use a 
correction or use Event-Timestamp to get the real session start.

The problem is that if there is a huge detail.work file loading it may take 
some time. Buffered-sql server then updates (or creates if it is not already 
present in the detail.work file) the Acct-Delay-Time on the time the request 
was waiting in the detail.work file. If the server manages to load the 
detail.work file every 20s the Acct-Delay-Time delay stored in DB is then not 
10 but 20 or 30s (I am not sure here, it seems to me that previous value is 
replaced).

Now I see I could use Event-Timestamp and %S and reconstruct the delay from 
them...

I hope I manage to explain it. Or maybe I missed something?

Ales






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20141005/92c5caec/attachment.html>