Subject: (usr-tc) Link dead after 8 Days

From: Dale Hege <[email-masked]>
Date: Sun, 15 Aug 1999 17:12:19 +0000

Hello, 

Has anyone had problems with customers staying connected for more than 8
days straight? I have an ISDN customer that seems to not be able to pass
any packets other than icmp after 8 days of being connected. I'm running
on DSP 2.0.81 and 4.1.59 on the arc. 

Thanks,

-Dale

-
 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: Sam Lowe <[email-masked]>
Date: Mon, 16 Aug 1999 03:16:41 +0000

Dale,

You are not the only one with this problem.  It is a real problem, and you
can't count on the eight days.  It can happen any time.  Here are the
particulars that a group of us have noticed:

It only happens with HiPer DSPs, quad modems aren't affected.
It has occurred with the following ISDN routers: Cisco 760 series, Eicon
Diva, Ascend Pipeline 50, and Netgear RT-328/RH-348
It primarily starts with http packets, and sometimes migrates to e-mail.
Usually your can telnet and ftp to the affected site.
I have a couple of previous posts in this group with in the last few days
that cover this in more detail.

The only fix is the terminate the connection and re-connect.

The real problem is that 3Com doesn't want to help. I have posted this more
than once and get very little attention.  Recently, after another loud post
to this group I got a direct e-mail from krish, but it was Friday and I
haven't had a chance to go through the whole thing.  I will be forwarding it
to 6 other ISPs who have told me they have the same problem. I will send
copies out in the morning after I get to the office.

If 3Com can't fix it, then I will have to buy another NAS.  We have lost
money/customers due to this problem.  I wish they cared.  You can believe
that if they don't fix it, they won't appreciate my comments in this group.

----- Original Message -----
From: Dale Hege <[email-masked]>
To: <[email-masked]>
Sent: Sunday, August 15, 1999 10:10 AM
Subject: (usr-tc) Link dead after 8 Days

-

---

From: K Mitchell <[email-masked]>
Date: Mon, 16 Aug 1999 04:36:15 +0000

>copies out in the morning after I get to the office.

I'd appreciate a copy also. I just started a customer with a Cisco 804 a
few days ago. I'll let you know if anything comes up with him.

-- 
Kirk Mitchell-General Manager        [email-masked]
Keystone Connect                     Unlock Your World
Altoona, PA   814-941-5000      http://www.keyconn.net

-

---

From: Tatai SV Krishnan <[email-masked]>
Date: Mon, 16 Aug 1999 05:39:44 +0000

> >than once and get very little attention.  Recently, after another loud post

If that is the case you would not have seen any emails from me.  The real 
problem here is there indications of the problem but we need to know the 
exact senario and how are you concluding the problem.  Can you reproduce 
the problem on demand.  First of all I have not received an email back 
from you on what versions of code you are using.  If there is a 
consistant way to reproduce this problem - then its easy to fix.  Else 
you take time to reproduce and we take time to reproduce the same - and 
so does the fix.

> >copies out in the morning after I get to the office.
Here is what you need to do.  First if you have this problem on 2.0.81 or 
any 2.0.X DSP code and hiper arc 4.1.59 then we need to understand the 
problem and may have to take some traces.  However in the mean time a 
small change in the setup for the user (if you can do it and test  it) 
will give us enough clues on what the problem is.  Here is what I wnated 
to be done.

Pick any one or two customers, create them as local users on the hiper 
arc and set the users MTU to some small value like 576.

set net user <username> mtu 576

have the customer dial and lets wait for the failure.  if you have syslog 
and have access to it, we would also like to run some debug.

regards

krish

-

---

From: Sam Lowe <[email-masked]>
Date: Mon, 16 Aug 1999 18:38:27 +0000

The original post is getting kind of lengthy.  I'll try to address all
Krish's questions.

1.  The problem cannot be replicated/reproduced on demand.

2.  The versions of code: HiPer DSP: 1.2.59, HiPer ARC: 4.1.59, NMC:5.5.5

3.  I understand these problems can take time to fix, I am just frustrated
with the 3Com responses through last Thursday evening.  The response from
Krish was the first real help I've gotten.

4.  We have implemented the  MTU change.  If Krish can contact me
(850-337-016), we have a locked up system right now.

----- Original Message -----
From: Tatai SV Krishnan <[email-masked]>
To: K Mitchell <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, August 15, 1999 10:25 AM
Subject: Re: (usr-tc) Link dead after 8 Days

-

---

From: Tatai SV Krishnan <[email-masked]>
Date: Mon, 16 Aug 1999 18:44:20 +0000

> 1.  The problem cannot be replicated/reproduced on demand.
Good that is nice - we can have it reproduce on demand

> 2.  The versions of code: HiPer DSP: 1.2.59, HiPer ARC: 4.1.59, NMC:5.5.5

I would suggest the latest DSP code, 1.2.59 DSP code is really old and 
had some issues - you need the latest 2.0.x code.

> (850-337-016), we have a locked up system right now.
I would be more than willing to call you but the above phone number is 
not correct.  
Send me the correct the number.

krish

-

---

From: Ken Kirchner <[email-masked]>
Date: Mon, 16 Aug 1999 19:34:51 +0000

> Good that is nice - we can have it reproduce on demand

uh, what?  We have also had ISDN issues since our last upgrade.  I have a
NetGear RT-328 at the house, and while I cant make it lock up on demand,
if my roomate and I pound on it for a half-hour or so with two
simultaneous sessions of "Half-Life TFC" it will usually happen.  I am
bringing home a modem so I can log in and see whats happened to the
session tonight.

> had some issues - you need the latest 2.0.x code.

We are using:

HDM: 2.0.81
ARC: 4.1.59-6
NMC: 6.2.17

So I doubt 2.0.81 will help.  The main reason we jumped to 2.0.81 was
because 1.2.37 caused authentication problems with our Mac users.  Fix one
thing, break another. :)

> > Krish was the first real help I've gotten.

Well, thankfully Krish is here now.  I hope we can give him something to
work with.

> > (850-337-016), we have a locked up system right now.

We have not tried the MTU option.  I want to make sure it's not my
Netgear first.  Don't get me wrong, we have a lot of ISDN customers
complaining, but I've had compression turned on recently, and now that
it's off, I want to make sure that isnt what was choking the router.  The
router, when first recieved and brought on-line (around September of last
year) worked flawlessly (with out compression) until 2.0.81.  AFAIK it was
screwing up before I played with compression.

Krish, what commands would be most beneficial for me to run for your
troubleshooting efforts?  (from the ARC or HDM? Both?)

  ___                                                         ___
 (___) Kenneth Kirchner    .o.  mailto:[email-masked]       (___)  
  (__) Asst SysAdmin       .o.  Voice (318) 222-2638 Ext 108 (__)
   (_) ShreveNet, Inc.     .o.  Fax   (318) 213-6612         (_)

-

---

From: Tatai SV Krishnan <[email-masked]>
Date: Mon, 16 Aug 1999 20:57:00 +0000

> bringing home a modem so I can log in and see whats happened to the

I have not seen this problem nor have heard from anyone - A few days ago 
I came to know about this - may be I missed this list or something.  As 
far as ISDN goes - I used it - have a nailedup connection with our 
chassis here and have never seen the problem - I do use some of the same 
TA's mentioned in the problem.

> because 1.2.37 caused authentication problems with our Mac users.  Fix one
Got to disagree with this.  2.0.81 has more fixes in terms of packet bus 
issues and features.  Yes 1.2.37 is very close but does not have the same 
type of feature set.  

> troubleshooting efforts?  (from the ARC or HDM? Both?)
So the problem is there irrespective of compression enabled or not correct?
If so are you also have the same problem where you cannot browse (send 
http data) but can use pings etc?  If that is the case first in order to 
reproduce the problem faster I would recommend setting the mtu for the 
user at a low value like 576 and then disable tcp header compression.

If you have a setup where the problem is currently happening send me 
note, will be glad to take a look at it.

krish

-

---

From: "Clint R. Sparks" <[email-masked]>
Date: Mon, 16 Aug 1999 23:30:29 +0000

Krish,

Since you seem to be so helpful with the total control stuff, I wanted to
ask you a couple of questions. We use the total control Hiper DSP  -  Hiper
Arc version using Hiper DSP code 1.2.43 and Hiper Arc code 4.1.59-6, we ran
into a problem last week where two modems on our 3rd card decided to stop
letting people in, it would answer then have a strange handshaking tone and
disconnect the customer. I tried resetting the two modems numerous times
with no luck so I busied them out until I could look into it more, the next
day when the modems before the busied ones got to them we got a busy on that
number, there was still plenty of modems available after the two busied
ones. I ended up doing a Hardware Reset of the whole card and the two
previously bad modems started working again and we have not had a problem in
the last few days.

I guess my question is can you explain why the modems would quit working and
why we were getting busies after I did a soft busy of the two bad modems?

Also, what Hiper DSP and Hiper Arc code do you recommend running right now?

Any insight you can give would be appreciated.

Thank you,

Clint R. Sparks
ComQuest Internet Services
[email-masked]

----- Original Message -----
From: Tatai SV Krishnan <[email-masked]>
To: Sam Lowe <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, August 15, 1999 11:29 PM
Subject: Re: (usr-tc) Link dead after 8 Days

-

---

From: Ken Kirchner <[email-masked]>
Date: Tue, 17 Aug 1999 00:06:39 +0000

> TA's mentioned in the problem.

Nailing up both channels seems to keep things in harmony for longer
periods, but using a BOD set-up like I used to caused problems a lot more
often.

> issues and features.  Yes 1.2.37 is very close but does not have the same 

No argument there.  I like the telnet to the HDM feature of the 2.x.x
code.  What I meant was that his upgrading to 2.0.81 probably wouldnt help
his ISDN problem (at least judging from what I am experiencing).  Not that
he shouldnt try.

> So the problem is there irrespective of compression enabled or not correct?

Yes, I believe that to be the case.

> user at a low value like 576 and then disable tcp header compression.

When this happens to me I experience "router death".  I cant go anywhere
through any TCP port.  No web, no mail, no telnet.  I can run around fine
on the lan of course, and telnet into the router, but thats it.  Turning
off the router is the only way to unlock it.  Like I said before, I am
still at the stage of determining if it's my router or it's the TC box.
One would think that if it was the TC box, I could simply drop both
channels and reconnect, problem corrected, but I dont believe this is the
case.  I will post my observations later this evening.  I have re-software
downloaded the router once already with no effect.  Like I said, this was
not an issue until our last upgrade to the TC box.  I will try the MTU
fix.  There is no option I can find for header compression on the Netgear
so I will have to disable it on the arc.  When I refer to compression I am
referring to STAC which I believe is packet data only.  I could be wrong.

That being said, the largest part of our customers problems seem to occur
when they are bringing up the B2 channel.  If it works, everything goes
ok, if it doesnt, the packets stop until the B2 channel times out (BOD
causes it to drop due to 0% utilization) and things start up once again on
the B1 channel.  Of course this causes a flood on the B1 which causes B2
to re-kick in and hopefully this time it gets a good connect.  if not, we
repeat the time-out again...  When I was using BOD, this is also what I
experienced.  This is from Netgears, 3Com IQ modems, Pipelines, etc.

> note, will be glad to take a look at it.

I will definately keep you posted.

-Ken
  ___                                                         ___

-

---

From: Tatai SV Krishnan <[email-masked]>
Date: Tue, 17 Aug 1999 05:42:13 +0000

> why we were getting busies after I did a soft busy of the two bad modems?

The modems and the hiper arc use a packet bus protocol to communicate.  
This protocol is set upon reset by the modem/hiper arc.  The hiper arc 
tells the modem to set itself on the packet bus and the modems agree.  
The hiper arc talks to the modem periodically.  So does the modem also.  
However there could be a state when the modem stops talking to the hiper 
arc - at that point one of them have to reset and re-sync.  

The modem in question here has 1.2.4x code which has some issues with the 
packet bus - where in if the hiper arc does not get a response or if the 
modem sends bad corruptted data the hiper arc could remove it from 
service.  The only way to recover that was to either reboot the DSP or 
the hiper arc sometimes both.  This issues was resolved in the 1.2.37 and 
2.x code on the DSP and on 4.1.59 code on the hiper arc.

> Also, what Hiper DSP and Hiper Arc code do you recommend running right now?
4.1.59 or above on the hiper arc 2.0.81 or above on the DSP

regards

krish

-

---

From: Tatai SV Krishnan <[email-masked]>
Date: Tue, 17 Aug 1999 05:43:03 +0000

> referring to STAC which I believe is packet data only.  I could be wrong.
STac is what I was talking about also.

> experienced.  This is from Netgears, 3Com IQ modems, Pipelines, etc.

I use Ascend, 3com and Cisco to the most part, I have not seen any 
problems with Cisco (1000 and 760) Ascend Pipelines - 3com lan modem 
etc.  Netgear Have not tried to get a nailed up connection but will.
All the info here suggest that the problem happens only to tcp - 
disabling header compression - Does it help?

krish

-

---

From: Paul Farber <[email-masked]>
Date: Tue, 17 Aug 1999 06:45:44 +0000

I am using a netgear RT328 to dial into a Courier I modem and experience
the same problem.  I think the Netgear gear has a problem with not keeping
NAT mappings or some such thing.

I message to netgear tech got me a "reload the flash".. not to helpful.
It's not your DSP's... its the Netgear.

I have a 3Com OfficeConnect also that dials into the DSP's..... will run
fine for days then the B's wont come up.  Reboot the OfficeConnect (or
simple DROP the B's manually and your back in business).

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

-

---

From: Ken Kirchner <[email-masked]>
Date: Fri, 20 Aug 1999 00:36:25 +0000

> NAT mappings or some such thing.

It's possible, but this only happened recently.  I've been using the v1.50
code on the Netgear for quite awhile with no problem.

> It's not your DSP's... its the Netgear.

Like a mentioned above, why now?

> simple DROP the B's manually and your back in business).

So you just accept this? :)

  ___                                                         ___

-

---

From: Paul Farber <[email-masked]>
Date: Fri, 20 Aug 1999 15:38:56 +0000

Nothing can be done.  The DSP's have problems.  I can't expect a customer
to allow me to tinker with the the setup and run up their ISDN bill so I
can "see if I can get it to work".

THese are not leased lines, so I just explained that line drops are to be
expected.  Some people have them others don't.  I have one business
customer up for weeks using a BOCA 33.6 calling into another BOCA 33.6.  
But the OfficeConnect will not reliably call into the TC chassis.  One
vendor has it right (BOCA) the other one (3Com) dosen't.

They are still much happier now then with thier other ISP..... they value
the serivce more than the internet conncetion.

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

-