Alan DeKok wrote:
Alexander Serkin [EMAIL PROTECTED] wrote:
No. It takes the time that the packet was received. The
Event-Timestamp attribute MAY be a lie.
oops. When and why? Have not seen a lie from cisco NASes yet.
Set the time wrong on the Cisco box, then look at Event-Timestamp.
Set
Alexander Serkin wrote:
Edit oraclesql.conf to use the query you want. That's why the
queries are configurable.
Shure i will. I've seen them occasionally :-)
The question was to guys who may did the trick already. Because in Oracle
You can parse the string May 18 2005 12:08:18 +0400 easily,
Alexander Serkin [EMAIL PROTECTED] wrote:
And finally i can modify the timezone presentation by Solaris zone
info compiler so that it would be +0400, but radiusd modifies it
into =2B0400, and that confuses oracle completely:
Look for safe in sql.conf.
Alan DeKok.
-
List
Alexander Serkin [EMAIL PROTECTED] wrote:
No. It takes the time that the packet was received. The
Event-Timestamp attribute MAY be a lie.
oops. When and why? Have not seen a lie from cisco NASes yet.
Set the time wrong on the Cisco box, then look at Event-Timestamp.
It happens
Ok. RFC says exactly that
The Value field is four octets encoding an unsigned integer with
the number of seconds since January 1, 1970 00:00 UTC.
I did not think radiusd rewrites unix timestamp into date.
Just because previous radius i was using used to put the timestamp into
accounting as
Alexander Serkin wrote:
Ok. RFC says exactly that
The Value field is four octets encoding an unsigned integer with
the number of seconds since January 1, 1970 00:00 UTC.
I did not think radiusd rewrites unix timestamp into date.
Just because previous radius i was using used to put the
from the Event-Timestamp
field of the accounting packet?
No. It takes the time that the packet was received. The
Event-Timestamp attribute MAY be a lie.
Hm. That's not a trick. And not good at all. %S takes time at which the
request comes to radius.
Exactly. You can't trust the NAS
Hi.
The Event-Timestamp attribute is now (according to yesterday CVS
snapshot) in separate file dictionary.rfc2869.
This RFC says the attribute to be unsigned integer. Why is it date in
dictionary.rfc2869?
If we name the file with rfc number, then why didn't we follow it ?
It's not difficult
Alexander [EMAIL PROTECTED] wrote:
This RFC says the attribute to be unsigned integer. Why is it date in
dictionary.rfc2869?
Because it's a date. See RFC 2866 for a definition of the time
type. It's the same as date, and is stored as a 32-bit integer.
If we name the file with rfc number,
9 matches
Mail list logo
