On Apr 1, 6:51pm, Christian Brem wrote:
> Subject: Antwort: Re: (RADIATOR) Duplicate Accounting Entries
> ---------------------- Weitergeleitet von Christian Brem/DEBIS/EDVG/AT on
> 04/01/99 06:54 PM ---------------------------
> Martin Laubach
> 04/01/99 01:37 PM
> An: Christian Brem/DEBIS/EDVG/AT@EDVG
> Thema: Antwort: Re: (RADIATOR) Duplicate Accounting Entries (Document
> link not converted)
> | Hmmm, I cant see that Radiator will NAK or ignore just because an
> | insertion failed. Are you sure thats whats happening?
> No, not really. I have another theory though...
> At times this happens, the database machine was rather busy. So busy
> as queries taking 10 secs or more. Can it happen, that the NAS sends
> an Accounting-Request, Radiator tries to insert it into the database
> and hangs there for some time -- in the meantime, the NAS times out
> and retransmits the request, and again, and again. Finally, the query
> returns, and now Radiator will diligently insert those queued accounting
> records too...
Yes, that seems more likely.
If so, it might be worth looking at your accounting table. You might need to
tune the indexes so that the inserts happen more quickly?
> This is what I see in the database:
> : SQL> select acctstatustype, time_stamp, acctsessionid, acctdelaytime
> : from radacct where acctsessionid = '00026205' order by time_stamp;
> : ACCTSTATUS TIME_STAMP ACCTSESSIO ACCTDELAYTIME
> : ---------- ---------- ---------- -------------
> : Start 922376419 00026205 0
> : Stop 922376435 00026205 20
> : Stop 922376440 00026205 0
> : Stop 922376447 00026205 5
> : Stop 922376450 00026205 10
> (Notice the rather peculiar ordering)
> Might that theory explain the phenomenum?
Yes, I think so.
> If so -- perhaps something like AcctDupInterval may be a possibility?
> Throw away all accounting requests that have the same NAS-Session-Id from
> the same NAS within a configurable period (say 60 seconds or so?).
yes, this has been suggested before, but its difficult. I think we will have to
escalate this in the priority.
Mike McCauley [EMAIL PROTECTED]
Open System Consultants Pty. Ltd Unix, Perl, Motif, C++, WWW
24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au
Phone +61 3 9598-0985 Fax +61 3 9598-0955
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, external, etc etc on Unix, Win95/8, NT, Rhapsody
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.