Subject: RE: (usr-tc) Logging modem disconnect reasons

From: Colin Wantling <[email-masked]>
Date: Fri, 15 Sep 2000 11:47:55 +0000

Kevin,

we do this by turning on the logging on the NMC (using TCM) and sending the accounting info to our radius server. Of course, the NMC will need to be entered in the Radius clients file.

Using TCM on each DSP, you can redirect the DSP traps so that the NMC can send them out to the Radius.

regards,

Colin Wantling

	----------
	From: 	Kevin Godby[SMTP:[email-masked]]
	Reply To: 	[email-masked]
	Sent: 	Friday, September 15, 2000 6:32 AM
	To: 	[email-masked]
	Subject: 	(usr-tc) Logging modem disconnect reasons

	Hello.

	I was wondering if anyone out there that's using 3Com/USR Total Control
	boxes (with HiPerARCs) know of any utilities that could store the disconnect
	reasons that the HiPerDSP generates (the actual modem disconnect reasons,
	not the general  disconnect reasons that the HiPerARC uses) along with the
	person's usename and the date/time.  They are wonderful for troubleshooting
	because they are so specific, but it's time-consuming to watch someone's
	session until they happen to get disconnected. :-)  If we could somehow get
	the Total Control to send these to Vircom's VPRRS, that would be excellent,
	but I'm not too picky.

	Thanks for any ideas!

	Kevin Godby  <[email-masked]>
	Professional Computer Solutions, Inc.
	434 W. Second St.      Phone: (641) 682-4691
	Ottumwa, Iowa  52501     Fax: (641) 682-0633

	-
	 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.

-
 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: Jeff Mcadams <[email-masked]>
Date: Fri, 15 Sep 2000 13:23:43 +0000

Also sprach Colin Wantling
>we do this by turning on the logging on the NMC (using TCM) and sending
>the accounting info to our radius server. Of course, the NMC will need
>to be entered in the Radius clients file.

Yes...this is probably the best way of doing this.  The tricky part is
correlating them with the userids as the NMC doesn't know the userids,
so you'll have to match these records up with the Arc RADIUS accounting
records to be able to correlate disconnect reasons with userids.  Not
impossible by any means, but it does add another little wrinkle.  :)
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Charles Sprickman <[email-masked]>
Date: Fri, 15 Sep 2000 18:47:05 +0000

> impossible by any means, but it does add another little wrinkle.  :)

Hmmm...  I didn't even know you could do this.  What common information is
there between your normal ARC-supplied accounting record and the NMC
info?  Do you generally log to the same radius server or keep this
seperate and match things up on an as-needed basis?  Any idea what
Radiator would think of these 'extra' accounting records?

Thanks,

Charles

-

---

From: Kevin Godby <[email-masked]>
Date: Fri, 15 Sep 2000 21:08:09 +0000

Hello, Colin.

I'll have to look into that, but it sounds like that is my solution.  What
RADIUS attributes does the NMC use?  (Do I need to add those to the
dictionary file?)  Also, is there any correlating information between the
NMC accounting logs and the ARC accounting logs?  (I'm presuming that
Port-ID would be in both, at least.)

Thanks!

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Colin Wantling
> Sent: Friday, September 15, 2000 4:45 AM
> To: [email-masked]'
> Subject: RE: (usr-tc) Logging modem disconnect reasons
>
>
> Kevin,
>
> we do this by turning on the logging on the NMC (using TCM) and
> sending the accounting info to our radius server. Of course, the
> NMC will need to be entered in the Radius clients file.
>

-

---

From: Jeff Mcadams <[email-masked]>
Date: Sat, 16 Sep 2000 00:48:54 +0000

Also sprach Charles Sprickman
>> Yes...this is probably the best way of doing this.  The tricky part
>> is correlating them with the userids as the NMC doesn't know the
>> userids, so you'll have to match these records up with the Arc RADIUS
>> accounting records to be able to correlate disconnect reasons with
>> userids.  Not impossible by any means, but it does add another little
>> wrinkle.  :)

>Hmmm...  I didn't even know you could do this.  What common information
>is there between your normal ARC-supplied accounting record and the NMC
>info?  

Well...I'm pretty sure that slot and channel are available in both, so
that can be used to match them up.  It would really be nice if there
some sort of call reference number to match between DSPs and Arcs, while
the DSPs do have a call reference number, I don't believe the Arcs know
what it is.  Would be nice though.  :)

>Do you generally log to the same radius server or keep this seperate
>and match things up on an as-needed basis?  

We've only played with this and never set it up to make full use of it.
I just wish I could trade some of these square tuits for some round
ones.  :/

>Any idea what Radiator would think of these 'extra' accounting records?

I would hope it wouldn't have any problem with them.  RADIUS is designed
to be a stateless protocol, so it *shouldn't* have any problems with
them.  It should just be new records that come into the RADIUS server
and get logged or processed like any other.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Mike Andrews <[email-masked]>
Date: Sun, 17 Sep 2000 09:08:04 +0000

These days I think the call reference numbers *do* match up between the
ARC and NMC.  There used to be some incompatibilities between the two (one
would log in hex and one in decimal, or one would log big-endian and one
little-endian, that kinda thing)...  but I think that's all in the past.

I have a Perl script that tails the Radius accounting logs, matches the
ARC and NMC records up, and writes it to a MySQL table.  From there it's
easy to write a web page that users (or admins for that matter) can go to
to view their most recent sessions and see exactly why it was they were
disconnected, with both the ARC and modem reasons given (unless one gets
lost, or gets logged to the other accounting server, or whatever -- this
is UDP after all).  You can throw other stuff in there too, like connect
speed.

I can't remember what fields I used to try to match them up; I think just
hostname (you need a list of what arcs match which nmc's) and session-id
is enough...
Lemme go look at the code a sec.
Hm.  Weird.  I matched up session-id, slot, channel, ANI, and
DNIS.  That's probably overkill...  :)

This script isn't currently up on the web with the rest of my scripts, but
I could put it there or mail it if anyone cared -- I'll have to clean it
up a bit (read: remove SQL passwords) first.  It's as sloppy as the rest
of my code but it's a starting point and saves reinventing at least some
of the wheel.

Mike Andrews (MA12) * [email-masked] * http://www.bit0.com/
VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY
Dialup/ADSL/ISDN/T1 Internet access for Frankfort KY and surrounding counties
www.fark.com: If it's not news, it's Fark.  (Or something like that.)

-