Subject: (usr-tc) HyperARC/DSP Problem

From: Scot bethke <[email-masked]>
Date: Thu, 13 Jan 2000 00:30:11 +0000

I am having the absolute worst time trying to get my HyperDSP cards working in any capacity what-so-ever.  Hoping someone from here has seen this or can tell me what to check.

First i'm running HyperARC HW Version 19.0.0, with Version 4.1.59 Software.  HyperDSP's are HW V 0.49.0, and I have thus far tried both 1.2.5 and 2.0.51 software.  Im using PRI's and they both show up as UP and OPERATIONAL.

(2) Problems...  First of all I cant manage the cards (any of them) with TCM.  Running 6.0.23, had the same problem on 5.X TCM as well.  What happenes is I select the card, click on configure, click on card level and then click ok.  I can get the 
Hyper DSP/ARC Information item, and all values come in and display fine.  However I click on "Routing Method" and it comes up with this:

Error Type:    No Data Available
Parameter:    Modem Routing Method
Object ID:     1.3.6.1.4.1.429.1.26.1.1.1.2.14000

Same type of message comes up on every query except info.  I can communicate with the NMC card just fine (its an older NMC, not a HyperNMC).  So I had to go in and USE HARM to program the HyperARC (that works fine btw), and I programmed the DSP's with a terminal.

Second Issue (and this is the big one) I have two PRI's, 23B+D, Bell atlantic says everything is fine with both of them.  But they refuse to hunt from the first hyperDSP to the second.  I plug in the first PRI into either DSP card and it takes calls and works like a charm till it gets to channel 23, where we get a fast busy from then on.  Im hoping there is a special "Oh you havemore than one hyperDSP" button that I need to push.  anyone know what might cause this?

-Scott

---

From: Jeff Mcadams <[email-masked]>
Date: Thu, 13 Jan 2000 05:33:02 +0000

Thus spake Scot bethke
>Second Issue (and this is the big one) I have two PRI's, 23B+D, Bell
>atlantic says everything is fine with both of them.  But they refuse to
>hunt from the first hyperDSP to the second.  I plug in the first PRI
>into either DSP card and it takes calls and works like a charm till it
>gets to channel 23, where we get a fast busy from then on.  Im hoping
>there is a special "Oh you havemore than one hyperDSP" button that I
>need to push.  anyone know what might cause this?

Get Hell Atlantic back on the line and smack them upside the head with a
clue by four.  :)  If the both cards are taking calls, then there's a
problem with the hunting and that's all telco there.  There is no way to
configure your equipment to control the hunt group in any way.  The
originating side (the telco in this case) decides where to send the
call, the receiving side has no say in the matter other than to
possibly reject the call (resulting in either a fast busy/reorder tone
type of response to the caller, or a user busy if its rejected with
cause code 17).

I suspect that they've set it up as two seperate trunk groups and not
got the hunting between them configured correctly.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-
 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: Thu, 13 Jan 2000 06:51:03 +0000

Are you sure that you don't have a hung modem that is stopping the hunt
group (not answering the phone)?

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

-

---

From: Mike Andrews <[email-masked]>
Date: Thu, 13 Jan 2000 07:06:44 +0000

What software version is your NMC?  It almost sounds like you've got a
4 meg NMC, which isn't going to be able to manage a DSP at all -- gotta
have 16 meg and the 16 meg code.

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: Scot bethke <[email-masked]>
Date: Thu, 13 Jan 2000 15:45:16 +0000

How would I tell if I had a hung modem?  well  wait now if I had a hung
modem though wouldnt it be caught when I pluged the initial PRI into the
next card..  When I do that it will take all calls to capacity and still not
hunt over to the next set of PRI's

-Scott

----- Original Message -----
From: "Paul Farber" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, January 12, 2000 11:52 PM
Subject: Re: (usr-tc) HyperARC/DSP Problem

> > I am having the absolute worst time trying to get my HyperDSP cards
working in any capacity what-so-ever.  Hoping someone from here has seen
this or can tell me what to check.
> >
> > First i'm running HyperARC HW Version 19.0.0, with Version 4.1.59
Software.  HyperDSP's are HW V 0.49.0, and I have thus far tried both 1.2.5
and 2.0.51 software.  Im using PRI's and they both show up as UP and
OPERATIONAL.
> >
> > (2) Problems...  First of all I cant manage the cards (any of them) with
TCM.  Running 6.0.23, had the same problem on 5.X TCM as well.  What
happenes is I select the card, click on configure, click on card level and
then click ok.  I can get the
> > Hyper DSP/ARC Information item, and all values come in and display fine.
However I click on "Routing Method" and it comes up with this:
> > Same type of message comes up on every query except info.  I can
communicate with the NMC card just fine (its an older NMC, not a HyperNMC).
So I had to go in and USE HARM to program the HyperARC (that works fine
btw), and I programmed the DSP's with a terminal.
> > Second Issue (and this is the big one) I have two PRI's, 23B+D, Bell
atlantic says everything is fine with both of them.  But they refuse to hunt
from the first hyperDSP to the second.  I plug in the first PRI into either
DSP card and it takes calls and works like a charm till it gets to channel
23, where we get a fast busy from then on.  Im hoping there is a special "Oh
you havemore than one hyperDSP" button that I need to push.  anyone know
what might cause this?

-

---

From: Paul Farber <[email-masked]>
Date: Thu, 13 Jan 2000 17:10:00 +0000

Just something to check.... never overlook the obvious because *sometimes*
telco is right.

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

-

---

From: Scot bethke <[email-masked]>
Date: Thu, 13 Jan 2000 17:22:41 +0000

Well that gets me back to my original question though how do I check modem
status for a hung modem.

-Scott

----- Original Message -----
From: "Paul Farber" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 13, 2000 10:06 AM
Subject: Re: (usr-tc) HyperARC/DSP Problem

> > atlantic says everything is fine with both of them.  But they refuse to
hunt

-

---

From: K Mitchell <[email-masked]>
Date: Thu, 13 Jan 2000 17:48:27 +0000

>hunt over to the next set of PRI's

I use a perl script to check for hung modems. You can see the output at
http://www.keyconn.net/mrtg/modem-fail.htm When one(a pair actually) hangs,
it won't be long till you're getting calls reporting "computer is not
answering". My failure ratios don't exceed 2.5-3% unless I've got a pair
hung, and it rapidly climbs above 5% when they do.

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

-

---

From: Kevin Benton <[email-masked]>
Date: Thu, 13 Jan 2000 18:10:38 +0000

On Thu, 13 Jan 2000, Paul Farber wrote:

The easiest way I can think of to verify this to be true or not is to busy
out the first PRI and then see if you can dial the number or not.  If
there's a question about a hung modem, reverse the PRI's on your chassis
and then try it.  It's been my experience that fast busy has usually been
an issue on the telco side or that our DS1 span provisioning isn't right
in the card.  The other thing you will want to check (which wouldn't cause
a fast busy but could cause standard busy) is to have them check the hunt
group size on the PRI.  Also, if you're talking with provisioning, have
them do an ISDN trace and see which trunk is causing the fast busy not to
mention how many trunks they're going into.

Kevin Benton
Network Administrator
SOTANet LLC, A Voyager.net Company

>  "help" to the same address.  Do not use quotes in your message.

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

-

---

From: Paul Farber <[email-masked]>
Date: Thu, 13 Jan 2000 18:43:16 +0000

Call in to the rack and see if you get 'dead air'.  IE pick up with no
negotiation.

Or if you get a busy but still have open modems.  I don't think there is a
way in TCM to check it.

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

-

---

From: Scot bethke <[email-masked]>
Date: Thu, 13 Jan 2000 21:23:10 +0000

Well Bell Atlantic just called back, they set up a protocol Analyzer on the
trunks and said my HyperDSPs are returning a "NO CHANNELS AVAILABLE" error
when they dial in past the last channel on my first PRI..  Now again I have
swapped the PRI's so I know that both cards work.  Would there be something
I'm missing here to tell these cards (or the Harc) that they need to pass
stuff over to the second PRI?

-Scott

----- Original Message -----
From: "Kevin Benton" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 13, 2000 11:01 AM
Subject: Re: (usr-tc) HyperARC/DSP Problem

-

---

From: "The NOC (COX Internet)" <[email-masked]>
Date: Thu, 13 Jan 2000 21:24:26 +0000

This problem as stumped us from a while.  Here is the situation:

We have a ISD that is using ISDN to dial into one of our older TCHs.  They
can dial in a connect. When they try to go to a web page using the DNS name
they can not go to it.  They can type in the ip address to get to it but not
the dns.  Here is where it gets strange.  They can connect to two other
isp's without any problems and they can surf the net just fine.  We have
checked just about everything that is possible to check, including making
sure it wasn't looking for a auto-proxy.  This ISD is the only person that
is having this problem.  As a side note, we have a profiles set up for our
ISDN customers on that TCH.

Bryan
NOC Technician
COX Internet

-

---

From: Scot Desort <[email-masked]>
Date: Thu, 13 Jan 2000 21:32:25 +0000

What ISDN equipment is the customer using? Is it Cisco perhaps? I've seen
this before with Cisco (don't recall what version of IOS though). I believe
the resolve was

no ip mroute-cache

--
Scot

----- Original Message -----
From: The NOC (COX Internet) <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 13, 2000 2:30 PM
Subject: (usr-tc) Odd Problem

-

---

From: "The NOC (COX Internet)" <[email-masked]>
Date: Thu, 13 Jan 2000 21:48:27 +0000

Honestly I do not remember.  I was not the primary technician working on
this problem.  But I do believe it was either Cisco or the Ascend Pipeline
ISDN router.  The ISD gave us like a hour to fix the problem before they
switched providers and obviously we didn't make the time limit.

Bryan
NOC Technician
COX Internet

----- Original Message -----
From: "Scot Desort" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 13, 2000 1:24 PM
Subject: Re: (usr-tc) Odd Problem

-

---

From: K Mitchell <[email-masked]>
Date: Thu, 13 Jan 2000 21:50:29 +0000

>ISDN customers on that TCH.

Check TCP/IP's DNS settings in the connectoid, make sure it's set to your
servers or server assigned.

-

---

From: K Mitchell <[email-masked]>
Date: Thu, 13 Jan 2000 21:50:43 +0000

>stuff over to the second PRI?

Maybe this was asked or answered already, but are the switch and framing
types set properly under trunk settings?

-

---

From: Mike Wronski <[email-masked]>
Date: Thu, 13 Jan 2000 21:54:58 +0000

|-----Original Message-----
|From: [email-masked]
|[mailto:[email-masked]]On Behalf Of The NOC (COX
|Internet)
|Sent: Thursday, January 13, 2000 1:30 PM
|To: [email-masked]
|Subject: (usr-tc) Odd Problem
|
|
|
|This problem as stumped us from a while.  Here is the situation:
|
|We have a ISD that is using ISDN to dial into one of our older TCHs.  They
|can dial in a connect. When they try to go to a web page using the DNS name
|they can not go to it.  They can type in the ip address to get to
|it but not
|the dns.

Were you providing the ISD a valid DNS server address during IPCP? The
symptom sounds like the client didnt have any DNS server configured.

| Here is where it gets strange.  They can connect to two other
|isp's without any problems and they can surf the net just fine.  We have
|checked just about everything that is possible to check, including making
|sure it wasn't looking for a auto-proxy.  This ISD is the only person that
|is having this problem.  As a side note, we have a profiles set up for our
|ISDN customers on that TCH.
|
|Bryan
|NOC Technician
|COX Internet
|
|
|-
| 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: "The NOC (COX Internet)" <[email-masked]>
Date: Thu, 13 Jan 2000 21:59:25 +0000

Kirk,

Yes.  This was done.

Bryan
NOC Technician
COX Internet

----- Original Message -----
From: "K Mitchell" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 13, 2000 1:41 PM
Subject: Re: (usr-tc) Odd Problem

-

---

From: Scot bethke <[email-masked]>
Date: Thu, 13 Jan 2000 22:23:55 +0000

> types set properly under trunk settings?

Yes they are, we prove this by putting the working PRI on both DSP cards and
it takes calls fine.

-

---

From: Kevin Benton <[email-masked]>
Date: Thu, 13 Jan 2000 22:24:11 +0000

> stuff over to the second PRI?

Nope.  Absolutely nothing.  Now, on the other hand, if you do a list
interfaces, what does it give back to you?  Is the HARC seeing the
channels up and available on your second DSP?  If not, what does list
chassis give back to you?

Here's the deal - hunting from PRI to PRI is a telco switch side issue.
If all channels are up and running on your PRI's, then it's the telco's
responsibility to pass those calls to you in some fashion.  Did you ask
them when they did an ISDN trace how many trunks were in the group?  1?
2?  x?  To do that trace, you'll need to give them the lead phone number
for your hunt group.

What I would do is the following...

1)  Select the second DSP.
2)  Click on the actions button.
3)  Click on Hardware and change it to Software.
4)  Click on No Command and change it to Restore T1/E1 and Modems from
    Default.
5)  Click on Execute.
6)  When the result is successful click on Save both T1/E1 and Modems to
    NVRAM.
7)  Click on Execute.
8)  When the result is successful, click on Software and change it to
    Hardware.
9)  Click on Hardware No Command and change it to Hardware Reset.

When the result is successful, close that window, then re-program your
DSP's T1 level settings by hand after it comes back up.  This will guard
against old settings interfering with current issues.  You know that DSP
#1 works.  The best way I've found to program these settings is to open up
the programmed settings for both DSP's simultaneously by clicking on the
first DSP's T1 then control clicking on the second DSP's T1.  Then you
should be able to manually set copy the information.

I have personally run into a few cases where old settings did interfere
with current settings and restoring to factory default has saved me a
bunch of time and effort from past attempts to fix things.  I have also
found that using "Load From" isn't the best way to change settings and
know that they're set accurately.

Make sure that if you're expecting DNIS that the telco is sending it.  If
not, the DSP will not accept the call.

If there is still an issue, have the telco provisioning people go back and
compare PRI #1 versus #2.  If they're not identical in translations, have
them fix #2 to match #1.  If they tell you that things are identical after
all that, then maybe Krish would be willing to help you or your 3Com sales
rep may send you over to an NC who might help.

Nope, I don't work for 3Com.  I just teach people how to use their
stuff...  :)

Kevin

E-Mail:  [email-masked]

-

---

From: Scot Desort <[email-masked]>
Date: Thu, 13 Jan 2000 22:39:55 +0000

I *still* think there is a hunt group problem with that first PRI. If the BA
switch does not know that there is a second trunk in the group, then of
course, the HiperDSP will return NO CHANNELS, because the telco switch is
trying to pass a 24th call to the first PRI. Telco switch is supposed to
pass that 24th call to the next trunk in the hunt group which would be your
2nd PRI.

Technically speaking, I don't know enough about PRI call control, so I don't
know if the telco switch is keeping track of how many active channels there
are on a PRI (via the D channel), and making it's own determination to bump
the call the the next PRI in the hunt group, or it asks the HiperDSP (again,
via the D channel) how many channels are available, and if it's 0, the telco
switch moves to the next PRI in the hunt group.....

Either way, I believe that the DSP is supposed to return that indicator when
all channels are full. Telco switch should now hunt the call, which it does
not appear to be doing. Have them try switching the hunt method -- if they
are set to top-down (sequential), change to round-robin/random, or
vice-versa. Maybe they have something funky in the hunt config.

Just some ideas...

--
Scot

----- Original Message -----
From: Scot bethke <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 13, 2000 2:25 PM
Subject: Re: (usr-tc) HyperARC/DSP Problem

> > > > Software.  HyperDSP's are HW V 0.49.0, and I have thus far tried
both
> 1.2.5
> > > > happenes is I select the card, click on configure, click on card
level
> and
> > > > > > Hyper DSP/ARC Information item, and all values come in and
display
> fine.

-

---

From: Mark Thornton <[email-masked]>
Date: Thu, 13 Jan 2000 22:54:58 +0000

Is this an NFAS problem? Our PRI lines all appear as a single trunk at the
telco, controlled by the NFAS functionality across as many PRI lines that
are included in the NFAS group. At least that is how the switch guys
described it to me. All I do at my end is make sure the second, third, etc.
card are set up as being a member of the NFAS group, and determine whether I
am going to add additional d channels for redundancy. If the PRI lines are
not part of an NFAS group, then there must be some sort of hunting or
rollover involved.

It is very similar to the way our incoming T1's are handled, they all are
piled into one big group as available lines with no hunting set up at all.
While hunting would be beneficial in some troubleshooting situations we had
it get messed up so many times they moved to this mode. Any time we add
lines the switch tech just adds the transport layer to the group and whamo,
there are additional lines at our site that work without the intervention of
some other "programming tech" at the telco.

Mark Thornton
San Marcos Internet, Inc.
512-393-5300

-

---

From: K Mitchell <[email-masked]>
Date: Thu, 13 Jan 2000 22:58:02 +0000

>Yes they are, we prove this by putting the working PRI on both DSP cards and

  My mistake, I overlooked the "swapped the PRI's so I know that both cards
work" in your message.
  It would appear that this problem is unavoidably telco-based. One of the
things we do when ordering PRI is specify that each one has it's own lead
dial-in number for testing purposes. The PRI still works as usual within
the hunt group, but you have the ability to dial into a specific PRI. This
ability would help determine whether your problems are rollover based, or
specific to the line itself.

-

---

From: Jeff Mcadams <[email-masked]>
Date: Thu, 13 Jan 2000 23:07:03 +0000

Thus spake Scot Desort

>switch moves to the next PRI in the hunt group.....

The telco switch keeps track of how many channels are available.

>all channels are full. 

Bzzt...no can do.  There is no indication such as this.  If the DSP (or
any PRI equipment) returns an indication that it doesn't have any trunks
available, the caller gets a busy indication of some kind (either
regular user busy, or some sort of reorder tone), the call does *not*
get re-hunted, its released.  In all actuality, if all 23 channels are
full, the telco switch shouldn't send a request on the D channel at all
since it already knows that the span is already full.  If it does send a
D channel message, there's a *SERIOUS* bug in the telco switch
code...and that's rather unlikely.  :)
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Terry Kennedy <[email-masked]>
Date: Fri, 14 Jan 2000 05:02:01 +0000

I've heard this can doen rather using console cables to each
DSP. Can someone point me to right docs to figure this out. I
can't find it anywhere. Meanwhile back to the PDF files.
Thanks

-

---

From: Ed <[email-masked]>
Date: Fri, 14 Jan 2000 05:14:49 +0000

Has any come up with a sure fire way to limit sessions based on Radius
without using Accounting? With 3com Accounting turned on our database
becomes 100MB+ in a day so that seems out of the question.

It used be done in netservers by using Traps... also you used to be able to
use Traps to log to a Logserver and now you can't... it all seems to have to
be run through a large Database file. We would rather not do this as Access
just cannot handle 100MB files without croaking.

Basically I wanted to know what others are using for solutions to these old
problems... I know of various ways things can be done but none seem pratical
for large volume systems with 20,000+ people logging onto in a day.

Thanks!

Ed

----- Original Message -----
From: Terry Kennedy
To: [email-masked]
Sent: Thursday, January 13, 2000 9:53 PM
Subject: (usr-tc) Connect via the Arc to the Dsp

-

-

---

From: Mike Andrews <[email-masked]>
Date: Fri, 14 Jan 2000 06:27:41 +0000

Yup, if you have new enough code on all the cards, you can do something
resembling the following on your ARC:

arc> add network service dsp8cons server_type telnetd socket 8000 data
     "service_type=dialout,auth=off,interface=\"SLOT:8/CON:1\""

...then telnet to port 8000 on your ARC and you'll be dumped directly to
the console of the DSP in slot 8.

You'll want to make sure you've got a console password set on your DSP's,
of course. :)  There is a way to set up a password on the ARC side, but I
never got it to work right.  I didn't try very hard though.

-

---

From: [email-masked]
Date: Fri, 14 Jan 2000 18:08:00 +0000

>hunt over to the next set of PRI's
Tell Bell Atlantic to up the number of available channels. We had the
same problem on one of our pools. Turns out, BA told their switch there
were 46 channels available whereas, in reality, there were 69. They kept
telling us the hunt was programmed properly; it took a bit of whooping
and hollering to get 'em to check a little more carefully. 8-\

*********************************************************
Michelle M. Mogil
Network and Computing Systems
721 Rhodes Hall, Cornell University, Ithaca, NY 14853
vox: (607) 255-0516, fax: (607) 255-8420
email: [email-masked]
**********************************************

-

---

From: John Verreault <[email-masked]>
Date: Fri, 14 Jan 2000 18:50:25 +0000

Since flashing my DSP's 2 days ago to 2.0.51 we are starting to get calls
from users that have Older Sportster 28.8 modems who are unable to connect.

Has anyone else seen this ????

Thanks

John Verreault
AEI Internet

-

---

From: Vincent Frallicciardi <[email-masked]>
Date: Sat, 15 Jan 2000 00:27:33 +0000

Hi,

I am looking for a used Total Control Chasse with power supply no other
cards if you know some one who has one let me know.

Vince

[email-masked]
> "help" to the same address.  Do not use quotes in your message.
Vincent

-

---

From: Vincent Frallicciardi <[email-masked]>
Date: Sat, 15 Jan 2000 00:29:58 +0000

Hi,

Vince

[email-masked]
Vincent

-

---

From: Vincent Frallicciardi <[email-masked]>
Date: Sat, 15 Jan 2000 00:29:59 +0000

Hi,

Vince

[email-masked]
atlantic says everything is fine with both of them.  But they refuse to
hunt from the first hyperDSP to the second.  I plug in the first PRI into
either DSP card and it takes calls and works like a charm till it gets to
channel 23, where we get a fast busy from then on.  Im hoping there is a
special "Oh you havemore than one hyperDSP" button that I need to push.
anyone know what might cause this?
Vincent

-

---

From: Vincent Frallicciardi <[email-masked]>
Date: Sat, 15 Jan 2000 00:30:20 +0000

Hi,

Vince

[email-masked]
Vincent

-

---

From: Vincent Frallicciardi <[email-masked]>
Date: Sat, 15 Jan 2000 00:34:06 +0000

Hi,

Vince

[email-masked]
Vincent

-

---

From: Terry Kennedy <[email-masked]>
Date: Sun, 16 Jan 2000 04:10:27 +0000

Mike,

Tried this and I am dropped back at the hiperarc's cli.3kb.com and found
nothing on this. Is their a syntax problem here?  A list of the network
services show the I have also looked on 3kb.com and found nothing on this.
All I found was some expalnation for doing telneting to a hiperarv from a
netserver with a set of console cables hooked tied together with a null
modem connector. Have no idea why anyone would want to do that. I'll keep
looking.

Thanks

-

---

From: Terry Kennedy <[email-masked]>
Date: Sun, 16 Jan 2000 04:25:15 +0000

Wow, that was a screwed up response! let me try again..

Mike,

Tried this and it telnets just fine back to the hiperarc. Is their a syntax
problem here?  A list of the network services show:

CONFIGURED NETWORK SERVICES
                                 Server                    Admin
Name                             Type      Socket  Close   Status
dsp12                            TELNETD   8000    FALSE   ENABLED
DATA: service_type=dialout,auth=off,interface="slot:12/con:1"

I also have looked at 3kb.com and all I found was some explanation for
telneting to a hiperarc from a
netserver with a set of console cables tied together with a null modem
connector. Have no idea why anyone would want to do that. I'll keep looking.

Thanks
Terry

-

-

---

From: Mike Andrews <[email-masked]>
Date: Sun, 16 Jan 2000 20:37:08 +0000

This is live off of one of my ARCs:

law-ts1> list network service

CONFIGURED NETWORK SERVICES
                                 Server                    Admin
Name                             Type      Socket  Close   Status
tftpd                            TFTPD     69      FALSE   ENABLED
    DATA:

telnetd                          TELNETD   23      FALSE   ENABLED
    DATA:

dsp8cons                         TELNETD   8000    FALSE   ENABLED
    DATA: service_type=dialout,auth=off,interface="SLOT:8/CON:1"

dsp9cons                         TELNETD   9000    FALSE   ENABLED
    DATA: service_type=dialout,auth=off,interface="SLOT:9/CON:1"

dsp10cons                        TELNETD   10000   FALSE   ENABLED
    DATA: service_type=dialout,auth=off,interface="SLOT:10/CON:1"

dsp11cons                        TELNETD   11000   FALSE   ENABLED
    DATA: service_type=dialout,auth=off,interface="SLOT:11/CON:1"

dsp12cons                        TELNETD   12000   FALSE   ENABLED
    DATA: service_type=dialout,auth=off,interface="SLOT:12/CON:1"

This is with DSP version 2.0.51 and ARC version 4.2.32.  You must have at
least DSP 2.0.x to make it work.  With the above, I can telnet to port
11000 to get to the console of the DSP in slot 11...

Does "list interface" show the console ports?  If not, you probably don't
have the newest release of code.  If you do, try 'list chassis' and make
sure console is set to yes on all your DSP's there.

-

---

From: Jack Singer <[email-masked]>
Date: Thu, 17 Feb 2000 21:00:42 +0000

Does anyone know where I can find information on older Total Control cards
on the 3Com web site.  All I can find is the new stuff and Y2k information.
No specs available on the individual cards????

Jack
Internet Connections
[email-masked]

-