Subject: RE: (usr-tc) Dropped connections for 2nd login with same login ID . MPPP weird thing?

From: Scott Trautman <[email-masked]>
Date: Tue, 23 Nov 1999 16:27:38 +0000

Okay! Ask ye for a mon ppp, gets ye a mon ppp:

slot:14/mod:17 is the already-logged-on session
slot:14/mod:9  is the new session that (per below), gets the PAP ACK then
boom, dropped,
no more PPP messages about it. What does the IP_DATA mean for the other?
Same message
over and again, before and after the event.

So is the dropping of the connection a "non PPP" event? Like the ARC taking
a whack at it? The disconnection reason, shown by RADIUS, is LOST_CARRIER,
which of course means any 
number of things, rarely that <we> dropped them in any administrative way.

Any clues? god save me to call into 3Com support on this one; I may open the
ticket and
try King George directly.

Man, I don't know what more data possibly could be gotten other than what
I've got here.
Other than duplicating it at another site. Which we review each day from
customers as
not happening anywhere else.

...related perhaps; anyone have a quick way to read out the entire config of
an ARC?
If I can do that quick I can look for any setting changes with diff between
the two.

SMT

>>>>>>>Output of mon ppp<<<<<<<<<<<<

 Monitor a specific user

 Enter the user name to monitor below:
     Press Escape to return to the previous screen.
     Press Enter/Return to enter the name.

 User Name: [Pstandish                       ]
 Monitoring user Pstandish.
Decode tracing started, press ESCAPE to stop; press X for hex tracing.

Incoming PPP Data on interface: slot:14/mod:17 
    IP_DATA    45 00 00 4e ca 3b 00 00 80 11 7e 5a 9c 2e b9 ac 9c 2e ff ff
...

Incoming PPP Data on interface: slot:14/mod:17 
    IP_DATA    45 00 00 4e cb 3b 00 00 80 11 7d 5a 9c 2e b9 ac 9c 2e ff ff
...

Incoming PPP Data on interface: slot:14/mod:17 
    IP_DATA    45 00 00 4e cc 3b 00 00 80 11 7c 5a 9c 2e b9 ac 9c 2e ff ff
...

########################This is it for this session! Boom!
Dropped!############
Outgoing PPP Data on interface: slot:14/mod:9 
    PAP        ACK               
Incoming PPP Data on interface: slot:14/mod:17 
    IP_DATA    45 00 01 82 d4 3b 00 00 80 11 73 26 9c 2e b9 ac 9c 2e ff ff
...

Incoming PPP Data on interface: slot:14/mod:17 
    IP_DATA    45 00 00 4e d6 3b 00 00 80 11 72 5a 9c 2e b9 ac 9c 2e ff ff
...

Incoming PPP Data on interface: slot:14/mod:17 
    IP_DATA    45 00 00 4e d8 3b 00 00 80 11 70 5a 9c 2e b9 ac 9c 2e ff ff
...

Incoming PPP Data on interface: slot:14/mod:17 
    IP_DATA    45 00 00 4e da 3b 00 00 80 11 6e 5a 9c 2e b9 ac 9c 2e ff ff
...

Incoming PPP Data on interface: slot:14/mod:17 
    IP_DATA    45 00 00 4e db 3b 00 00 80 11 6d 5a 9c 2e b9 ac 9c 2e ff ff
...

Incoming PPP Data on interface: slot:14/mod:17 
    IP_DATA    45 00 00 4e dc 3b 00 00 80 11 6c 5a 9c 2e b9 ac 9c 2e ff ff
...

Incoming PPP Data on interface: slot:14/mod:17 
    IP_DATA    45 00 00 4e dd 3b 00 00 80 11 6b 5a 9c 2e b9 ac 9c 2e ff ff
...

Incoming PPP Data on interface: slot:14/mod:17 
    IP_DATA    45 00 01 82 ed 3b 00 00 80 11 5a 26 9c 2e b9 ac 9c 2e ff ff
...

Incoming PPP Data on interface: slot:14/mod:17 
    IP_DATA    45 00 00 4e ef 3b 00 00 80 11 59 5a 9c 2e b9 ac 9c 2e ff ff
...

Incoming PPP Data on interface: slot:14/mod:17 
    IP_DATA    45 00 00 4e f1 3b 00 00 80 11 57 5a 9c 2e b9 ac 9c 2e ff ff
...

Incoming PPP Data on interface: slot:14/mod:17 
    IP_DATA    45 00 00 4e f3 3b 00 00 80 11 55 5a 9c 2e b9 ac 9c 2e ff ff
...

Incoming PPP Data on interface: slot:14/mod:17 
    IP_DATA    45 00 00 4e f4 3b 00 00 80 11 54 5a 9c 2e b9 ac 9c 2e ff ff
...

Incoming PPP Data on interface: slot:14/mod:17 
    IP_DATA    45 00 00 4e f5 3b 00 00 80 11 53 5a 9c 2e b9 ac 9c 2e ff ff
...

Incoming PPP Data on interface: slot:14/mod:17 
    IP_DATA    45 00 00 4e f6 3b 00 00 80 11 52 5a 9c 2e b9 ac 9c 2e ff ff
...

Incoming PPP Data on interface: slot:14/mod:17 
    IP_DATA    45 00 01 82 fe 3b 00 00 80 11 49 26 9c 2e b9 ac 9c 2e ff ff
...

Incoming PPP Data on interface: slot:14/mod:17 
    IP_DATA    45 00 00 4e 00 3c 00 00 80 11 48 5a 9c 2e b9 ac 9c 2e ff ff
...

Incoming PPP Data on interface: slot:14/mod:17 
    IP_DATA    45 00 00 4e 02 3c 00 00 80 11 46 5a 9c 2e b9 ac 9c 2e ff ff
...

Incoming PPP Data on interface: slot:14/mod:17 
    IP_DATA    45 00 00 4e 04 3c 00 00 80 11 44 5a 9c 2e b9 ac 9c 2e ff ff
...

Incoming PPP Data on interface: slot:14/mod:17 
    IP_DATA    45 00 00 4e 05 3c 00 00 80 11 43 5a 9c 2e b9 ac 9c 2e ff ff
...

Incoming PPP Data on interface: slot:14/mod:17 
    IP_DATA    45 00 00 4e 06 3c 00 00 80 11 42 5a 9c 2e b9 ac 9c 2e ff ff
...

Incoming PPP Data on interface: slot:14/mod:17 
    IP_DATA    45 00 00 4e 07 3c 00 00 80 11 41 5a 9c 2e b9 ac 9c 2e ff ff
...

-----Original Message-----
From: Tatai SV Krishnan [mailto:[email-masked]]
Sent: Saturday, November 20, 1999 9:16 PM
To: Scott Trautman
Cc: [email-masked]'; [email-masked]';
[email-masked]'
Subject: Re: (usr-tc) Dropped connections for 2nd login with same login
ID. MPPP weird thing?

On Fri, 19 Nov 1999, Scott Trautman wrote:

> Hi-
>  
> Okay, I am really stumped. As I'm sure most of you do, we have customers
> that have one login in use by more than one connection at a time, and not
> Multilink PPP, but separate connections. In all our locations but one, we
> haven't heard of any problems. In our one location, the first one logs on
> fine (Pstandish), then anyone after that on the SAME unit logging in as
> Pstandish, will authenticate just fine, then be dropped with:
>  
> Nov 19 11:16:10 lkm-ha1 At 17:16:09, Facility "Auth Facility", Level
> "COMMON":: Port slot:14/mod:3 successful RADIUS authentication for user:
> Pstandish
> Nov 19 11:16:13 lkm-ha1 At 17:16:12, Facility "Auth Facility", Level
> "COMMON":: The connection for call id 218234989, on if slot:14/mod:3 was
> dropped for user UNKNOWN

The first tell clearly talks about the user - The second one talks about 
user unknown - clearly some where in the mean time the hiper arc has lost 
the user info for some reason.  All there should be some other messages 
in the same seqence which will talk about call id -218234989  - looking 
at them could be of some use.

>  
> It's like it's sitting there trying to negotiate something it can't and
> hangs up. There's nothing weird in HiperARC's that has some knowledge of a
> given login ID (Pstandish), and as it sees the next one trying to login,
> hey, they must want MPPP, why don't I start the LCP negotiation for that?
I
> don't know this to be fact, It's just conjecture at this point. It
> definately authenticates, but doesn't assign an IP and drive on, it drops
> the connection for UNKNOWN (which is tre' odd...it isn't unknown...)
>  
Do you have MPIP setup?  If you do them dropping the user make sense, 
else if its plain MPPP then unless and untill the user has been setup for 
port limit or for max challenels with a limit of 1 dropping the user does 
not make sense.

> If they dial into another on of our POP's (IE, any TC unit 
other than this
> one) with same Pstandish, no problem. Next line isn't the "dropped for
user
> unknown", it's the usual...assigned IP x.x.x.x and they're fine. Have not
> tested for sure having them test the whole ball of wax at another POP, so
> can't say 100% it's just that site other than we do have lots of other
users
> using the same way and don't seem to have that problem.
>  
You need to get a mon ppp and look at the hiper arc settings first.

Get a mom ppp to start

krish

> Nope, no TSMON or anything forcing them off, it is only in the HiperARC
and
> this particular unit that it seems to be a problem. Yep, HiperARC is:
>  
> System Version:                           V4.2.32
>  
> Everything DSP, Quad, NMC, everything current as well.
>  
> Man, anyone seen anything like this?
>  
> 
> Scott Trautman           608-240-4638,4637fax
> Global Dialog Internet   www.gdinet.com
> 2810 Crossroads, STE LL2
> Madison WI 53718 
> 
>  
> 
> -
>  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: Jeff Mcadams <[email-masked]>
Date: Tue, 23 Nov 1999 16:37:27 +0000

Thus spake Scott Trautman

>slot:14/mod:17 is the already-logged-on session slot:14/mod:9  is the
>new session that (per below), gets the PAP ACK then boom, dropped, no
>more PPP messages about it. What does the IP_DATA mean for the other?
>Same message over and again, before and after the event.

IP_DATA is the actual data that is being transmitted on the PPP
link...pulling up web pages, checking email...mundane stuff like
that...not significant to your problem.

>Man, I don't know what more data possibly could be gotten other than
>what I've got here.  Other than duplicating it at another site. Which
>we review each day from customers as not happening anywhere else.

You're not going to like this, but...you need to get the LCP
negotiation, which occurs before PAP, and consequently you can't get at
with mon ppp on a username.  :/

It might be easier for you to get this log from the customer's side by
setting up a ppp log on their machine...that way you can be sure to get
the whole negotiation...not just the part after PAP.  The format will be
different, but unless its a really lame format, it should have the
information needed to figure out what's going on...or at least where we
need to look.

Oh, and you'll probably need to get ahold of the negotiation for both
channels, not just the one being dropped as some of the values in the
negotiation will need to be compared between the two.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Tatai SV Krishnan <[email-masked]>
Date: Tue, 23 Nov 1999 17:36:16 +0000

> Okay! Ask ye for a mon ppp, gets ye a mon ppp:
Good the mon ppp that you have for the user is after the start of the ppp 
call and it shows that you are passing IP data which is normal.

> number of things, rarely that <we> dropped them in any administrative way.
No you are dropping the second connection so what you need to do is 
capture the mon ppp for the next call, and get the traces like lcp and 
ipcp info ect.

> try King George directly.
Well if 3com support is not what you want then fine, I sure hope someone 
else in this list will take time to look at the issue and help you 
resolve it.  But if you want us to help you resolve the problem - open a 
ticket, and give us access to your hiper arc.

krish

-

---

From: Marcelo Souza <[email-masked]>
Date: Tue, 23 Nov 1999 17:51:01 +0000

Is there any way to block collect calls in the TC, in HARC or in
DSPs?
	The telco told me that they can't block from their side.

- Marcelo

-

---

From: Tatai SV Krishnan <[email-masked]>
Date: Tue, 23 Nov 1999 18:05:13 +0000

You can try using the DNIS/ANI based authentication.

krish

-----------------------------------------
		\	T.S.V. Krishnan  \
		 \      Network System Engineer \ ( : - : )
		  \     3Com ............   \
		----------------------------------------------/
[email-masked]  
----------------------------/ http://interproc.ae.usr.com ----/
-------------------------------------------------------------------------\
	Any Sufficiently advanced bug is indistinguishable for a feature.
						- Rick Kulawiec
-------------------------------------------------------------------------/

-

---

From: [email-masked]
Date: Tue, 23 Nov 1999 18:22:02 +0000

We are seeing times when a user is connected and all of a sudden
they loose the ability to navigate or pull email...  The connection is
stil up, but it appears that no data is being TX/RX?   Is there something
in the DSP/quads that can cause this timeout?  Is this a function of
MTU/MSS?   Or is it the fact that the HIPER ARC can't keep up with the
requests?

   Would routing protocols help this?  Right now we run a network on a
single class C with 180 dialup IPs in the modem pools.  3 HUB, two run
quads, the othe has 3 DSPs  all running HARCs and latest TC3.6 code.

  We are starting to get a lot of TIMEOUTS, the connection is never
dropped, but the modem quits responding for a time.  If left alone it will
come back to life.

  Anyone have any ideas?  Thanks in advance!

==============================================================================
Phillip Ferraro				WorldNet Access, Inc
[email-masked]	Onslow County's PREMIER InterNet Service 
Voice (910) 346-0835		    824 Gumbranch Square, Suite R3
FAX   (910) 455-1933		     Jacksonville, Nc  28540-6269
==============================================================================

-

---

From: Tatai SV Krishnan <[email-masked]>
Date: Tue, 23 Nov 1999 20:35:50 +0000

> MTU/MSS?   Or is it the fact that the HIPER ARC can't keep up with the
Well need to know the exact versions of hiper arc and DSP code to start.

krish

-

---

From: [email-masked]
Date: Tue, 23 Nov 1999 21:01:22 +0000

Krish,

 We are running the 4.1.59-6 on the HiperArc and 2.0.81 on the DSPs.  the
quads are using the 6.x.x code!

-

---

From: Scot Desort <[email-masked]>
Date: Tue, 23 Nov 1999 22:48:38 +0000

We have the *same* exact problem here. I had posted about this, and the
general thought was that it was the modems retraining. But sometimes it goes
on for close to a minute. Seems a little long for retraining. Haven't
investigated it further.

----- Original Message -----
From: <[email-masked]>
To: Tatai SV Krishnan <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, November 23, 1999 1:57 PM
Subject: (usr-tc) Re: DATA STOPS

> quads are using the 6.x.x code!
============================================================================
==
> FAX   (910) 455-1933      Jacksonville, Nc  28540-6269
============================================================================
==
> > >   Anyone have any ideas?  Thanks in advance!
============================================================================
==
> > > FAX   (910) 455-1933      Jacksonville, Nc  28540-6269
============================================================================
==

-

---

From: Tatai SV Krishnan <[email-masked]>
Date: Tue, 23 Nov 1999 23:55:17 +0000

> on for close to a minute. Seems a little long for retraining. Haven't

So in your case are you saying that - > data stops for some time and then 
you get back the data transfer?  or are you saying that - data stops. 
have to dial again to recheck mail.

please clarify

regards

krish

-

---

From: [email-masked]
Date: Tue, 23 Nov 1999 23:57:02 +0000

This is not a RETRAIN issue... The customer is actually logged in
and "surf'n", but then things SUDDENLY stop!  The length of time varies
from a few seconds to several minute... Almost like, the network is SOOOO
BUSY that it doesn't have time to answer all the queries!!   Does this
make sense?

-

---

From: Scot Desort <[email-masked]>
Date: Tue, 23 Nov 1999 23:59:37 +0000

You do not need to disconnect. Data resumes all by itself. TX/RX activity
COMPLETELY stops, then suddenly resumes. Cannot ping anywhere, not even the
TC ethernet port. Then it comes back to life. It *seems* to happen most when
the initial connect speed is "low" (below 44K or so), perhaps contributing
to the retraining theory (the slower connection may indicate more noise
present, which would leads to retrains). Never been actually cut-off as a
result of this, but sometimes it is so frustrating, that you are forced to
disconnect and redial. Then, it may be fine for hours. Weird.

-Scot

----- Original Message -----
From: Tatai SV Krishnan <[email-masked]>
To: Scot Desort <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, November 23, 1999 4:39 AM
Subject: Re: (usr-tc) Re: DATA STOPS

> > > > > dropped, but the modem quits responding for a time.  If left alone
it
> > will

-

---

From: Tatai SV Krishnan <[email-masked]>
Date: Wed, 24 Nov 1999 00:00:43 +0000

> quads are using the 6.x.x code!

So you are having this problem on both the quads?  
If this problem is easily reproduceble can you collect some mon ppp trace?

krish

-

---

From: [email-masked]
Date: Wed, 24 Nov 1999 00:12:33 +0000

EXACTLY!

-

---

From: [email-masked]
Date: Wed, 24 Nov 1999 00:12:58 +0000

It seems to be more "NOTICABLE" on the quads than the DSPs...  I
do know that When I am dialed in and I get this stall, that if I go to my
FTP program and access another server, that the connnection syncs back up
and things start working properly again...  Almost like it gets stuck and
then needs a nudge to get it going!

-

---

From: Aaron Nabil <[email-masked]>
Date: Wed, 24 Nov 1999 00:13:45 +0000

Marcelo Souza writes...
>Is there any way to block collect calls in the TC, in HARC or in DSPs?

Call the business office, tell them you want "Billed number screening",
and that you want "no collect" and "no third-party".

-- 
Aaron Nabil

-

---

From: Tatai SV Krishnan <[email-masked]>
Date: Wed, 24 Nov 1999 00:50:56 +0000

> TC ethernet port. Then it comes back to life. It *seems* to happen most when

So even the hiper arc stops sending data out of its ethernet port at this 
time?  This is the first instance I am hearing about this.  We can run a 
debug and see what is happeing and why it is happening.  Are you using 
4.1.59 code also?  

krish

-

---

From: Marius Strom <[email-masked]>
Date: Wed, 24 Nov 1999 00:55:09 +0000

I believe he means the CUSTOMER cannot ping the TC Ethernet port, or at
least this is what happens to us.  It's not analog customers only, because
we've had it happen with ISDN customers as well.

-- 
Marius Strom <[email-masked]>
Professional Geek/Unix System Administrator
Alpha1 Internet <http://www.alpha1.net>
http://www.marius.org/marius.pgp 0x5645C228

In theory, there is no difference between theory and practice...
...In practice, there is a big difference.

-

---

From: Scot Desort <[email-masked]>
Date: Wed, 24 Nov 1999 01:12:04 +0000

Yes, that's what I meant. I used "I" because "I" have personally experienced
it when I dial into the system from home, as well as several of my techs.
All with different modems.

Don't think it happens with ISDN, but I'll check.

And, yes, we are running 4.1.59

-Scot

----- Original Message -----
From: Marius Strom <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, November 23, 1999 5:50 PM
Subject: Re: (usr-tc) Re: DATA STOPS

> > > > > general thought was that it was the modems retraining. But
sometimes it
> > > goes
> > > > > >  We are running the 4.1.59-6 on the HiperArc and 2.0.81 on the
DSPs.
> > > the
> > > > > > > > stil up, but it appears that no data is being TX/RX?   Is
there
> > > > > something
> > > > > > > > in the DSP/quads that can cause this timeout?  Is this a
function
> > > of
> > > > > > > > MTU/MSS?   Or is it the fact that the HIPER ARC can't keep
up with
> > > the
> > > > > > > > requests?
> > > > > > > Well need to know the exact versions of hiper arc and DSP code
to
> > > start.
> > > > > > >
> > > > > > > krish
> > > > > > >
> > > > > > > >
> > > > > > > >    Would routing protocols help this?  Right now we run a
network
> > > on a
> > > > > > > > single class C with 180 dialup IPs in the modem pools.  3
HUB, two
> > > run
> > > > > > > > quads, the othe has 3 DSPs  all running HARCs and latest
TC3.6
> > > code.
> > > > > > > >
> > > > > > > >   We are starting to get a lot of TIMEOUTS, the connection
is
> > > never

-

---

From: [email-masked]
Date: Wed, 24 Nov 1999 01:27:42 +0000

Can someone tell me how to change the telnet password on s USR?

Thanks 

Vito

----------------------------
Click on the link below to get
paid to use a browser:
http://www.gotoworld.com/getpaid/default.asp?rid=1030553292

-

---

From: Tatai SV Krishnan <[email-masked]>
Date: Wed, 24 Nov 1999 17:21:10 +0000

> And, yes, we are running 4.1.59

Which version of DSP code are you using?  Also is this happening with a 
particular client?  The reason I bring up client is to understand the 
type of compression that is being used here.

regards

krish

-

---

From: Kevin Benton <[email-masked]>
Date: Wed, 24 Nov 1999 22:23:43 +0000

> disconnect and redial. Then, it may be fine for hours. Weird.

Krish - this seems to be a lot like the issue we're having with
cambcity...  Please talk to Sanjay / Tom Cwikala about it.  All of the
sudden, routing stops.  The problem is, in our case, however, that routing
stops all together and it doesn't recover.  It just so happens that the
customer equip. is a Bay Networks Instant Internet 400 though and they
can't route at all once it stops dead like that - no recovery.  I don't
have the case numbers in front of me (sorry).

Kevin

> > > > quads are using the 6.x.x code!

E-Mail:  [email-masked]
Web:     http://users.sota-oh.com/~s1kevin/
Unsolicited advertisements processing fee: $50 subject to change without notice

-

---

From: [email-masked]
Date: Wed, 24 Nov 1999 22:40:00 +0000

Ditto, except I have a Bay Networks ISDN T/A R235(?)  Usually needs a
reboot 2/3 times a week.

Turning off van-jacobson compression kinda helped, so did sending RIP
broadcasts to the unit.

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

-

---

From: Tatai SV Krishnan <[email-masked]>
Date: Wed, 24 Nov 1999 23:13:21 +0000

> have the case numbers in front of me (sorry).

Your issue with Bay networks is a problem where the packet bus connection 
with the hiper arc - hdm actually fails and the hdm stops talking over 
the packet bus to the hiper arc.  That problem is unique to hiper 
dsp/bay. In your case the connection is still up but no data comes up 
on the packet bus to the hiper arc at all.  I know Tom is working the 
issue. However the problem here that I have heard so far differs -
There are two cases

1. Problem occours with both Quad and HDM on the hiper arc
2. Generally there is stop gap and data transfer resumes.

There is no indication of packet bus problems ( we would need to 
investigate however).  The problem with Bay is one of its kind, I have 
not seen or anything similar.  HOwever the people of this list can 
correct if they do see a packet bus problem or a case where the hiper arc 
looses the modem after the call.

regards

krish

-

---

From: Marcelo Souza <[email-masked]>
Date: Thu, 25 Nov 1999 13:58:18 +0000

On Mon, 22 Nov 1999, Tatai SV Krishnan wrote:

|You can try using the DNIS/ANI based authentication.

	To use this I will need to ask the telco to send the entire number
of DNIS right? Nowadays, they only send 4 digits to me.

- Marcelo

|krish
|
|-----------------------------------------
|		\	T.S.V. Krishnan  \
|		 \      Network System Engineer \ ( : - : )
|		  \     3Com ............   \
|		----------------------------------------------/
[email-masked]  
|----------------------------/ http://interproc.ae.usr.com ----/
|-------------------------------------------------------------------------\
|	Any Sufficiently advanced bug is indistinguishable for a feature.
|						- Rick Kulawiec
|-------------------------------------------------------------------------/
|
|On Tue, 23 Nov 1999, Marcelo Souza wrote:
|
|> 
|> 	Is there any way to block collect calls in the TC, in HARC or in
|> DSPs?
|> 	The telco told me that they can't block from their side.
|> 
|> - Marcelo
|> 
|> 
|> 
|> -
|>  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.
|> 
|

- Marcelo

-

---

From: Tatai SV Krishnan <[email-masked]>
Date: Thu, 25 Nov 1999 17:09:14 +0000

> of DNIS right? Nowadays, they only send 4 digits to me.

No you set authentication based on the 4 digits, thats not a problem.
All you will be doing is telling the hiper arc to authenticate users only 
when the DNIS has these four digits.

krish

-

---

From: Clayton Zekelman <[email-masked]>
Date: Thu, 25 Nov 1999 17:51:51 +0000

That wouldn't block collect calls though.

In North America, the "collect call-ability" of a particular number is
stored in the LIDB.  This allows the terminating telco to inform the
originating telco if a line has collect calls blocked or not.

Generally, for a collect call to be processed, the charged party must
accept the charges - a squeal from a modem isn't a "Yes, I accept charges".
 Your telco should be more cooperative on this matter.

> "help" to the same address.  Do not use quotes in your message.
---
Clayton Zekelman
Managed Network Systems Inc. (MNSi)
875 Ouellette Avenue
Windsor, Ontario
N9A 4J6

tel. 519-985-8410
fax. 519-258-3009

-

---

From: [email-masked]
Date: Mon, 29 Nov 1999 16:21:29 +0000

Folks,

Just a little of experience here on a similar issue.  We have been 
having the same issue at a couple of our customers and they always just 
rebooted their workstations and the problem went away.  Upon further 
investigation we found that this only happened on Windows 95 not NT 
machines.  Looking into the routing tables we found that an extra 
default gateway was popping up due to another device on their network 
sending ICMP redirects.  Manually deleting the gateway fixed the 
problem.  Sometmes the problem was intermittient as described below and 
it would fix itself.  The solution was to turn off ICMP broadcasts from 
the other device.  The access device we are using is an Ascend Pipeline 
50.

Jeff Binkley
ASA Network Computing 

U>On Tue, 23 Nov 1999, Scot Desort wrote:

U>> You do not need to disconnect. Data resumes all by itself. TX/RX
U>> activity COMPLETELY stops, then suddenly resumes. Cannot ping
U>> anywhere, not even the TC ethernet port. Then it comes back to life.
U>> It *seems* to happen most when the initial connect speed is "low"
U>> (below 44K or so), perhaps contributing to the retraining theory
U>> (the slower connection may indicate more noise present, which would
U>> leads to retrains). Never been actually cut-off as a result of this,
U>> but sometimes it is so frustrating, that you are forced to
U>> disconnect and redial. Then, it may be fine for hours. Weird.

U>Krish - this seems to be a lot like the issue we're having with
U>cambcity...  Please talk to Sanjay / Tom Cwikala about it.  All of the
U>sudden, routing stops.  The problem is, in our case, however, that
U>routing stops all together and it doesn't recover.  It just so happens
U>that the customer equip. is a Bay Networks Instant Internet 400 though
U>and they can't route at all once it stops dead like that - no
U>recovery.  I don't have the case numbers in front of me (sorry).

U>Kevin

U>> ----- Original Message -----
U>> From: Tatai SV Krishnan <[email-masked]>
U>> To: Scot Desort <[email-masked]>
U>> Cc: <[email-masked]>
U>> Sent: Tuesday, November 23, 1999 4:39 AM
U>> Subject: Re: (usr-tc) Re: DATA STOPS

U>> >
U>> > On Tue, 23 Nov 1999, Scot Desort wrote:

U>> > > We have the *same* exact problem here. I had posted about this,
U>> > > and the general thought was that it was the modems retraining.
U>> But sometimes it goes
U>> > > on for close to a minute. Seems a little long for retraining.
U>> > > Haven't investigated it further.

U>> > So in your case are you saying that - > data stops for some time
U>> > and then you get back the data transfer?  or are you saying that -
U>> > data stops. have to dial again to recheck mail.

U>> > please clarify

U>> > regards

U>> > krish

U>> > >

U>> > > ----- Original Message -----
U>> > > From: <[email-masked]>
U>> > > To: Tatai SV Krishnan <[email-masked]>
U>> > > Cc: <[email-masked]>
U>> > > Sent: Tuesday, November 23, 1999 1:57 PM
U>> > > Subject: (usr-tc) Re: DATA STOPS

U>> > > >
U>> > > > Krish,
U>> > > >
U>> > > >  We are running the 4.1.59-6 on the HiperArc and 2.0.81 on the
U>> DSPs. the
U>> > > > quads are using the 6.x.x code!
U>> > > >
U>> > > >

U>> ====================================================================
U>> ======== > > ==
U>> > > > Phillip Ferraro WorldNet Access, Inc
U>> > > > [email-masked] Onslow County's PREMIER InterNet
U>> > > > Service Voice (910) 346-0835     824 Gumbranch Square, Suite
U>> > > > R3 FAX   (910) 455-1933      Jacksonville, Nc  28540-6269
U>> > > >

U>> ====================================================================
U>> ======== > > ==
U>> > > >
U>> > > > On Tue, 23 Nov 1999, Tatai SV Krishnan wrote:
U>> > > >
U>> > > > > On Tue, 23 Nov 1999 [email-masked] wrote:
U>> > > > >
U>> > > > > >
U>> > > > > > We are seeing times when a user is connected and all of a
U>> > > > > > sudden they loose the ability to navigate or pull email...
U>> The connection is
U>> > > > > > stil up, but it appears that no data is being TX/RX?   Is
U>> > > there something
U>> > > > > > in the DSP/quads that can cause this timeout?  Is this a
U>> function of
U>> > > > > > MTU/MSS?   Or is it the fact that the HIPER ARC can't keep
U>> up with the
U>> > > > > > requests?
U>> > > > > Well need to know the exact versions of hiper arc and DSP
U>> code to start.
U>> > > > >
U>> > > > > krish
U>> > > > >
U>> > > > > >
U>> > > > > >    Would routing protocols help this?  Right now we run a
U>> network on a
U>> > > > > > single class C with 180 dialup IPs in the modem pools.  3
U>> HUB, two run
U>> > > > > > quads, the othe has 3 DSPs  all running HARCs and latest
U>> TC3.6 code.
U>> > > > > >
U>> > > > > >   We are starting to get a lot of TIMEOUTS, the connection
U>> is never
U>> > > > > > dropped, but the modem quits responding for a time.  If
U>> left alone it
U>> > > will
U>> > > > > > come back to life.
U>> > > > > >
U>> > > > > >   Anyone have any ideas?  Thanks in advance!
U>> > > > > >
U>> > > > > >

U>> ====================================================================
U>> ======== > > ==
U>> > > > > > Phillip Ferraro WorldNet Access, Inc
U>> > > > > > [email-masked] Onslow County's PREMIER InterNet
U>> > > > > > Service Voice (910) 346-0835     824 Gumbranch Square,
U>> > > > > > Suite R3 FAX   (910) 455-1933      Jacksonville, Nc
U>> > > > > >28540-6269 

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

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

U>E-Mail:  [email-masked]
U>Web:     http://users.sota-oh.com/~s1kevin/
U>Unsolicited advertisements processing fee: $50 subject to change
U>without notice

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 9999

-