(RADIATOR) Duplicated Stops Accounting Records

[Brian Morris]

Hi all,

I got around this by making the username, nasidentifier, nasport and acctsessionid a combined unique key in my sql accounting table.  This way sql will not allow a duplicate record to be written.  It will print an error to your logfile though but don't worry about it.

I know this is not perfect but I think it is pretty unlikely that the above combination will ever be repeated legitimately.

Regards,  

Brian Morris
NetSpeed.


  ----- Original Message ----- 
  From: Hugh Irvine 
  To: Ing. Flavio Rodriguez (ISP) 
  Cc: radiator at open.com.au 
  Sent: Monday, October 21, 2002 4:14 PM
  Subject: Re: (RADIATOR) Duplicated Stops Accounting Records



  Hello Flavio -

  Duplicate radius packets are always a possibility and always a problem.

  In your case, I would probably use an AcctSQLStatement instead of the standard AccountingTable/AcctColumnDef's, that would check to make the packet is not a duplicate and not already in the database. This should be possible by checking the username, identifier and timestamp. 

  Note that the timestamp in the accounting request is added by Radiator and is corrected for the Acct-Delay-Time automatically. You should of course check this.

  I am fairly sure this topic has been discussed before on the mailing list, so have a look at the archive site and do some searching.

  http://www.open.com.au/archives/radiator

  regards

  Hugh


  On Monday, October 21, 2002, at 12:41 AM, Ing. Flavio Rodriguez ((ISP)) wrote:


    Hi,

    I have the following problem with Radiator:

    Sometimes, I have more than one stop accounting record in my database for user's sessions. It not happens many many times but happens. The records are different between them only because they have different ACCTDELAYTIME (each 60 seconds=NAS Timeout) and different TIME-STAMP of course.

    This problem is very serious for me, because I am offering prepaid cards internet access controled by time, and many stops records affect the TIME-LEFT of my customers, because the TIME-LEFT is subtracted many times. My billing process in general is affected, because for the rest of my customers I only take data for billing process from stops accounting records and if they are duplicated I have a problem ...!!!

    I noticed that it happens or it begins to happen when I have in my logs erros like the following in my database:

    Sat Oct 19 09:59:57 2002: ERR: do failed for 'delete from RADONLINE where NASIDENTIFIER='XXX.XXX.XXX.XXX' and NASPORT='XXXX': SQL Timeout

    I don't know why my database is reporting an "SQL Timeout" error. I think that perhaps it can be caused for some attribute on database (for example: open_cursors attribute. I think that I need to increase this value (current value=)

    Here is my aditional information of my platform:

    Server: RS/6000 AIX 4.3.3 with maintenance level 10 [512 MB RAM / 9 GB SCSI HARD DRIVE (whith mirrr)].
    Radiator Version: Radiator 3.3.1 whith all patches applied.
    DataBase: Oracle 8i (8.1.6 version). All the tablespaces have enought disk free.

    Also here is a part of my logs when it happens:

    Sat Oct 19 09:15:22 2002: ERR: do failed for 'delete from RADONLINE where NASIDENTIFIER='XXX.XXX.XXX.XXX' and NASPORT='XXXX': SQL Timeout
    Sat Oct 19 09:16:40 2002: INFO: Duplicate request id 158 received from XXX.XXX.XXX.XXX(YYYY): ignored
    Sat Oct 19 09:16:40 2002: INFO: Duplicate request id 158 received from XXX.XXX.XXX.XXX(YYYY): ignored
    Sat Oct 19 09:16:40 2002: INFO: Duplicate request id 158 received from XXX.XXX.XXX.XXX(YYYY): ignored

    Any help will be appreciated.

    Regards.

    Eng. Flavio Rodriguez
    ISP - ETAPA



  NB: I am travelling this week, so there may be delays in our correspondence.

  -- 
  Radiator: the most portable, flexible and configurable RADIUS server
  anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
  -
  Nets: internetwork inventory and management - graphical, extensible,
  flexible with hardware, software, platform and database independence.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.open.com.au/pipermail/radiator/attachments/20021021/72889277/attachment.html>