Subject: (usr-tc) TCPIP Stall

From: Scot Desort <[email-masked]>
Date: Fri, 26 May 2000 23:43:22 +0000

We are running DSP's with 2.0.51 software. We have had 2 customers in the
past 3 weeks with this issue. They connect to us just fine. If they simply
connect and do nothing else, their connection  is stable. We can ping back
and forth. They then launch a TCPIP application like IE. Sometimes
immediately, other times after several minutes, their connection simply
stalls. All data traffic stops. They can no longer ping. Even if they close
the app, the ability to send traffic does not return.

Happens with IE, netscape, OE. Installed latest IE5 and reset all browser
defaults.

Customers both have different modems. One runs Win98, the other Win98SE.

One has AOL5, the other doesn't. Tried disabling AOL Dialup Adapter. Removed
extra occurences of wsock.vxd in the AOL directories. Removed TCPIP and DUN
and reinstalled. Cannot pin this problem down.

Might now be related to the DSP's at all, but I figured I'd give this list a
shot. Maybe someone else has run across this problem. Any ideas?

--
Regards,

Scot

-
 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: V <[email-masked]>
Date: Sat, 27 May 2000 00:00:31 +0000

The problem has nothing to do with DSP code, need to know the version of
Hiper arc code, and also
would need traces.  Mon PPP on the user when connected will show some info
to begin with.

-V

->-----Original Message-----
->From: [email-masked]
->[mailto:[email-masked]]On Behalf Of Scot Desort
->Sent: Friday, May 26, 2000 4:44 PM
->To: [email-masked]
->Subject: (usr-tc) TCPIP Stall
->
->
->We are running DSP's with 2.0.51 software. We have had 2 customers in the
->past 3 weeks with this issue. They connect to us just fine. If they simply
->connect and do nothing else, their connection  is stable. We can ping back
->and forth. They then launch a TCPIP application like IE. Sometimes
->immediately, other times after several minutes, their connection simply
->stalls. All data traffic stops. They can no longer ping. Even if
->they close
->the app, the ability to send traffic does not return.
->
->Happens with IE, netscape, OE. Installed latest IE5 and reset all browser
->defaults.
->
->Customers both have different modems. One runs Win98, the other Win98SE.
->
->One has AOL5, the other doesn't. Tried disabling AOL Dialup
->Adapter. Removed
->extra occurences of wsock.vxd in the AOL directories. Removed
->TCPIP and DUN
->and reinstalled. Cannot pin this problem down.
->
->Might now be related to the DSP's at all, but I figured I'd give
->this list a
->shot. Maybe someone else has run across this problem. Any ideas?
->
->--
->Regards,
->
->Scot
->
->
->
->
->-
-> 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: "Clint R. Sparks" <[email-masked]>
Date: Sat, 27 May 2000 00:12:45 +0000

We had this problem as well a couple of months ago using 2.0.51 on our
DSP's, I spoke with 3 Com and another ISP about it and they said they had
been hearing of some issues with the stalling with 2.0.51 so they suggested
going back to 2.0.60 which we did and no more complaints or problems with
stalling since switching back to 2.0.60.

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

----- Original Message -----
From: "Scot Desort" <[email-masked]>
To: <[email-masked]>
Sent: Friday, May 26, 2000 4:44 PM
Subject: (usr-tc) TCPIP Stall

-

---

From: "Clint R. Sparks" <[email-masked]>
Date: Sat, 27 May 2000 00:18:27 +0000

I disagree it does have to do with the DSP code 2.0.51 on certain telco
switch equipment as we were having similar problems and went back to 2.0.60
and no more stalling, all the customers that were complaining about it said
it was then fine and none have complained about it since, and the only thing
we switched was the Hiper DSP code from 2.0.51 to 2.0.60. We are running
Hiper ARC code 4.1.59-6. Also 3 Com has told me that they are seeing
complaints specifically from those running 2.0.51 and customers complaining
about stalling, they were not sure what was causing it when I spoke to them
but they did say it was related to DSP code 2.0.51.

Clint R. Sparks

----- Original Message -----
From: "V" <[email-masked]>
To: <[email-masked]>
Sent: Friday, May 26, 2000 5:03 PM
Subject: RE: (usr-tc) TCPIP Stall

-

---

From: V <[email-masked]>
Date: Sat, 27 May 2000 06:04:35 +0000

I can only think of Async Map causing issues if any.  However that would be
only with certain modems  if at all.
Who in 3com told you about issues with 2.0.51?  2.0.51 was the only code
with good fixes for
MFP problem.  We do not have any issues with 2.0.51 - did have MFP issues
with 2.0.60.

If the user/DSP async map has issues data could stall, the easy way to see
if this is the problem is to
disable ppp offloading. That would have the hiper arc do the async map.,
that may be a clue.

However you do need to take a trace also to make sure that data is being
delivered - A mon ppp
would also show if there is a PPP async issue.

- V

->-----Original Message-----
->From: [email-masked]
->[mailto:[email-masked]]On Behalf Of Clint R. Sparks
->Sent: Friday, May 26, 2000 5:17 PM
->To: [email-masked]
->Subject: Re: (usr-tc) TCPIP Stall
->
->
->I disagree it does have to do with the DSP code 2.0.51 on certain telco
->switch equipment as we were having similar problems and went back
->to 2.0.60
->and no more stalling, all the customers that were complaining
->about it said
->it was then fine and none have complained about it since, and the
->only thing
->we switched was the Hiper DSP code from 2.0.51 to 2.0.60. We are running
->Hiper ARC code 4.1.59-6. Also 3 Com has told me that they are seeing
->complaints specifically from those running 2.0.51 and customers
->complaining
->about stalling, they were not sure what was causing it when I
->spoke to them
->but they did say it was related to DSP code 2.0.51.
->
->Clint R. Sparks
->ComQuest Internet Services
->[email-masked]
->
->
->----- Original Message -----
->From: "V" <[email-masked]>
->To: <[email-masked]>
->Sent: Friday, May 26, 2000 5:03 PM
->Subject: RE: (usr-tc) TCPIP Stall
->
->
->> The problem has nothing to do with DSP code, need to know the version of
->> Hiper arc code, and also
->> would need traces.  Mon PPP on the user when connected will
->show some info
->> to begin with.
->>
->> -V
->>
->> ->-----Original Message-----
->> ->From: [email-masked]
->> ->[mailto:[email-masked]]On Behalf Of Scot Desort
->> ->Sent: Friday, May 26, 2000 4:44 PM
->> ->To: [email-masked]
->> ->Subject: (usr-tc) TCPIP Stall
->> ->
->> ->
->> ->We are running DSP's with 2.0.51 software. We have had 2 customers in
->the
->> ->past 3 weeks with this issue. They connect to us just fine. If they
->simply
->> ->connect and do nothing else, their connection  is stable. We can ping
->back
->> ->and forth. They then launch a TCPIP application like IE. Sometimes
->> ->immediately, other times after several minutes, their
->connection simply
->> ->stalls. All data traffic stops. They can no longer ping. Even if
->> ->they close
->> ->the app, the ability to send traffic does not return.
->> ->
->> ->Happens with IE, netscape, OE. Installed latest IE5 and reset all
->browser
->> ->defaults.
->> ->
->> ->Customers both have different modems. One runs Win98, the
->other Win98SE.
->> ->
->> ->One has AOL5, the other doesn't. Tried disabling AOL Dialup
->> ->Adapter. Removed
->> ->extra occurences of wsock.vxd in the AOL directories. Removed
->> ->TCPIP and DUN
->> ->and reinstalled. Cannot pin this problem down.
->> ->
->> ->Might now be related to the DSP's at all, but I figured I'd give
->> ->this list a
->> ->shot. Maybe someone else has run across this problem. Any ideas?
->> ->
->> ->--
->> ->Regards,
->> ->
->> ->Scot
->> ->
->> ->
->> ->
->> ->
->> ->-
->> -> 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: Paul Farber <[email-masked]>
Date: Sat, 27 May 2000 18:54:17 +0000

Wasn't .51 just an engineering patch to correct a bad batch of DSP's?

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

-

---

From: "Clint R. Sparks" <[email-masked]>
Date: Sun, 28 May 2000 00:26:39 +0000

Yes I believe so but there is something wrong with it as far as stalling
connections goes. The DSP's we were having this problem with have PRI's
coming from a GTE GTD5 switch. We have DSP's at another POP that is
Ameritech using a 5ESS switch and running 2.0.51 with no problems. When we
were using 2.0.51 on the GTD5 switch we started noticing an increase to the
point of 10 to 15 complaints a day of stalling connections, I spoke with 3
Com and another ISP having similar problems and the consensus was to go back
to 2.0.60 which we did and all of the sudden no more stalling complaints. We
did nothing more that go back to 2.0.60 and we did not change any settings
in the DSP cards. It is strange I will grant you but it worked for us and
our customers quit having problems and were happy again so that was enough
for me and we have not noticed any other problems with 2.0.60.

Clint R. Sparks

----- Original Message -----
From: "Paul Farber" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, May 27, 2000 11:59 AM
Subject: Re: (usr-tc) TCPIP Stall

> > > ->We are running DSP's with 2.0.51 software. We have had 2 customers
in
> > the
> > > ->connect and do nothing else, their connection  is stable. We can
ping
> > back

-

---

From: Scot Desort <[email-masked]>
Date: Sun, 28 May 2000 20:04:56 +0000

ppp mon trace was the next thing I was going to do with the customer when
they call back. We have a few .54 DSP cards, so I need to have 2051 running.

Funny that this just started happening in the past 3 weeks. Only to 2
customers. And we've been running 2.0.51 since a week after it released
(December?).

--
Scot

----- Original Message -----
From: Clint R. Sparks <[email-masked]>
To: <[email-masked]>
Sent: Friday, May 26, 2000 6:11 PM
Subject: Re: (usr-tc) TCPIP Stall

> > Might now be related to the DSP's at all, but I figured I'd give this
list
> a

-

---

From: [email-masked]
Date: Tue, 30 May 2000 03:33:02 +0000

Scot,

I've seen the same behavior when one end has IP header compression 
turned on and the other end doesn't (i.e. you and the customer).  That's 
our #1 problem with folks seeing slow or non-existent throughput.

Jeff Binkley
ASA Network Computing

U>ppp mon trace was the next thing I was going to do with the customer
U>when they call back. We have a few .54 DSP cards, so I need to have
U>2051 running.

U>Funny that this just started happening in the past 3 weeks. Only to 2
U>customers. And we've been running 2.0.51 since a week after it
U>released (December?).

U>--
U>Scot

U>----- Original Message -----
U>From: Clint R. Sparks <[email-masked]>
U>To: <[email-masked]>
U>Sent: Friday, May 26, 2000 6:11 PM
U>Subject: Re: (usr-tc) TCPIP Stall

U>> We had this problem as well a couple of months ago using 2.0.51 on
U>> our DSP's, I spoke with 3 Com and another ISP about it and they said
U>> they had been hearing of some issues with the stalling with 2.0.51
U>so they suggested
U>> going back to 2.0.60 which we did and no more complaints or problems
U>> with stalling since switching back to 2.0.60.
U>>
U>> Clint R. Sparks
U>> ComQuest Internet Services
U>> [email-masked]
U>>
U>>
U>> ----- Original Message -----
U>> From: "Scot Desort" <[email-masked]>
U>> To: <[email-masked]>
U>> Sent: Friday, May 26, 2000 4:44 PM
U>> Subject: (usr-tc) TCPIP Stall
U>>
U>>
U>> > We are running DSP's with 2.0.51 software. We have had 2 customers
U>in the
U>> > past 3 weeks with this issue. They connect to us just fine. If
U>they simply
U>> > connect and do nothing else, their connection  is stable. We can
U>ping back
U>> > and forth. They then launch a TCPIP application like IE. Sometimes
U>> > immediately, other times after several minutes, their connection
U>> > simply stalls. All data traffic stops. They can no longer ping.
U>> Even if they close
U>> > the app, the ability to send traffic does not return.

U>> > Happens with IE, netscape, OE. Installed latest IE5 and reset all
U>browser
U>> > defaults.

U>> > Customers both have different modems. One runs Win98, the other
U>> >Win98SE. 

U>> > One has AOL5, the other doesn't. Tried disabling AOL Dialup
U>> Adapter. Removed
U>> > extra occurences of wsock.vxd in the AOL directories. Removed
U>> TCPIP and DUN
U>> > and reinstalled. Cannot pin this problem down.

U>> > Might now be related to the DSP's at all, but I figured I'd give
U>this list
U>> a
U>> > shot. Maybe someone else has run across this problem. Any ideas?

U>> > --
U>> > Regards,

U>> > Scot

U>> > -
U>> >  To unsubscribe to usr-tc, send an email to
U>> >  "[email-masked]" with "unsubscribe usr-tc" in the body of
U>> >  the message. For information on digests or retrieving files and
U>> >  old messages send "help" to the same address.  Do not use quotes
U>> >in your message. 

U>>
U>>
U>> -
U>>  To unsubscribe to usr-tc, send an email to "[email-masked]"
U>>  with "unsubscribe usr-tc" in the body of the message.
U>>  For information on digests or retrieving files and old messages
U>>  send "help" to the same address.  Do not use quotes in your
U>message. >

U>-
U> To unsubscribe to usr-tc, send an email to "[email-masked]"
U> with "unsubscribe usr-tc" in the body of the message.
U> For information on digests or retrieving files and old messages send
U> "help" to the same address.  Do not use quotes in your message.

CMPQwk 1.42-21 9999

-