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.