Subject: RE: (usr-tc) billing software

From: "Stainforth, Matthew" <[email-masked]>
Date: Tue, 25 Jan 2000 20:53:46 +0000

> -----Original Message-----
> From: Brian Elfert [mailto:[email-masked]]
> Sent: Tuesday, January 25, 2000 2:33 PM
> > if you guys are using radius accounting for billing data, 
> do you also use it
> 
> We use Platypus which uses radius for the time logging.  How 
> else could
> you record time used, syslog?

A company tried to pitch a package to us that used telnet to check
periodically.  *gag*
 
> If a radius stop record is missing, the customer just got a 
> free call, not
> a big deal.
> 
> > to limit concurrent logons?  I see a lot of people on the 
> list saying radius
> > accounting isn't reliable enough to be used to control 
> concurrency.  Just
> > wondering what the general concensus is...
> 
> Conncurency control is a whole different deal.  A missing stop record
> could cause a customer to not be able to login.

Since we are completely unlimited we haven't messed with radius accounting
much.  I completely missed the fact that the stop record contains the time
elapsed since logon.  My bad.  I guess that's what the list is for....learn
something new every day. :)

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 with "unsubscribe usr-tc" in the body of the message.
 For information on digests or retrieving files and old messages send
 "help" to the same address.  Do not use quotes in your message.

---

From: "Lon R. Stockton, Jr." <[email-masked]>
Date: Tue, 25 Jan 2000 21:05:53 +0000

> A company tried to pitch a package to us that used telnet to check

This reminds me of something I forgot to mention in my previous
message.

There's a radius server called Radiator which maintains a current-
calls database for concurrency checking; it updates it with the
accounting-start & stop records. To alleviate problems with lost
packets causing it to get out of sync, it periodically checks the
hub via SNMP and compares who's really on with who it thinks is
logged on.

Pretty spiffy, if you ask me.

-

---

From: Aaron Nabil <[email-masked]>
Date: Tue, 25 Jan 2000 22:19:02 +0000

> Pretty spiffy, if you ask me.

It is spiffy, but it's doesn't periodically check with the hub to see
who's logged on (at least it doesn't in my version, I am running one rev
back).  Only when it's about to deny someone a login because they are
exceeding their max session count does it go out and look to see if the
other sessions are still up.   Since radiator is single threaded, I'd
think this could really cause a problem if the check is slow or hangs.

--
Aaron Nabil

-

---

From: Brian <[email-masked]>
Date: Tue, 25 Jan 2000 22:20:07 +0000

> A company tried to pitch a package to us that used telnet to check

Their's nothing wrong with that.  Using telnet to grab stateful
information about who is logged in works very well.

The only other way, besides telnet, to grab that information reliably is
SNMP.  Because of missing records and whatnot, RADIUS I don't consider a
good idea.

>  "help" to the same address.  Do not use quotes in your message.

-----------------------------------------------------
Brian Feeny (BF304)     [email-masked]   
318-222-2638 x 109	http://www.shreve.net/~signal      
Network Administrator   ShreveNet Inc. (ASN 11881) 	      

-

---

From: Brian <[email-masked]>
Date: Tue, 25 Jan 2000 22:35:38 +0000

> think this could really cause a problem if the check is slow or hangs.

Aaron,

Are  you using Radiators session database to limit your concurrent
sessions of your users?  does it work well?

I use Radiator.  But for concurrency I use tsmon, just because thats how I
started.  I may use radiators session database in time though.

Their are alot of cool things you can do with Radiator, I love it.

Brian

-

---

From: Aaron Nabil <[email-masked]>
Date: Tue, 25 Jan 2000 22:50:50 +0000

> sessions of your users?  does it work well?

No, but I've looked at it.  Mostly been concerned about the
potential for blocking, and the fact that I run a separate acct and auth 
instances.  I _think_ gdbm is single writer, multiple reader safe (and
I'm almost sure the other dbm's aren't), so it might work.

The main problem that I see is that by hard blocking mulitple access it
allows people to effectively multiplex one account across several users,
something I'm not keen on encouraging.  What I do now is run a program
that checks for multiple connections every 5 mins, then I write people a
nasty gram when I catch them.  My _dream_ solution is to modify radiator
(or write a separate program) that simply hangs up any other connections
but allows the last person to call in to log on. People would get very 
tired of getting bumped off-line when their buddy calls in with their
password.  Then of course they call back in, bump the buddy off line, who
then calls back in, etc...

--
Aaron Nabil

-

---

From: Jason Englander <[email-masked]>
Date: Tue, 01 Feb 2000 10:13:40 +0000

> Pretty spiffy, if you ask me.

Check out Cistron http://www.cistron.nl/~miquels/radius, and an off-shoot
in production (by the same author and a co-author) at www.freeradius.org

It's FREE and does the same thing using radutmp/radwtmp (utils radwho
and radlast (radlast is just "last -f /var/log/radwtmp")) and does
verification via a perl script (using the SNMP Perl mods that come
with MRTG).

I'm using it with Lucentston pm2s, pm3s, and TCs w/ HiperDSPs.

  Jason

-- 
Jason Englander <[email-masked]>
Systems Administrator - InterLink L.C.

-