Subject: (usr-tc) v.42bis problems

From: Mike Andrews <[email-masked]>
Date: Fri, 07 Jan 2000 23:55:17 +0000

An old problem has just come back, but in only one weird case.

I've got a crapload of people getting randomly bumped offline with v.42 or
v.42bis related problems.  (I suspect v.42bis.)

However... it's only happening on the first 12 channels of ONE DSP card.

It's not happening on the other 11 channels of that card, or of any other
card in that city or any other city.  The card is configured *identically*
to the others in every way I can think of checking -- all DSP's are
running 2.0.51, though they have varying hardware revisions.  The card in
question is revision 0.49.

Just from midnight to 4:30 pm today on these 12 channels, I've had 310
disconnects for "v.42 string too long", 63 disconnects for "v.42 invalid
codeword", and 17 disconnects for "Link security abort".

It doesn't matter what brand of modem the client is calling in with.  It
could be a cheap Winmodem, it could be a USR Courier.  It definitely
happens with USR modems.

For now I've disabled v.42bis on this card until I can figure out what's
going on.  Disabling v.42bis stops the disconnects.

I seem to remember having this problem once quite a while ago, but it was
more widespread then...  it had popped up right after a DSP firmware
upgrade (I think to 1.2.68 at the time).  And this has popped up right
after going from 2.0.60 to 2.0.51 -- but again, only on half of one card.

Ideas?

Mike Andrews (MA12) * [email-masked] * http://www.bit0.com/
VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY
Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville
"It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear."

-
 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: Terry Kennedy <[email-masked]>
Date: Sat, 08 Jan 2000 01:00:52 +0000

Anyone have a clue as to the correct ( if there is even such a thing )
settings
on the dsp's. On all code previous to 2.0.51 the the default has been 11db.
I have
experimented with using a setting of 13db, 2 db lower power. Don't really
know
how this has affected the overall problem that i'm trying to solve of
disconnects.
I came to setting from trials with multitech analog modems. Changing from 11
to 13
on those solved a ton of problems. So i was surprised to see the default
setting
for 2.0.51 set to 10. What are you guys running or do you even bother
setting
these levels?

-

---

From: Horace Demmink <[email-masked]>
Date: Sat, 08 Jan 2000 21:12:50 +0000

> However... it's only happening on the first 12 channels of ONE DSP card.

I had a similar problem that turned out to be a DSP hardware problem. One
of my DSP's would, after moderate use, not answer on the first 12 channels
until it was reset. I had flashed several different versions of code,
tried different lines (CT1 and PRI), different locations, chassis's,
etc. Nothing made a difference. After jerking around with 3COM's RMA dept
for a while (you can't RMA it until a tech says it's bad, you can't talk
to a tech without a contract) my vendor offered to RMA it for me. I have
not seen this symptom pop up on any other cards I have.

-- 
Horace Demmink
PathWay Computing

-

---

From: Terry Kennedy <[email-masked]>
Date: Sun, 09 Jan 2000 20:02:24 +0000

Since noone replied to the first request for info on this I take it 1)
noneone else IS messing with these settings or 2)noone HAS been messing with
these settings or 3) Everyone simply ignored the mail.  So I'll ask once
again and then leave it alone on this list.

A few revisions back, can't remember how far, the dsp code started to allow
setting of the transmiter power levels. This was under line interface
options, transmitter level (-db), the same as the quads used to have. They
also had the same -11db setting as the quads did. I have had better luck
with the quads ( and some old analog multitech modems ) by lowering the
power level to -13db. It helped two different problems, disconnects and the
long training sessions that never would connect. I was about to start
changing these levels to -13db when I noticed that 3com has changed the
default setting from -11db to -10db in 2.0.51. In all previuos releases they
were set at -11db. Anyone out have any input on this? Does anyone know how
to get measurements from the ct1s to determine what the correct level should
be?

Terry Kennedy
OlyPen, Inc.

-

---

From: Rob Nelson <[email-masked]>
Date: Sun, 09 Jan 2000 21:21:03 +0000

> to get measurements from the ct1s to determine what the correct level should

I changed our DSP's to -13db when I read the following in the release
notes for 2.0.81

<quote>
Adjustable Transmit Level
Adjustable transmit level provides the ability to configure the modems
for
optimum performance. Ranges: -3 to -30 dBm for digital T1 line sources.
A setting of -13 dBm (S39=13) is recommended for calls over digital
lines
(T1 or PRI).
</quote>

We have seen no ill effects from this setting. We had problems with what
you describe above, long training sessions that wouldn't connect. I
don't know yet if this setting has made an improvement.
What I would like to know is why the recommended setting is not the
default setting?

-

---

From: Mike Andrews <[email-masked]>
Date: Sun, 09 Jan 2000 22:11:25 +0000

> not seen this symptom pop up on any other cards I have.

Interesting.

Any idea what hardware revision the card was?  0.49 maybe?  I'm just
trying to see if there's any pattern to these at all...

-

---

From: Terry Kennedy <[email-masked]>
Date: Sun, 09 Jan 2000 22:37:43 +0000

Thanks for the reply Rob, When I was working with multitech a long time ago
on some analog modems made by them, we started playing around for with the
power levels in an effort to solve connection problems ( the same long
training and then no connect or the dropped connection ) The only
explanation I ever got out them was something to do with the way the phone
co. provisioned the line and whether or no they added padding to them.
Apparently some do some don't. Padding on ct1s is out my experience range so
I took their word for it. But there must some way to check this, either a
measurement made directly on the line or a indirect method by querying the
modems somehow. A 3com tech I tallked to once made reference to reading this
info directly off the dsp by plugging in a console cable to them. He never
did make it out here on-site, so his knowlege was lost to wind.. Oh well..

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Rob Nelson
Sent: Sunday, January 09, 2000 11:17 AM
To: [email-masked]
Subject: Re: (usr-tc) Second request --dsp transmitter levels

<quote>

-

-

---

From: Horace Demmink <[email-masked]>
Date: Mon, 10 Jan 2000 05:43:55 +0000

> trying to see if there's any pattern to these at all...

No idea, I didn't keep record on what revision the card was. It very well
could be 0.49 (why are the hardware revisions 0.xx, are these beta release
cards? :-) as the others I installed at the same time are.

-- 
Horace Demmink
PathWay Computing

-

---

From: Mike Andrews <[email-masked]>
Date: Wed, 12 Jan 2000 09:23:47 +0000

Hm.  So far it seems to be isolated to version 0.49 cards.  3Com?  Any
insight here?

Mike Andrews (MA12) * [email-masked] * http://www.bit0.com/
VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY
Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville
"Don't sweat the petty things, and don't pet the sweaty things."

-

---

From: "Jason A. Nunnelley" <[email-masked]>
Date: Tue, 18 Jan 2000 03:38:06 +0000

WOW! I would definitely get a tech contract. I just burned a DSP card
and it started dumping - one call, one shipment, and I had a new DSP
card. I would have never considered RMA had it not been for the tech.
He told me the dumps were most likely due to the card being bad. I was
still screaming at my telco (they earned it before this problem with a
list of provisioning different switch types in a single hunt group - u
know - standard Telco Crap.

I saved myself countless thousands in tech support and lost revenues by
not letting customers leave me while I wait to guess the problem. I'd
definitely invest in the support contract.

Jason A. Nunnelley
President of Linkfast Internet Services,
Linkfast Inc. 256-739-2008 VOICE CONTACT

Linkfast Labs, GPN, MFG, MentionMe Studios,
and, the Stupid Project
http://www.linkfast.net

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Horace Demmink
Sent: Saturday, January 08, 2000 11:08 AM
To: [email-masked]
Subject: Re: (usr-tc) v.42bis problems

--
Horace Demmink
PathWay Computing

-

-