(RADIATOR) Timestamp attribute

[Hugh Irvine]

Hello Dave, Hello Viraj -

The radius protocol itself has no notion of wall (clock) time - it only deals 
with delta times in numbers of seconds. This being the case, there are 
various "hacks" in use to get some idea of wall time. 

In the case of Radiator, there is an internal Radiator attribute called 
"Timestamp" added to each packet when it is received which contains the local 
time on the host on which Radiator is running.

In addition, there are some other definitons for Timestamp, such as when using 
GRIC roaming services, that add a "Timestamp" attribute to forwarded 
requests. 

As Dave says, the question really is "what time do you need?".

If it is the local time on the local host, then it is most useful to use the 
Radiator "Timestamp", because it has already been corrected to deal with any 
potential Acct-Delay-Time in the request. Again keep in mind that the radius 
protocol is UDP based, and packets can and do go missing, therefore 
accounting packets contain this mechanism to indicate how much of a delay 
there was between the actual event occuring and the transmission of the 
request.

regards

Hugh


On Thu, 25 Jul 2002 03:03, Dave Kitabjian wrote:
> 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:valankar at ifxcorp.com]
> > Sent: Wednesday, July 24, 2002 9:36 AM
> > To: radiator at open.com.au
> > 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 radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.