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

From: Dwayne Varey <[email-masked]>
Date: Wed, 20 Sep 2000 08:45:23 +0000

umm, this may sound like a dumb question, but how is the nmc setup to log
radius call data.  I've been looking around in our nmc's and the only sort
of logging that seems to be available is syslog.  Do you just set the nmc to
syslog all of its info to a radius server?  and then have the radius server
insert data into sql table, or did I miss something along the way?

 ________________________________________________
 Dwayne Varey
 Systems Administrator
 WestNet - WA's Statewide Internet Provider
 Phone: 92182600 - Fax: 92182666
 http://www.wn.com.au
 _________________________________________________

-----Original Message-----
From: Mike Andrews [mailto:[email-masked]]
Sent: Sunday, 17 September 2000 14:57
To: [email-masked]
Subject: Re: (usr-tc) Logging modem disconnect reasons

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

On Fri, 15 Sep 2000, Jeff Mcadams wrote:

> Also sprach Charles Sprickman
> >On Fri, 15 Sep 2000, Jeff Mcadams wrote:
> >> 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
> 
> -
>  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.

-
 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: Mike Andrews <[email-masked]>
Date: Thu, 21 Sep 2000 23:28:58 +0000

> insert data into sql table, or did I miss something along the way?

Yes to both, the NMC sends it as a Radius accounting packet.  That means
for every disconnect you have two Radius accounting packets -- one from
the ARC, one from the NMC.  Matching the two records up after the fact and
making sense of it is then your problem, and putting it in a SQL database
made it a bit easier for me...

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

-