Subject: (usr-tc) TRAP disconnect reasons

From: Paul Farber <[email-masked]>
Date: Wed, 18 Aug 1999 06:26:44 +0000

Anyone figure out why ALL modem failure reasons are always 0?

enterprises.usr.nas.mdm.mdmCs.mdmCsTable.mdmCsEntry.mdmCsConnectFailReason.1
= 0,

The reference chp 24 "Modem Disconnect and Fail to Connect Reasons" starts
at drtDrop(1) and is only for the Quad modems????

TCM reports a variety of call failure types, but traps don't.

Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax 570-628-5545
[email-masked]

-
 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: Wed, 18 Aug 1999 06:39:38 +0000

Thus spake Paul Farber

>enterprises.usr.nas.mdm.mdmCs.mdmCsTable.mdmCsEntry.mdmCsConnectFailReason.1

Well...not sure exactly what you're getting at here, but keep in mind
that the mdmCs tree is for the current or last call.  Basically, these
values are reset at the beginning of each call, so if there is a call
currently connected, the connectfailreason will be none because the
current call didn't fail to connect.  If the modem is idle, the
connectfailreason will be none if the last call did successfully
connect, but will be something different if the last call was a failed
call.

(Note...I haven't experienced this personally...going on my
understanding of how the mib trees function within the TC equipment)

>at drtDrop(1) and is only for the Quad modems????

Not sure what you mean by "is only for the Quad modems."  I believe at
least the 1.2.43 code has an off-by-error in it for these values...you
have to subtract one from the value being reported via snmp to get the
actual value from DSP's.  I *think* the quads report it correctly (ie,
not off-by-one)
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Paul Farber <[email-masked]>
Date: Wed, 18 Aug 1999 06:52:50 +0000

But wouldn't the trap have to have the correct call fail reason?  The call
failure is what triggered the trap.

As for off by on.. that would make the vaule -1 (0 - 1 = -1).

TCM seems to have at least different reasons for call failures... no way
to be sure they are correct... but at least they change.

Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax 570-628-5545
[email-masked]

-

---

From: Jeff Mcadams <[email-masked]>
Date: Wed, 18 Aug 1999 07:28:16 +0000

Thus spake Paul Farber
>failure is what triggered the trap.

Ah...you're dealing with traps...I missed that part....

I don't see any traps that include mdmCsConnectFailReason in them...
RADIUS logging from the NMC includes the equivalent value in there with
some of its logs, but it doesn't seem to be sent with any actual SNMP
traps from what I can see...perhaps I'm wrong though.

>As for off by on.. that would make the vaule -1 (0 - 1 = -1).

But the number in the mib file that I have starts with 1, not
0...perhaps we're looking at different mib files?  not sure.  We seem to
be talking past each other, but I'm not sure why...

>to be sure they are correct... but at least they change.

Hrmm...I'm pretty sure TCM doesn't pull it from traps, it just polls,
but I'm not sure what its pulling.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-