Hi all, I've tried searching the 3Com support site and etc. several times over the last several days about this, but if the answer's there I'm managing to miss it completely: For some time we have been having entries such as the following appearing in our radius log: "S12 didn't get online! status=-1, connect_fail=79, link_fail=31" ...where the "connect_fail=" value varies but the "status=-1" and "link_fail=31" values are always the same. For example, between 04:00 and 13:00 today there were 69 such entries, all from our USR equipment, with the value and count for "connect_fail=XX" as follows: connect_fail=3 -- 1 entry connect_fail=13 -- 28 entries connect_fail=21 -- 2 entries connect_fail=36 -- 16 entries connect_fail=79 -- 19 entries connect_fail=80 -- 3 entries I'd thought these were from the set of "Failure-to-Connect-Reason" values in the Vendor Specific Attributes, but that doesn't seem to be it since there are no Failure-to-Connect-Reason values for 79 and 80. Can anyone help me decipher this, please? TIA, - David - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.

Every so often we'll have a situation arise where users complain they are getting busy signals or dead air, and find that one of the quad modems is showing a red alarm when a call tries to connect to it. Resetting the modem generally corrects the problem. I'm trying to discover whether there are any trap settings that can be used to detect this kind of problem so that we can use Alarm Server to alert us to the problem, and resolve it before it has much impact on our customers. Does anyone know which trap settings, if any, would be useful in this situation? TIA, David - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.

Howdy, Are these on a HiPer or NetServer? What SW version? PRI or CT1? I don't know about trap settings, but if you use snmpwalk to take a look at the following MIBs, you should get the status: #ds0-level items (PRI/T1 card only) $oid_ds0_stat=".iso.org.dod.internet.private.enterprises.usr.nas.ds0.ds0StatTable.d s0StatEntry.ds0StatDs0"; $oid_ds0_statmodem=".iso.org.dod.internet.private.enterprises.usr.nas.ds0.ds0StatTa ble.ds0StatEntry.ds0StatModem"; I'm sorry I don't have the numeric OID's, this box has all the USR MIBs loaded up. This is a snippet from a general TC health monitor we put together. When I get the symptoms you describe, the modem status shows "modem busy out". We are running CT1's and ARCs, and this problem did not appear until an upgrade of the Hiper software to 4.2.32... Just putting together a perl script that walks those snmp values once a day and mails you the output should be enough to alert you to problems before customers start to complain. As to the root cause, I have no idea; we don't have a support contract so I can't open a ticket. Something in the HiPer code broke it though, as this started as soon as we upgraded the Arc. If anyone knows the OIDs to reset channels on the quads, that would be great. I'd love to have my script do this rather than having to fire up TCM. If anyone is curious about my monitoring script, let me know. It's very ugly as it was one of my first perl projects. I need to basically rewrite it to use the perl snmp module... Charles | Charles Sprickman | Internet Channel | INCH System Administration Team | (212)243-5200 | spork@inch.com | access@inch.com On Fri, 17 Nov 2000, D. W. Piper wrote:

I've searched through the 3Com documentation, online knowledgebase, etc. for information or help on this without success.

The symptoms:

- customers complain about experiencing busy signals, and/or RNA, and/or dead air; - we discover that one of the quad modems on the relevant chassis is showing a flashing red LED when a call comes in; - resetting the modem using TCM generally resolves the problem.

The questions:

What causes this to occur? Is there any way to test for this situation (perhaps using Alarm Server, if there's any trap setting that would detect this kind of problem) sooner, before we have irate customers calling in to complain?

Thanks for any help,

David (at wits' end - or is that witless?)

- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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 "majordomo@xmission.com" 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.