Howdy,
> -----Original Message-----
> From: Hugh Irvine [mailto:[EMAIL PROTECTED]]
> Sent: Friday, 3 September 1999 18:33
> To: [EMAIL PROTECTED]; Chris Knight; [EMAIL PROTECTED]
> Subject: Re: (RADIATOR) Accounting
>
>
>
> Hello Chris -
>
> On Fri, 03 Sep 1999, Chris Knight wrote:
> > Howdy,
> > A client of ours is running Radiator, and I need to get
> the Accounting data
> > into a SQL server for billing purposes. Because of management and
> > responsibility requirements, I have to get the data from
> the accounting log
> > file, play with it in Perl, and put it into the SQL Server.
> I'm not able to
> > use the SQL logging features of Radiator.
>
> I would be tempted to set up a Radiator proxy running SQL
> accounting, and
> configure the client Radiator to proxy only the accounting
> packets to it. That
> way you retain your management and responsibility
> requirements, and you can use
> all of the Radiator features to log to an SQL database. You
> might inform your
> client that this is how all roaming systems work, for example.
>
I've got to convince the client to upgrade to a site license however. I can
see the sense in it though. Jee, I wonder why you suggested that?... :-)
> > I've got a couple of questions relating to the
> implementation I need to do.
> > First, is the Acct-Session-Id truly unique for each
> session? Secondly, if
> > multiple Radiator servers are running - both servicing the
> same set of
> > NASes - will the Acct-Session-Id still be unique, or do I
> need to catenate
> > the Acct-Session-Id with the Radiator server IP address,
> for instance?
> > Thirdly, out of curiosity, how is the last set of six digits for the
> > Acct-Session-Id generated? I managed to figure out the
> first two sets all by
> > myself :-)
>
> The Acct-Session-Id is generated by the NAS. However I would
> have thought that
> you would want to make sure that your User-Name's are unique
> and use those for
> your accounting.
>
Yes, that's currently happening, but I'm looking for a unique attribute(s)
on which to key the data to stop charging the customer twice (or more) for
the same session. My first coding attempt simply entered STOP events where
the appropriate number of attributes were present and contained acceptable
values. This didn't stop duplicate accounting entries.
> > I need a unique reference, as I am seeing duplicate
> accounting entries in
> > the log file.
>
> You always have the possibility of duplicate packets due to
> the UDP protocol
> used by radius. If you are logging to an SQL accounting
> database, the duplicate
> inserts will fail in any case.
>
Yes, this duplicate packet entry is very annoying. I would very much like to
log directly to the SQL server, but that isn't happening - yet. I'm assuming
that the duplicate inserts fail due to a unique constraint on the
AccountSessionID field. Please correct me if I'm wrong. Also, if the NAS
creates the AcctSessionID, what stops two NASes sending Radiator (or any
other RADIUS server, for that matter) the same AcctSessionID?
> hth
>
Sort of. If you can verify my assumption above, then yes it does. Look
forward to hearing from you.
> Hugh
>
>
> --
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
> Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8,
> NT, Rhapsody
>
Regards,
Chris Knight
Systems Administrator
AIMS Independent Computer Professionals
Tel: +61 3 6334 6664 Fax: +61 3 6331 7032 Mob: +61 419 528 795
Web: http://www.aims.com.au
===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
