Roger Kristiansen <roger.kristiansen@cc.uit.no> wrote:
We have set up freeradius to do accounting to a postgresql database, and I was expecting to see one record pr. session, and mostly we do. But there are also a lot of records that: ...
Are screwed up. Can you say "NAS implementations are often bad"?
I am guessing that in case nr. 1 an explicit "Stop" message has not been received, but when it comes to the two others, I have no clue.
NAS implementations are bad. FreeRADIUS just logs what it's sent. You can post-process the data to clean it up, but I'm strongly opposed to always processing it before doing the logging. There's just too much of a chance to lose information.
As I am trying to write an application to more easily extract useful information from the data in the database, I need to know when the session started and when it ended. Having duplicates and missing stop times makes this a bit difficult.
Welcome to RADIUS accounting. I'd suggesting looking at "radiusreport", which deals with some of these issues. It may give you ideas as to how to deal with the problems in your application.
Can I get freeradius to log every "Alive" message to the database, so that I at least know when the last "Alive" was received?
See "accounting_update_query", which is run for Alive (i.e. Interim-Update) packets.
If someone could take the time to explain why the stuff I mention here occur, or have tips on other ways to extract the time the session ends, I'd really appreciate it.
If you don't get a stop record, the session ends: a) some time after the last Start or Alive packet was received b) some time before the next Start packet is received for that port. That's pretty much it. Alan DeKok.