Interesting question.
The question for you is, what event do you want the stamp for?
The Timestamp attribute indicates, I think, when the RADIUS packet is
actually sent by the NAS.
The line at the top:
Wed Jul 24 12:59:01 2002
Acct-Session-Id = "0002BAA0"
Framed-Protocol = PPP
indicates when RADIATOR generated the record.
Your 2nd Timestamp attribute might be when RADIATOR is acting like a NAS
and proxying the packet to the next RADIUS server. In theory, that could
be minutes or hours later.
So, which of these events do you want to capture? You may want to write
a hook to throw out preexisting Timestamp attributes before you proxy
them over to the next RADIUS server...
Dave
:)
> -----Original Message-----
> From: Viraj Alankar [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, July 24, 2002 9:36 AM
> To: [EMAIL PROTECTED]
> Subject: (RADIATOR) Timestamp attribute
>
>
> Hello,
>
> From what I can understand, the timestamp used in AuthSQL for
> accounting is the Timestamp attribute that is created in the
> request packet by the current time minus Acct-Delay-Time.
>
> However, when I have one Radiator proxying to another, the
> 2nd Radiator ends up with 2 Timestamp different attributes.
> It isn't clear to me which one will be used by the 2nd
> Radiator. I see get_attr in the code being called for this
> value but wouldn't this just return the first (incorrect)
> Timestamp value?
>
> Would it be better for me to depend on a database function
> for the timestamp? For example, with an insert statement similar to:
>
> ..., now() - 0%{Acct-Delay-Time}, ...
>
> Viraj.
> ===
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
