Event-Timestamp

[Alan DeKok]

Arran Cudbard-Bell wrote:
> * In the default SQL accounting schemas %S is used over the
> Event-Timestamp attribute included in the accounting packet. I guess
> this is because of the potential drift between NAS, and it makes
> correlation easier. Is this the real reason or is it just an omission ?

  Many NASes have broken clocks.  Many, many, have broken clocks.

> * RFC 2869 Specifies the format of Event-Timestamp to be number of
> seconds since the Unix Epoch. Yet FR prints it as     Event-Timestamp =
> "Apr 24 2008 20:06:52 BST". Is this FR's interpretation of the integer
> timestamp as a date string or is the NAS sending the timestamp as a string?

  It's being *printed* as a string.  The contents of it in the packets
are always 32-bit integers.

  It may be worth adding some logic to the server to double-check for
"bad" Event-Timestamps...

> * In accounting detail packets, a timestamp attribute is included. But I
> can't figure out how to access it as an attribute when the detail
> entries are read back into the server. Any ideas how to ?

  Hmm... you can't.  It may be useful to add it as something like
Packet-Original-Timestamp, to distinguish it from Event-Timestamp.

  That's not hard to do.

> It would be
> better to use this in accounting queries than %S and there will be a
> delay between the packet arriving and the packet being inserted into the
> SQL db.

  Yes.  But the server adds Acct-Delay-Time to the accounting packet,
with exactly that time difference.

  But I see what you mean...

  Alan DeKok.