accounting to db - duplicate entrys & missing stop time?

[Alan DeKok]

Roger Kristiansen <roger.kristiansen at 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.