ftp.xmission.com/2014.06.ftp.xmission.com.tar/ftp.xmission.com/pub/lists/usr-tc/archive/usr-tc.199908

Internet Message Format | 1999-08-31 | 1MB

From: "Paul M. Oster" <[e-mail]>
Subject: Re: (usr-tc) Question.
Date: 01 Aug 1999 11:27:47 -0500 (CDT)



   Hrm... I've had problems with that in the past also, my "shell" users
have been informed to login as

username.shell

instead of username... the .shell extension clues off my radius that this
is a telnet type connection, NOT a ppp connection.  Anything else is
assumed to be ppp.  Works great, and in my case, only like 50/3500 users
ever USE their shell account via telnet, and only may 10 of them dial in
directly.  I've only done this with Cistron Radiusd, and not anything else
(in fact that was one of my MANY reasons for switching to cistron)


Hope this helps.



Paul M. Oster <[e-mail]>               http://www.minot.com/
Magic Internet Services                         [phone]
Minots FIRST Internet Connection

-=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=-

"I might not agree with what you have to say but I will defend, to
my death, your right to say it." - Voltaire

On Fri, 30 Jul 1999, Chad Schwartz wrote:

> Not sure if there is an archive available for this list, and if there is,
> I would glady search through it. (Point me in the right direction, if this
> question is answered elsewhere.)
>
> I've recently purchased a USR NetServer 8/I, and am looking to do a
> specific thing, that I don't know if USR's 4.x OS versions support.
>
> I need to do both PAP, and NON-PAP authentication.  (I.E. when a user
> dials in w/ a PAP-Enabled PPP client (such as Win95/Win98/MacOS/Whatever)
> the Netserver will see that, and start the PAP process automatically.)
>
> Yet, I also need the ability for a user to dial in with Procomm, and log
> in with just a username and password, and get rlogin'ed directly to a
> shell account.  (And also, w/ non-pap type customers, who use a radius
> prefix 'P' in front of their username, to designate that they want to do
> PPP.)
>
> I can do this with my PM2's, and I know the older NetServer (ComOS based
> code) could do this.
>
> Is there a method to do this, on the new OS? Or am I stuck with either
> login only, or PAP only?
>
> I know the older versions of the NetserverOS have the 'look&feel' of
> ComOS.  But, my Netserver Manager program complains that it isn't a valid
> image, when I tried to load it on the unit...
>
> (I don't MIND using 4.x, if it'll do what I need it to do.)
>
> Thanks in advance to anyone who might have an answer.
>
>
>  Chad
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: John Schmerold <[e-mail]>
Subject: Re: (usr-tc) Question.
Date: 01 Aug 1999 21:05:18 -0500

re:  "unlimited attended access", How do you validate that your clients are at
their computer?

"Paul M. Oster" wrote:

>    Hrm... I've had problems with that in the past also, my "shell" users
> have been informed to login as
>
> username.shell
>
> instead of username... the .shell extension clues off my radius that this
> is a telnet type connection, NOT a ppp connection.  Anything else is
> assumed to be ppp.  Works great, and in my case, only like 50/3500 users
> ever USE their shell account via telnet, and only may 10 of them dial in
> directly.  I've only done this with Cistron Radiusd, and not anything else
> (in fact that was one of my MANY reasons for switching to cistron)
>
> Hope this helps.
>
> Paul M. Oster <[e-mail]>               http://www.minot.com/
> Magic Internet Services                         [phone]
> Minots FIRST Internet Connection
>
> -=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=-
>
> "I might not agree with what you have to say but I will defend, to
> my death, your right to say it." - Voltaire
>
> On Fri, 30 Jul 1999, Chad Schwartz wrote:
>
> > Not sure if there is an archive available for this list, and if there is,
> > I would glady search through it. (Point me in the right direction, if this
> > question is answered elsewhere.)
> >
> > I've recently purchased a USR NetServer 8/I, and am looking to do a
> > specific thing, that I don't know if USR's 4.x OS versions support.
> >
> > I need to do both PAP, and NON-PAP authentication.  (I.E. when a user
> > dials in w/ a PAP-Enabled PPP client (such as Win95/Win98/MacOS/Whatever)
> > the Netserver will see that, and start the PAP process automatically.)
> >
> > Yet, I also need the ability for a user to dial in with Procomm, and log
> > in with just a username and password, and get rlogin'ed directly to a
> > shell account.  (And also, w/ non-pap type customers, who use a radius
> > prefix 'P' in front of their username, to designate that they want to do
> > PPP.)
> >
> > I can do this with my PM2's, and I know the older NetServer (ComOS based
> > code) could do this.
> >
> > Is there a method to do this, on the new OS? Or am I stuck with either
> > login only, or PAP only?
> >
> > I know the older versions of the NetserverOS have the 'look&feel' of
> > ComOS.  But, my Netserver Manager program complains that it isn't a valid
> > image, when I tried to load it on the unit...
> >
> > (I don't MIND using 4.x, if it'll do what I need it to do.)
> >
> > Thanks in advance to anyone who might have an answer.
> >
> >
> >  Chad
> >
> >
> > -
> >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> >  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 "[e-mail]"
>  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.

--
John Schmerold
Katy Computer, LLC
20 Meramec Station Rd
Valley Park, MO 63088
314-316-9000
314-316-9200 fax



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: [e-mail] (Suncoast Networking ISP TC List Mailbox)
Subject: (usr-tc) Filters on net0 question - Not filtering?
Date: 02 Aug 1999 13:44:39 -0400

I'm having trouble with packets getting through that
I didn't think could. We have the out filter on our
Netservers NET0 set to

(1-4 all denies)
5 deny 0.0.0.0/0 192.168.0.0/16 ip
6 permit (localnet)/24 0.0.0.0/0 ip
7 deny 0.0.0.0/0 0.0.0.0/0 ip

The In filter has the same rule in reverse as line
5. Yet our firewall reports ICMP packets coming from
this Netservers net0 IP to destination 192.168.2.208,
which should be blocked by line 5.

Does this mean I have to specify UDP and ICMP in
addition to IP for each rule? Or does NET0 filtering
only apply to packets coming from within the chassis?

Thanks
 Steve Kinkaid
 Suncoast Networking Inc.
 Largo, FL



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Scott Trautman <[e-mail]>
Subject: (usr-tc) HiperARC: Very bogus route accepted from dialup user even though
Date: 02 Aug 1999 13:12:23 -0500

This is with the new release of code; saw it in old release as well.

Our address space is part of a class B, so some routers/devices want to put
in an incorrect route for that 255.255.0.0 network.
Via radius, we don't listen or broadcast routes to customers; don't need it.
Default gateway is all they really need.

Found though that a customer, who likely has an incorrect setup somewhere
along the way, was able to get a route injected into our HiperARC, of type
"Net Mgr" (as opposed to RIP, OSPF...)

Other than not really even knowning what "Net Mgr" routes are, how the heck
can I make sure that the ARC doesn't accept ANY routes EXCEPT as assigned in
RADIUS?

Anyone else seen this? Kinda Krazy and meant our ARC disappeared for awhile
last night to most of our network. Hasn't happened on other ARC's,
yet..but...

SMT

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 "[e-mail]"
 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: [e-mail]
Subject: (usr-tc) are power supplies swapable.
Date: 02 Aug 1999 12:36:14 -0600

I have a newer chassis with the integrated fan tray.
The power supply apparently just died.  I do not have
an extra 70 am supply but I have a few 45 am supplies.
The unit is at a remote site and I do not have a newer chassis
here to test compatibility.

Can I replace the one 70 amp with two 45 amp power supplies?
3 com said i needed to replace the front and back. I pulled
the 45 amp power supplies out of the chassis.  When I took off
the back plate on the chassis for the power supplies it looks
like it is hardwired and not to be removed.  What is the correct
answer? Can I swap the 2 45's for a 70 and do I just pull the front
nic card out and replace them?
thanks
eric



Delaware Online!.........The SMART Choice!
With 56K V.90 & X2 & Flex Modems
Phone : [phone]
Fax:     [phone]
Failure is NOT an option...



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Marshall Morgan" <[e-mail]>
Subject: RE: (usr-tc) are power supplies swapable.
Date: 02 Aug 1999 13:43:06 -0500

The Dual 45A PS are not compatible with the newer integrated fan chassis.  I
believe the pinouts are wrong for starters.

Marshall Morgan

Internet Doorway, Inc. (aka NETDOOR)

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of [e-mail]
> Sent: Monday, August 02, 1999 1:36 PM
> To: [e-mail]
> Subject: (usr-tc) are power supplies swapable.
>
>
> I have a newer chassis with the integrated fan tray.
> The power supply apparently just died.  I do not have
> an extra 70 am supply but I have a few 45 am supplies.
> The unit is at a remote site and I do not have a newer chassis
> here to test compatibility.
>
> Can I replace the one 70 amp with two 45 amp power supplies?
> 3 com said i needed to replace the front and back. I pulled
> the 45 amp power supplies out of the chassis.  When I took off
> the back plate on the chassis for the power supplies it looks
> like it is hardwired and not to be removed.  What is the correct
> answer? Can I swap the 2 45's for a 70 and do I just pull the front
> nic card out and replace them?
> thanks
> eric


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Mike Wronski" <[e-mail]>
Subject: RE: (usr-tc) HiperARC: Very bogus route accepted from dialup user even though supposedly not accepting routes from dialup users....
Date: 02 Aug 1999 13:52:11 -0500



|-----Original Message-----
|From: [e-mail]
|[mailto:[e-mail]]On Behalf Of Scott Trautman
|Sent: Monday, August 02, 1999 1:12 PM
|To: [e-mail]
|Subject: (usr-tc) HiperARC: Very bogus route accepted from dialup user
|even though supposedly not accepting routes from dialup users....
|
|
|This is with the new release of code; saw it in old release as well.
|
|Our address space is part of a class B, so some routers/devices want to put
|in an incorrect route for that 255.255.0.0 network.
|Via radius, we don't listen or broadcast routes to customers; don't need it.
|Default gateway is all they really need.
|
|Found though that a customer, who likely has an incorrect setup somewhere
|along the way, was able to get a route injected into our HiperARC, of type
|"Net Mgr" (as opposed to RIP, OSPF...)
|
|Other than not really even knowning what "Net Mgr" routes are, how the heck
|can I make sure that the ARC doesn't accept ANY routes EXCEPT as assigned in
|RADIUS?
|
|Anyone else seen this? Kinda Krazy and meant our ARC disappeared for awhile
|last night to most of our network. Hasn't happened on other ARC's,
|yet..but...
|

I would be very curious to see how this customer is adding this route.. NetMgr
routes are static routes configured on the HARC or via FRAMED_ROUTE (local or
RADIUS).  A "learned" route would not show up as NetMgr.

Can you get me the RADIUS entry for this user. "show remote user <X>" when the
user is online. Also show me your default user configs.

-M


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) HiperARC: Very bogus route accepted from dialup user even though
Date: 02 Aug 1999 14:59:22 -0400 (EDT)

Thus spake Scott Trautman
>This is with the new release of code; saw it in old release as well.

>Found though that a customer, who likely has an incorrect setup somewhere
>along the way, was able to get a route injected into our HiperARC, of type
>"Net Mgr" (as opposed to RIP, OSPF...)

>Other than not really even knowning what "Net Mgr" routes are, how the heck
>can I make sure that the ARC doesn't accept ANY routes EXCEPT as assigned in
>RADIUS?

RADIUS assigned routes show up as NetMgr.  NetMgr basically just means
that they are routes assigned by some sort of "higher level" thing,
whether that be someone typing them in at the CLI, or the equivalent of
being assigned via a RADIUS Accept-Accept.  You'll also see "LOCAL"
which would be the equivalent of Cisco's "directly connected" (ie, the
Arc has an interface directly on the network that route is on).  And
then of course, you'll see OSPF and RIP currently (with other protocols
likely to come in the future)
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) are power supplies swapable.
Date: 02 Aug 1999 15:00:39 -0400 (EDT)

Thus spake [e-mail]
>I have a newer chassis with the integrated fan tray.
>The power supply apparently just died.  I do not have
>an extra 70 am supply but I have a few 45 am supplies.
>The unit is at a remote site and I do not have a newer chassis
>here to test compatibility.

>Can I replace the one 70 amp with two 45 amp power supplies?
>3 com said i needed to replace the front and back. I pulled
>the 45 amp power supplies out of the chassis.  When I took off
>the back plate on the chassis for the power supplies it looks
>like it is hardwired and not to be removed.  What is the correct
>answer? Can I swap the 2 45's for a 70 and do I just pull the front
>nic card out and replace them?

Nope, 45's can't go into the newer chassis.  The power supply slots in
the newer chassis are different from the ones in the older chassis, the
power supplies are not exchangeable between them.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: [e-mail]
Subject: Re: (usr-tc) are power supplies swapable.
Date: 02 Aug 1999 13:16:11 -0600

Thanks Jeff
I need a 70 amp or 130 amp supply now.
Can someone who has one to sell call me at 609-898-9870
I will need next day shipment.
thanks
eric


At 03:00 PM 8/2/99 -0400, you wrote:
>Thus spake [e-mail]
>>I have a newer chassis with the integrated fan tray.
>>The power supply apparently just died.  I do not have
>>an extra 70 am supply but I have a few 45 am supplies.
>>The unit is at a remote site and I do not have a newer chassis
>>here to test compatibility.
>
>>Can I replace the one 70 amp with two 45 amp power supplies?
>>3 com said i needed to replace the front and back. I pulled
>>the 45 amp power supplies out of the chassis.  When I took off
>>the back plate on the chassis for the power supplies it looks
>>like it is hardwired and not to be removed.  What is the correct
>>answer? Can I swap the 2 45's for a 70 and do I just pull the front
>>nic card out and replace them?
>
>Nope, 45's can't go into the newer chassis.  The power supply slots in
>the newer chassis are different from the ones in the older chassis, the
>power supplies are not exchangeable between them.
>--
>Jeff McAdams                            Email: [e-mail]
>Head Network Administrator              Voice: [phone]
>IgLou Internet Services                        [phone]
>
>-
> To unsubscribe to usr-tc, send an email to "[e-mail]"
> 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.
>Delaware Online!.........The SMART Choice!
With 56K V.90 & X2 & Flex Modems
Phone : [phone]
Fax:     [phone]
Failure is NOT an option...



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Scott Trautman <[e-mail]>
Subject: RE: (usr-tc) HiperARC: Very bogus route accepted from dialup user
Date: 02 Aug 1999 15:28:08 -0500

Well, I'm going to guess that the problem was a HiperARC default, as we
didn't have a Framed-Routing default, so assume it'd default to something I
didn't want on the ARC. We have the USER_DEFAULT set to Framed-Routing = 0
now and I strongly suspect we'll not see this problem again.

Might still be useful to know how to shut it off in the ARC, but basically
problem solved.

When I had this before, I recall trying to find something on NetMgr in the
ARC 1.0 PDF manual and couldn't find it.

Thanks for the tip....

SMT
|
>
> I would be very curious to see how this customer is adding
> this route.. NetMgr
> routes are static routes configured on the HARC or via
> FRAMED_ROUTE (local or
> RADIUS).  A "learned" route would not show up as NetMgr.
>
> Can you get me the RADIUS entry for this user. "show remote
> user <X>" when the
> user is online. Also show me your default user configs.
>
> -M
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: Rick <[e-mail]>
Subject: (usr-tc) hyper arc v4.2.29 on hold
Date: 02 Aug 1999 21:43:04 -0400

I see that the latest verion of arc firmware has been put on hold by
3com. Wow, guess the feedback some of us left regarding the annoying bug
of losing current authentication settings was not received by deaf
ears...

thanks Krish if you had any role on this one....

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rick Allan / [e-mail] | Connect to a Backbone not a Wishbone
Head of Network Engineering    |    Monmouth Internet Corporation
732-842-5366=====extension 102 |      http://www.monmouth.com
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Aaron Nabil <[e-mail]>
Subject: Re: (usr-tc) hyper arc v4.2.29 on hold
Date: 03 Aug 1999 04:11:28 -0700 (PDT)

Rick writes...
>I see that the latest verion of arc firmware has been put on hold by
>3com. Wow, guess the feedback some of us left regarding the annoying bug
>of losing current authentication settings was not received by deaf
>ears...

I must have missed something.  You mean 4.2.29 loses it's configuration
while it's running?


--
Aaron Nabil

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Clayton Zekelman <[e-mail]>
Subject: Re: (usr-tc) RE:Total Control
Date: 30 Jul 1999 15:22:41 -0400

Personally, I don't mind the "for sale" messages from other ISP's trying to
get rid of something they don't need.  Its the dealer messages that bother me.


At 02:58 PM 7/30/99 -0500, you wrote:
>-> Sorry All about the equipment posts. I thought the TCU would be an
>-> appropriate place to post TCU equipment but now I know otherwise.
>-> Best Regards,
>-> Andrew Shlensky
>
>I personally don't mind them as long as it isn't every other
>message.  I can't believe someone would mind saving a couple
>of bucks.
>
>
>Jeff Binkley
>ASA Network Computing
>
>-
> To unsubscribe to usr-tc, send an email to "[e-mail]"
> 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.
>
---
Clayton Zekelman
Managed Network Systems Inc. (MNSi)
875 Ouellette Avenue
Windsor, Ontario
N9A 4J6

tel. [phone]
fax. [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Stainforth, Matthew" <[e-mail]>
Subject: (usr-tc) cost of DSP
Date: 03 Aug 1999 10:00:07 -0300


What's the suggested retail price of a single DSP card?

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: K Mitchell <[e-mail]>
Subject: Re: (usr-tc) cost of DSP
Date: 03 Aug 1999 09:33:47 -0400

At 10:00 AM 8/3/99 -0300, you wrote:
>
>What's the suggested retail price of a single DSP card?

I can't say for certain, but from what checking around I've done recently,
it looks like $4,500-5,000


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


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Hostmaster Soho Solutions - Javier Szyszlican" <[e-mail]>
Subject: Re: (usr-tc) cost of DSP
Date: 03 Aug 1999 10:39:16 -0300

Here in Argentina a 30 channel DSP  cost $9000
-----Original Message-----


>At 10:00 AM 8/3/99 -0300, you wrote:
>>
>>What's the suggested retail price of a single DSP card?
>
>I can't say for certain, but from what checking around I've done recently,
>it looks like $4,500-5,000
>
>
>--
>Kirk Mitchell-General Manager        [e-mail]
>Keystone Connect                     Unlock Your World
>Altoona, PA   814-941-5000      http://www.keyconn.net
>
>
>-
> To unsubscribe to usr-tc, send an email to "[e-mail]"
> 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 "[e-mail]"
 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: Mike Andrews <[e-mail]>
Subject: Re: (usr-tc) hyper arc v4.2.29 on hold
Date: 03 Aug 1999 09:57:49 -0400 (EDT)

On Tue, 3 Aug 1999, Aaron Nabil wrote:

> Rick writes...
> >I see that the latest verion of arc firmware has been put on hold by
> >3com. Wow, guess the feedback some of us left regarding the annoying bug
> >of losing current authentication settings was not received by deaf
> >ears...
>
> I must have missed something.  You mean 4.2.29 loses it's configuration
> while it's running?

No, when you *upgrade* to it, your previous authentication settings from
4.1.x get wiped.


Mike Andrews (MA12) -=-=-  VP & Sysadmin, Digital Crescent, Frankfort KY
[e-mail]  -=--=-  [e-mail]  -=--=-  http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Aaron Nabil <[e-mail]>
Subject: Re: (usr-tc) hyper arc v4.2.29 on hold
Date: 03 Aug 1999 08:19:17 -0700 (PDT)

Mike Andrews writes...
>On Tue, 3 Aug 1999, Aaron Nabil wrote:
>
>> Rick writes...
>> >I see that the latest verion of arc firmware has been put on hold by
>> >3com. Wow, guess the feedback some of us left regarding the annoying bug
>> >of losing current authentication settings was not received by deaf
>> >ears...
>>
>> I must have missed something.  You mean 4.2.29 loses it's configuration
>> while it's running?
>
>No, when you *upgrade* to it, your previous authentication settings from
>4.1.x get wiped.

Ah, that explains why I didn't notice.  I store the configuration in the
flash as a text file, and when I upgraded I wiped the old config out and
reloaded it from the flash with the "do" command.

--
Aaron Nabil

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Brian Elfert <[e-mail]>
Subject: Re: (usr-tc) cost of DSP
Date: 03 Aug 1999 10:33:17 -0500 (CDT)



On Tue, 3 Aug 1999, K Mitchell wrote:

> >What's the suggested retail price of a single DSP card?
>
> I can't say for certain, but from what checking around I've done recently,
> it looks like $4,500-5,000

The SRP is by definition a fixed price set by the manufacturer.  I think
you're talking the street price.  I'm sure 3Com has a sheet with the SRPs
printed on it.

Brian


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Clayton Zekelman <[e-mail]>
Subject: Re: (usr-tc) hyper arc v4.2.29 on hold
Date: 03 Aug 1999 11:46:24 -0400

How do you store the configuration in flash as a text file?



>
>Ah, that explains why I didn't notice.  I store the configuration in the
>flash as a text file, and when I upgraded I wiped the old config out and
>reloaded it from the flash with the "do" command.
>
>--
>Aaron Nabil
>
>-
> To unsubscribe to usr-tc, send an email to "[e-mail]"
> 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.
>
---
Clayton Zekelman
Managed Network Systems Inc. (MNSi)
875 Ouellette Avenue
Windsor, Ontario
N9A 4J6

tel. [phone]
fax. [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: <[e-mail]>
Subject: (usr-tc) Error Opening Device Configuration File?
Date: 03 Aug 1999 10:55:04 -0500 (CDT)

Hello-

I recently upgraded an nmc from 5.5.0 to 6.1.17 and now when I try to get
to it in TCM I get an error opening device configuration file with a
secondary error of configuration not supported.  okay, now what did I do
wrong?

Steve


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Aaron Nabil <[e-mail]>
Subject: Re: (usr-tc) hyper arc v4.2.29 on hold
Date: 03 Aug 1999 09:27:14 -0700 (PDT)

Clayton Zekelman writes...
>How do you store the configuration in flash as a text file?

Save the configuration commands in a text file, tftp the file into
the arc, then "do" the file from the command prompt.

My process is a little more involved, but basicly the same.  I
keep a short card-specific file for each arc (has addresses & pools),
a A/B specific files that configures the chassis depending on if
it's the left or right ARC, and a common file that contains the
bulk configuration that doesn't change between arc's.  And also
a refresh file that contains tftp instructions to tftp all of
the configurations over again at once, handy for bootstrapping
a blank card.

>>Ah, that explains why I didn't notice.  I store the configuration in the
>>flash as a text file, and when I upgraded I wiped the old config out and
>>reloaded it from the flash with the "do" command.
>>
>>--
>>Aaron Nabil
>>
>>-
>> To unsubscribe to usr-tc, send an email to "[e-mail]"
>> 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.
>>
>---
>Clayton Zekelman
>Managed Network Systems Inc. (MNSi)
>875 Ouellette Avenue
>Windsor, Ontario
>N9A 4J6
>
>tel. [phone]
>fax. [phone]
>
>-
> To unsubscribe to usr-tc, send an email to "[e-mail]"
> 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.
>


--
Aaron Nabil

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: K Mitchell <[e-mail]>
Subject: Re: (usr-tc) cost of DSP
Date: 03 Aug 1999 12:25:49 -0400

At 10:33 AM 8/3/99 -0500, Brian wrote:
>On Tue, 3 Aug 1999, K Mitchell wrote:
>
>> >What's the suggested retail price of a single DSP card?
>>
>> I can't say for certain, but from what checking around I've done recently,
>> it looks like $4,500-5,000
>
>The SRP is by definition a fixed price set by the manufacturer.  I think
>you're talking the street price.  I'm sure 3Com has a sheet with the SRPs
>printed on it.

True, my guess would be that it falls somewhere in the range I quoted.
Anybody know for sure?

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


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) cost of DSP
Date: 03 Aug 1999 13:02:02 -0400 (EDT)

I just got a quote for $8900 for 2 DPS's.. that's thier opening offer.. we
still have to play the field and talk to other 3Com resellers.  I'm sure
you can go as low as $8400-$8500 for 2 if you get a hungry dealer.

Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax [phone]
[e-mail]

On Tue, 3 Aug 1999, K Mitchell wrote:

> At 10:33 AM 8/3/99 -0500, Brian wrote:
> >On Tue, 3 Aug 1999, K Mitchell wrote:
> >
> >> >What's the suggested retail price of a single DSP card?
> >>
> >> I can't say for certain, but from what checking around I've done recently,
> >> it looks like $4,500-5,000
> >
> >The SRP is by definition a fixed price set by the manufacturer.  I think
> >you're talking the street price.  I'm sure 3Com has a sheet with the SRPs
> >printed on it.
>
> True, my guess would be that it falls somewhere in the range I quoted.
> Anybody know for sure?
>
> --
> Kirk Mitchell-General Manager        [e-mail]
> Keystone Connect                     Unlock Your World
> Altoona, PA   814-941-5000      http://www.keyconn.net
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: "Steve Valiunas" <[e-mail]>
Subject: Re: (usr-tc) Error Opening Device Configuration File?
Date: 03 Aug 1999 12:10:54 -0500



You didn't upgrade TCM, and the old TCM doesn't know about the new NMC.

steve




[e-mail] on 08/03/99 10:55:04 AM

Please respond to [e-mail]

Sent by:  [e-mail]


cc:    (Steve Valiunas/MW/US/3Com)




Hello-

I recently upgraded an nmc from 5.5.0 to 6.1.17 and now when I try to get
to it in TCM I get an error opening device configuration file with a
secondary error of configuration not supported.  okay, now what did I do
wrong?

Steve


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 "[e-mail]"
 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: Greg Genge <[e-mail]>
Subject: Re: (usr-tc) cost of DSP
Date: 03 Aug 1999 14:46:17 -0600

I'll quote your $8500 and throw in a Free Palm Pilot III with the order.
Hows that for hungry. I have 16 sets in stock right now???

Regards, Greg

At 01:02 PM 8/3/99 -0400, you wrote:
>I just got a quote for $8900 for 2 DPS's.. that's thier opening offer.. we
>still have to play the field and talk to other 3Com resellers.  I'm sure
>you can go as low as $8400-$8500 for 2 if you get a hungry dealer.
>
>Paul D. Farber II
>Farber Technology
>Ph. 570-628-5303
>Fax [phone]
>[e-mail]
>
>On Tue, 3 Aug 1999, K Mitchell wrote:
>
>> At 10:33 AM 8/3/99 -0500, Brian wrote:
>> >On Tue, 3 Aug 1999, K Mitchell wrote:
>> >
>> >> >What's the suggested retail price of a single DSP card?
>> >>
>> >> I can't say for certain, but from what checking around I've done
recently,
>> >> it looks like $4,500-5,000
>> >
>> >The SRP is by definition a fixed price set by the manufacturer.  I think
>> >you're talking the street price.  I'm sure 3Com has a sheet with the SRPs
>> >printed on it.
>>
>> True, my guess would be that it falls somewhere in the range I quoted.
>> Anybody know for sure?
>>
>> --
>> Kirk Mitchell-General Manager        [e-mail]
>> Keystone Connect                     Unlock Your World
>> Altoona, PA   814-941-5000      http://www.keyconn.net
>>
>>
>> -
>>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>>  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 "[e-mail]"
> 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.
>
>

Gregory F. Genge, President, Dynavar Networking, Inc.
Toll Free  877-Dynavar (Canada and US) [phone] Main, 5003 Direct,
5005 Fax, http://www.dynavar.com
#300, 1550 - 5th Street S.W.,  Calgary, Alberta, Canada, T2R-1K3
Ascend, 3Com (USRobotics), Alteon, Cisco, Lucent (Livingston), WatchGuard,
Cacheflow, Foundry, Breezecom, Redback Networks, Shiva, Adtran, Compatible,
Microcom (Compaq), Garrett, Sonic, Cobalt.

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Ken Kirchner <[e-mail]>
Subject: (usr-tc) Pipeline vs 3Com
Date: 03 Aug 1999 16:18:15 -0500 (CDT)


Here's a somewhat theoretical question:  How fast can an Ascend P50
transfer a text based file to a 3Com HDM using Stac compression?

Basically, we have a customer who claims to routinely have gotten
approximately 500KB/s ftp downloads when his P50 was connected to an
Ascend P400.  Using a P50 (128k w/ Stac 9) connected to our TC chassis,
the best we can achieve is 130KB/s.  Using a Netgear to our TC chassis the
best we can get is 100KB/s (only Stac compression used).

Keep in mind this is over a dual channel 128k ISDN line.

Is there something we dont have set up properly?  I normally (using a
Netgear) get 15KB/s downloading .zip files and I am quite pleased.
500KB/s downloading text files seems unrealistic in light of our tests
(our test text file was a 22MB file of all zero's for good compression).

I think this customer is on crack (very good crack at that) but I want a
second (third? fourth?) opinion since I have no experience with the P400.


  Kenneth Kirchner    .o.  mailto:[e-mail]
  Asst SysAdmin       .o.  Voice [phone] Ext 108
  ShreveNet, Inc.     .o.  Fax   [phone]


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Jason Cropper" <[e-mail]>
Subject: RE: (usr-tc) Pipeline vs 3Com
Date: 03 Aug 1999 16:46:05 -0500

He is correct.  Ascend <--> Ascend employs a *proprietary* compression (I
don't remember the name, but it is on the Descend ;-) web site), not STAC.
He is incorrect about STAC.  Ascend <--> 3Com is standard stuff as far as
compression is concerned.  (He's not on crack.)

Jason Cropper
CTO
ClearSail Communications
http://www.clearsail.net


-----Original Message-----
[mailto:[e-mail]]On Behalf Of Ken Kirchner
Sent: Tuesday, August 03, 1999 16:18



Here's a somewhat theoretical question:  How fast can an Ascend P50
transfer a text based file to a 3Com HDM using Stac compression?

Basically, we have a customer who claims to routinely have gotten
approximately 500KB/s ftp downloads when his P50 was connected to an
Ascend P400.  Using a P50 (128k w/ Stac 9) connected to our TC chassis,
the best we can achieve is 130KB/s.  Using a Netgear to our TC chassis the
best we can get is 100KB/s (only Stac compression used).

Keep in mind this is over a dual channel 128k ISDN line.

Is there something we dont have set up properly?  I normally (using a
Netgear) get 15KB/s downloading .zip files and I am quite pleased.
500KB/s downloading text files seems unrealistic in light of our tests
(our test text file was a 22MB file of all zero's for good compression).

I think this customer is on crack (very good crack at that) but I want a
second (third? fourth?) opinion since I have no experience with the P400.


  Kenneth Kirchner    .o.  mailto:[e-mail]
  Asst SysAdmin       .o.  Voice [phone] Ext 108
  ShreveNet, Inc.     .o.  Fax   [phone]


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 "[e-mail]"
 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: "Brett Murphy" <[e-mail]>
Subject: Re: (usr-tc) cost of DSP
Date: 04 Aug 1999 09:36:45 +1000

In Australia they are $18,000 AUD Inc Tax retail
Thats why I shop in USA.......

All the best,
Brett Murphy
Technical Manager, Alphalink (Australia) PTY LTD
ph: [phone]  fax: [phone]
email: [e-mail]

The contents of this email message may not be quoted,
copied, reproduced or published in part or in whole,
without the written authorization of Brett Murphy,
Director, Alphalink (Australia) Pty Ltd.

-----Original Message-----


>At 10:00 AM 8/3/99 -0300, you wrote:
>>
>>What's the suggested retail price of a single DSP card?
>
>I can't say for certain, but from what checking around I've done recently,
>it looks like $4,500-5,000
>
>
>--
>Kirk Mitchell-General Manager        [e-mail]
>Keystone Connect                     Unlock Your World
>Altoona, PA   814-941-5000      http://www.keyconn.net
>
>
>-
> To unsubscribe to usr-tc, send an email to "[e-mail]"
> 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 "[e-mail]"
 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: Mike Andrews <[e-mail]>
Subject: Re: (usr-tc) hyper arc v4.2.29 on hold
Date: 03 Aug 1999 19:57:16 -0400 (EDT)

> Ah, that explains why I didn't notice.  I store the configuration in the
> flash as a text file, and when I upgraded I wiped the old config out and
> reloaded it from the flash with the "do" command.

How'd you save it as a text file?  Can you export a live config as text
(a la Cisco) or do you just keep a record of the config commands as you
enter them and save that?  As far as I know you can't export a live config
as text, but I'd love to be proven wrong...


Mike Andrews (MA12) -=-=-  VP & Sysadmin, Digital Crescent, Frankfort KY
[e-mail]  -=--=-  [e-mail]  -=--=-  http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: das <[e-mail]>
Subject: (usr-tc) HiperDSP interface down
Date: 04 Aug 1999 09:29:48 +0900

Hi,

Got an HDM running 1.3.99, a beta PIAFs code.

When I do a li int, I get:

<snip>
slot:6/mod:10                   Up      Up
slot:6/mod:11                   Up      Up
slot:6/mod:12                   Up      Up
slot:6/mod:13                   Up      Up
slot:6/mod:14                   Up      Up
slot:6/mod:15                   Down    Up
slot:6/mod:16                   Up      Up
slot:6/mod:17                   Up      Up
slot:6/mod:18                   Up      Up
slot:6/mod:19                   Up      Up
</snip>

Does anyone have any suggestions on how to bring this interface up?

Thanks,

das


--
____________________________________________
Alex Substanley       Global OnLine Japan
                Engineering Department
Das Man               TEL: [phone]
Systems Engineer      FAX: [phone]
  The Highest Quality Service, Bar None
____________________________________________

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) hyper arc v4.2.29 on hold
Date: 03 Aug 1999 21:00:44 -0400 (EDT)

Thus spake Mike Andrews
>> Ah, that explains why I didn't notice.  I store the configuration in the
>> flash as a text file, and when I upgraded I wiped the old config out and
>> reloaded it from the flash with the "do" command.

>How'd you save it as a text file?  Can you export a live config as text
>(a la Cisco) or do you just keep a record of the config commands as you
>enter them and save that?  As far as I know you can't export a live config
>as text, but I'd love to be proven wrong...

There is a way to save a bulk configuration out to a file in the HiPer
Arc's filesystem...then you should be able to upload it via tftp or
something.  Not sure how off the top of my head, but I think I may have
mentioned it in a post a few weeks ago, so it should be in the archive.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Tatai SV Krishnan <[e-mail]>
Subject: Re: (usr-tc) HiperDSP interface down
Date: 03 Aug 1999 21:11:14 -0500 (CDT)

On Wed, 4 Aug 1999, das wrote:

> Hi,
>
> Got an HDM running 1.3.99, a beta PIAFs code.
>
> When I do a li int, I get:
>
> <snip>
> slot:6/mod:10                   Up      Up
> slot:6/mod:11                   Up      Up
> slot:6/mod:12                   Up      Up
> slot:6/mod:13                   Up      Up
> slot:6/mod:14                   Up      Up
> slot:6/mod:15                   Down    Up
> slot:6/mod:16                   Up      Up
> slot:6/mod:17                   Up      Up
> slot:6/mod:18                   Up      Up
> slot:6/mod:19                   Up      Up
> </snip>
>

A interface goes down due to communication error in the packet bus
communication.  Typically this error could be caused either by HDM or
HiPer arc.  The root cause of the error can only be indentified if we
know both version of code.  However if you are using 4.1.59-6 code then
this error is due to DSP - if you are using anything other than 4.1.59-6
or to say if you are using any code that is older than 4.1.59-6 - like
4.1.11 etc the problem could be the hiper arc/dsp.

To get back the interface either you can reboot the dsp or the hiper
arc.  Sometimes you may have to reboot the entire chassis.  So tell me
what version of hiper arc code you are using based on that we can pin
point the problem,  Also you may want to ask the person who gave you this
dsp code if the packet bus fixes for interface down are in this code?

regards

krish

> Does anyone have any suggestions on how to bring this interface up?
>
> Thanks,
>
> das
>
>
> --
> ____________________________________________
> Alex Substanley       Global OnLine Japan
>                 Engineering Department
> Das Man               TEL: [phone]
> Systems Engineer      FAX: [phone]
>   The Highest Quality Service, Bar None
> ____________________________________________
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: Tatai SV Krishnan <[e-mail]>
Subject: Re: (usr-tc) hyper arc v4.2.29 on hold
Date: 03 Aug 1999 21:20:45 -0500 (CDT)

The way to set up bulk file is


on the hiper arc you first setup a bulk file.

set bulkfile <name of a config file>

the next command is

save configuration

now a file with all your configuration will be created and this file will
be called the name you gave with the set command.  You can take this file
tftp it to another hiper arc and do the sec bulkfile "name of this file"
and then reboot the hiper arc without a save - that will resote the
configuration saved on the bulk file.

krish

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

On Tue, 3 Aug 1999, Jeff Mcadams wrote:

> Thus spake Mike Andrews
> >> Ah, that explains why I didn't notice.  I store the configuration in the
> >> flash as a text file, and when I upgraded I wiped the old config out and
> >> reloaded it from the flash with the "do" command.
>
> >How'd you save it as a text file?  Can you export a live config as text
> >(a la Cisco) or do you just keep a record of the config commands as you
> >enter them and save that?  As far as I know you can't export a live config
> >as text, but I'd love to be proven wrong...
>
> There is a way to save a bulk configuration out to a file in the HiPer
> Arc's filesystem...then you should be able to upload it via tftp or
> something.  Not sure how off the top of my head, but I think I may have
> mentioned it in a post a few weeks ago, so it should be in the archive.
> --
> Jeff McAdams                            Email: [e-mail]
> Head Network Administrator              Voice: [phone]
> IgLou Internet Services                        [phone]
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: Allen Marsalis <[e-mail]>
Subject: (usr-tc) TC SS7 gateway?
Date: 03 Aug 1999 21:44:03 -0500

Hi All,

About a year ago, maybe longer, our 3COM rep came to visit us and
gave some hints on future plans and products..  One thing that he
had mentioned was SS7 connectivity right in the Total Control
chassis.  For CLEC's, Data-CLECS's (DLEC's), or whatever, this
could be a significant advancement if a carrier-class tandem switch
is no longer needed to terminate modem calls.

Anyway, is there any word on when this might actually happen?
Or has it already happened?

A while back, I had heard that both Lucent and Ascent had SS7 on
the PM and Max TNT respectively...  I also heard that Lucent has
now dropped the Portmaster and Lucent salespeople are now pushing
Ascend...

Am I behind the times or what?  8-)

Allen


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: das <[e-mail]>
Subject: Re: (usr-tc) HiperDSP interface down
Date: 04 Aug 1999 11:51:20 +0900

Thanks, Krish.  This one is running 4.1.7 (looks like I've missed this one)

das

Tatai SV Krishnan ([e-mail]) spake:

> On Wed, 4 Aug 1999, das wrote:
>
> > Hi,
> >
> > Got an HDM running 1.3.99, a beta PIAFs code.
> >
> > When I do a li int, I get:
> >
> > <snip>
> > slot:6/mod:10                   Up      Up
> > slot:6/mod:11                   Up      Up
> > slot:6/mod:12                   Up      Up
> > slot:6/mod:13                   Up      Up
> > slot:6/mod:14                   Up      Up
> > slot:6/mod:15                   Down    Up
> > slot:6/mod:16                   Up      Up
> > slot:6/mod:17                   Up      Up
> > slot:6/mod:18                   Up      Up
> > slot:6/mod:19                   Up      Up
> > </snip>
> >
>
> A interface goes down due to communication error in the packet bus
> communication.  Typically this error could be caused either by HDM or
> HiPer arc.  The root cause of the error can only be indentified if we
> know both version of code.  However if you are using 4.1.59-6 code then
> this error is due to DSP - if you are using anything other than 4.1.59-6
> or to say if you are using any code that is older than 4.1.59-6 - like
> 4.1.11 etc the problem could be the hiper arc/dsp.
>
> To get back the interface either you can reboot the dsp or the hiper
> arc.  Sometimes you may have to reboot the entire chassis.  So tell me
> what version of hiper arc code you are using based on that we can pin
> point the problem,  Also you may want to ask the person who gave you this
> dsp code if the packet bus fixes for interface down are in this code?
>
> regards
>
> krish
>
> > Does anyone have any suggestions on how to bring this interface up?
> >
> > Thanks,
> >
> > das
> >
> >
> > --
> > ____________________________________________
> > Alex Substanley       Global OnLine Japan
> >                 Engineering Department
> > Das Man               TEL: [phone]
> > Systems Engineer      FAX: [phone]
> >   The Highest Quality Service, Bar None
> > ____________________________________________
> >
> > -
> >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> >  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 "[e-mail]"
>  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.

--
____________________________________________
Alex Substanley       Global OnLine Japan
                Engineering Department
Das Man               TEL: [phone]
Systems Engineer      FAX: [phone]
  The Highest Quality Service, Bar None
____________________________________________

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Aaron Nabil <[e-mail]>
Subject: Re: (usr-tc) hyper arc v4.2.29 on hold
Date: 04 Aug 1999 05:17:15 -0700 (PDT)

Tatai SV Krishnan writes...
>The way to set up bulk file is
>
>on the hiper arc you first setup a bulk file.
>
>set bulkfile <name of a config file>
>
>the next command is
>
>save configuration
>
>now a file with all your configuration will be created and this file will
>be called the name you gave with the set command.  You can take this file
>tftp it to another hiper arc and do the sec bulkfile "name of this file"
>and then reboot the hiper arc without a save - that will resote the
>configuration saved on the bulk file.

Unfortunatly the bulk file isn't editable text.  :(

-a

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Mike Andrews <[e-mail]>
Subject: Re: (usr-tc) hyper arc v4.2.29 on hold
Date: 04 Aug 1999 12:42:25 -0400 (EDT)

On Wed, 4 Aug 1999, Aaron Nabil wrote:

> Tatai SV Krishnan writes...
> >The way to set up bulk file is
> >
> >on the hiper arc you first setup a bulk file.
> >
> >set bulkfile <name of a config file>
> >
> >the next command is
> >
> >save configuration
> >
> >now a file with all your configuration will be created and this file will
> >be called the name you gave with the set command.  You can take this file
> >tftp it to another hiper arc and do the sec bulkfile "name of this file"
> >and then reboot the hiper arc without a save - that will resote the
> >configuration saved on the bulk file.
>
> Unfortunatly the bulk file isn't editable text.  :(

...and that was the basis of my question.  I already knew about the bulk
save/restore stuff.  I'd just like to have a way to crank it out in text
instead of binary so I can do comparisons.

Currently I'm doing what it seems like everyone else is doing -- keeping
text files of the commands we've entered to set the box up, and if
something freaks, we can just cut and paste it back in.  But if you have a
problem like the one 4.2.29 caused where it wiped SOME of your settings
but not all of them, it sure would be nice if you could dump the config
out in text and do a diff to see what changed.

Hell, even Xyplex came up with a way to do this.  They had a util called
"apgen" that would take the bulk config in binary (which had been written
via tftp), parse it, and spit out a text file you could use to recreate
the config on a different box.  That enabled us to tweak a running box in
various ways until it behaved right, and then generate a template for new
boxes from that, rather than the other way around.

Ascend sort-of has something similar; their bulk save is in text, even
though the config mechanism isn't a command line.

3Com isn't the only one that doesn't have this feature of course...
Lucent's ComOS comes to mind.


Mike Andrews (MA12) -=-=-  VP & Sysadmin, Digital Crescent, Frankfort KY
[e-mail]  -=--=-  [e-mail]  -=--=-  http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Aaron Nabil <[e-mail]>
Subject: Re: (usr-tc) hyper arc v4.2.29 on hold
Date: 04 Aug 1999 10:36:48 -0700 (PDT)

Mike Andrews writes...
>On Wed, 4 Aug 1999, Aaron Nabil wrote:
>
>> Tatai SV Krishnan writes...
>> >The way to set up bulk file is
>> >
>> >on the hiper arc you first setup a bulk file.
>> >
>> >set bulkfile <name of a config file>
>> >
>> >the next command is
>> >
>> >save configuration
>> >
>> >now a file with all your configuration will be created and this file will
>> >be called the name you gave with the set command.  You can take this file
>> >tftp it to another hiper arc and do the sec bulkfile "name of this file"
>> >and then reboot the hiper arc without a save - that will resote the
>> >configuration saved on the bulk file.
>>
>> Unfortunatly the bulk file isn't editable text.  :(
>
>...and that was the basis of my question.  I already knew about the bulk
>save/restore stuff.  I'd just like to have a way to crank it out in text
>instead of binary so I can do comparisons.
>
>Currently I'm doing what it seems like everyone else is doing -- keeping
>text files of the commands we've entered to set the box up, and if
>something freaks, we can just cut and paste it back in.

Right.  Just to be clear, I'm not using the bulk config at all, I'm
just automating the cutting-and-pasting part by transfering the text file
over to the flash.

If I think this card is hosed, or I did an upgrade, or I want to re-configure
the card to think it's a different card, it literally takes about 15 seconds
to wipe the config clean and reload it from the flash files.


--
Aaron Nabil

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: <[e-mail]>
Subject: (usr-tc) Now for my next problem, HiperDSP upgrade
Date: 04 Aug 1999 14:13:41 -0500 (CDT)

Hello-

Thanks for the help with the TCM update problem.  I had actually figured
that out right after I sent the message, that's how it usually goes.

I'm having a problem getting HiperDSP's or the HiperARC to accept new
software via TCM.  Even trying to do it via HyperTerm and rebooting the
card won't work.

I've tried the archive website but it appears to not let me search.  Any
tips?

Running DSP Code 1.2.60 trying to get 1.2.37
Running NMC Code 6.1.17
Running HiperARC code 4.1.59 trying to get to 4.2.29


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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" <[e-mail]>
Subject: (usr-tc) Switch type
Date: 04 Aug 1999 12:38:36 -0700

Will a DSP running 2.0.81 work with a DMS10.
There is no setting for it. Should I just tell it
it's DMS100 or is there a generic phone switch type.
I am replacing Quads and there T1 card. These lines
are ct1's running ami.

Terry Kennedy

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Clayton Zekelman <[e-mail]>
Subject: Re: (usr-tc) Switch type
Date: 04 Aug 1999 16:25:51 -0400

If you're running CT1, the signalMode should be set to robbedBit.  The
Primary Switch Type  setting does not matter in robbedBit signal mode.

At 12:38 PM 8/4/99 -0700, you wrote:
>Will a DSP running 2.0.81 work with a DMS10.
>There is no setting for it. Should I just tell it
>it's DMS100 or is there a generic phone switch type.
>I am replacing Quads and there T1 card. These lines
>are ct1's running ami.
>
>Terry Kennedy
>
>-
> To unsubscribe to usr-tc, send an email to "[e-mail]"
> 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.
>
---
Clayton Zekelman
Managed Network Systems Inc. (MNSi)
875 Ouellette Avenue
Windsor, Ontario
N9A 4J6

tel. [phone]
fax. [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: (usr-tc) Looked but can't find this
Date: 04 Aug 1999 17:34:07 -0400 (EDT)

OK...I've looked but can't find this...

I've got a user that is occasionally getting "NAS-Error" for a terminate
cause on his account from the Arc.

Anyone have any idea what would cause this in an Arc?
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Richard Lorbieski <[e-mail]>
Subject: (usr-tc) 3Com Modem tradeup
Date: 04 Aug 1999 17:16:50 -0500

We merge another ISP with ours and inherireted some old USR equipment.
Thet're not QUAD cards. They are 2 modems on a one slot (analog) and are
housed in a Total Control Chassis. The power supplies are 35 AMP.

Do these modems qualify for the Double Play package?
--

Richard Lorbieski - [e-mail]
Chief Technical Officer - Senior System Administrator
Alpha1 Internet  http://www.alpha1.net
409.731.8236  - 877.4.alpha1 (877.425.7421)

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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" <[e-mail]>
Subject: RE: (usr-tc) Switch type
Date: 04 Aug 1999 15:23:33 -0700

Thanks for the help.

-----Original Message-----
[mailto:[e-mail]]On Behalf Of Clayton Zekelman
Sent: Wednesday, August 04, 1999 1:26 PM


If you're running CT1, the signalMode should be set to robbedBit.  The
Primary Switch Type  setting does not matter in robbedBit signal mode.

At 12:38 PM 8/4/99 -0700, you wrote:
>Will a DSP running 2.0.81 work with a DMS10.
>There is no setting for it. Should I just tell it
>it's DMS100 or is there a generic phone switch type.
>I am replacing Quads and there T1 card. These lines
>are ct1's running ami.
>
>Terry Kennedy
>
>-
> To unsubscribe to usr-tc, send an email to "[e-mail]"
> 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.
>
---
Clayton Zekelman
Managed Network Systems Inc. (MNSi)
875 Ouellette Avenue
Windsor, Ontario
N9A 4J6

tel. [phone]
fax. [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 "[e-mail]"
 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: "Mike Wronski" <[e-mail]>
Subject: RE: (usr-tc) 3Com Modem tradeup
Date: 04 Aug 1999 17:23:26 -0500



|-----Original Message-----
|From: [e-mail]
|[mailto:[e-mail]]On Behalf Of Richard Lorbieski
|Sent: Wednesday, August 04, 1999 5:17 PM
|To: [e-mail]
|Subject: (usr-tc) 3Com Modem tradeup
|
|
|We merge another ISP with ours and inherireted some old USR equipment.
|Thet're not QUAD cards. They are 2 modems on a one slot (analog) and are
|housed in a Total Control Chassis. The power supplies are 35 AMP.
|
|Do these modems qualify for the Double Play package?

Dont know about Double Play, but they do qualify for a museum exhibit.. :)..

-M


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Stephen Amadei <[e-mail]>
Subject: Re: (usr-tc) 3Com Modem tradeup
Date: 04 Aug 1999 17:36:59 -0400 (EDT)

On Wed, 4 Aug 1999, Richard Lorbieski wrote:

> We merge another ISP with ours and inherireted some old USR equipment.
> Thet're not QUAD cards. They are 2 modems on a one slot (analog) and are
> housed in a Total Control Chassis. The power supplies are 35 AMP.
>
> Do these modems qualify for the Double Play package?

These are older Dual Analog Modem Cards... I'm pretty sure they do not
qualify... only Quads.  Besides, the double up package ended July 31st.

                    ----Steve
Stephen Amadei
Director of MIS
Dandy Connections, Inc.
Atlantic City, NJ


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) 3Com Modem tradeup
Date: 04 Aug 1999 18:57:29 -0400 (EDT)

Thus spake Richard Lorbieski
>We merge another ISP with ours and inherireted some old USR equipment.
>Thet're not QUAD cards. They are 2 modems on a one slot (analog) and are
>housed in a Total Control Chassis. The power supplies are 35 AMP.

Wow...someone else has some duals still in use?  I thought we were the
only place with any left!  :)

>Do these modems qualify for the Double Play package?

I highly doubt it.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Ralph Helfenberger <[e-mail]>
Subject: (usr-tc) Is there a command to completely turn of Chap Authentication on the
Date: 05 Aug 1999 09:38:40 +0200

Hi all
Is there a command wich allows to completely turn off CHAP Authentication on
the Netserver (version 3.8.1)?
I could only find the

set chapfst off

command

Thanks
Ralph

--
==========================================================================
R. Helfenberger                Internet  [e-mail]
Comlight AG                    Tel  [phone]
Tennisweg 21                   Fax  [phone]
3178 Boesingen
Switzerland                    www.comlight.ch
==========================================================================



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Mini Computer Room T-5" <[e-mail]>
Subject: (usr-tc) v.42 selective reject on dsp
Date: 05 Aug 1999 10:53:14 -0300

a couple years ago,there was a problem with selective reject on hiper dsp's
We have it disabled since then
I was wondering if it's ok now; is it ok to enable it?
thanks,

Mario

[e-mail]


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Tatai SV Krishnan <[e-mail]>
Subject: Re: (usr-tc) Looked but can't find this
Date: 05 Aug 1999 09:00:17 -0500 (CDT)

On Wed, 4 Aug 1999, Jeff Mcadams wrote:

> OK...I've looked but can't find this...
>
> I've got a user that is occasionally getting "NAS-Error" for a terminate
> cause on his account from the Arc.

NAS error is a error detected by the NAS - it is not anyway related to
modem/port, it basically revolves around PPP framing or data related
error that is being processed by the NAS.

krish

>
> Anyone have any idea what would cause this in an Arc?
> --
> Jeff McAdams                            Email: [e-mail]
> Head Network Administrator              Voice: [phone]
> IgLou Internet Services                        [phone]
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: "Brian Hitchcock" <[e-mail]>
Subject: Re: (usr-tc) v.42 selective reject on dsp
Date: 05 Aug 1999 09:02:59 -0500

DO they sell BRI ISDN cards for a Total control case? And if so what do they
run?
Brian Hitchcock
KC Web
----- Original Message -----
Sent: Thursday, August 05, 1999 8:53 AM


> a couple years ago,there was a problem with selective reject on hiper
dsp's
> We have it disabled since then
> I was wondering if it's ok now; is it ok to enable it?
> thanks,
>
> Mario
>
> [e-mail]
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: <[e-mail]>
Subject: (usr-tc) ISDN Call control option
Date: 05 Aug 1999 11:41:46 -0400 (EDT)


    I would like to know what the proper setting is for
Set Originate HDLC Protocol  One hub has: none the other has PPP.  We do
not do any DIALOUT from the site... Does this make a difference for modem
performance itself?

  Thanks in advance!

==============================================================================
Phillip Ferraro                WorldNet Access, Inc
[e-mail]    Onslow County's PREMIER InterNet Service
Voice [phone]            824 Gumbranch Square, Suite R3
FAX   [phone]             Jacksonville, Nc  28540-6269
==============================================================================



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: K Mitchell <[e-mail]>
Subject: (usr-tc) CustoFlex ISDN
Date: 05 Aug 1999 13:13:20 -0400

  Anybody in Bell Atlantic land have ISDN customers using CustoFlex BRI
lines? I have a customer wanting one, and I'm being told that he cannot
call into my PRIs with it, that I need to install a matching CustoFlex BRI
line or dedicate an entire PRI to CustoFlex. On that note, is there a BRI
DSP card or equivalent for HiPer chassis?

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


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Cheryl Johnson" <[e-mail]>
Subject: (usr-tc) Hiper DSP code 2.0.19
Date: 05 Aug 1999 13:55:41 -0500

This is a multi-part message in MIME format.

------=_NextPart_000_003C_01BEDF4A.34BEB540
Content-Type: text/plain;
    charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Having problem getting the DSP code 2.0.19 to download to the HiPerDSP =
cards through TCM remotely...seems the TCM does not even recognize the =
software is there to download...Anyone else having these problems? I am =
currently using the NMC version 5.5.5 on most of the chassis' we have in =
the process of downloading new NMC code 6.1.17 ...seems to download =
fine..

-Cheryl

------=_NextPart_000_003C_01BEDF4A.34BEB540
Content-Type: text/html;
    charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML><HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<STYLE></STYLE>

<META content=3D'"MSHTML 5.00.0910.1309"' name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Having problem getting the DSP code 2.0.19 to =
download to the=20
HiPerDSP cards through TCM remotely...seems the TCM does not even =
recognize the=20
software is there to download...Anyone else having these problems? I am=20
currently using the NMC version 5.5.5 on most of the chassis' we have in =
the=20
process of downloading new NMC code 6.1.17 ...seems to download=20
fine..</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>-Cheryl</FONT></DIV></BODY></HTML>

------=_NextPart_000_003C_01BEDF4A.34BEB540--


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Jim Johnson <[e-mail]>
Subject: (usr-tc) Locating a bad port on DSP
Date: 05 Aug 1999 15:20:54 -0400



We have a port which must have gone bad on one of our DSPs.

The line picks up and then just makes a steady whining sound until the
client modem times out.

I have narrowed it down to one TC Chassis, but it has eight DSPs in it.

What is the quickest way to isolate the offending port/DSP card?

Thanks,

Jim

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Jim Johnson <[e-mail]>
Subject: Re: (usr-tc) Locating a bad port on DSP
Date: 05 Aug 1999 15:48:02 -0400



I found the bad port(s) by using TCM to show Modem Events => Incoming
Connections Failed   The numbers stood out like a sore thumb and it
turned out to be two ports.  The hiper ports always go in pairs don't
they?

Fortunately, the problem went away with a software reset.

But, back to the original question, is that the best way?

Regards,

Jim

Jim Johnson wrote:
>
> We have a port which must have gone bad on one of our DSPs.
>
> The line picks up and then just makes a steady whining sound until the
> client modem times out.
>
> I have narrowed it down to one TC Chassis, but it has eight DSPs in it.
>
> What is the quickest way to isolate the offending port/DSP card?
>
> Thanks,
>
> Jim
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: Ken Kirchner <[e-mail]>
Subject: Re: (usr-tc) Locating a bad port on DSP
Date: 05 Aug 1999 15:26:01 -0500 (CDT)

Our SysAdmin wrote a program that sends us an e-mail once a day containing
the total calls connected/failed and the ratio for each modem in our
chassis'.

This lets us see which cards are not performing well in relation to the
rest of the cards in the chassis.  It also keeps us informed on a daily
basis. It's very helpful in troubleshooting.  I dont know if it's the
"best" way, but it works for us.

Wouldnt it be nice if 3Com or someone would make some type of cross-over
cable and software to hook between two HDM's so you could use one to check
out the other?

On Thu, 5 Aug 1999, Jim Johnson wrote:

> I found the bad port(s) by using TCM to show Modem Events => Incoming
> Connections Failed   The numbers stood out like a sore thumb and it
> turned out to be two ports.  The hiper ports always go in pairs don't
> they?
>
> Fortunately, the problem went away with a software reset.
>
> But, back to the original question, is that the best way?

  ___                                                         ___
 (___) Kenneth Kirchner    .o.  mailto:[e-mail]       (___)
  (__) Asst SysAdmin       .o.  Voice [phone] Ext 108 (__)
   (_) ShreveNet, Inc.     .o.  Fax   [phone]         (_)


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Pete Ashdown <[e-mail]>
Subject: Re: (usr-tc) Locating a bad port on DSP
Date: 05 Aug 1999 14:42:00 -0600 (MDT)

Jim Johnson said once upon a time:

>I found the bad port(s) by using TCM to show Modem Events => Incoming
>Connections Failed   The numbers stood out like a sore thumb and it
>turned out to be two ports.  The hiper ports always go in pairs don't
>they?
>
>Fortunately, the problem went away with a software reset.

I've been having the same issues with DSPs for a while.  Now I'm running
into situations where a reset doesn't cure the card.  It just moves to a
different channel.  The only fix I've found is to power down the entire
chassis (253 lines) and let it sit for a couple minutes then power up with
all the PRIs unplugged.  Once the chassis has returned to service, then I
can put the PRIs back in.

Highly annoying when it happens, because the cure affects a significant
portion of our pool.  I wish I had a 3com engineer near so they could see
the card repeatedly rejecting calls, even after a reset.

>But, back to the original question, is that the best way?

I have a perl script that runs every two hours that checks the ratio of
calls established to calls failed and if it is past a certain threshhold,
it will busy out the entire PRI.  Then it sends me a page alerting me of
the fact.

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Ed" <[e-mail]>
Subject: Re: (usr-tc) Looked but can't find this
Date: 05 Aug 1999 11:54:22 -0400

Ok so what EXACTLY causes the NAS error? We see them quite often...

Also when will the update for the latest code that was put on hold be out?


Ed Taylor
[e-mail]
FIRST Inc.

----- Original Message -----
Cc: <[e-mail]>
Sent: Thursday, August 05, 1999 10:00 AM


On Wed, 4 Aug 1999, Jeff Mcadams wrote:

> OK...I've looked but can't find this...
>
> I've got a user that is occasionally getting "NAS-Error" for a terminate
> cause on his account from the Arc.

NAS error is a error detected by the NAS - it is not anyway related to
modem/port, it basically revolves around PPP framing or data related
error that is being processed by the NAS.

krish

>
> Anyone have any idea what would cause this in an Arc?
> --
> Jeff McAdams                            Email: [e-mail]
> Head Network Administrator              Voice: [phone]
> IgLou Internet Services                        [phone]
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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 "[e-mail]"
 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: Jim Johnson <[e-mail]>
Subject: Re: (usr-tc) Locating a bad port on DSP
Date: 05 Aug 1999 16:43:36 -0400


Ken,

Assuming that the script was written in PERL and uses SNMP that would be
a useful script to have because it could probably be fairly easily
modified to incorporate other OIDs for critical monitoring purposes.

Would you be willing to email it to the list?

Jim

Ken Kirchner wrote:
>
> Our SysAdmin wrote a program that sends us an e-mail once a day containing
> the total calls connected/failed and the ratio for each modem in our
> chassis'.
>
> This lets us see which cards are not performing well in relation to the
> rest of the cards in the chassis.  It also keeps us informed on a daily
> basis. It's very helpful in troubleshooting.  I dont know if it's the
> "best" way, but it works for us.
>
> Wouldnt it be nice if 3Com or someone would make some type of cross-over
> cable and software to hook between two HDM's so you could use one to check
> out the other?
>
> On Thu, 5 Aug 1999, Jim Johnson wrote:
>
> > I found the bad port(s) by using TCM to show Modem Events => Incoming
> > Connections Failed   The numbers stood out like a sore thumb and it
> > turned out to be two ports.  The hiper ports always go in pairs don't
> > they?
> >
> > Fortunately, the problem went away with a software reset.
> >
> > But, back to the original question, is that the best way?
>
>   ___                                                         ___
>  (___) Kenneth Kirchner    .o.  mailto:[e-mail]       (___)
>   (__) Asst SysAdmin       .o.  Voice [phone] Ext 108 (__)
>    (_) ShreveNet, Inc.     .o.  Fax   [phone]         (_)
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: Mr Bill <[e-mail]>
Subject: (usr-tc) Bulk config file text decoder program - 3COM???
Date: 04 Aug 1999 21:59:16 -0700 (PDT)

Tatai SV Krishnan / Mike Wronski,

Somebody in 3COM's AE department once told me that they
had developed a Unix-based program which could translate a file in bulk
config file format to/from
an ASCII text file.

Is this tool publically available?

For which versions of the HARC is this tool available?

Integrating this tool into the HARC itself or into
HARM or TCM seems like the way to go...




_____________________________________________________________
Do You Yahoo!?
Free instant messaging and more at http://messenger.yahoo.com

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Dan Hollis <[e-mail]>
Subject: Re: (usr-tc) Locating a bad port on DSP
Date: 05 Aug 1999 13:46:33 -0700 (PDT)

On Thu, 5 Aug 1999, Pete Ashdown wrote:
> I've been having the same issues with DSPs for a while.  Now I'm running
> into situations where a reset doesn't cure the card.  It just moves to a
> different channel.  The only fix I've found is to power down the entire
> chassis (253 lines) and let it sit for a couple minutes then power up with
> all the PRIs unplugged.  Once the chassis has returned to service, then I
> can put the PRIs back in.

Hows the cooling situation on the chassis? Ive had other vendors equipment
(not 3com, yet) act very strange when it overheats.

-Dan


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Randy Cosby" <[e-mail]>
Subject: RE: (usr-tc) Locating a bad port on DSP
Date: 05 Aug 1999 14:46:09 -0600

Wouldn't it be nice if your admin  shared that program :)

Randy
InfoWest


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Ken Kirchner
> Sent: Thursday, August 05, 1999 2:26 PM
> To: [e-mail]
> Subject: Re: (usr-tc) Locating a bad port on DSP
>
>
> Our SysAdmin wrote a program that sends us an e-mail once a day containing
> the total calls connected/failed and the ratio for each modem in our
> chassis'.
>
> This lets us see which cards are not performing well in relation to the
> rest of the cards in the chassis.  It also keeps us informed on a daily
> basis. It's very helpful in troubleshooting.  I dont know if it's the
> "best" way, but it works for us.
>
> Wouldnt it be nice if 3Com or someone would make some type of cross-over
> cable and software to hook between two HDM's so you could use one to check
> out the other?
>
> On Thu, 5 Aug 1999, Jim Johnson wrote:
>
> > I found the bad port(s) by using TCM to show Modem Events => Incoming
> > Connections Failed   The numbers stood out like a sore thumb and it
> > turned out to be two ports.  The hiper ports always go in pairs don't
> > they?
> >
> > Fortunately, the problem went away with a software reset.
> >
> > But, back to the original question, is that the best way?
>
>   ___                                                         ___
>  (___) Kenneth Kirchner    .o.  mailto:[e-mail]       (___)
>   (__) Asst SysAdmin       .o.  Voice [phone] Ext 108 (__)
>    (_) ShreveNet, Inc.     .o.  Fax   [phone]         (_)
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: Pete Ashdown <[e-mail]>
Subject: Re: (usr-tc) Question.
Date: 05 Aug 1999 14:56:10 -0600 (MDT)

Paul M. Oster said once upon a time:

>instead of username... the .shell extension clues off my radius that this
>is a telnet type connection, NOT a ppp connection.  Anything else is
>assumed to be ppp.  Works great, and in my case, only like 50/3500 users
>ever USE their shell account via telnet, and only may 10 of them dial in
>directly.  I've only done this with Cistron Radiusd, and not anything else
>(in fact that was one of my MANY reasons for switching to cistron)

I do "username@shell" with modifications I made to Merit's RADIUS.

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Ed" <[e-mail]>
Subject: Re: (usr-tc) Not True - Dynavar Quad trade in deal.
Date: 30 Jul 1999 20:36:45 -0400

No these are facts. Buy some of those Trade deals from Dynavar and see for
yourself.
If it does work you are not doing it legally by what 3com states on the
rules of the program.

Also I do not believe this list was made for these reasons and thus Dynavar
you are Spamming the list.
People don't wish to receive this sort of stuff from this list. It is meant
for technical purposes....not sales.


Ed

----- Original Message -----
Sent: Friday, July 30, 1999 5:12 PM


Whoever ED is with the Anonymous posting about Dynavar is absolutely
uncorrect. If you truely have something to say, post your name, company and
phone number and say whatever you want. Dynavar is following the rules of
the trade-in program to the letter and will guarantee that all trade-ins
will be accepted. If you have any concern, I would like to have the
appropriate 3COM rep in your area call you to confirm that this is
absolutely not true.

I have heard that another large 3COM VAR has been spreading this rumor in
order to win business away from Dynavar. I won't mention their name to give
them the benefit of the doubt, but In my opinion , if true, this is a very
slimey tactic against Dynavar and is completely unwarranted.

They have changed one rule stating that all Quad cards must be owned by the
customer for 120 days which should not affect any legitimate trade-in's.

To all of you who are voting with their dollars, thanks for your support.

Regards, Greg

At 10:37 PM 7/29/99 -0400, you wrote:
>Be Aware.3Com is aware of the games that Dynavar is playing with the quad
>trade in deal.  They will not be accepting quad trade ins from Dyanavar
>Customers.
>
>http://www.3com.com/promotions/hipertrade/quad_to_hiper_rules.html
>
>
>Ed
>
>-
> To unsubscribe to usr-tc, send an email to "[e-mail]"
> 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.
>
>

Gregory F. Genge, President, Dynavar Networking, Inc.
Toll Free  877-Dynavar (Canada and US) [phone] Main, 5003 Direct,
5005 Fax, http://www.dynavar.com
#300, 1550 - 5th Street S.W.,  Calgary, Alberta, Canada, T2R-1K3
Ascend, 3Com (USRobotics), Alteon, Cisco, Lucent (Livingston), WatchGuard,
Cacheflow, Foundry, Breezecom, Redback Networks, Shiva, Adtran, Compatible,
Microcom (Compaq), Garrett, Sonic, Cobalt.

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 "[e-mail]"
 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: "Ed" <[e-mail]>
Subject: Re: (usr-tc) ATTENTION SHOPPERS - Last day for 3COM Quad Trade-up promotion, special!!
Date: 30 Jul 1999 20:29:26 -0400

This is a multi-part message in MIME format.

------=_NextPart_000_003D_01BEDACA.37827CA0
Content-Type: text/plain;
    charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Is this list for SELLING or is it for Technical type stuff? I see =
Dynavar all over this list. People are leaving the list because of such =
things. It is considered Spam unless this list was meant for Buying and =
Selling instead of Technical agenda.


Ed

----- Original Message -----=20
  From: Greg Genge=20
  To: [e-mail]=20
  Sent: Friday, July 30, 1999 1:18 PM
  Subject: (usr-tc) ATTENTION SHOPPERS - Last day for 3COM Quad Trade-up =
promotion, special!!


  If you are about to buy 3COM, Ascend/Lucent, Alteon, or WatchGuard =
products, you might want to give us a call today at 877-DYNAVAR.

  Today is the last day of our Fiscal year and we are currently at $9.5 =
million in sales and may possibly break $10Million in annual sales. We =
are looking to book another $500,000 in orders today (Already booked an =
unbelievable $300,000).

  If you want to book your orders, today would definitly be the best day =
as we are ready to deal!!!=20

  I have another 30 sets of 3COM 003446-0 Double Play cardsets - only =
$8250 - in stock right now ready to ship. These qualify for the Quad =
Trade-in program which allows you to trade 12Quad cards for another 2 =
FREE 24port DSP cards from 3COM.
  http://3com.com/promotions/hipertrade/index2.html

  We can also book ANY total Control sales for fully loaded chassis, Arc =
cards, Memory upgrades, Quad cards, whatever you need.

  Other specials:
  WatchGuard FireboxII - $3500
  Alteon Ace-Directors - $Call
  Sonic Wall Firewalls.
  Max6096 $17,995

  Regards, Greg




  Gregory F. Genge, President, Dynavar Networking, Inc.
  Toll Free 877-Dynavar (Canada and US) [phone] Main, 5003 =
Direct, 5005 Fax, http://www.dynavar.com
  #300, 1550 - 5th Street S.W., Calgary, Alberta, Canada, T2R-1K3
  Ascend, 3Com (USRobotics), Alteon, Cisco, Lucent (Livingston), =
WatchGuard, Cacheflow, Foundry, Breezecom, Redback Networks, Shiva, =
Adtran, Compatible, Microcom (Compaq), Garrett, Sonic, Cobalt.
  - To unsubscribe to usr-tc, send an email to "[e-mail]" =
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.=20

------=_NextPart_000_003D_01BEDACA.37827CA0
Content-Type: text/html;
    charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Is this list for SELLING or is it for Technical type =
stuff? I=20
see Dynavar all over this list. People are leaving the list because of =
such=20
things. It is considered Spam unless this list was meant for Buying and =
Selling=20
instead of Technical agenda.</FONT></DIV>
<DIV> </DIV>
<DIV><BR>Ed</DIV>
<DIV> </DIV>
<DIV>----- Original Message ----- </DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A href=3D"mailto:[e-mail]" title=[e-mail]>Greg =
Genge</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
  href=3D"mailto:[e-mail]"=20
  title=[e-mail]>[e-mail]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, July 30, 1999 =
1:18 PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> (usr-tc) ATTENTION =
SHOPPERS -=20
  Last day for 3COM Quad Trade-up promotion, special!!</DIV>
  <DIV><BR></DIV>If you are about to buy 3COM, Ascend/Lucent, Alteon, or =

  WatchGuard products, you might want to give us a call today at=20
  877-DYNAVAR.<BR><BR>Today is the last day of our Fiscal year and we =
are=20
  currently at <B>$9.5 million</B> in sales and may possibly break =
$10Million in=20
  annual sales. We are looking to book another $500,000 in orders today =
(Already=20
  booked an unbelievable $300,000).<BR><BR>If you want to book your =
orders,=20
  today would definitly be the best day as we are ready to deal!!! =
<BR><BR>I=20
  have another 30 sets of 3COM 003446-0 Double Play cardsets - only =
$8250 - in=20
  stock right now ready to ship. These qualify for the Quad Trade-in =
program=20
  which allows you to trade 12Quad cards for another 2 FREE 24port DSP =
cards=20
  from =
3COM.<BR>http://3com.com/promotions/hipertrade/index2.html<BR><BR>We can =

  also book ANY total Control sales for fully loaded chassis, Arc cards, =
Memory=20
  upgrades, Quad cards, whatever you need.<BR><BR>Other =
specials:<BR>WatchGuard=20
  FireboxII - $3500<BR>Alteon Ace-Directors - $Call<BR>Sonic Wall=20
  Firewalls.<BR>Max6096 $17,995<BR><BR>Regards, =
Greg<BR><BR><BR><BR><BR>Gregory=20
  F. Genge, President, Dynavar Networking, Inc.<BR>Toll Free 877-Dynavar =
(Canada=20
  and US) [phone] Main, 5003 Direct, 5005 Fax,=20
  http://www.dynavar.com<BR>#300, 1550 - 5th Street S.W., Calgary, =
Alberta,=20
  Canada, T2R-1K3<BR>Ascend, 3Com (USRobotics), Alteon, Cisco, Lucent=20
  (Livingston), WatchGuard, Cacheflow, Foundry, Breezecom, Redback =
Networks,=20
  Shiva, Adtran, Compatible, Microcom (Compaq), Garrett, Sonic, =
Cobalt.<BR>- To=20
  unsubscribe to usr-tc, send an email to "[e-mail]" with=20
  "unsubscribe usr-tc" in the body of the message. For information on =
digests or=20
  retrieving files and old messages send "help" to the same address. Do =
not use=20
  quotes in your message. </BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_003D_01BEDACA.37827CA0--

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Pete Ashdown <[e-mail]>
Subject: Re: (usr-tc) Locating a bad port on DSP
Date: 05 Aug 1999 14:58:46 -0600 (MDT)

Randy Cosby said once upon a time:
>
>Wouldn't it be nice if your admin  shared that program :)

I posted it to the list when I wrote it several months ago.  Since we are
direct competitors Randy, I will leave it as an exercise to the reader to
extract it from the archives.

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Pete Ashdown <[e-mail]>
Subject: Re: (usr-tc) Locating a bad port on DSP
Date: 05 Aug 1999 15:00:35 -0600 (MDT)

Dan Hollis said once upon a time:
>
>On Thu, 5 Aug 1999, Pete Ashdown wrote:
>> I've been having the same issues with DSPs for a while.  Now I'm running
>> into situations where a reset doesn't cure the card.  It just moves to a
>> different channel.  The only fix I've found is to power down the entire
>> chassis (253 lines) and let it sit for a couple minutes then power up with
>> all the PRIs unplugged.  Once the chassis has returned to service, then I
>> can put the PRIs back in.
>
>Hows the cooling situation on the chassis? Ive had other vendors equipment
>(not 3com, yet) act very strange when it overheats.

Good.  The chassis on the top of the stack doesn't get over 90F.

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Ken Kirchner <[e-mail]>
Subject: Re: (usr-tc) Locating a bad port on DSP
Date: 05 Aug 1999 16:06:12 -0500 (CDT)

On Thu, 5 Aug 1999, Pete Ashdown wrote:

> Randy Cosby said once upon a time:
> >
> >Wouldn't it be nice if your admin  shared that program :)
>
> I posted it to the list when I wrote it several months ago.  Since we are
> direct competitors Randy, I will leave it as an exercise to the reader to
> extract it from the archives.

Oops, my apologies if you are the author of the program, Mr. Ashdown.  I
assumed Brian had written it.  I assume incorrectly a lot though. :)

  ___                                                         ___
 (___) Kenneth Kirchner    .o.  mailto:[e-mail]       (___)
  (__) Asst SysAdmin       .o.  Voice [phone] Ext 108 (__)
   (_) ShreveNet, Inc.     .o.  Fax   [phone]         (_)


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Brice Ligget <[e-mail]>
Subject: Re: (usr-tc) Locating a bad port on DSP
Date: 05 Aug 1999 15:11:49 -0600

I'll just add this datum.  I don't know how relevant it is.  We keep our
chassis at 62F.

At 03:00 PM 8/5/99 -0600, you wrote:
>Dan Hollis said once upon a time:
> >
> >On Thu, 5 Aug 1999, Pete Ashdown wrote:
> >> I've been having the same issues with DSPs for a while.  Now I'm running
> >> into situations where a reset doesn't cure the card.  It just moves to a
> >> different channel.  The only fix I've found is to power down the entire
> >> chassis (253 lines) and let it sit for a couple minutes then power up with
> >> all the PRIs unplugged.  Once the chassis has returned to service, then I
> >> can put the PRIs back in.
> >
> >Hows the cooling situation on the chassis? Ive had other vendors equipment
> >(not 3com, yet) act very strange when it overheats.
>
>Good.  The chassis on the top of the stack doesn't get over 90F.


--
Brice Ligget
Billings MT
[e-mail]
http://www.twoalpha.net/~bligget
DoD#2159

User Error: Replace user and press any key to continue.

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Scott Boggs <[e-mail]>
Subject: (usr-tc) 2.0.81 dsp code
Date: 05 Aug 1999 17:21:20 -0400

I upgraded to all the latest codes for NMC,HARC,and HDSP
I have had very many complaints that user connect speeds are now much
slower,
and some connection problems as well.  I am curently downgrading
the DSp's to 1.2.37.  Does any one have any insight into this problem,
or expeienced similar results.  On the two HARCs NMC awareness is off and
slots are divided between the two Harcs.

Thanks,
Scott Boggs


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: <[e-mail]>
Subject: Re: (usr-tc) 2.0.81 dsp code
Date: 05 Aug 1999 17:27:09 -0400 (EDT)


    Scott,

 Have not experinced it on the DSPs, but have noticed a problem with
connections on the quads with the 6.0.x code...  Really bad!!!  The 5.10.X
code for the quads seems very stable.

==============================================================================
Phillip Ferraro                WorldNet Access, Inc
[e-mail]    Onslow County's PREMIER InterNet Service
Voice [phone]            824 Gumbranch Square, Suite R3
FAX   [phone]             Jacksonville, Nc  28540-6269
==============================================================================

On Thu, 5 Aug 1999, Scott Boggs wrote:

> I upgraded to all the latest codes for NMC,HARC,and HDSP
> I have had very many complaints that user connect speeds are now much
> slower,
> and some connection problems as well.  I am curently downgrading
> the DSp's to 1.2.37.  Does any one have any insight into this problem,
> or expeienced similar results.  On the two HARCs NMC awareness is off and
> slots are divided between the two Harcs.
>
> Thanks,
> Scott Boggs
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: Mike Moore <[e-mail]>
Subject: (usr-tc) Radius suggestions?
Date: 05 Aug 1999 16:49:39 -0500

I'm looking for a reliable NT Radius package. I've tried 3Com. Any
suggestions?

Mike Moore

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Joe Priestley <[e-mail]>
Subject: Re: (usr-tc) Locating a bad port on DSP
Date: 05 Aug 1999 16:45:55 -0500

Could you narrow down the month of that post or email me?  I'm relatively
new to the group and I'm interested in that script.



At 04:06 PM 8/5/99 -0500, you wrote:
>On Thu, 5 Aug 1999, Pete Ashdown wrote:
>
> > Randy Cosby said once upon a time:
> > >
> > >Wouldn't it be nice if your admin  shared that program :)
> >
> > I posted it to the list when I wrote it several months ago.  Since we are
> > direct competitors Randy, I will leave it as an exercise to the reader to
> > extract it from the archives.
>
>Oops, my apologies if you are the author of the program, Mr. Ashdown.  I
>assumed Brian had written it.  I assume incorrectly a lot though. :)
>
>   ___                                                         ___
>  (___) Kenneth Kirchner    .o.  mailto:[e-mail]       (___)
>   (__) Asst SysAdmin       .o.  Voice [phone] Ext 108 (__)
>    (_) ShreveNet, Inc.     .o.  Fax   [phone]         (_)
>
>
>-
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: "Stainforth, Matthew" <[e-mail]>
Subject: RE: (usr-tc) Radius suggestions?
Date: 05 Aug 1999 18:41:41 -0300


I like Steel Belted from Funk Software for proxying to an NT SAM.

> -----Original Message-----
> From:    Mike Moore [SMTP:[e-mail]]
> Sent:    Thursday, August 05, 1999 6:50 PM
> To:    [e-mail]
> Subject:    (usr-tc) Radius suggestions?
>
> I'm looking for a reliable NT Radius package. I've tried 3Com. Any
> suggestions?
>
> Mike Moore
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: "Brian Hitchcock" <[e-mail]>
Subject: Re: (usr-tc) Radius suggestions?
Date: 05 Aug 1999 17:08:34 -0500

I use the lucent package it works ok for us. And its free.
http://www.livingston.com
Brian Hitchcock
KC Web
-----Original Message-----


>
>I like Steel Belted from Funk Software for proxying to an NT SAM.
>
>> -----Original Message-----
>> From: Mike Moore [SMTP:[e-mail]]
>> Sent: Thursday, August 05, 1999 6:50 PM
>> To: [e-mail]
>> Subject: (usr-tc) Radius suggestions?
>>
>> I'm looking for a reliable NT Radius package. I've tried 3Com. Any
>> suggestions?
>>
>> Mike Moore
>>
>> -
>>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>>  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 "[e-mail]"
> 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 "[e-mail]"
 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: Jim Johnson <[e-mail]>
Subject: Re: (usr-tc) Locating a bad port on DSP
Date: 05 Aug 1999 18:21:42 -0400




The only post I saw which included a script like this *was* from Brian
back in April - hdm-analyzer.pl (revised).

It analyzes the log files.

I was looking for something which queried the arcs directly using SNMP
and checked their counters for 'Incoming Connections Failed', etc.

Jim

Joe Priestley wrote:
>
> Could you narrow down the month of that post or email me?  I'm relatively
> new to the group and I'm interested in that script.
>
> At 04:06 PM 8/5/99 -0500, you wrote:
> >On Thu, 5 Aug 1999, Pete Ashdown wrote:
> >
> > > Randy Cosby said once upon a time:
> > > >
> > > >Wouldn't it be nice if your admin  shared that program :)
> > >
> > > I posted it to the list when I wrote it several months ago.  Since we are
> > > direct competitors Randy, I will leave it as an exercise to the reader to
> > > extract it from the archives.
> >
> >Oops, my apologies if you are the author of the program, Mr. Ashdown.  I
> >assumed Brian had written it.  I assume incorrectly a lot though. :)
> >
> >   ___                                                         ___
> >  (___) Kenneth Kirchner    .o.  mailto:[e-mail]       (___)
> >   (__) Asst SysAdmin       .o.  Voice [phone] Ext 108 (__)
> >    (_) ShreveNet, Inc.     .o.  Fax   [phone]         (_)
> >
> >
> >-
> >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> >  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 "[e-mail]"
>  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 "[e-mail]"
 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: Richard Lorbieski <[e-mail]>
Subject: Re: (usr-tc) Radius suggestions?
Date: 05 Aug 1999 17:39:15 -0500

We use vircom. http://www.vircom.com.
Support SAM NT, text - (Livingston), and SQL.

Mike Moore wrote:
>
> I'm looking for a reliable NT Radius package. I've tried 3Com. Any
> suggestions?
>
> Mike Moore
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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.

--

Richard Lorbieski - [e-mail]
Chief Technical Officer - Senior System Administrator
Alpha1 Internet  http://www.alpha1.net
409.731.8236  - 877.4.alpha1 (877.425.7421)

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Brett Murphy" <[e-mail]>
Subject: Re: (usr-tc) Locating a bad port on DSP
Date: 06 Aug 1999 10:36:23 +1000



-----Original Message-----


>
>
>I found the bad port(s) by using TCM to show Modem Events => Incoming
>Connections Failed   The numbers stood out like a sore thumb and it
>turned out to be two ports.  The hiper ports always go in pairs don't
>they?

Where in TCM can I find this please?


>
>Fortunately, the problem went away with a software reset.
>
>But, back to the original question, is that the best way?
>
>Regards,
>
>Jim
>
>Jim Johnson wrote:
>>
>> We have a port which must have gone bad on one of our DSPs.
>>
>> The line picks up and then just makes a steady whining sound until the
>> client modem times out.
>>
>> I have narrowed it down to one TC Chassis, but it has eight DSPs in it.
>>
>> What is the quickest way to isolate the offending port/DSP card?
>>
>> Thanks,
>>
>> Jim
>>
>> -
>>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>>  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 "[e-mail]"
> 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 "[e-mail]"
 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: Ken Kirchner <[e-mail]>
Subject: Re: (usr-tc) Locating a bad port on DSP
Date: 05 Aug 1999 19:42:23 -0500 (CDT)

On Fri, 6 Aug 1999, Brett Murphy wrote:

> Where in TCM can I find this please?

Highlight the modem(s) you want to see, then go into the Performance
Monitor.  It's all in there.

Ken
  ___                                                         ___
 (___) Kenneth Kirchner    .o.  mailto:[e-mail]       (___)
  (__) Asst SysAdmin       .o.  Voice [phone] Ext 108 (__)
   (_) ShreveNet, Inc.     .o.  Fax   [phone]         (_)


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: K Mitchell <[e-mail]>
Subject: Re: (usr-tc) Radius suggestions?
Date: 05 Aug 1999 20:44:33 -0400

At 05:08 PM 8/5/99 -0500, you wrote:
>I use the lucent package it works ok for us. And its free.
>http://www.livingston.com

It's a free download but, if you don't own Livingston/Lucent equipment,
you're violating the licensing by using it.


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


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Dan Hollis <[e-mail]>
Subject: Re: (usr-tc) Radius suggestions?
Date: 05 Aug 1999 17:49:17 -0700 (PDT)

On Thu, 5 Aug 1999, K Mitchell wrote:
> At 05:08 PM 8/5/99 -0500, you wrote:
> >I use the lucent package it works ok for us. And its free.
> >http://www.livingston.com
> It's a free download but, if you don't own Livingston/Lucent equipment,
> you're violating the licensing by using it.

I thought they changed the license back, recently.

-Dan


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: K Mitchell <[e-mail]>
Subject: Re: (usr-tc) Radius suggestions?
Date: 05 Aug 1999 20:53:49 -0400

At 05:49 PM 8/5/99 -0700, you wrote:
>On Thu, 5 Aug 1999, K Mitchell wrote:
>> At 05:08 PM 8/5/99 -0500, you wrote:
>> >I use the lucent package it works ok for us. And its free.
>> >http://www.livingston.com
>> It's a free download but, if you don't own Livingston/Lucent equipment,
>> you're violating the licensing by using it.
>
>I thought they changed the license back, recently.

Not that I'm aware of, but I haven't checked recently  :)


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


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Scot Desort" <[e-mail]>
Subject: RE: (usr-tc) CustoFlex ISDN
Date: 05 Aug 1999 22:20:16 -0400

Kirk-

I am in NJ, and I have several Custoflex BRI customers. However, they do not
dial into our TC. I have quad BRI cards in my Cisco's. I believe the
information you have is correct -- the entire PRI must be made into a
custoflex PRI in order for the cflex BRI customers to connect to you. Keep
in mind that a cflex PRI is functionally the same as a standard PRI in that
regular analog and BRI customers can also call into the same trunks as your
cflex customers. Cflex PRI trunks still get fully dial-able directory
numbers.

We _would_ have made our PRI custoflex, but our PRI's are not provided by
Bell Atlantic. We get PRI service from a CLEC who feels that it is not fair
to charge ISP's by the mile for each LSO we want coverage in. We only pay
for the directory number in the LSO, like $1.50 per month per LSO. It's all
done with SS7 and tandem switches. Since Bell Atlantic owns their custoflex
network, a Bell Atlantic custoflex BRI customer cannot connect to our CLEC
PRI. Pitty...

If you get your PRI's directly from BA (hope not), you should be able to
convert as many as you want to cflex.

Scot
NJ Internet Access

-----Original Message-----
[mailto:[e-mail]]On Behalf Of K Mitchell
Sent: Thursday, August 05, 1999 1:13 PM


  Anybody in Bell Atlantic land have ISDN customers using CustoFlex BRI
lines? I have a customer wanting one, and I'm being told that he cannot
call into my PRIs with it, that I need to install a matching CustoFlex BRI
line or dedicate an entire PRI to CustoFlex. On that note, is there a BRI
DSP card or equivalent for HiPer chassis?

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




-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: K Mitchell <[e-mail]>
Subject: RE: (usr-tc) CustoFlex ISDN
Date: 05 Aug 1999 22:48:20 -0400

At 10:20 PM 8/5/99 -0400, you wrote:
>Kirk-
>
>I am in NJ, and I have several Custoflex BRI customers. However, they do not
>dial into our TC. I have quad BRI cards in my Cisco's. I believe the
>information you have is correct -- the entire PRI must be made into a
>custoflex PRI in order for the cflex BRI customers to connect to you. Keep
>in mind that a cflex PRI is functionally the same as a standard PRI in that
>regular analog and BRI customers can also call into the same trunks as your
>cflex customers. Cflex PRI trunks still get fully dial-able directory
>numbers.
>
>We _would_ have made our PRI custoflex, but our PRI's are not provided by
>Bell Atlantic. We get PRI service from a CLEC who feels that it is not fair
>to charge ISP's by the mile for each LSO we want coverage in. We only pay
>for the directory number in the LSO, like $1.50 per month per LSO. It's all
>done with SS7 and tandem switches. Since Bell Atlantic owns their custoflex
>network, a Bell Atlantic custoflex BRI customer cannot connect to our CLEC
>PRI. Pitty...
>
>If you get your PRI's directly from BA (hope not), you should be able to
>convert as many as you want to cflex.

Unfortunately BA's my only option. I wasn't aware that a PRI could be
CustoFlex and still function normally in my modem pool, I'll work on the
tomorrow.

Thanks,
Kirk


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


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Mike Andrews <[e-mail]>
Subject: Re: (usr-tc) Locating a bad port on DSP
Date: 05 Aug 1999 23:31:29 -0400 (EDT)

> > Wouldnt it be nice if 3Com or someone would make some type of cross-over
> > cable and software to hook between two HDM's so you could use one to check
> > out the other?

Well, you can get to the console ports via the ARC if you have 2.x DSP
code...  It's easier than trying to wire up all the console ports to a
terminal server like a Livingston PM2E or a Cisco 2511.

Pulling the stats via SNMP, a la the Perl script everyone's talking about
(that I should really track down) is probably the way to go here.  Maybe
even have MRTG graph it, though that's a hell of a lot of graphs to get
anything useful. :)



Mike Andrews (MA12) -=-=-  VP & Sysadmin, Digital Crescent, Frankfort KY
[e-mail]  -=--=-  [e-mail]  -=--=-  http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Thomas C Kinnen <[e-mail]>
Subject: Re: (usr-tc) Radius suggestions?
Date: 05 Aug 1999 20:44:28 -0700

K Mitchell wrote:

> >I use the lucent package it works ok for us. And its free.
> >http://www.livingston.com
>
> It's a free download but, if you don't own Livingston/Lucent equipment,
> you're violating the licensing by using it.

Depends on the version.  Though if you want all the extras look at :

http://www.livingston.com/marketing/products/port-authority.html


--
Thomas C Kinnen - <[e-mail]> <[e-mail]>
[RADIUS Test Engineer] - LUCENT Technologies RABU
"All of the opinions stated above are my own and not my employer's,
unless they were given to me by my employer"

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Mike Andrews <[e-mail]>
Subject: Re: (usr-tc) Locating a bad port on DSP
Date: 05 Aug 1999 23:45:59 -0400 (EDT)

On Thu, 5 Aug 1999, Mike Andrews wrote:

> Pulling the stats via SNMP, a la the Perl script everyone's talking about
> (that I should really track down) is probably the way to go here.  Maybe
> even have MRTG graph it, though that's a hell of a lot of graphs to get
> anything useful. :)

Oh, and for whoever asked, since I'm not anyone's competitor here (except
maybe Iglou :), Brian's script is in the April 99 archives. It uses syslog
and not SNMP though.  Oops.



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Richard Lorbieski <[e-mail]>
Subject: Re: (usr-tc) Radius suggestions?
Date: 05 Aug 1999 23:46:54 -0500

no. You must own a livingston product.

Dan Hollis wrote:
>
> On Thu, 5 Aug 1999, K Mitchell wrote:
> > At 05:08 PM 8/5/99 -0500, you wrote:
> > >I use the lucent package it works ok for us. And its free.
> > >http://www.livingston.com
> > It's a free download but, if you don't own Livingston/Lucent equipment,
> > you're violating the licensing by using it.
>
> I thought they changed the license back, recently.
>
> -Dan
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: "Jamie Orzechowski" <[e-mail]>
Subject: (usr-tc) High Pitch Tone
Date: 06 Aug 1999 06:27:26 -0400

We are having a TERRIBLE time with some DSPS ... when a caller dials in they
will get the 1st 3 tones of the handshake then it will go into a contstand
tone and then drop the call ... has anyone seen this before?? how can I
track it down if it's a bad modem (520 ports to check) ...


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Jim Johnson <[e-mail]>
Subject: Re: (usr-tc) High Pitch Tone
Date: 06 Aug 1999 08:23:56 -0400

Ummm, we just went over this yesterday didn't we?

This is the same problem I had and I would like to find a script to help
locate these more proactively rather than have our customers find them
for us!

Anyway, once you know about the problem, here is what I did to locate
the port:

1) Open TCM and go to the chassis with the problem.
2) Select a modem port, then do a Select All
3) Go to Performance Monitor
4) Pick Modem Events
5) Select Incoming Call Failures
6) When you get the result, scan the list and look for the port with an
abnormally high count.  It will probably be a pair of ports.
7) Select the port(s) and do a Software Reset
8) Hope the problem goes away.
9) Start more disruptive attempts to clear the problem :(

Regards,

Jim

Jamie Orzechowski wrote:
>
> We are having a TERRIBLE time with some DSPS ... when a caller dials in they
> will get the 1st 3 tones of the handshake then it will go into a contstand
> tone and then drop the call ... has anyone seen this before?? how can I
> track it down if it's a bad modem (520 ports to check) ...
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: "Kalev Nurklik" <[e-mail]>
Subject: (usr-tc) NMC booting failure after power down
Date: 06 Aug 1999 17:03:51 +0300

On our production equipment we have had some trouble
with NMC NACs. That is with 486 ones not the Hiper or 386 NMCs.

Sometimes when TC chassis is powered down while in production
or there is too long power failure (UPSes can't hold up) NMC NAC
flash gets screwed up. I'm not sure if it's the flash but the
symptoms are that NAC will boot over and over again. When
connected to console then I can see the initial menu display for a
second and then *boom* it reboots again.

I dug through the archives and found that if I reflash the NMC with
older code and then with newer one the NMC should come up
normally. Reflashing at once with new code would not do any
good.
Been there done that and it works.

Has anybody pinpointed down the exact problem source?
I'm asking this because reflashing remote POPs about twice a year
just that I had to power down the chassis or there was a power
failure isn't a good solution.
What I've found out is that this problem is probably only with 486
NMC cards and is not related to one chassis - happened to
two of them with different cards. Of course maybe we have two
broken chassis or two broken NMCs but it seems quite far fetched.
And maybe this hasn't happened to 586 or 386 NMC yet.

Anyway, can somebody help me with this?


__________________________________
Kalev Nurklik
MicroLink Online
Sakala 19, 10141 Tallinn, Estonia
Tel: [phone]
Fax: [phone]
E-mail: [e-mail]
http://www.online.ee

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Stainforth, Matthew" <[e-mail]>
Subject: RE: (usr-tc) NMC booting failure after power down
Date: 06 Aug 1999 11:46:13 -0300

On Friday, August 06, 1999 11:04 AM, Kalev Nurklik [SMTP:[e-mail]]
wrote:
> Sometimes when TC chassis is powered down while in production
> or there is too long power failure (UPSes can't hold up) NMC NAC
> flash gets screwed up. I'm not sure if it's the flash but the
> symptoms are that NAC will boot over and over again. When
> connected to console then I can see the initial menu display for a
> second and then *boom* it reboots again.

I ran into this when I upgraded the firmware on the card.  It ended up being
the fact that I had put all 0.0.0.0 for the LAN or WAN or both IP addresses
(can't remember exactly right now).  The solution was to downgrade the
firmware, change the IP address to something valid, and reflash with the
current code.

The only thing I can think of that might be causing your problem is that for
some reason your WAN address is getting reset after a power outage, perhaps
because you haven't saved it properly.  I always do "save settings" at the
CLI, then go into TCM and "save chassis to NVRAM" just to be sure.

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Pete Ashdown <[e-mail]>
Subject: (usr-tc) bad port locator
Date: 06 Aug 1999 10:56:03 -0600 (MDT)

My apologies.  I couldn't find this in the archive, although I have a
distinct memory of posting it to the list.  Oh well.  Here it is anyway:

#!/usr/local/bin/perl

# hdmcheck
#
# Checks the individual HDM stats in order to find stuck modems.  If the
# total number of calls is greater than $minimum and the failed calls is
# greater than the $threshold percentage of established calls, an external
# script is called.  This script busy-outs the span and pages me.  How you
# deal with the card after that point is your own voodoo.
#
# Stuck modems will exhibit themselves as RNA, wrong-carrier, and fast-busies.
# No fun for your callers, and even less fun for you.
#
# If you crontab this script, be sure to run it in periods larger than the
# time it takes "hdmreset" to run (ie: approximately 2 hours).
#
# Like many of my other scripts, this comes with no guarantee or warranty.
# This script was crafted in a few hours in an attempt to workaround a
# 3com/USR bug.
#
# This script requires the UNIX version of 3com/USR's TCM.
# Questions or comments can be directed to [e-mail]

# User definable variables
# Location of your UNIX TCM
$ENV{'TCMHOME'} = "/usr/local/lib/tcm";
$ENV{'LD_LIBRARY_PATH'} = "/usr/local/lib";

# Your SNMP read variable
$readsnmp = "public";

# Your SNMP write variable
$writesnmp = "private";

# Percentage of established calls that failed calls must exceed
$threshold = 75;

# Minimum number of calls that need to have been attempted
$minimum = 25;

# If you want to see things in action (set to 0 for crontab use)
$debug = 0;

# Where the hdmreset script is located
$hdmreset = "/home/users/pashdown/usr/hdmreset";

# Don't change these two unless you know what you're doing.
$tcmperf = "$ENV{'TCMHOME'}/bin/tcmperf -s 1 -c $readsnmp ";
$threshold = $threshold / 100;

if (-e "/tmp/.hdmcheck") {
    system ("/usr/local/bin/sendpage -q -p pete 'hdmcheck stuck'");
    exit;
}
else {
    system ("touch /tmp/.hdmcheck");
}

# Define these for each of your HIPER racks


foreach $i ( 1 .. 11 ) {
    &check_channels (slc1,$i);
}

foreach $i ( 1 .. 11 ) {
    &check_channels (slc2,$i);
}

foreach $i ( 1 .. 11 ) {
    &check_channels (slc3,$i);
}

foreach $i ( 1 .. 11 ) {
    &check_channels (slc4,$i);
}

foreach $i ( 1 .. 11 ) {
    &check_channels (slc5,$i);
}

foreach $i ( 1 .. 6 ) {
    &check_channels (bond,$i);
}


unlink ("/tmp/.hdmcheck");

exit;

# check_channels(NMC name, span #)
# assumes NMC is "city-snmp"
#
sub check_channels {

    ($rack,$span) = @_;

    print ("Rack: $rack\tSpan: $span\n") if $debug;

    open ( TCMPERF, "$tcmperf -G \"Modem Events\" \"Incoming Connections Established\" -G \"Modem Events\" \"Incoming Connections Failed\" ${rack}-snmp:s${span}c1-23 2>&1 |");
    while (<TCMPERF>) {
    chop;
    if (/Incoming Connections Established\s+(.*)/) {
        @established = split (/\s+/,  $1);
    }
    if (/Incoming Connections Failed\s+(.*)/) {
        @failed = split (/\s+/, $1);
    }
    }

    $badcard = 0;

    foreach $channel ( 0 .. $#established ) {
    printf ("Channel %d\t Est: %d\tFail: %d",
        $channel+1, $established[$channel], $failed[$channel])
        if $debug;
    if (($established[$channel] + $failed[$channel] > $minimum) &&
        ($failed[$channel] > $established[$channel] * $threshold)) {
        printf ("Channel %d\t Est: %d\tFail: %d",
            $channel+1, $established[$channel], $failed[$channel]);
        printf ("\tStuck Modem! %d > %d\n",
            $failed[$channel], ($established[$channel] * $threshold));
        $badcard = 1;
    }
    print ("\n") if $debug;

    }
    if ($badcard) {
    print ("Resetting $rack $span!\n") if $debug;
    system ("$hdmreset $rack $readsnmp $writesnmp $span &");
    }
    print ("\n") if $debug;
}


#!/bin/csh

# hdmreset - reset an HDM card and give enough time for people to get off
# Usage: hdmset target read write card

# note - This used to reset the card when it actually helped.  I have found
# that this doesn't cure everything, so now it just pages me.

setenv LD_LIBRARY_PATH "/usr/local/lib"
setenv TCMHOME "/usr/local/lib/tcm"
set target=$1
set read=$2
set write=$3
set card=$4

# Busy out the card
$TCMHOME/bin/tcmcmd -E "local out of service" -G commands -C $write -c $read ${target}-snmp:s${card}c25

# sleep two hours
sleep 7200

# Reset the card
#$TCMHOME/bin/tcmcmd -E "hardware reset" -G "hardware commands" -C $write -c $read ${target}-snmp:s${card}

# Page someone
/usr/local/bin/sendpage -q -p pete "reset modem card ${target} slot ${card}"






-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Jim Johnson <[e-mail]>
Subject: Re: (usr-tc) bad port locator
Date: 06 Aug 1999 14:17:49 -0400


Thanks for the post.

I was wondering if anyone has anything written that uses PERL and
SNMP_Session.pm for the SNMP access.

Jim

Pete Ashdown wrote:
>
> My apologies.  I couldn't find this in the archive, although I have a
> distinct memory of posting it to the list.  Oh well.  Here it is anyway:
>
> #!/usr/local/bin/perl
>
> # hdmcheck
> #
> # Checks the individual HDM stats in order to find stuck modems.  If the
> # total number of calls is greater than $minimum and the failed calls is
> # greater than the $threshold percentage of established calls, an external
> # script is called.  This script busy-outs the span and pages me.  How you
> # deal with the card after that point is your own voodoo.
> #
> # Stuck modems will exhibit themselves as RNA, wrong-carrier, and fast-busies.
> # No fun for your callers, and even less fun for you.
> #
> # If you crontab this script, be sure to run it in periods larger than the
> # time it takes "hdmreset" to run (ie: approximately 2 hours).
> #
> # Like many of my other scripts, this comes with no guarantee or warranty.
> # This script was crafted in a few hours in an attempt to workaround a
> # 3com/USR bug.
> #
> # This script requires the UNIX version of 3com/USR's TCM.
> # Questions or comments can be directed to [e-mail]
>
> # User definable variables
> # Location of your UNIX TCM
> $ENV{'TCMHOME'} = "/usr/local/lib/tcm";
> $ENV{'LD_LIBRARY_PATH'} = "/usr/local/lib";
>
> # Your SNMP read variable
> $readsnmp = "public";
>
> # Your SNMP write variable
> $writesnmp = "private";
>
> # Percentage of established calls that failed calls must exceed
> $threshold = 75;
>
> # Minimum number of calls that need to have been attempted
> $minimum = 25;
>
> # If you want to see things in action (set to 0 for crontab use)
> $debug = 0;
>
> # Where the hdmreset script is located
> $hdmreset = "/home/users/pashdown/usr/hdmreset";
>
> # Don't change these two unless you know what you're doing.
> $tcmperf = "$ENV{'TCMHOME'}/bin/tcmperf -s 1 -c $readsnmp ";
> $threshold = $threshold / 100;
>
> if (-e "/tmp/.hdmcheck") {
>     system ("/usr/local/bin/sendpage -q -p pete 'hdmcheck stuck'");
>     exit;
> }
> else {
>     system ("touch /tmp/.hdmcheck");
> }
>
> # Define these for each of your HIPER racks
>
> foreach $i ( 1 .. 11 ) {
>     &check_channels (slc1,$i);
> }
>
> foreach $i ( 1 .. 11 ) {
>     &check_channels (slc2,$i);
> }
>
> foreach $i ( 1 .. 11 ) {
>     &check_channels (slc3,$i);
> }
>
> foreach $i ( 1 .. 11 ) {
>     &check_channels (slc4,$i);
> }
>
> foreach $i ( 1 .. 11 ) {
>     &check_channels (slc5,$i);
> }
>
> foreach $i ( 1 .. 6 ) {
>     &check_channels (bond,$i);
> }
>
> unlink ("/tmp/.hdmcheck");
>
> exit;
>
> # check_channels(NMC name, span #)
> # assumes NMC is "city-snmp"
> #
> sub check_channels {
>
>     ($rack,$span) = @_;
>
>     print ("Rack: $rack\tSpan: $span\n") if $debug;
>
>     open ( TCMPERF, "$tcmperf -G \"Modem Events\" \"Incoming Connections Established\" -G \"Modem Events\" \"Incoming Connections Failed\" ${rack}-snmp:s${span}c1-23 2>&1 |");
>     while (<TCMPERF>) {
>         chop;
>         if (/Incoming Connections Established\s+(.*)/) {
>             @established = split (/\s+/,  $1);
>         }
>         if (/Incoming Connections Failed\s+(.*)/) {
>             @failed = split (/\s+/, $1);
>         }
>     }
>
>     $badcard = 0;
>
>     foreach $channel ( 0 .. $#established ) {
>         printf ("Channel %d\t Est: %d\tFail: %d",
>                 $channel+1, $established[$channel], $failed[$channel])
>             if $debug;
>         if (($established[$channel] + $failed[$channel] > $minimum) &&
>             ($failed[$channel] > $established[$channel] * $threshold)) {
>             printf ("Channel %d\t Est: %d\tFail: %d",
>                     $channel+1, $established[$channel], $failed[$channel]);
>             printf ("\tStuck Modem! %d > %d\n",
>                     $failed[$channel], ($established[$channel] * $threshold));
>             $badcard = 1;
>         }
>         print ("\n") if $debug;
>
>     }
>     if ($badcard) {
>         print ("Resetting $rack $span!\n") if $debug;
>         system ("$hdmreset $rack $readsnmp $writesnmp $span &");
>     }
>     print ("\n") if $debug;
> }
>
> ------------------------------------------------------------------------------
> #!/bin/csh
>
> # hdmreset - reset an HDM card and give enough time for people to get off
> # Usage: hdmset target read write card
>
> # note - This used to reset the card when it actually helped.  I have found
> # that this doesn't cure everything, so now it just pages me.
>
> setenv LD_LIBRARY_PATH "/usr/local/lib"
> setenv TCMHOME "/usr/local/lib/tcm"
> set target=$1
> set read=$2
> set write=$3
> set card=$4
>
> # Busy out the card
> $TCMHOME/bin/tcmcmd -E "local out of service" -G commands -C $write -c $read ${target}-snmp:s${card}c25
>
> # sleep two hours
> sleep 7200
>
> # Reset the card
> #$TCMHOME/bin/tcmcmd -E "hardware reset" -G "hardware commands" -C $write -c $read ${target}-snmp:s${card}
>
> # Page someone
> /usr/local/bin/sendpage -q -p pete "reset modem card ${target} slot ${card}"
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: Mike Andrews <[e-mail]>
Subject: Re: (usr-tc) bad port locator
Date: 06 Aug 1999 17:35:02 -0400 (EDT)

I probably will as soon as I dig up the appropriate OID's...


Mike Andrews (MA12) -=-=-  VP & Sysadmin, Digital Crescent, Frankfort KY
[e-mail]  -=--=-  [e-mail]  -=--=-  http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."

On Fri, 6 Aug 1999, Jim Johnson wrote:

>
> Thanks for the post.
>
> I was wondering if anyone has anything written that uses PERL and
> SNMP_Session.pm for the SNMP access.
>
> Jim
>
> Pete Ashdown wrote:
> >
> > My apologies.  I couldn't find this in the archive, although I have a
> > distinct memory of posting it to the list.  Oh well.  Here it is anyway:
> >
> > #!/usr/local/bin/perl
> >
> > # hdmcheck
> > #
> > # Checks the individual HDM stats in order to find stuck modems.  If the
> > # total number of calls is greater than $minimum and the failed calls is
> > # greater than the $threshold percentage of established calls, an external
> > # script is called.  This script busy-outs the span and pages me.  How you
> > # deal with the card after that point is your own voodoo.
> > #
> > # Stuck modems will exhibit themselves as RNA, wrong-carrier, and fast-busies.
> > # No fun for your callers, and even less fun for you.
> > #
> > # If you crontab this script, be sure to run it in periods larger than the
> > # time it takes "hdmreset" to run (ie: approximately 2 hours).
> > #
> > # Like many of my other scripts, this comes with no guarantee or warranty.
> > # This script was crafted in a few hours in an attempt to workaround a
> > # 3com/USR bug.
> > #
> > # This script requires the UNIX version of 3com/USR's TCM.
> > # Questions or comments can be directed to [e-mail]
> >
> > # User definable variables
> > # Location of your UNIX TCM
> > $ENV{'TCMHOME'} = "/usr/local/lib/tcm";
> > $ENV{'LD_LIBRARY_PATH'} = "/usr/local/lib";
> >
> > # Your SNMP read variable
> > $readsnmp = "public";
> >
> > # Your SNMP write variable
> > $writesnmp = "private";
> >
> > # Percentage of established calls that failed calls must exceed
> > $threshold = 75;
> >
> > # Minimum number of calls that need to have been attempted
> > $minimum = 25;
> >
> > # If you want to see things in action (set to 0 for crontab use)
> > $debug = 0;
> >
> > # Where the hdmreset script is located
> > $hdmreset = "/home/users/pashdown/usr/hdmreset";
> >
> > # Don't change these two unless you know what you're doing.
> > $tcmperf = "$ENV{'TCMHOME'}/bin/tcmperf -s 1 -c $readsnmp ";
> > $threshold = $threshold / 100;
> >
> > if (-e "/tmp/.hdmcheck") {
> >     system ("/usr/local/bin/sendpage -q -p pete 'hdmcheck stuck'");
> >     exit;
> > }
> > else {
> >     system ("touch /tmp/.hdmcheck");
> > }
> >
> > # Define these for each of your HIPER racks
> >
> > foreach $i ( 1 .. 11 ) {
> >     &check_channels (slc1,$i);
> > }
> >
> > foreach $i ( 1 .. 11 ) {
> >     &check_channels (slc2,$i);
> > }
> >
> > foreach $i ( 1 .. 11 ) {
> >     &check_channels (slc3,$i);
> > }
> >
> > foreach $i ( 1 .. 11 ) {
> >     &check_channels (slc4,$i);
> > }
> >
> > foreach $i ( 1 .. 11 ) {
> >     &check_channels (slc5,$i);
> > }
> >
> > foreach $i ( 1 .. 6 ) {
> >     &check_channels (bond,$i);
> > }
> >
> > unlink ("/tmp/.hdmcheck");
> >
> > exit;
> >
> > # check_channels(NMC name, span #)
> > # assumes NMC is "city-snmp"
> > #
> > sub check_channels {
> >
> >     ($rack,$span) = @_;
> >
> >     print ("Rack: $rack\tSpan: $span\n") if $debug;
> >
> >     open ( TCMPERF, "$tcmperf -G \"Modem Events\" \"Incoming Connections Established\" -G \"Modem Events\" \"Incoming Connections Failed\" ${rack}-snmp:s${span}c1-23 2>&1 |");
> >     while (<TCMPERF>) {
> >         chop;
> >         if (/Incoming Connections Established\s+(.*)/) {
> >             @established = split (/\s+/,  $1);
> >         }
> >         if (/Incoming Connections Failed\s+(.*)/) {
> >             @failed = split (/\s+/, $1);
> >         }
> >     }
> >
> >     $badcard = 0;
> >
> >     foreach $channel ( 0 .. $#established ) {
> >         printf ("Channel %d\t Est: %d\tFail: %d",
> >                 $channel+1, $established[$channel], $failed[$channel])
> >             if $debug;
> >         if (($established[$channel] + $failed[$channel] > $minimum) &&
> >             ($failed[$channel] > $established[$channel] * $threshold)) {
> >             printf ("Channel %d\t Est: %d\tFail: %d",
> >                     $channel+1, $established[$channel], $failed[$channel]);
> >             printf ("\tStuck Modem! %d > %d\n",
> >                     $failed[$channel], ($established[$channel] * $threshold));
> >             $badcard = 1;
> >         }
> >         print ("\n") if $debug;
> >
> >     }
> >     if ($badcard) {
> >         print ("Resetting $rack $span!\n") if $debug;
> >         system ("$hdmreset $rack $readsnmp $writesnmp $span &");
> >     }
> >     print ("\n") if $debug;
> > }
> >
> > ------------------------------------------------------------------------------
> > #!/bin/csh
> >
> > # hdmreset - reset an HDM card and give enough time for people to get off
> > # Usage: hdmset target read write card
> >
> > # note - This used to reset the card when it actually helped.  I have found
> > # that this doesn't cure everything, so now it just pages me.
> >
> > setenv LD_LIBRARY_PATH "/usr/local/lib"
> > setenv TCMHOME "/usr/local/lib/tcm"
> > set target=$1
> > set read=$2
> > set write=$3
> > set card=$4
> >
> > # Busy out the card
> > $TCMHOME/bin/tcmcmd -E "local out of service" -G commands -C $write -c $read ${target}-snmp:s${card}c25
> >
> > # sleep two hours
> > sleep 7200
> >
> > # Reset the card
> > #$TCMHOME/bin/tcmcmd -E "hardware reset" -G "hardware commands" -C $write -c $read ${target}-snmp:s${card}
> >
> > # Page someone
> > /usr/local/bin/sendpage -q -p pete "reset modem card ${target} slot ${card}"
> >
> > -
> >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> >  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 "[e-mail]"
>  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 "[e-mail]"
 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: Stephen Amadei <[e-mail]>
Subject: (usr-tc) Gateways and routing...
Date: 06 Aug 1999 17:08:18 -0400 (EDT)


O.K... I'm going to tip my hand and demostrate how much of a moron I am.
;-)

I have three class C networks, and a Cisco 2501, and a pile of TCs.

Most of my TC's are on the first two Class C's.  Defining a default
gateway on them was easy... I had Class C #1's gateway on my Cisco.
When we needed the second Class C, I was able to alias the Cisco's
IP as a second gateway.  Everything worked.  I now have to put my latest
TC on the third Class C... but the Cisco won't allow another IP alias
(only 2)... so I pointed the default gateway to the first class C
gateway... and the TC won't take it.  It wants a gateway that matchs
it's IP and netmask (I guess that's reasonable).  So how do I do this?

I know this is basic TCPIP routing, but do I have to start mucking with
RIP or so?

My next concern is trying to stuff 336 connections into one box.
Obviously this would require more than 1 class C... and only one default
gateway... so it seems to have the same problem.  I imagine this problem
will get cleared up after the first problem is solved.

The last thing I'd like to get working is that we have two small static
IP groups in the first class C and the second class C.  The problem is
I would like to have our small number of static users to be able to
use any TC reguardless of the class C of the TC.  I.e. my main TC
is on 206.135.129.0, but I'd like it to be able to assign an IP from
209.101.140.0.

My 3 class C's are not contiguous.

Could someone please slap some sense into me... Thanx.

                    ----Steve
Stephen Amadei
Director of MIS
Dandy Connections, Inc.
Atlantic City, NJ


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Aaron Nabil <[e-mail]>
Subject: Re: (usr-tc) 2.0.81 dsp code
Date: 06 Aug 1999 15:14:38 -0700 (PDT)


<followup trimmed to usr-tc>

What is "very much slower"?  From v.90 to v.34, or from 46k to 44k?

Although it's almost impossible to convince lusers of this,
unless you are talking about going from v.90 to v.34 rates,
a change in _connect_ speed rarely correlates to a change in
throughput.


Scott Boggs writes...
>I upgraded to all the latest codes for NMC,HARC,and HDSP
>I have had very many complaints that user connect speeds are now much
>slower,
>and some connection problems as well.  I am curently downgrading
>the DSp's to 1.2.37.  Does any one have any insight into this problem,
>or expeienced similar results.  On the two HARCs NMC awareness is off and
>slots are divided between the two Harcs.
>
>Thanks,
>Scott Boggs

--
Aaron Nabil

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Charles Sprickman <[e-mail]>
Subject: Re: (usr-tc) Gateways and routing...
Date: 06 Aug 1999 18:30:41 -0400 (EDT)

I'm guessing that you're trying to add secondary interfaces to the cisco
by doing something like 'ip address x.x.x.x x.x.x.x third' or
something because you mentioned it could only have one...  It should take
many, many more.  Just keep repeating 'ip address x.x.x.x x.x.x.x
secondary' as many times as you need, and you should be fine.

For organization's sake, you may want to put just a subnet (/28 or so) on
the cisco and put the arcs, netservers, and nmcs in that net, then just
add static routes to each tch in the cisco.  Or you could play with RIP
if you're brave, but it seems like there's many postings here about the
arc/netserver not aggregating things in a sane way...

Charles

--
=-----------------=                                        =
| Charles Sprickman                       Internet Channel |
| INCH System Administration Team         [phone]    |
| [e-mail]                          [e-mail]  |
=                                         =----------------=

On Fri, 6 Aug 1999, Stephen Amadei wrote:

>
> O.K... I'm going to tip my hand and demostrate how much of a moron I am.
> ;-)
>
> I have three class C networks, and a Cisco 2501, and a pile of TCs.
>
> Most of my TC's are on the first two Class C's.  Defining a default
> gateway on them was easy... I had Class C #1's gateway on my Cisco.
> When we needed the second Class C, I was able to alias the Cisco's
> IP as a second gateway.  Everything worked.  I now have to put my latest
> TC on the third Class C... but the Cisco won't allow another IP alias
> (only 2)... so I pointed the default gateway to the first class C
> gateway... and the TC won't take it.  It wants a gateway that matchs
> it's IP and netmask (I guess that's reasonable).  So how do I do this?
>
> I know this is basic TCPIP routing, but do I have to start mucking with
> RIP or so?
>
> My next concern is trying to stuff 336 connections into one box.
> Obviously this would require more than 1 class C... and only one default
> gateway... so it seems to have the same problem.  I imagine this problem
> will get cleared up after the first problem is solved.
>
> The last thing I'd like to get working is that we have two small static
> IP groups in the first class C and the second class C.  The problem is
> I would like to have our small number of static users to be able to
> use any TC reguardless of the class C of the TC.  I.e. my main TC
> is on 206.135.129.0, but I'd like it to be able to assign an IP from
> 209.101.140.0.
>
> My 3 class C's are not contiguous.
>
> Could someone please slap some sense into me... Thanx.
>
>                     ----Steve
> Stephen Amadei
> Director of MIS
> Dandy Connections, Inc.
> Atlantic City, NJ
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: Stephen Amadei <[e-mail]>
Subject: Re: (usr-tc) Gateways and routing...
Date: 06 Aug 1999 18:42:03 -0400 (EDT)

On Fri, 6 Aug 1999, Charles Sprickman wrote:

> I'm guessing that you're trying to add secondary interfaces to the cisco
> by doing something like 'ip address x.x.x.x x.x.x.x third' or

Actually, I tried 'tertiary'... never thought of trying 'third'.

> something because you mentioned it could only have one...  It should take
> many, many more.  Just keep repeating 'ip address x.x.x.x x.x.x.x
> secondary' as many times as you need, and you should be fine.

I'll give this a shot, thanks.

> For organization's sake, you may want to put just a subnet (/28 or so) on
> the cisco and put the arcs, netservers, and nmcs in that net, then just

Subnetting our system is coming.  I'm just trying to delay the inevidible.

                    ----Steve
Stephen Amadei
Director of MIS
Dandy Connections, Inc.
Atlantic City, NJ


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Mike Andrews <[e-mail]>
Subject: Re: (usr-tc) Gateways and routing...
Date: 06 Aug 1999 19:41:09 -0400 (EDT)

On Fri, 6 Aug 1999, Stephen Amadei wrote:

> On Fri, 6 Aug 1999, Charles Sprickman wrote:
>
> > I'm guessing that you're trying to add secondary interfaces to the cisco
> > by doing something like 'ip address x.x.x.x x.x.x.x third' or
>
> Actually, I tried 'tertiary'... never thought of trying 'third'.

Nope.  Keep repeating "secondary".  The second "secondary" doesn't
overwrite the first -- you have to use the "no" prefix to do that.
You can put just about as many secondaries on as you want.

I just checked my own Cisco 804 at home here by slapping 10.0.0.1/24 and
10.0.1.0/24 on top of the existing real address, just to test.  Sure
enough:

interface Ethernet0
 ip address 10.0.0.1 255.255.255.0 secondary
 ip address 10.0.1.1 255.255.255.0 secondary
 ip address 207.246.72.161 255.255.255.240
 no ip directed-broadcast
 no ip proxy-arp
 no cdp enable


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Stainforth, Matthew" <[e-mail]>
Subject: RE: (usr-tc) Gateways and routing...
Date: 06 Aug 1999 21:21:23 -0300

no, do this

ip address x.x.x.x 255.255.255.0
ip address y.y.y.y 255.255.255.0 secondary
ip address z.z.z.z 255.255.255.0 secondary
ip address b.b.b.b 255.255.255.0 secondary

ad nauseaum...should work

> -----Original Message-----
> From:    Stephen Amadei [SMTP:[e-mail]]
> Sent:    Friday, August 06, 1999 7:42 PM
> To:    [e-mail]
> Subject:    Re: (usr-tc) Gateways and routing...
>
> On Fri, 6 Aug 1999, Charles Sprickman wrote:
>
> > I'm guessing that you're trying to add secondary interfaces to the cisco
> > by doing something like 'ip address x.x.x.x x.x.x.x third' or
>
> Actually, I tried 'tertiary'... never thought of trying 'third'.
>
> > something because you mentioned it could only have one...  It should
> take
> > many, many more.  Just keep repeating 'ip address x.x.x.x x.x.x.x
> > secondary' as many times as you need, and you should be fine.
>
> I'll give this a shot, thanks.
>
> > For organization's sake, you may want to put just a subnet (/28 or so)
> on
> > the cisco and put the arcs, netservers, and nmcs in that net, then just
>
> Subnetting our system is coming.  I'm just trying to delay the inevidible.
>
>                     ----Steve
> Stephen Amadei
> Director of MIS
> Dandy Connections, Inc.
> Atlantic City, NJ
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: "Brett Murphy" <[e-mail]>
Subject: Re: (usr-tc) High Pitch Tone
Date: 07 Aug 1999 13:33:29 +1000

>1) Open TCM and go to the chassis with the problem.
>2) Select a modem port, then do a Select All
>3) Go to Performance Monitor
>4) Pick Modem Events
>5) Select Incoming Call Failures
>6) When you get the result, scan the list and look for the port with an
>abnormally high count.  It will probably be a pair of ports.



Can someone sussgest what would be an "abnormally hight count"?
 I am seeing up to 5% on ALL ports



>7) Select the port(s) and do a Software Reset
>8) Hope the problem goes away.
>9) Start more disruptive attempts to clear the problem :(
>
>Regards,
>
>Jim
>
>Jamie Orzechowski wrote:
>>
>> We are having a TERRIBLE time with some DSPS ... when a caller dials in
they
>> will get the 1st 3 tones of the handshake then it will go into a
contstand
>> tone and then drop the call ... has anyone seen this before?? how can I
>> track it down if it's a bad modem (520 ports to check) ...
>>
>> -
>>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>>  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 "[e-mail]"
> 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 "[e-mail]"
 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: "Bob Purdon (Lists)" <[e-mail]>
Subject: Re: (usr-tc) Looked but can't find this
Date: 07 Aug 1999 17:28:02 +1000 (EST)


> > I've got a user that is occasionally getting "NAS-Error" for a terminate
> > cause on his account from the Arc.
>
> NAS error is a error detected by the NAS - it is not anyway related to
> modem/port, it basically revolves around PPP framing or data related
> error that is being processed by the NAS.

I had this the other day - turned out that I was applying a filter to a
user, but the filter wasn't defined on the NAS (it was defined on every
NAS except one...).

Bob Purdon,                          Ground Floor, Marine Board Building
Technical Manager (Tas/Vic),                  1 Franklin Wharf, Tas 7000
Southern Internet Services.                            [phone]


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Jim Johnson <[e-mail]>
Subject: Re: (usr-tc) High Pitch Tone
Date: 07 Aug 1999 09:53:24 -0400


Brett,

You can do one of two things:

1) Since call distribution should be uniform, a number much higher than
the average for a particular span would be a good criterion.  For
example, it should be easy to spot the naughty ports below from the
failed connections data below:

    Calls failed for Span X:

    Port 1 - 56
    Port 2 - 78
    Port 3 - 34
    Port 4 - 78
    Port 5 - 3457
    Port 6 - 3783
    Port 7 - 54
    Port 8 - 67


2) The other way is to compare the percentage of calls completed vs.
calls attempted

    calls completed /(calls completed + calls failed)

A number greater than 5% would probably indicate a bad port.

Jim


Brett Murphy wrote:
>
> >1) Open TCM and go to the chassis with the problem.
> >2) Select a modem port, then do a Select All
> >3) Go to Performance Monitor
> >4) Pick Modem Events
> >5) Select Incoming Call Failures
> >6) When you get the result, scan the list and look for the port with an
> >abnormally high count.  It will probably be a pair of ports.
>
> Can someone sussgest what would be an "abnormally hight count"?
>  I am seeing up to 5% on ALL ports
>
> >7) Select the port(s) and do a Software Reset
> >8) Hope the problem goes away.
> >9) Start more disruptive attempts to clear the problem :(
> >
> >Regards,
> >
> >Jim
> >
> >Jamie Orzechowski wrote:
> >>
> >> We are having a TERRIBLE time with some DSPS ... when a caller dials in
> they
> >> will get the 1st 3 tones of the handshake then it will go into a
> contstand
> >> tone and then drop the call ... has anyone seen this before?? how can I
> >> track it down if it's a bad modem (520 ports to check) ...
> >>
> >> -
> >>  To unsubscribe to usr-tc, send an email to "[e-mail]"
> >>  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 "[e-mail]"
> > 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 "[e-mail]"
>  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 "[e-mail]"
 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: <[e-mail]>
Subject: (usr-tc) Script for pulling USER times
Date: 07 Aug 1999 10:12:54 -0400 (EDT)


    Does anyone have a script that they use to pull the user hours out
of their radius detail files?   What I would like to be able to do is,
have a link on a web page where the user can check the daily hours, weekly
hours, and monthly hours.  We ROTATE out detail logs every Saturday and
name them like: detail-month.wk1   The script would need to be able to
identify the month and then query all of those files to compile a Monthly
time online!

  If anyone has something like this, I'd like to hear from you.  We ARE
NOT using 3Com's S/A server, nor are we using MSQL databases.  Any and
all help appreciated!

==============================================================================
Phillip Ferraro                WorldNet Access, Inc
[e-mail]    Onslow County's PREMIER InterNet Service
Voice [phone]            824 Gumbranch Square, Suite R3
FAX   [phone]             Jacksonville, Nc  28540-6269
==============================================================================



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: [e-mail] (Jeff Binkley)
Subject: (usr-tc) WebRamp 310i
Date: 07 Aug 1999 12:39:00 -0500




Has anyone seen problems with the Web Ramp 310i units and the HiPerArc ?
This is the first 310i we have hooked up and while the connect speed is
resonable, the throughput is brutally slow.  The only options you have
on the 310i are:

header compression
data compression
MRU length


Since we run header compression here, we have it set for VanJacobsen
header compression.  For data compression the choices are stac and none.
We've tried both to no avail and changing the setting in Radius to auto,
Stac, and MS.  None helped.  For MRU they default to 1524 and the
HiPerArc is set to 1514 in Radius.  We had them drop their MRU down to
1514 and it helped some but was still about 25% of what you would expect
on an FTP session.  There is no new code on Ramp Networks site.  I am
running 4.1.64 code .  These tests were all ran into Quads.


Thanks,

Jeff Binkley
ASA Network Computing

CMPQwk 1.42-21 9999


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Allen Marsalis <[e-mail]>
Subject: Re: (usr-tc) Script for pulling USER times
Date: 07 Aug 1999 12:43:18 -0500

At 10:12 AM 8/7/99 -0400, [e-mail] wrote:
>
>    Does anyone have a script that they use to pull the user hours out
>of their radius detail files?

Processing radius logs is somewhat similar in nature to processing
webserver logs for user web access..  Either you need to use a
SQL database or in effect, roll your own like WebTrends does with
it's 'Fastrac' feature.

Sure we have a script that processes the radius logs each evening,
but the data goes into a SQL server where it can easily and
efficiently be searched and presented via html..  Without having
it in a database, the data would be considerably more difficult to
process, search, backup, authenticate, and present via webpages IMO..

You can purchase canned software that does all this (within a SQL
billing system such as Platypus) for not much money (around $3.5k)
compared to the time spent designing and implementing your own
from scratch.  Or even if you want to do it yourself, using a SQL
server would really speed up developement time.

>What I would like to be able to do is,
>have a link on a web page where the user can check the daily hours, weekly
>hours, and monthly hours.

We do that.  Without a SQL database, I imagine that it would be
fairly difficult to implement and manage..  You would end up
creating your own data structure and search routines.  There
are added benefits to going the Platypus route such as being
able to reliably bill off those hours. (we charge per hour
over 300 hours/mo).  You can give users access to other info
while they are there, such as updated credit cards and
expirations (platypus sends out an email warning of an upcoming
expiration and gives a link to update it).  Pretty cool..  Users
can also edit their address and phone numbers and change their
password..

>We ROTATE out detail logs every Saturday and
>name them like: detail-month.wk1   The script would need to be able to
>identify the month and then query all of those files to compile a Monthly
>time online!

But it would need to be run nightly if you want up to date
info available via webpages..  Running it every Saturday or
monthly would suck..  So each day, it builds upon previous days
logs..  The logs have to be rolled nightly to unless you deal
with the duplicate records.  It's really a pretty easy process
with a SQL server..  And it's easy to deliver the html with
php or .asp pages..

>
>  If anyone has something like this, I'd like to hear from you.  We ARE
>NOT using 3Com's S/A server, nor are we using MSQL databases.  Any and
>all help appreciated!

I would seriously consider adding a SQL server to the rack.  my .02

Allen

>
>==============================================================================
>Phillip Ferraro                WorldNet Access, Inc
>[e-mail]    Onslow County's PREMIER InterNet Service
>Voice [phone]            824 Gumbranch Square, Suite R3
>FAX   [phone]             Jacksonville, Nc  28540-6269
>==============================================================================
>
>
>
>-
> To unsubscribe to usr-tc, send an email to "[e-mail]"
> 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 "[e-mail]"
 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: "Jamie Orzechowski" <[e-mail]>
Subject: Re: (usr-tc) WebRamp 310i
Date: 07 Aug 1999 14:48:06 -0400

same here ... I just setup a Ramp 410i (ISDN) and it's slow ... VERY SLOW
...

----- Original Message -----
Sent: Saturday, August 07, 1999 1:39 PM


>
>
>
> Has anyone seen problems with the Web Ramp 310i units and the HiPerArc ?
> This is the first 310i we have hooked up and while the connect speed is
> resonable, the throughput is brutally slow.  The only options you have
> on the 310i are:
>
> header compression
> data compression
> MRU length
>
>
> Since we run header compression here, we have it set for VanJacobsen
> header compression.  For data compression the choices are stac and none.
> We've tried both to no avail and changing the setting in Radius to auto,
> Stac, and MS.  None helped.  For MRU they default to 1524 and the
> HiPerArc is set to 1514 in Radius.  We had them drop their MRU down to
> 1514 and it helped some but was still about 25% of what you would expect
> on an FTP session.  There is no new code on Ramp Networks site.  I am
> running 4.1.64 code .  These tests were all ran into Quads.
>
>
> Thanks,
>
> Jeff Binkley
> ASA Network Computing
>
> CMPQwk 1.42-21 9999
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: [e-mail] (Suncoast Networking ISP TC List Mailbox)
Subject: RE: (usr-tc) Gateways and routing...
Date: 07 Aug 1999 17:51:28 -0400

Just realize that packets going from a host
on one block will go in and out the 2501's
ethernet port to get to hosts on other blocks.

Steve


>no, do this
>
>ip address x.x.x.x 255.255.255.0
>ip address y.y.y.y 255.255.255.0 secondary
>ip address z.z.z.z 255.255.255.0 secondary
>ip address b.b.b.b 255.255.255.0 secondary
>
>ad nauseaum...should work
>
>> -----Original Message-----
>> From:    Stephen Amadei [SMTP:[e-mail]]
>> Sent:    Friday, August 06, 1999 7:42 PM
>> To:    [e-mail]
>> Subject:    Re: (usr-tc) Gateways and routing...
>>
>> On Fri, 6 Aug 1999, Charles Sprickman wrote:
>>
>> > I'm guessing that you're trying to add secondary interfaces to the cisco
>> > by doing something like 'ip address x.x.x.x x.x.x.x third' or
>>
>> Actually, I tried 'tertiary'... never thought of trying 'third'.
>>
>> > something because you mentioned it could only have one...  It should
>> take
>> > many, many more.  Just keep repeating 'ip address x.x.x.x x.x.x.x
>> > secondary' as many times as you need, and you should be fine.
>>
>> I'll give this a shot, thanks.
>>
>> > For organization's sake, you may want to put just a subnet (/28 or so)
>> on
>> > the cisco and put the arcs, netservers, and nmcs in that net, then just
>>
>> Subnetting our system is coming.  I'm just trying to delay the inevidible.
>>
>>                     ----Steve
>> Stephen Amadei
>> Director of MIS
>> Dandy Connections, Inc.
>> Atlantic City, NJ
>>


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) Gateways and routing...
Date: 07 Aug 1999 18:17:40 -0400 (EDT)

Thus spake Suncoast Networking ISP TC List Mailbox
>Just realize that packets going from a host
>on one block will go in and out the 2501's
>ethernet port to get to hosts on other blocks.

On that note, either make sure redirects are enabled (which will allow
the cisco to issue ICMP Redirects which will avoid what was described
above), or do an "ip route-cache same-interface" to enable fast
switching for packets doing the above...indeed, it might not be a bad
idea to do both!  :)
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: [e-mail]
Subject: (usr-tc) Filtering Specific username
Date: 10 Aug 1999 02:06:56 +0800

Good day.

Is there a way to Filter a specific username/s in TC.
What i would like to do is the user can only go to only one a specific
website.
Can this be done?

Herbert

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) Filtering Specific username
Date: 09 Aug 1999 07:56:48 -0400 (EDT)

Thus spake [e-mail]
>Is there a way to Filter a specific username/s in TC.  What i would
>like to do is the user can only go to only one a specific website.  Can
>this be done?

Sure...assign the filter from that user's RADIUS profile.  That way it
will only be assigned to that one user.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: [e-mail]
Subject: Re: (usr-tc) Script for pulling USER times
Date: 09 Aug 1999 23:13:51 +0900

[e-mail] ([e-mail]) wrote:
>     Does anyone have a script that they use to pull the user hours out
> of their radius detail files?   What I would like to be able to do is,
> have a link on a web page where the user can check the daily hours, weekly
> hours, and monthly hours.  We ROTATE out detail logs every Saturday and
> name them like: detail-month.wk1   The script would need to be able to
> identify the month and then query all of those files to compile a Monthly
> time online!

>   If anyone has something like this, I'd like to hear from you.  We ARE
> NOT using 3Com's S/A server, nor are we using MSQL databases.  Any and
> all help appreciated!

    ^_^; you called?

    livingston radius 2.1 with hacks to make it happy with USR VSA/dictionary
    and run with a cdb user db and as a regular user. I fail to see any need for
    it to run as root ^^; (these hacks are easy, I could post these)

    2 programs. parser (which parses radius --> flat file 1 rec/line)
        crossply (which stuffs teh results into oracle)

    4 radius servers (1,2,3,4, 1 talks to a portmonster so no license prob there ^^;)

    oracle sucks for this for a couple of reasons, mostly price related. Have you
    seen how many headaches a 5gb db causes oracle 7?
    On
    8.6megarecords, it takes about 10 minutes to tell me how long user A has been
    on this month. ^^;

    Anyway:
        parser/

        as it rotates detail files, it has some transaction buckets it keeps
        around, so even if a user is logged in for a million years, it will still
        see him ^^;

        supports "Alive", does not yet work on "Server-Reboot"

        protects against double billing if crossply breaks by doing dumb md5 tricks.


        crossply/

        brute force oracle import by perl/dbi ^^; no tricks, not proof against
        db errors.


    none of this code is release-worthy, as it is designed for my systems, but it could
    be massaged into such a state in my "copious free time".

    it took only a few days to get going and a weekend to put it on full-auto.

    After I send this, I will try and put some more complete information on my web page.
    (http://www.gol.ad.jp/) no guarantees though!!


    P

--
My words, my mail, my meaning.

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Scott Trautman <[e-mail]>
Subject: FW: (usr-tc) HiperARC: Very bogus route accepted from dialup user
Date: 09 Aug 1999 09:30:34 -0500

It's baaaack....thought we'd taken care of it by adding the default
Framed-Routing = none;
apparently not!

HiPer>> list ip route

IP ROUTES
Destination        Prot   NextHop         Metric  Interface
        0.0.0.0/0  NetMgr 151.46.147.1    1       eth:1
      127.0.0.1/H  LOCAL  127.0.0.1       1       loopback
     156.46.0.0/B  NetMgr 151.46.147.98   1       slot:4/mod:2

Our radius USER_DEFAULT Section:

USER_DEFAULT Password = "TUH3UyS3x5a04"
        Idle-Timeout = 1200,
        User-Service-Type = Framed-User,
        Framed-Protocol = PPP,
        Framed-Address = 255.255.255.254,
        Framed-MTU = 1500,
        Framed-Routing = None

The radius entry for the offending user:

PmruserguyD Crypt-Password = "ZuperCryptic", NAS-IP-Address = 151.46.147.*
        Idle-Timeout = 0,
        Framed-Address = 151.46.147.97,
        Framed-Netmask = 255.255.255.248,
        Framed-Route = "151.46.147.96 151.46.147.98 1",
        Framed-Filter-Id = std

I was, again, able to do a delete ip route 151.46.0.0 and the problem went
away, but, I need to get this setup so it just won't listen to routes from
dialup users!

Any new ideas? Any way to set the default on the ARC to not accept routes
from dialup users?
Additional information I can provide?

Names, networks and passwords changed of course to protect the guilty.

Thanks!

SMT


Sent: Monday, August 02, 1999 3:28 PM
user even though supposedly not accepting routes from dialup users....


Well, I'm going to guess that the problem was a HiperARC default, as we
didn't have a Framed-Routing default, so assume it'd default to something I
didn't want on the ARC. We have the USER_DEFAULT set to Framed-Routing = 0
now and I strongly suspect we'll not see this problem again.

Might still be useful to know how to shut it off in the ARC, but basically
problem solved.

When I had this before, I recall trying to find something on NetMgr in the
ARC 1.0 PDF manual and couldn't find it.

Thanks for the tip....

SMT
|
>
> I would be very curious to see how this customer is adding
> this route.. NetMgr
> routes are static routes configured on the HARC or via
> FRAMED_ROUTE (local or
> RADIUS).  A "learned" route would not show up as NetMgr.
>
> Can you get me the RADIUS entry for this user. "show remote
> user <X>" when the
> user is online. Also show me your default user configs.
>
> -M
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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 "[e-mail]"
 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 Oster" <[e-mail]>
Subject: (usr-tc) Odd route showing up in netserver
Date: 09 Aug 1999 09:54:23 -0500

This is a multi-part message in MIME format.

------=_NextPart_000_000F_01BEE24D.28E4E040
Content-Type: text/plain;
    charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

207.3.82.240     /28  206.30.138.243    NS      1   Unknown      0

I've got a user who has a subnet over dialup, and the above route
keeps
shoing up and taking precidence... any idea WHERE this is coming from
and why
it is showing up?  I'm about stumped on this one.  My radius entry for
the user looks like
this


USER    Auth-Type = System
        Session-Timeout = 0,
        Idle-Timeout = 0,
        Service-Type = Framed,
        Framed-Protocol = PPP,
        Framed-IP-Address = 207.3.82.241,
        Framed-IP-Netmask = 255.255.255.240,
        Framed-Route = "207.3.82.240/28 207.3.82.241 1",
        Framed-Compression = Van-Jacobson-TCP-IP,
        Framed-Routing = Broadcast,
        Simultaneous-Use = 1

Paul

------=_NextPart_000_000F_01BEE24D.28E4E040
Content-Type: text/x-vcard;
    name="Paul M Oster.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
    filename="Paul M Oster.vcf"

BEGIN:VCARD
VERSION:2.1
N:Oster;Paul;M;Mr
FN:Paul M Oster
ORG:Magic Internet Services
TITLE:IT Manager
TEL;WORK;VOICE:701-838-1265
TEL;WORK;FAX:[phone]
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;400 10th St =
SE=3D0D=3D0A;Minot;ND;58701;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:400 10th St =
SE=3D0D=3D0A=3D0D=3D0AMinot, ND 58701=3D0D=3D0AUSA
EMAIL;PREF;INTERNET:[e-mail]
REV:19990809T145423Z
END:VCARD

------=_NextPart_000_000F_01BEE24D.28E4E040--


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Steve Johnson <[e-mail]>
Subject: (usr-tc) Utilization
Date: 09 Aug 1999 09:28:42 -0700


I have 5 USR Total Control units, all with about 5 Hyper DSPs each.


What is the best way to monitor PRI usage?  I need to find out how far up
into my hunt group I am getting, so I can see if it is time to order new
PRIs, How is this monitored?  Thanks for any help.

-Steve



--
 ----------------------------------------------------------------------------
 Steve Johnson                                     Sonic Sys Admin
 [phone] (33.6kbps)                          [phone] (Voice)
 e-mail linuxnut at sonic.net                       http://www.sonic.net
 ----------------------------------------------------------------------------
   "Knowing others is wisdom, knowing your self is Enlightenment."
                                                   -- Lao-Tzu

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Steve McConnell <[e-mail]>
Subject: Re: (usr-tc) Utilization
Date: 09 Aug 1999 12:45:14 -0400

mrtg and the usr script that come with it.

work like  a dream.

 http://ee-staff.ethz.ch/~oetiker/webtools/mrtg/mrtg.html



--On Monday, August 09, 1999, 9:28 AM -0700 Steve Johnson
<[e-mail]> wrote:

>
> I have 5 USR Total Control units, all with about 5 Hyper DSPs each.
>
>
> What is the best way to monitor PRI usage?  I need to find out how far up
> into my hunt group I am getting, so I can see if it is time to order new
> PRIs, How is this monitored?  Thanks for any help.
>
> -Steve
>
>
>
> --
>  ------------------------------------------------------------------------
>  ---- Steve Johnson                                     Sonic Sys Admin
>   [phone] (33.6kbps)                          [phone] (Voice)
>   e-mail linuxnut at sonic.net                       http://www.sonic.net
>
>  ------------------------------------------------------------------------
>  ---- "Knowing others is wisdom, knowing your self is Enlightenment." --
>                                                    Lao-Tzu
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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.



Steve McConnell
EMJI
919-303-3217
888-258-8959


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Brice Ligget <[e-mail]>
Subject: Re: (usr-tc) Utilization
Date: 09 Aug 1999 10:48:04 -0600

One TLA (Three Letter Acronym) MRTG.  Stick that in a Yahoo! search and
you'll find plenty.  It's not the easiest thing to set up but it's worth
it.  It's free.  Until then you can count it by hand by doing a li con on
each hiperarc.

At 09:28 AM 8/9/99 -0700, you wrote:

>I have 5 USR Total Control units, all with about 5 Hyper DSPs each.
>
>
>What is the best way to monitor PRI usage?  I need to find out how far up
>into my hunt group I am getting, so I can see if it is time to order new
>PRIs, How is this monitored?  Thanks for any help.
>
>-Steve


--
Brice Ligget
Billings MT
[e-mail]
http://www.twoalpha.net/~bligget
DoD#2159

The truth is that life is hard and dangerous; that those
who seek their own happiness do not find it; that those
who are weak must suffer; that those who demand love
will be disappointed; that those who are greedy will not
be fed; that those who seek peace will find strife; that
truth is only for the brave; that joy is only for those
who do not fear to be alone; that life is only for the
one who is not afraid to die.
                                 Joyce Cary

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Allen Marsalis <[e-mail]>
Subject: Re: (usr-tc) Utilization
Date: 09 Aug 1999 12:57:02 -0500

At 09:28 AM 8/9/99 -0700, Steve Johnson wrote:
>
>I have 5 USR Total Control units, all with about 5 Hyper DSPs each.
>
>
>What is the best way to monitor PRI usage?

also, pmmon (www.tsmon.com) makes nice graphs of modem/pri usage...
for a sample, see:  http://mars.shreve.net/pmmon/

Allen


>I need to find out how far up
>into my hunt group I am getting, so I can see if it is time to order new
>PRIs, How is this monitored?  Thanks for any help.
>
>-Steve
>
>
>
>--
> ----------------------------------------------------------------------------
> Steve Johnson                                     Sonic Sys Admin
> [phone] (33.6kbps)                          [phone] (Voice)
> e-mail linuxnut at sonic.net                       http://www.sonic.net
> ----------------------------------------------------------------------------
>   "Knowing others is wisdom, knowing your self is Enlightenment."
>                                                   -- Lao-Tzu
>
>-
> To unsubscribe to usr-tc, send an email to "[e-mail]"
> 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 "[e-mail]"
 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: Mike Andrews <[e-mail]>
Subject: Re: (usr-tc) Utilization
Date: 09 Aug 1999 14:21:44 -0400 (EDT)

MRTG:

    http://ee-staff.ethz.ch/~oetiker/webtools/mrtg/mrtg.html

and docs on how to get it talking to your Total Controls:

    http://www.dcr.net/~mandrews/usrtoys/mrtg.shtml


Mike Andrews (MA12) -=-=-  VP & Sysadmin, Digital Crescent, Frankfort KY
[e-mail]  -=--=-  [e-mail]  -=--=-  http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."

On Mon, 9 Aug 1999, Steve Johnson wrote:

>
> I have 5 USR Total Control units, all with about 5 Hyper DSPs each.
>
>
> What is the best way to monitor PRI usage?  I need to find out how far up
> into my hunt group I am getting, so I can see if it is time to order new
> PRIs, How is this monitored?  Thanks for any help.
>
> -Steve
>
>
>
> --
>  ----------------------------------------------------------------------------
>  Steve Johnson                                     Sonic Sys Admin
>  [phone] (33.6kbps)                          [phone] (Voice)
>  e-mail linuxnut at sonic.net                       http://www.sonic.net
>  ----------------------------------------------------------------------------
>    "Knowing others is wisdom, knowing your self is Enlightenment."
>                                                    -- Lao-Tzu
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: [e-mail]
Subject: (usr-tc) ARC's Ethernet Port2
Date: 09 Aug 1999 15:45:55 -0500

I just found a pop with a bad ARC card. Can't communicate with it via
Ethernet. If I grab hold of the console port, what do I need to do to
reroute the hiperDSP's thru the second eth port rather than the first.

Thanks,
Brian

Brian Becker
Poplar Bluff Internet, Inc.
    http://www.semo.net
Home of JerusalemPerspective.com Bookstore
    http://www.JerusalemPerspective.com
TotallyFabricated.com's Webgabber Chat Software
    http://www.TotallyFabricated.com
and my personal page
    http://www.Tonionio.com



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Scott Trautman <[e-mail]>
Subject: FW: (usr-tc) HiperARC: Very bogus route accepted from dialup user
Date: 09 Aug 1999 15:55:29 -0500

It's baaaack....thought we'd taken care of it by adding the default
Framed-Routing = none;
apparently not!

HiPer>> list ip route

IP ROUTES
Destination        Prot   NextHop         Metric  Interface
        0.0.0.0/0  NetMgr 151.46.147.1    1       eth:1
      127.0.0.1/H  LOCAL  127.0.0.1       1       loopback
     156.46.0.0/B  NetMgr 151.46.147.98   1       slot:4/mod:2

Our radius USER_DEFAULT Section:

USER_DEFAULT Password = "TUH3UyS3x5a04"
        Idle-Timeout = 1200,
        User-Service-Type = Framed-User,
        Framed-Protocol = PPP,
        Framed-Address = 255.255.255.254,
        Framed-MTU = 1500,
        Framed-Routing = None

The radius entry for the offending user:

PmruserguyD Crypt-Password = "ZuperCryptic", NAS-IP-Address = 151.46.147.*
        Idle-Timeout = 0,
        Framed-Address = 151.46.147.97,
        Framed-Netmask = 255.255.255.248,
        Framed-Route = "151.46.147.96 151.46.147.98 1",
        Framed-Filter-Id = std

I was, again, able to do a delete ip route 151.46.0.0 and the problem went
away, but, I need to get this setup so it just won't listen to routes from
dialup users!

Any new ideas? Any way to set the default on the ARC to not accept routes
from dialup users?
Additional information I can provide?

Names, networks and passwords changed of course to protect the guilty.

Thanks!

SMT


Sent: Monday, August 02, 1999 3:28 PM
user even though supposedly not accepting routes from dialup users....


Well, I'm going to guess that the problem was a HiperARC default, as we
didn't have a Framed-Routing default, so assume it'd default to something I
didn't want on the ARC. We have the USER_DEFAULT set to Framed-Routing = 0
now and I strongly suspect we'll not see this problem again.

Might still be useful to know how to shut it off in the ARC, but basically
problem solved.

When I had this before, I recall trying to find something on NetMgr in the
ARC 1.0 PDF manual and couldn't find it.

Thanks for the tip....

SMT
|
>
> I would be very curious to see how this customer is adding
> this route.. NetMgr
> routes are static routes configured on the HARC or via
> FRAMED_ROUTE (local or
> RADIUS).  A "learned" route would not show up as NetMgr.
>
> Can you get me the RADIUS entry for this user. "show remote
> user <X>" when the
> user is online. Also show me your default user configs.
>
> -M
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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 "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) ARC's Ethernet Port2
Date: 09 Aug 1999 16:58:31 -0400 (EDT)

Thus spake [e-mail]
>I just found a pop with a bad ARC card. Can't communicate with it via
>Ethernet. If I grab hold of the console port, what do I need to do to
>reroute the hiperDSP's thru the second eth port rather than the first.

Well...assuming you have a cable plugged into the second one and all
that.  :)

I *think*:
reconfigure ip network <networkname> interface eth:2

will do what you need.

Otherwise, you could disable, and delete the network from the first int,
then add it again, just specifying the second int.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: FW: (usr-tc) HiperARC: Very bogus route accepted from dialup user
Date: 09 Aug 1999 17:13:46 -0400 (EDT)

Thus spake Scott Trautman
>It's baaaack....thought we'd taken care of it by adding the default
>Framed-Routing = none;
>apparently not!

>The radius entry for the offending user:

>PmruserguyD Crypt-Password = "ZuperCryptic", NAS-IP-Address = 151.46.147.*
>        Idle-Timeout = 0,
>        Framed-Address = 151.46.147.97,
>        Framed-Netmask = 255.255.255.248,
>        Framed-Route = "151.46.147.96 151.46.147.98 1",
                         ^^^^^^^^^^^^^^
>        Framed-Filter-Id = std

>I was, again, able to do a delete ip route 151.46.0.0 and the problem went
>away, but, I need to get this setup so it just won't listen to routes from
>dialup users!

Its not listening to routes from users...its setting the route you're
(sort of) telling it to set from RADIUS.

You'll notice the highlighted portion above...the natural mask of that
address is a class B mask.  So, the Arc is most likely (and this is
based on the information I have...so I might be wrong here) taking that
Framed-Route and assuming the netmask of 255.255.0.0.  You will probably
want to change that line to be:
Framed-Route = "151.46.147.96/29 151.46.147.98 1"

That will for the route entry to match the Framed-Netmask you've
supplied.

A couple of other tips...

Assuming you're wanting the Framed-Route to enter the route that matches
the Framed-Netmask that you've supplied...the Framed-Route entry is
superfluous.  The Framed-Address, combined with the Framed-Netmask
should get the Arc to add the /29 route that you're using, without
needing to add the Framed-Route seperately.

Also...if you do need the Framed-Route...you can set the "destination"
of the Framed-Route in RADIUS to be "0.0.0.0".  This is a flag value
used in most (all?) NASen to tell them to use the Framed-Address
supplied (or not supplied) as the destination of the Framed-Route.  This
allows the systems to use a dynamic IP address for the PPP link, and
still route a block to the dialup connection.  Kind of a nice
functionality that I've not seen anyone really take advantage of.  We do
use the 0.0.0.0 address, but we also specify the Framed-Address
specifically, so we really don't take full advantage of this feature as
we could.

>Additional information I can provide?

To confirm that the Arc is indeed not listening for routes (it shouldn't
be from what I can see) you should be able to do a list ip networks,
pick out the network name assigned to this user and do a show ip network
<networknameforuser>.

Look for "IP Routing Protocol" and I suspect it'll say "NONE" indicating
that its not actually listening to routes.

Besides...if it were listening for routes...the route in your routing
table would show up as "RIP", not "NetMgr".  "NetMgr" indicates that it
was inserted into the routing table administratively (RADIUS, or CLI, or
SNMP, or something like that).
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Mike Wronski" <[e-mail]>
Subject: RE: (usr-tc) HiperARC: Very bogus route accepted from dialup user even though supposedly not accepting routes from dialup users....
Date: 09 Aug 1999 16:29:38 -0500


Looks like you are specifying that route in the Framed-Route statement.
    Framed-Route = "151.46.147.96 151.46.147.98 1"

From the RFC since you didn't specify a netmask the device applies the netmask
based on the prefix.. You listed 151.46. (Class B) thus the route in the table is
151.46.0.0/B 151.46.147.98 and correct.

What route are you trying to set for this user? You are assigning a 29 bit
netmask (.248) Giving you:
Network: 151.46.147.96
Bcast: 151.46.147.103
Valid Addresses: 97-102
You assign .97 to the user interface.

You then have a framed route sending all class B traffic to 151.46.x.x to
151.46.147.98.
Can you clarify what you really want? I think you may want
"Framed-Route = "151.46.147.96/29 151.46.147.97 1" Sending all subnet traffic to
the interface address you assigned.




NOTE: This route was not "learned". It was specified by RADIUS. The end user did
not inject anything.


-M


|-----Original Message-----
|From: [e-mail]
|[mailto:[e-mail]]On Behalf Of Scott Trautman
|Sent: Monday, August 09, 1999 3:55 PM
|To: '[e-mail]'
|Subject: FW: (usr-tc) HiperARC: Very bogus route accepted from dialup
|user even though supposedly not accepting routes from dialup users....
|
|
|It's baaaack....thought we'd taken care of it by adding the default
|Framed-Routing = none;
|apparently not!
|
|HiPer>> list ip route
|
|IP ROUTES
|Destination        Prot   NextHop         Metric  Interface
|        0.0.0.0/0  NetMgr 151.46.147.1    1       eth:1
|      127.0.0.1/H  LOCAL  127.0.0.1       1       loopback
|     156.46.0.0/B  NetMgr 151.46.147.98   1       slot:4/mod:2
|
|Our radius USER_DEFAULT Section:
|
|USER_DEFAULT Password = "TUH3UyS3x5a04"
|        Idle-Timeout = 1200,
|        User-Service-Type = Framed-User,
|        Framed-Protocol = PPP,
|        Framed-Address = 255.255.255.254,
|        Framed-MTU = 1500,
|        Framed-Routing = None
|
|The radius entry for the offending user:
|
|PmruserguyD Crypt-Password = "ZuperCryptic", NAS-IP-Address = 151.46.147.*
|        Idle-Timeout = 0,
|        Framed-Address = 151.46.147.97,
|        Framed-Netmask = 255.255.255.248,
|        Framed-Route = "151.46.147.96 151.46.147.98 1",
|        Framed-Filter-Id = std
|
|I was, again, able to do a delete ip route 151.46.0.0 and the problem went
|away, but, I need to get this setup so it just won't listen to routes from
|dialup users!
|
|Any new ideas? Any way to set the default on the ARC to not accept routes
|from dialup users?
|Additional information I can provide?
|
|Names, networks and passwords changed of course to protect the guilty.
|
|Thanks!
|
|SMT
|
|
|Sent: Monday, August 02, 1999 3:28 PM
|To: '[e-mail]'
|Subject: RE: (usr-tc) HiperARC: Very bogus route accepted from dialup
|user even though supposedly not accepting routes from dialup users....
|
|
|Well, I'm going to guess that the problem was a HiperARC default, as we
|didn't have a Framed-Routing default, so assume it'd default to something I
|didn't want on the ARC. We have the USER_DEFAULT set to Framed-Routing = 0
|now and I strongly suspect we'll not see this problem again.
|
|Might still be useful to know how to shut it off in the ARC, but basically
|problem solved.
|
|When I had this before, I recall trying to find something on NetMgr in the
|ARC 1.0 PDF manual and couldn't find it.
|
|Thanks for the tip....
|
|SMT
||
|>
|> I would be very curious to see how this customer is adding
|> this route.. NetMgr
|> routes are static routes configured on the HARC or via
|> FRAMED_ROUTE (local or
|> RADIUS).  A "learned" route would not show up as NetMgr.
|>
|> Can you get me the RADIUS entry for this user. "show remote
|> user <X>" when the
|> user is online. Also show me your default user configs.
|>
|> -M
|>
|>
|> -
|>  To unsubscribe to usr-tc, send an email to "[e-mail]"
|>  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 "[e-mail]"
| 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 "[e-mail]"
| 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 "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) HiperARC: Very bogus route accepted from dialup user even though supposedly not accepting routes from dialup users.
Date: 09 Aug 1999 18:36:41 -0400 (EDT)

Thus spake Mike Wronski
>Looks like you are specifying that route in the Framed-Route statement.
>    Framed-Route = "151.46.147.96 151.46.147.98 1"

>From the RFC since you didn't specify a netmask the device applies the
>netmask based on the prefix.. You listed 151.46. (Class B) thus the
>route in the table is 151.46.0.0/B 151.46.147.98 and correct.

You know...in this day and age, I'd almost say it would be better to not
assume classful routing and generate an error.  I know...that may not be
by the books, but classful behavior in stuff is pretty much broken in
this day and age...I guess I'd like to see the book changed in this
case.  Ah well.  :)

>What route are you trying to set for this user? You are assigning a 29 bit
>netmask (.248) Giving you:
>Network: 151.46.147.96
>Bcast: 151.46.147.103
>Valid Addresses: 97-102
>You assign .97 to the user interface.

Hrmm...there's something that's interesting...Basically the RADIUS entry
is informing the Arc of two different routes (one via Framed-Route, the
other via the combination of Framed-Address and Framed-Netmask).  I
would *think* the Arc would install both of these routes in the routing
table (and thus advertise them out), but the original question didn't
indicate that this was happening (maybe it did and I missed it?).  I was
thinking ours did do this (we use a Framed-Netmask of 255.255.255.255,
so we get a /32 and /xx for whatever Framed-Route is assigned), but
wasn't sure if maybe it handled it differently if one of them wasn't a
/32 or something?  That would be really odd.  Just wanted to confirm
that this does actually add both routes and advertise them (if using a
routing protocol of course).  :)

>You then have a framed route sending all class B traffic to 151.46.x.x
>to 151.46.147.98.  Can you clarify what you really want? I think you
>may want "Framed-Route = "151.46.147.96/29 151.46.147.97 1" Sending all
>subnet traffic to the interface address you assigned.

Nyah, nyah, Mike...beat ya to it.  ;)
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Brett Murphy" <[e-mail]>
Subject: (usr-tc) Packet Bus Clock setting on Netserver?
Date: 10 Aug 1999 10:42:39 +1000

Hi All,
I have a chassis where the netserver says "Packet Bus Clock :Slave" and both
Span's
on my Dual PRI E1 card work fine.
On FOUR other identical chassis it says "Packet Bus Clock: MASTER"
and on these chassis SPAN1 does NOT work, but SPAN 2 does.
Am I on the right track to solving this problem?
If so how do I set it to SLAVE on the other chassis(es)????

All the best,
Brett Murphy
Technical Manager, Alphalink (Australia) PTY LTD
ph: [phone]  fax: [phone]
email: [e-mail]

The contents of this email message may not be quoted,
copied, reproduced or published in part or in whole,
without the written authorization of Brett Murphy,
Director, Alphalink (Australia) Pty Ltd.



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) Packet Bus Clock setting on Netserver?
Date: 09 Aug 1999 21:48:31 -0400 (EDT)

Thus spake Brett Murphy
>I have a chassis where the netserver says "Packet Bus Clock :Slave" and
>both Span's on my Dual PRI E1 card work fine.  On FOUR other identical
>chassis it says "Packet Bus Clock: MASTER" and on these chassis SPAN1
>does NOT work, but SPAN 2 does.  Am I on the right track to solving
>this problem?  If so how do I set it to SLAVE on the other
>chassis(es)????

Nope...I don't think you are...I seriously doubt that the packet bus
clock has anything to do with your spans not working.  The packet bus
clock setting is an indication of where the clocking signal for the
packet bus (I know...duh) is pulled from.  This has nothing to do with
the clocking on the spans.  What you'll want to check if you think its a
clocking problem is in the t1 span settings somewhere it should tell you
what the source for the clock is...span 1, span 2, or internal would be
the most common sources.

The packet bus is a bus in the chassis midplane, and has nothing to do
with the spans (pri or t1).  The only time any signaling having to do
with spans has anything to do with the packet bus is d channel signaling
information is forwarded to the modems from the dual-pri card on the
packet bus I believe.  Otherwise, clocking for the spans is either off
an internal clock (bad idea generally) or recovered from one of the
spans (typically the first one).

The newer chassis' have clocks for the packet bus in the chassis
circuitry itself...older ones will most often I believe pull clocking
from the NMC (but don't quote me on that)...but it can be on other cards
at times.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Brett Murphy" <[e-mail]>
Subject: (usr-tc) Dual E1 NIC Problem
Date: 10 Aug 1999 15:08:34 +1000

Hi All,
I have 5 Dual E1 NIC's part number 69-000395-01 that do not work on SPAN1
but do on SPAN2
I Also have a Dual E1 NIC part number 69-000395-00 that works fine on both
SPAN's

The only difference I can see between the two are the revision of the main
IC on the board.

69-000395-00 has version 1.019.527 and is dated 10/13/95
69-000395-01 has version 1.019.812 and is dated 3/3/98

If anyone has any idea whatsoever why the newer cards would have problems
with the SPAN 1
port on Australian E1's please let me know.


All the best,
Brett Murphy
Technical Manager, Alphalink (Australia) PTY LTD
ph: [phone]  fax: [phone]
email: [e-mail]

The contents of this email message may not be quoted,
copied, reproduced or published in part or in whole,
without the written authorization of Brett Murphy,
Director, Alphalink (Australia) Pty Ltd.



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Ed" <[e-mail]>
Subject: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 10 Aug 1999 01:24:13 -0400

3com not doing V.90 as well as Ascend's.....

We have tested and found it to be true that Ascend's authenticate and work
at V.90 speeds much more often than 3com. It even happens when using a
3com/USR modem. It takes certain a certain situation for this to happen but
it does happen...

Just wondered if others out there have noticed it or had their competitors
using Ascend's have customers that say "Well I get 56K speeds on so and so
Internet Service, why not yours?"


Ed
4 Year Total Control User


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Jim Johnson <[e-mail]>
Subject: Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 10 Aug 1999 08:18:27 -0400


Just my .02, but when testing like this, make sure that you have the NAS
equipment in the same location.  Test with the PRI connected to one NAS
and then connect the same PRI to the other NAS and test.

Otherwise, you are evaluating the phone companies local network.

Jim

Ed wrote:
>
> 3com not doing V.90 as well as Ascend's.....
>
> We have tested and found it to be true that Ascend's authenticate and work
> at V.90 speeds much more often than 3com. It even happens when using a
> 3com/USR modem. It takes certain a certain situation for this to happen but
> it does happen...
>
> Just wondered if others out there have noticed it or had their competitors
> using Ascend's have customers that say "Well I get 56K speeds on so and so
> Internet Service, why not yours?"
>
> Ed
> 4 Year Total Control User
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: Greg Coffey <[e-mail]>
Subject: Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 10 Aug 1999 07:30:24 -0600

We have a pocket of customers that get v90 connects with a competitor using
Ascend and cannot with the same setup to our TC hubs.  Never get a v90 with
us and they get one pretty consistently with the competition.  The
customers are running Sportsters on their end.  I ran it by 3Com some
months back and was told that it was a bug in the Ascend software and to a
degree in the Sportsters.  I asked if that bug could be introduced to the
TC's but he said that it would break other areas and cause more problems
than it would address.

At 01:24 AM 8/10/99 -0400, you wrote:
>3com not doing V.90 as well as Ascend's.....
>
>We have tested and found it to be true that Ascend's authenticate and work
>at V.90 speeds much more often than 3com. It even happens when using a
>3com/USR modem. It takes certain a certain situation for this to happen but
>it does happen...
>
>Just wondered if others out there have noticed it or had their competitors
>using Ascend's have customers that say "Well I get 56K speeds on so and so
>Internet Service, why not yours?"
>
>
>Ed
>4 Year Total Control User
>
>
>-
> To unsubscribe to usr-tc, send an email to "[e-mail]"
> 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.
>
>
Thanks,

Greg Coffey, Visionary Communications  V 307-234-5443  F 307-234-5446
=====================================================================
142 S. Center St.          3Com v.90 56k Casper, Rawlins, Douglas,
Casper, WY  82601          Sheridan, Cody, Gillette, Buffalo,
http://WWW.VCN.COM         Rock Springs, Cheyenne, & Laramie, WY


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Greg Coffey <[e-mail]>
Subject: Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 10 Aug 1999 07:39:37 -0600

In our situation, we are two blocks from the main CO.  The competition is
about 1/2 mile further away.  Both of us use USWorst for facilities and
both of us are using channelized T1's on UAS.  As far as I know, the lines
are setup exactly the same.  John Powell was my contact at 3Com.  3Com
acknowledged the issue that some modems, including Sportsters, could
connect at v90 with other RAS equipment but would not with 3Com's.  My
discussion on this took place 6 mos or so ago.  I don't know that there has
been any change in the meantime.  John said that it would break more areas
than it was worth.  It was a bug in the Ascend software.  Perhaps it is a
decent time to investigate it again.

At 08:18 AM 8/10/99 -0400, you wrote:
>
>Just my .02, but when testing like this, make sure that you have the NAS
>equipment in the same location.  Test with the PRI connected to one NAS
>and then connect the same PRI to the other NAS and test.
>
>Otherwise, you are evaluating the phone companies local network.
>
>Jim
>
>Ed wrote:
>>
>> 3com not doing V.90 as well as Ascend's.....
>>
>> We have tested and found it to be true that Ascend's authenticate and work
>> at V.90 speeds much more often than 3com. It even happens when using a
>> 3com/USR modem. It takes certain a certain situation for this to happen but
>> it does happen...
>>
>> Just wondered if others out there have noticed it or had their competitors
>> using Ascend's have customers that say "Well I get 56K speeds on so and so
>> Internet Service, why not yours?"
>>
>> Ed
>> 4 Year Total Control User
>>
>> -
>>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>>  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 "[e-mail]"
> 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.
>
>
Thanks,

Greg Coffey, Visionary Communications  V 307-234-5443  F 307-234-5446
=====================================================================
142 S. Center St.          3Com v.90 56k Casper, Rawlins, Douglas,
Casper, WY  82601          Sheridan, Cody, Gillette, Buffalo,
http://WWW.VCN.COM         Rock Springs, Cheyenne, & Laramie, WY


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 10 Aug 1999 09:47:49 -0400 (EDT)

Post some logs please.

Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax [phone]
[e-mail]

On Tue, 10 Aug 1999, Ed wrote:

> 3com not doing V.90 as well as Ascend's.....
>
> We have tested and found it to be true that Ascend's authenticate and work
> at V.90 speeds much more often than 3com. It even happens when using a
> 3com/USR modem. It takes certain a certain situation for this to happen but
> it does happen...
>
> Just wondered if others out there have noticed it or had their competitors
> using Ascend's have customers that say "Well I get 56K speeds on so and so
> Internet Service, why not yours?"
>
>
> Ed
> 4 Year Total Control User
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: "Stainforth, Matthew" <[e-mail]>
Subject: (usr-tc) HARC 4.2.29
Date: 10 Aug 1999 10:35:55 -0300


Any idea when this will be unlocked or a new version will be released?  I
have a new chassis that I have to get flashed and into service.

Is this revision still able to handle 14 DSPs without advanced routing or
IPX?

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: [e-mail] (Jeff Binkley)
Subject: (usr-tc) Webramp 310i
Date: 10 Aug 1999 11:13:00 -0500



I asked this last week and only got one reply, si I'll throw it out
again and hopefully Krish can join in.  We have a reseller who is trying
to hook up to us (HiperArc v 4.1.64 w/Quads and DSPs) with a Ramp
Networks 310i Web Ramp.  They have tried 3 different units and all three
will connect fine but the data throughput is brutally slow (about 20% of
capacity).  The only options the 310i has is compression, header
compression and MRU.  We've tried all combinations of settings and
nothing seems to make a major difference. We run IP header compression
on our HiPerArc so they have Van-Jacobsen header compression enabled.
For data compression they only support Stac or none and the MRU setting
defaults to 1524.  I am open to suggestions.  They other person who
answered last week is having a similar experience.

Jeff Binkley
ASA Network Computing

CMPQwk 1.42 9999


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Tatai SV Krishnan <[e-mail]>
Subject: Re: (usr-tc) Webramp 310i
Date: 10 Aug 1999 10:25:58 -0500 (CDT)

On Tue, 10 Aug 1999, Jeff Binkley wrote:

>
>
> I asked this last week and only got one reply, si I'll throw it out
> again and hopefully Krish can join in.  We have a reseller who is trying
> to hook up to us (HiperArc v 4.1.64 w/Quads and DSPs) with a Ramp
> Networks 310i Web Ramp.  They have tried 3 different units and all three
> will connect fine but the data throughput is brutally slow (about 20% of
> capacity).  The only options the 310i has is compression, header
> compression and MRU.  We've tried all combinations of settings and
> nothing seems to make a major difference. We run IP header compression
> on our HiPerArc so they have Van-Jacobsen header compression enabled.
> For data compression they only support Stac or none and the MRU setting

Is there a difference if you disable STac compression?


krish

> defaults to 1524.  I am open to suggestions.  They other person who
> answered last week is having a similar experience.
>
> Jeff Binkley
> ASA Network Computing
>
> CMPQwk 1.42 9999
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: Frank Basso <[e-mail]>
Subject: Re: (usr-tc) Webramp 310i
Date: 10 Aug 1999 08:29:46 -0700

Turn off the header compression. Webramp are notorious for not working with
the Hiper Chassis if you have VJ compression enabled. We turn this off by
default; it actually worked once but in recent versions it now does not, I
think 4.0.32 on the Arc, and 1.0.29 on the Modem was the last time it worked
for us..long time ago...


-Frank

Tatai SV Krishnan wrote:

> On Tue, 10 Aug 1999, Jeff Binkley wrote:
>
> >
> >
> > I asked this last week and only got one reply, si I'll throw it out
> > again and hopefully Krish can join in.  We have a reseller who is trying
> > to hook up to us (HiperArc v 4.1.64 w/Quads and DSPs) with a Ramp
> > Networks 310i Web Ramp.  They have tried 3 different units and all three
> > will connect fine but the data throughput is brutally slow (about 20% of
> > capacity).  The only options the 310i has is compression, header
> > compression and MRU.  We've tried all combinations of settings and
> > nothing seems to make a major difference. We run IP header compression
> > on our HiPerArc so they have Van-Jacobsen header compression enabled.
> > For data compression they only support Stac or none and the MRU setting
>
> Is there a difference if you disable STac compression?
>
> krish
>
> > defaults to 1524.  I am open to suggestions.  They other person who
> > answered last week is having a similar experience.
> >
> > Jeff Binkley
> > ASA Network Computing
> >
> > CMPQwk 1.42 9999
> >
> >
> > -
> >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> >  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 "[e-mail]"
>  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 "[e-mail]"
 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: "Ed" <[e-mail]>
Subject: Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 10 Aug 1999 11:45:13 -0400

No trust me we tested in full. We have an Ascend box and used the same PRI
line and plugged it into the 3com and then into the Ascend. Ascend got V.90
speeds and the 3com did not. It is not the phone company's network....


Ed

----- Original Message -----
Sent: Tuesday, August 10, 1999 8:18 AM



Just my .02, but when testing like this, make sure that you have the NAS
equipment in the same location.  Test with the PRI connected to one NAS
and then connect the same PRI to the other NAS and test.

Otherwise, you are evaluating the phone companies local network.

Jim

Ed wrote:
>
> 3com not doing V.90 as well as Ascend's.....
>
> We have tested and found it to be true that Ascend's authenticate and work
> at V.90 speeds much more often than 3com. It even happens when using a
> 3com/USR modem. It takes certain a certain situation for this to happen
but
> it does happen...
>
> Just wondered if others out there have noticed it or had their competitors
> using Ascend's have customers that say "Well I get 56K speeds on so and so
> Internet Service, why not yours?"
>
> Ed
> 4 Year Total Control User
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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 "[e-mail]"
 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: Allen Marsalis <[e-mail]>
Subject: Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 10 Aug 1999 11:09:23 -0500

At 01:24 AM 8/10/99 -0400, Ed wrote:
>3com not doing V.90 as well as Ascend's.....
>
>We have tested and found it to be true that Ascend's authenticate and work
>at V.90 speeds much more often than 3com. It even happens when using a
>3com/USR modem. It takes certain a certain situation for this to happen but
>it does happen...
>
>Just wondered if others out there have noticed it or had their competitors
>using Ascend's have customers that say "Well I get 56K speeds on so and so
>Internet Service, why not yours?"

We have been 100% USR/3COM for 3 years and we recently received a Max
TNT for eval to address the above problem..  Both chassis will be
at the same NOC.  2 new PRI's for the TNT should be up this week..
I'll keep you posted as to the results and try to provide some statistical
data..

Allen


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Scott Trautman <[e-mail]>
Subject: (usr-tc) Prime on Dual T1 card & HiperARC
Date: 10 Aug 1999 15:49:14 -0500

Hi--

I usually put my ISDN customers/primes on Livingston PM3's (run for 9
months+ without a problem...), but I have a free Dual T1 card hanging around
and would just as well like to do in in my ARC box.

Know in the past many issues with Netservers and ISDN, in that any time I
called support they wanted the Prime channels associated with Quad modems,
even though that shouldn't have been the case& 2 T1 cards in same chassis
never worked out all that great for us w/Netservers. Now we're using ARC's,
and I'd rather not waste 24 modems (again) in a DSP (which I could also use
if that's how it's got to go). This will be 100% ISDN calls, no modem calls,
so no need for modems.

Anyone out there doing this? Any idea of the headaches I'm just begging for?
Any tricks to setting this up with ARC's?
There really wasn't any "trick" with Netservers, it just locked up too often
and USR support couldn't support me in the configuration, and any support I
got or documentation I read all said "....associate the channels on the
Prime with a Quad modem....."

In this same chassis I'll be continuing to run 2 other DSP's and another
(for the time being) Dual T1 w/quads. I'm planning on forgoing 1 Quad modem
card (4 modem lines) to do this temporarily until I get all DSP's in there.
IE, full chassis right now.

SMT


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 "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) Prime on Dual T1 card & HiperARC
Date: 10 Aug 1999 16:56:28 -0400 (EDT)

Thus spake Scott Trautman
>I usually put my ISDN customers/primes on Livingston PM3's (run for 9
>months+ without a problem...), but I have a free Dual T1 card hanging
>around and would just as well like to do in in my ARC box.

OK...lemme get this straight...you wanna do a dual-pri card, for ISDN
lines sending the call to an Arc?  No can do.  The reason it worked with
a NETServer was because of the Munich daughtercard that most of them had
which terminated the ISDN.  The Arc doesn't have this, and the dual-PRI
card can't do it itself either.  You'll need quad-i-modems, or DSP's to
handle the ISDN termination for the Arc's.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Scott Trautman <[e-mail]>
Subject: RE: (usr-tc) Prime on Dual T1 card & HiperARC
Date: 10 Aug 1999 16:32:55 -0500

You guys are goooood. I'll have to try to stump the experts harder next
time...
This really did save me a fair amount of time and effort.

SMT

-----Original Message-----
Sent: Tuesday, August 10, 1999 3:56 PM


Thus spake Scott Trautman
>I usually put my ISDN customers/primes on Livingston PM3's (run for 9
>months+ without a problem...), but I have a free Dual T1 card hanging
>around and would just as well like to do in in my ARC box.

OK...lemme get this straight...you wanna do a dual-pri card, for ISDN
lines sending the call to an Arc?  No can do.  The reason it worked with
a NETServer was because of the Munich daughtercard that most of them had
which terminated the ISDN.  The Arc doesn't have this, and the dual-PRI
card can't do it itself either.  You'll need quad-i-modems, or DSP's to
handle the ISDN termination for the Arc's.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 "[e-mail]"
 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: "Scot Desort" <[e-mail]>
Subject: RE: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 10 Aug 1999 18:36:25 -0400

I can't speak for Ascend, but our v90 customers have been exstatic since we
went to TC's with DSP's. We were previously on a Compaq RAS solution. Our
connect rates, including v90, have increased dramatically.

Do the end-users have the latest firmware for their modems? And while SOME
of them may be 3COM/USR modems, I can bet you that some of them are also
Rockwell HCF modems. They'll connect just fine (usually) to Ascend, since
Ascend also uses Rockwell chipsets. But HCF + TC = trouble.

Are YOU on the latest software from 3COM? Are you using duals or DSP's? I
don't recall you posting any of the specifics of your config.

When all else fails, pull $35 out of petty cash and send the customer a
Paradise Winmodem (LT chipset, PCI), for free. These things are GREAT, will
save you hours of tech support headaches, and inevitably win you over a
customer that, in the long run, is worth a lot more than the $35 you spent
on the modem. We even offer to install it for free if they bring the box in.
Let's remember that the goal is to KEEP the customer a PAYING customer. And
nothing makes them more warm and fuzzy then getting something for free.

We are also evaluating 3COM OEM v90 ISA Winmodems. I believe we have also
been having similar success with these modems. But the way that 3COM handles
OEM firmware is bizarre (similar to Rockwell/Conexant), in that you can't go
to their web site to get firmware updates for OEM chipsets. You have to go
back to the OEM, who unfortunately, may be gone tomorrow. Some OEM firmware
is available on 3COM's site, but you have to pull the modem out and get the
product code off the board, not something an end user is willing to do when
they're frustrated. Lucent, to their credit, releases firmware that works
with ALL LT winmodems, no matter who slapped the chip on the board. THAT'S
how easy it SHOULD be.

My .02.

...Scot
(3 month TC user)


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Ed
> Sent: Tuesday, August 10, 1999 1:24 AM
> To: [e-mail]
> Subject: (usr-tc) 3com not doing V.90 as well as Ascends
>
>
> 3com not doing V.90 as well as Ascend's.....
>
> We have tested and found it to be true that Ascend's authenticate and work
> at V.90 speeds much more often than 3com. It even happens when using a
> 3com/USR modem. It takes certain a certain situation for this to
> happen but
> it does happen...
>
> Just wondered if others out there have noticed it or had their competitors
> using Ascend's have customers that say "Well I get 56K speeds on so and so
> Internet Service, why not yours?"
>
>
> Ed
> 4 Year Total Control User


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Ed" <[e-mail]>
Subject: Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 10 Aug 1999 22:49:30 -0400

I wasn't saying that when they get V90 that it isn't better now....it is.
The issue is not getting V90 when they do on other access systems.

The facts are we have proof that on certain situations the 3com's will not
authenticate V90 when the Ascends will. It should not matter what the client
modem is because we are talking a Standard....however since you mention it
the client modem used to test this was a 3com/USR Sportster V90. So it
should be even more compliant with 3com than anything.

Even if offering another modem that would work (which we cannot find one
that will work on the 3com) I don't see why ISP's should have to pay for
such because of the lack of 3com's compliance. That is not a good solution
to the underlying problem. Simply put 3com needs to fix the issue so there
is no issue.....3com I would think would want in all situations to be better
than Ascend or any other dialup platform.


Ed

----- Original Message -----
Sent: Tuesday, August 10, 1999 6:36 PM


I can't speak for Ascend, but our v90 customers have been exstatic since we
went to TC's with DSP's. We were previously on a Compaq RAS solution. Our
connect rates, including v90, have increased dramatically.

Do the end-users have the latest firmware for their modems? And while SOME
of them may be 3COM/USR modems, I can bet you that some of them are also
Rockwell HCF modems. They'll connect just fine (usually) to Ascend, since
Ascend also uses Rockwell chipsets. But HCF + TC = trouble.

Are YOU on the latest software from 3COM? Are you using duals or DSP's? I
don't recall you posting any of the specifics of your config.

When all else fails, pull $35 out of petty cash and send the customer a
Paradise Winmodem (LT chipset, PCI), for free. These things are GREAT, will
save you hours of tech support headaches, and inevitably win you over a
customer that, in the long run, is worth a lot more than the $35 you spent
on the modem. We even offer to install it for free if they bring the box in.
Let's remember that the goal is to KEEP the customer a PAYING customer. And
nothing makes them more warm and fuzzy then getting something for free.

We are also evaluating 3COM OEM v90 ISA Winmodems. I believe we have also
been having similar success with these modems. But the way that 3COM handles
OEM firmware is bizarre (similar to Rockwell/Conexant), in that you can't go
to their web site to get firmware updates for OEM chipsets. You have to go
back to the OEM, who unfortunately, may be gone tomorrow. Some OEM firmware
is available on 3COM's site, but you have to pull the modem out and get the
product code off the board, not something an end user is willing to do when
they're frustrated. Lucent, to their credit, releases firmware that works
with ALL LT winmodems, no matter who slapped the chip on the board. THAT'S
how easy it SHOULD be.

My .02.

...Scot
(3 month TC user)


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Ed
> Sent: Tuesday, August 10, 1999 1:24 AM
> To: [e-mail]
> Subject: (usr-tc) 3com not doing V.90 as well as Ascends
>
>
> 3com not doing V.90 as well as Ascend's.....
>
> We have tested and found it to be true that Ascend's authenticate and work
> at V.90 speeds much more often than 3com. It even happens when using a
> 3com/USR modem. It takes certain a certain situation for this to
> happen but
> it does happen...
>
> Just wondered if others out there have noticed it or had their competitors
> using Ascend's have customers that say "Well I get 56K speeds on so and so
> Internet Service, why not yours?"
>
>
> Ed
> 4 Year Total Control User


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 "[e-mail]"
 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: "Scot Desort" <[e-mail]>
Subject: RE: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 10 Aug 1999 23:43:53 -0400

It *does* matter what modem the client has because, while v90 itself is a
standard, every single modem chip manufacturer implements it slightly
differently. Modem interoperability has been an issue since modems were
invented, and will probably never be resolved.

Look at Lucent's release notes on their firmware for PM3's -- they too are
constantly correcting issues with modem interoperability, including LT
client modems. As does Cisco MICA. As does 3COM. The fact that the client
modems are 3COM's is an issue, but only if 1) the client is running the
latest firmware and 2) the ISP is running the latest firmware. When 3COM
tests the TC firmware for release, I'm sure they use Sportsters with the
latest firmware. Early v90 firmware on ANY modem was buggy, unreliable, and
will almost always need to be updated to negotiate v90 today on all major
RAS platforms consistently.

  "Even if offering another modem that would work (which we cannot find one
that will work on the 3com)..."

You cannot find ANY modem that will negotiate v90 AT ALL to the TC? I'm
sorry to say that over 65% of my dialup users connect to my TC at v90.

Is there a principal issue here with wanting 3COM to fix it -- sure there
is. Does 3COM want to be better than Ascend and Lucent in the RAS
business -- sure they do. But in the business world, telling the customer
that we are holding out on 3COM to fix the problem, while they are annoyed
they can't connect to you at v90 does no one any good. Customer leaves, you
lose $20 a month. With each release of firmware on clients AND on ISP
equipment, connection speeds and reliability generally get better each time.

I'm not here to tell you you're wrong in wanting 3COM to correct your issue
Ed, believe me. I'm only trying to offer some alternatives for you that WE
have found work. Make sure you AND the end user have the latest firmware. We
have managed to keep several customers from leaving by giving them these
modems, and after you factor in the monthly revenue we kept, the modems cost
us NOTHING. I didn't have to spend an hour or 2 on the phone with the end
user messing with AT command strings. I don't have to call 3COM and complain
about interoperability. My blood pressure drops. It's just a matter of
finding a solution to a problem that I'm sure will eventually clear up.
Until it does, I'm not going to lose customers over it if I can help it. It
seems like that's your goal as well.

Good luck,

Scot




-----Original Message-----
[mailto:[e-mail]]On Behalf Of Ed
Sent: Tuesday, August 10, 1999 10:50 PM


I wasn't saying that when they get V90 that it isn't better now....it is.
The issue is not getting V90 when they do on other access systems.

The facts are we have proof that on certain situations the 3com's will not
authenticate V90 when the Ascends will. It should not matter what the client
modem is because we are talking a Standard....however since you mention it
the client modem used to test this was a 3com/USR Sportster V90. So it
should be even more compliant with 3com than anything.

Even if offering another modem that would work (which we cannot find one
that will work on the 3com) I don't see why ISP's should have to pay for
such because of the lack of 3com's compliance. That is not a good solution
to the underlying problem. Simply put 3com needs to fix the issue so there
is no issue.....3com I would think would want in all situations to be better
than Ascend or any other dialup platform.


Ed



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Len Pikulski <[e-mail]>
Subject: (usr-tc) WTB - USR Total Control NETServer 8 Power Supply
Date: 11 Aug 1999 01:57:53 -0400 (EDT)

Anyone know of a resource for USR parts?
We need (1) USR Total Control NETServer 8 Power Supply board.
Any help would be greatly appreciated.
Thanks
<*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*>
 Len Pikulski            [e-mail]           [phone]
                      http://www.nothinbut.net


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Ed" <[e-mail]>
Subject: Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 11 Aug 1999 03:25:05 -0400

As I stated it is a 3com/USR Sportster modem....with the latest codes. It
should work and does work on the Ascends. It also will work if you take that
same modem to a different location and dialup the 3com's.

Please understand we have worked with 3com's for almost 4 years....and we
were involved in Betas of X2 and V90. We know how V90 works and we know
there is no reason for this not to work....other than 3com's systems not
doing V90 properly in all situations. This situation is solid as the persons
testing are also employees at our service....they have the latest code on
both ends and it is 3com on both ends. No reason for it to work on Ascends
and not 3com.....and that is why 3com is investigating it now.

You mentioned losing customers and how to fix that... giving away $35 modems
to everyone... in which we don't believe is right for us to have to do to
cover their systems because they aren't compliant. Also I can tell you there
are people who you will never know leave your service because of slow
speeds. No way to fix those. The solution to this is for everyone involved
in this list to be concerned about such issues and let 3com know it needs
fixed asap. Continuing to make excuses, justify or give alternatives to the
problem isn't going to help 3com solve it for us.

Ed

----- Original Message -----
Sent: Tuesday, August 10, 1999 11:43 PM


It *does* matter what modem the client has because, while v90 itself is a
standard, every single modem chip manufacturer implements it slightly
differently. Modem interoperability has been an issue since modems were
invented, and will probably never be resolved.

Look at Lucent's release notes on their firmware for PM3's -- they too are
constantly correcting issues with modem interoperability, including LT
client modems. As does Cisco MICA. As does 3COM. The fact that the client
modems are 3COM's is an issue, but only if 1) the client is running the
latest firmware and 2) the ISP is running the latest firmware. When 3COM
tests the TC firmware for release, I'm sure they use Sportsters with the
latest firmware. Early v90 firmware on ANY modem was buggy, unreliable, and
will almost always need to be updated to negotiate v90 today on all major
RAS platforms consistently.

  "Even if offering another modem that would work (which we cannot find one
that will work on the 3com)..."

You cannot find ANY modem that will negotiate v90 AT ALL to the TC? I'm
sorry to say that over 65% of my dialup users connect to my TC at v90.

Is there a principal issue here with wanting 3COM to fix it -- sure there
is. Does 3COM want to be better than Ascend and Lucent in the RAS
business -- sure they do. But in the business world, telling the customer
that we are holding out on 3COM to fix the problem, while they are annoyed
they can't connect to you at v90 does no one any good. Customer leaves, you
lose $20 a month. With each release of firmware on clients AND on ISP
equipment, connection speeds and reliability generally get better each time.

I'm not here to tell you you're wrong in wanting 3COM to correct your issue
Ed, believe me. I'm only trying to offer some alternatives for you that WE
have found work. Make sure you AND the end user have the latest firmware. We
have managed to keep several customers from leaving by giving them these
modems, and after you factor in the monthly revenue we kept, the modems cost
us NOTHING. I didn't have to spend an hour or 2 on the phone with the end
user messing with AT command strings. I don't have to call 3COM and complain
about interoperability. My blood pressure drops. It's just a matter of
finding a solution to a problem that I'm sure will eventually clear up.
Until it does, I'm not going to lose customers over it if I can help it. It
seems like that's your goal as well.

Good luck,

Scot




-----Original Message-----
[mailto:[e-mail]]On Behalf Of Ed
Sent: Tuesday, August 10, 1999 10:50 PM


I wasn't saying that when they get V90 that it isn't better now....it is.
The issue is not getting V90 when they do on other access systems.

The facts are we have proof that on certain situations the 3com's will not
authenticate V90 when the Ascends will. It should not matter what the client
modem is because we are talking a Standard....however since you mention it
the client modem used to test this was a 3com/USR Sportster V90. So it
should be even more compliant with 3com than anything.

Even if offering another modem that would work (which we cannot find one
that will work on the 3com) I don't see why ISP's should have to pay for
such because of the lack of 3com's compliance. That is not a good solution
to the underlying problem. Simply put 3com needs to fix the issue so there
is no issue.....3com I would think would want in all situations to be better
than Ascend or any other dialup platform.


Ed



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 "[e-mail]"
 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: "Bob Purdon (Lists)" <[e-mail]>
Subject: RE: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 11 Aug 1999 21:47:15 +1000 (EST)


> It *does* matter what modem the client has because, while v90 itself is a
> standard, every single modem chip manufacturer implements it slightly
> differently. Modem interoperability has been an issue since modems were
> invented, and will probably never be resolved.

...and as I understand it, most of the smarts with V90 is in the client
end - the server end just does what it's told.

I also believe that's why different V90 modems train up differently (sound
different) - different manufacturers think they have better training
patterns than their competitors.

Bob Purdon,                          Ground Floor, Marine Board Building
Technical Manager (Tas/Vic),                  1 Franklin Wharf, Tas 7000
Southern Internet Services.                            [phone]


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 11 Aug 1999 08:00:03 -0400 (EDT)

Thus spake Ed
>As I stated it is a 3com/USR Sportster modem....with the latest codes.
>It should work and does work on the Ascends. It also will work if you
>take that same modem to a different location and dialup the 3com's.

>Please understand we have worked with 3com's for almost 4 years....and
>we were involved in Betas of X2 and V90. We know how V90 works and we
>know there is no reason for this not to work....other than 3com's
>systems not doing V90 properly in all situations.

While I basically agree with you...lemme just point out a bit of a flaw
in your statement here.  Basically this is what Scot was trying to say I
believe.

V.90 (and v.34, and v.42, and all the other modem protocol standards)
are not extremely precisely defined standards.  There is some "wiggle
room" as I call it in the standards...so its possible for two systems to
be totally "within the spec" and still not communicate the protocol to
each other.

Yes, this is still a problem and still needs to be resolved.  But let me
assure you that just because they don't speak v.90 to each other doesn't
mean that either system is not following the spec.  It could mean that
one system is at one end of the spec and the other system is at the
other end of the spec.  Vendors work very hard to make sure that they
can communicate with other implementations that may be at the other end
of the spec, but it does take time to work these issues out.

Having said that...I agree with you that it does definitely need to be
fixed.  Particularly 3com to 3com connections need to be rock solid, but
like Scot, we have a huge number of people connect to us with v.90
connections, so I'm relatively confident that v.90 isn't "broken" in the
TC's, though I certainly agree that it could still be improved.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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" <[e-mail]>
Subject: (usr-tc) Routing (?) problems
Date: 11 Aug 1999 07:34:14 -0500

Greetings,

I have encountered a technical problem related to routing and am at my wits
end.  Anyone with previous experience out there...  We have been to all the
manufacturers involved and all disavow any knowledge, or how to help,
although they confirm the problem is real.

Here's the scenario:

ISDN users connect to our Total Control equipped with HiPer ARCs and DSPs
(the TC is latest firmware/software all the way).  They connect via Cisco
760s, Eicon DIVAs, and Netgear Rx328.  At random instances they lose ability
to route http traffic (the router and any public addresses on the LAN side
are pingable, can FTP, etc), and stop receiving http data.  They must reset
the router and it clears the problem immediately.  Occasionally they will
also lose e-mail capability, but this always follows the loss of http
connectivity.

We have watched the connections at the Total Control and we see the outbound
request from their router, and see the returned http traffic from a website.
It just never seems to get past the router.  We only have problems where we
have Hiper DSPs installed.  In our other POPs where we have modem cards (and
HiPer ARCs) the problem does not seem to exist.  It does not exist in any of
our other connnectivity solutions.  We have fiddled with offloading and just
about every other switch we can see that might be a contributor.  We lean
toward the problem as being in the TC, but just can't seem to get our hands
around it.

Any help would be greatly appreciated.

Samuel S. Lowe
Director, Data Services
UniversalCom, Inc.
[e-mail]


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 11 Aug 1999 08:00:03 -0400 (EDT)

Thus spake Ed
>As I stated it is a 3com/USR Sportster modem....with the latest codes.
>It should work and does work on the Ascends. It also will work if you
>take that same modem to a different location and dialup the 3com's.

>Please understand we have worked with 3com's for almost 4 years....and
>we were involved in Betas of X2 and V90. We know how V90 works and we
>know there is no reason for this not to work....other than 3com's
>systems not doing V90 properly in all situations.

While I basically agree with you...lemme just point out a bit of a flaw
in your statement here.  Basically this is what Scot was trying to say I
believe.

V.90 (and v.34, and v.42, and all the other modem protocol standards)
are not extremely precisely defined standards.  There is some "wiggle
room" as I call it in the standards...so its possible for two systems to
be totally "within the spec" and still not communicate the protocol to
each other.

Yes, this is still a problem and still needs to be resolved.  But let me
assure you that just because they don't speak v.90 to each other doesn't
mean that either system is not following the spec.  It could mean that
one system is at one end of the spec and the other system is at the
other end of the spec.  Vendors work very hard to make sure that they
can communicate with other implementations that may be at the other end
of the spec, but it does take time to work these issues out.

Having said that...I agree with you that it does definitely need to be
fixed.  Particularly 3com to 3com connections need to be rock solid, but
like Scot, we have a huge number of people connect to us with v.90
connections, so I'm relatively confident that v.90 isn't "broken" in the
TC's, though I certainly agree that it could still be improved.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Ed" <[e-mail]>
Subject: Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 11 Aug 1999 10:06:18 -0400

Jeff,

   We thought the same exact way. We thought 3com was absolutely superior in
V90. Now we know differently because we saw it wasn't true with our own
eyes...

We have seen first hand more V90 connections via the Ascends....even 3com to
Ascend is better than 3com to 3com. That is our concern... some of our
competitors use Ascend and all the big nationals use Ascend and there is no
way I am going to stand by and let them out do us. It's a shame there is so
little concern about this issue. I believe if you saw it first hand you
would be more concerned...

Wait a minute maybe you HAVE seen the situation I am speaking of. You are in
Cincinnati area correct? How are your connects from WV or Kentucky? Seem a
little off? Get a few complaints from customers from that area about speeds?
Always thought it was just the Phone Co transition? Well if any of these fit
you have the same exact issue....and it is not what you thought. Ascends
work great in this situation. We would have NEVER know this but we did an
acquisition/merger in Marietta and they had Ascends... we removed the
Ascends and all of a sudden people were screaming they lost their V90
speeds. After testing and testing we figured it out! Ascends were actually
doing V90 better across the Phone Co. transition (Bell Atlantic to
Ameritech) for whatever reason. There is a lot of testing that was done and
we are certain of these facts.

Ed

----- Original Message -----
Sent: Wednesday, August 11, 1999 8:00 AM


Thus spake Ed
>As I stated it is a 3com/USR Sportster modem....with the latest codes.
>It should work and does work on the Ascends. It also will work if you
>take that same modem to a different location and dialup the 3com's.

>Please understand we have worked with 3com's for almost 4 years....and
>we were involved in Betas of X2 and V90. We know how V90 works and we
>know there is no reason for this not to work....other than 3com's
>systems not doing V90 properly in all situations.

While I basically agree with you...lemme just point out a bit of a flaw
in your statement here.  Basically this is what Scot was trying to say I
believe.

V.90 (and v.34, and v.42, and all the other modem protocol standards)
are not extremely precisely defined standards.  There is some "wiggle
room" as I call it in the standards...so its possible for two systems to
be totally "within the spec" and still not communicate the protocol to
each other.

Yes, this is still a problem and still needs to be resolved.  But let me
assure you that just because they don't speak v.90 to each other doesn't
mean that either system is not following the spec.  It could mean that
one system is at one end of the spec and the other system is at the
other end of the spec.  Vendors work very hard to make sure that they
can communicate with other implementations that may be at the other end
of the spec, but it does take time to work these issues out.

Having said that...I agree with you that it does definitely need to be
fixed.  Particularly 3com to 3com connections need to be rock solid, but
like Scot, we have a huge number of people connect to us with v.90
connections, so I'm relatively confident that v.90 isn't "broken" in the
TC's, though I certainly agree that it could still be improved.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 11 Aug 1999 10:19:44 -0400 (EDT)

Thus spake Ed
>We thought the same exact way. We thought 3com was absolutely superior
>in V90. Now we know differently because we saw it wasn't true with our
>own eyes...

Hrmm...I think we're violently agreeing here.  I won't argue that
Ascend^WLucent's v.90 interoperability could be better (don't have an
ascend box to really play with it so I'll take your word for it).  I was
just disputing your implication that 3Com is doing v.90 *wrong*.  It
could very well be that 3Com's v.90 is fully "within spec" and still not
be as interoperable as Ascends.

I certainly agree with you that v.90 interoperability needs to be
improved...I don't think I'd ever disagree with that statement...there
can always be improvements.  :)  I just don't want people to think that
3Com is strictly "out of spec" because, most likely, they aren't.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 Lynch <[e-mail]>
Subject: Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 11 Aug 1999 09:42:37 -0500 (CDT)

On Tue, 10 Aug 1999, Allen Marsalis wrote:

> At 01:24 AM 8/10/99 -0400, Ed wrote:

> We have been 100% USR/3COM for 3 years and we recently received a Max
> TNT for eval to address the above problem..  Both chassis will be
> at the same NOC.  2 new PRI's for the TNT should be up this week..
> I'll keep you posted as to the results and try to provide some statistical
> data..
>
> Allen

We're considering taking this step as well but we haven't decided yet to
try the TNT or 6096 yet--forget the 4k. We have a surplus of DSPs from arc
and quad tradeups so we are _really_ hoping this is a short term
workaround and does not become too entrenched in our network. OTH, timing
is good for this move as we are entering a traditionally high growth
period, but the need to buy equipment that we shouldn't have to has us
rather, uh, pissed.

--jeff

============================================================================
Jeffrey A. Lynch        | JORSM Internet, Regional Internet Services
email: [e-mail]        | 7 Area Codes in Chicagoland and NW Indiana
Voice: [phone]        | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN
Autoresponse: [e-mail]    | Quality Service, Affordable Prices
http://www.jorsm.com        | Serving Gov, Biz, Indivds Since 1995


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Ed" <[e-mail]>
Subject: Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 11 Aug 1999 10:44:33 -0400

They are a bit too far out of "SPEC" for my taste when 3com to 3com is not
as good as 3com to Ascend... no matter what the circumstances are.

Thats what is so upsetting about this situation...

BTW, if you would like to see it first hand I would happy to host ;-) You're
only about 150 miles away....

Ed

----- Original Message -----
Sent: Wednesday, August 11, 1999 10:19 AM


Thus spake Ed
>We thought the same exact way. We thought 3com was absolutely superior
>in V90. Now we know differently because we saw it wasn't true with our
>own eyes...

Hrmm...I think we're violently agreeing here.  I won't argue that
Ascend^WLucent's v.90 interoperability could be better (don't have an
ascend box to really play with it so I'll take your word for it).  I was
just disputing your implication that 3Com is doing v.90 *wrong*.  It
could very well be that 3Com's v.90 is fully "within spec" and still not
be as interoperable as Ascends.

I certainly agree with you that v.90 interoperability needs to be
improved...I don't think I'd ever disagree with that statement...there
can always be improvements.  :)  I just don't want people to think that
3Com is strictly "out of spec" because, most likely, they aren't.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 "[e-mail]"
 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: Scott Boggs <[e-mail]>
Subject: RE: (usr-tc) 2.0.81 dsp code
Date: 11 Aug 1999 10:46:34 -0400

The speed drops were from v.90 to v.34.
Say from mid-40s or better down to 26400 or 28.8.
We dropped back to dsp ver. 1.2.37 and results have been
the same.  So I am going back to 2.0.81


> -----Original Message-----
> From:    Aaron Nabil [SMTP:[e-mail]]
> Sent:    Friday, August 06, 1999 6:15 PM
> To:    [e-mail]
> Subject:    Re: (usr-tc) 2.0.81 dsp code
>
>
> <followup trimmed to usr-tc>
>
> What is "very much slower"?  From v.90 to v.34, or from 46k to 44k?
>
> Although it's almost impossible to convince lusers of this,
> unless you are talking about going from v.90 to v.34 rates,
> a change in _connect_ speed rarely correlates to a change in
> throughput.
>
>
> Scott Boggs writes...
> >I upgraded to all the latest codes for NMC,HARC,and HDSP
> >I have had very many complaints that user connect speeds are now much
> >slower,
> >and some connection problems as well.  I am curently downgrading
> >the DSp's to 1.2.37.  Does any one have any insight into this problem,
> >or expeienced similar results.  On the two HARCs NMC awareness is off and
> >slots are divided between the two Harcs.
> >
> >Thanks,
> >Scott Boggs
>
> --
> Aaron Nabil
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 11 Aug 1999 10:54:57 -0400 (EDT)

Thus spake Ed
>They are a bit too far out of "SPEC" for my taste when 3com to 3com is not
>as good as 3com to Ascend... no matter what the circumstances are.

s/too far out of "SPEC"/less interoperable/
and I'll agree with you.  :)

>Thats what is so upsetting about this situation...

I'll agree with you there.  We've had pretty good luck with them
overall..but there certainly are some interoperability problems that
we've been battling that I'd like to really be resolved...I've certainly
got your back on that.  :)

>BTW, if you would like to see it first hand I would happy to host ;-) You're
>only about 150 miles away....

Actually...we're considerably further than that...we have a POP in
Cincinnati, but we're based in Louisville, KY...about doubles the trip.
:)
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Ken Kirchner <[e-mail]>
Subject: RE: (usr-tc) 2.0.81 dsp code
Date: 11 Aug 1999 09:56:08 -0500 (CDT)

On Wed, 11 Aug 1999, Scott Boggs wrote:

> The speed drops were from v.90 to v.34.
> Say from mid-40s or better down to 26400 or 28.8.
> We dropped back to dsp ver. 1.2.37 and results have been
> the same.  So I am going back to 2.0.81

Is this the initial reported connect speed, or the average speed of the
connection over the duration?  Modems are supposed to constantly check
line conditions and adjust the transmission speeds accordingly, arent
they?  Just curious if this has been taken into consideration.

-Ken

  ___                                                         ___
 (___) Kenneth Kirchner    .o.  mailto:[e-mail]       (___)
  (__) Asst SysAdmin       .o.  Voice [phone] Ext 108 (__)
   (_) ShreveNet, Inc.     .o.  Fax   [phone]         (_)


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Andres Kroonmaa" <[e-mail]>
Subject: Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 11 Aug 1999 18:12:43 +0300

On 11 Aug 99, at 8:00, Jeff Mcadams <[e-mail]> wrote:

> Thus spake Ed
> >As I stated it is a 3com/USR Sportster modem....with the latest codes.
> >It should work and does work on the Ascends. It also will work if you
> >take that same modem to a different location and dialup the 3com's.
>
> >Please understand we have worked with 3com's for almost 4 years....and
> >we were involved in Betas of X2 and V90. We know how V90 works and we
> >know there is no reason for this not to work....other than 3com's
> >systems not doing V90 properly in all situations.
>
> V.90 (and v.34, and v.42, and all the other modem protocol standards)
> are not extremely precisely defined standards.  There is some "wiggle
> room" as I call it in the standards...so its possible for two systems to
> be totally "within the spec" and still not communicate the protocol to
> each other.
>
> Yes, this is still a problem and still needs to be resolved.  But let me
> assure you that just because they don't speak v.90 to each other doesn't
> mean that either system is not following the spec.  It could mean that
> one system is at one end of the spec and the other system is at the
> other end of the spec.  Vendors work very hard to make sure that they
> can communicate with other implementations that may be at the other end
> of the spec, but it does take time to work these issues out.

 Basically, if the same modem connects differently in differnet physical
 locations, then this means that it has to do with "last mile" copper, at
 least here (we are small country, one telco)

 One smart guy some time ago gave me quite a good explanation of why
 usr/3com modems suck in some situations, and not others. He is claiming
 that this is a fundamental flaw in usr/3com modems and there is no fix
 any time soon foreseeable. And I have to agree unless someone from 3com
 corrects me right away.

 Our main competitor is local telco, they are using Ascend TNT. They also
 say that part of their customers are complaining about poor connect speeds
 and telling them that our Hiper takes the calls much better. There is no
 strict pattern in which client modem vendor is used, but rather has more
 to do with client's physical location. We see the opposite, some of our
 customers complain that they can get much better connects with Ascend.

 Basically it has to do with modems measuring line parameters during
 initial handshaking. v.90 standard covers what sequences has to be passed
 to successfully connect. Both vendors implement v.90 enough for this to
 happen, we know that because modems from same vendors _do_ connect at
 v.90 speeds most of the time, its just some subset of "lines" where they
 cannot connect properly.

 I may be somewhat wrong and simplistic about this, but as I understand it,
 during initial handshaking, after modems have found common ground and
 understand each other, they are asking each other to "probe" the line,
 sending signals with predetermined frequencies and amplitude levels. One
 modem then listens to these, measures S/N and amplitude levels for each
 of the frequency ranges, and builds up a knowledge of spectral throughput
 of the line. This is used to pick "a best" frequency range where there is
 minimal noise and best S/N ratio, thus highest frequency-bandwidth product.

 When one modem finishes, the procedure is reversed, that is the other end
 sends the tones and other one listens. When both modems have done with that,
 they start to exchange "opinions" about which frequency ranges they should
 communicate on and at what speed. They are trying to find a common
 ground for "best" carrier frequency and range.

 Standards (IMO) define handshake sequences, frequencies, timeout times,
 and how modems negotiate, etc. They do not define too well how to solve
 situations when modems have vastly different views of the line and cannot
 easily reach consensus. If modems take too much time to "argue" about the
 best working range, or they agree that the best common region is smaller
 than each of them sees independantly, then they finally fallback to lower
 speeds, sometimes because handshake timers expire. All this is basically
 why in some situations same pair of modes are not able to achieve max speed
 for a given line.

 It has to do with differing views of the "last mile" line in question.
 They either can't agree or they agree on less optimal common noisefree
 range of frequencies.



 The guy explained to me, that the main difference in usr/3com modems and
 rockwell modems is how modems measure noise on the line.

 There are some parameters modems need to know to pick best workregion:
 - frequency-response spectral characteristics of the line
 - sound/noise level of the line
 - spectral characteristics of noise on the line
 from these they can find frequency ranges with best S/N ratios.

 Now, rockwell chips supposedly measure both, noise spectral distribution
 of the line and signal spectral characteristics. usr/3com on the other
 hand measures only signal spectral distribution, and _average_ level of
 noise over all frequencies. usr/3com _assumes_ that noise spectral
 distribution is even over the whole range, and calculates S/N per
 frequency only based on signal spectral response. It takes perhaps less
 time and effort by skipping spectral analysis of noise, allows for
 quicker connects, and the assumption is perhaps "right for 80-90% of cases".

 Rockwell modems again also count the cases where noise _IS NOT_ evenly
 distributed, and calculates S/N accordingly, possibly finding that some
 frequencies with good levels have unacceptable levels of noise, thus
 making S/N ratio for such frequencies unusable.

 Now, many lines _DO_ have uneven noise distribution, especially if there
 is low-frequency noise present, perhaps from utility lines, electric
 motors, DA-AD conversions, transmission jitter, whatever.
 Also, higher frequency noise could be unexpectedly high, from highspeed
 data lines like ISDN, DSL, baseband, etc.

 The ultimate goal of each modem is to find a spectral range with widest
 frequency range that has acceptable signal/noise ratio.

 3com, based on signal spectral analysis only may easily find this range
 to be shifted up or down on the total spectrum in such a manner that
 part of this workrange hits the region with higher noise levels.
 Especially towards lower end of frequencies, because low-frequency
 noise distorts modem's percieved low-band spectral response and leaves
 modem thinking there is signal levels going up.
 Rockwell chips, because they analyse noise spectrum also tend to skip
 frequency ranges where lots of noise is present.

 Thus, they are having differing views of the line. for eg. 3com says
 "lets pick frequency range of 200-2400 Hz, while rockwell sees high
 noise at 50-500Hz and hints "no-no, lets make it 600-3000Hz", 3Com
 again says "hey, I have poor response in 2600-3000 compared to 300,
 we should better pick 200-2400". So they haggle for some time, and
 finally agree on 600-2400 which might provide less bandwidth than
 possible in reality, and thus giving lower connect speeds.

 Whats worse, is that if both modems are 3com, they agree on the
 200-2400 range, although there is noise on 50-500 range, but they
 don't even suspect that. So they connect initially fast, but then
 begin coughing and sneezing, and some time later retrain to lower
 speed.

 All this makes perfect sense to me, and explains lots of why on
 some lines 3com modems can't achieve good performance, why they
 often "hang" in retrains, why they sometimes fail to connect at
 all, and even why in some cases 3com-3com sucks more that
 3com-rockwell.

 Until this guy I thought that usr modems were better than average,
 and pretty much believed that if usr-usr pair couldn't connect,
 then basically nothing could connect on any given line. I was
 proved to be wrong. This came up hurting when we merged an isp
 and all of their customers were forced to move from cisco as5200
 to our Hiper. He showed me lots of graphs his modem was gathering,
 showed how Hiper picked wrong working range, and how it failed
 to keep the initial connect-speed. We tryed tweaking all sorts
 of bits on our hiper, but to no avail. by any means, we lost
 this customer.

 The guy told me that this problem has been reported to 3com for
 ages, and the reponse has been "we know, but we won't bother to
 make any fundamental changes because of just 15-20% of market".
 Attitude sounds way too familiar, so I tend to believe that.

 Whatever, I'd be glad to hear clear and solid comment on that
 matter from 3com guys on this list.

 As to workarounds, I believe there are lots of modems that are
 able to give out noise spectral distribution of a line via AT
 commands, and perhaps there are ways to force modems to pick
 specific ranges of frequencies for specific lines.
 Without questions, this is not something unexperienced customers
 will ever do, and there is indeed very little ISP's can do on
 their end.

 So, most of the time, you have to live with that.


 ----------------------------------------------------------------------
  Andres Kroonmaa                                mail: [e-mail]
  Senior Network Engineer
  Organization:            MicroLink Online       Tel:        [phone]
  Tallinn, Sakala 19                              Pho:  [phone]
  Estonia, EE0001        http://www.online.ee     Fax:  [phone]
 ----------------------------------------------------------------------

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: [e-mail] (Jeff Binkley)
Subject: (usr-tc) RE: (USR-TC) WEBRAMP 310I
Date: 11 Aug 1999 12:32:00 -0500

Frank,

That was the trick.  I turned it off IP header compression in RADIUS and in the
WebRamp and throughput is as expected.  We left Stac compression enabled.  I am
not sure why IP header compression works with all of the other Web Ramps but I
am not going to argue with success.

Thanks,

Jeff Binkley
ASA Network Computing


-> Turn off the header compression. Webramp are notorious for not working with
-> the Hiper Chassis if you have VJ compression enabled. We turn this off by
-> default; it actually worked once but in recent versions it now does not, I
-> think 4.0.32 on the Arc, and 1.0.29 on the Modem was the last time it worked
-> for us..long time ago...
->
-> -Frank
->
-> Tatai SV Krishnan wrote:
->
-> > On Tue, 10 Aug 1999, Jeff Binkley wrote:
-> >
-> > >
-> > >
-> > > I asked this last week and only got one reply, si I'll throw it out > >
-> again and hopefully Krish can join in.  We have a reseller who is trying > >
-> to hook up to us (HiperArc v 4.1.64 w/Quads and DSPs) with a Ramp > >
-> Networks 310i Web Ramp.  They have tried 3 different units and all three > >
-> will connect fine but the data throughput is brutally slow (about 20% of > >
-> capacity).  The only options the 310i has is compression, header > >
-> compression and MRU.  We've tried all combinations of settings and > >
-> nothing seems to make a major difference. We run IP header compression > >
-> on our HiPerArc so they have Van-Jacobsen header compression enabled. > >
-> For data compression they only support Stac or none and the MRU setting >
-> > Is there a difference if you disable STac compression?
-> >
-> > krish
-> >
-> > > defaults to 1524.  I am open to suggestions.  They other person who > >
-> answered last week is having a similar experience.
-> > >
-> > > Jeff Binkley
-> > > ASA Network Computing

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Blake Fithen <[e-mail]>
Subject: RE: (usr-tc) bad port locator
Date: 11 Aug 1999 13:47:10 -0500

I hate to be annoying and reopen this thread but we seem
to be having similar problem with all of our ARC/DSP chassis.
The symptoms are:  user dials-in, handshaking starts, a few
seconds later a solid monotone ringing is heard.  On the ARC
side it looks like this:

slot:3/mod:7            DIALIN INVALID 00-   -0000 00:00:00

and the call never completes.  If you look in Performance
Monitor, select the modems, choose "modem events" functional
group, choose "Incoming connections est.", "Incoming
connections terminated", and "Incoming connections failed"
you will see the failed connection number WAY higher than
the connections est. or terminated.  The only way to correct
the modem is to reboot the card - rebooting the individual
modem does not work.  After rebooting the card the modem
takes the call without a problem.

We have quad modem chassis on the same set of PRI circuits
without any problems.

Does anyone have any advice on this?

Thanks for your time.


> -----Original Message-----
> From: Mike Andrews [mailto:[e-mail]]
> Sent: Friday, August 06, 1999 4:35 PM
> To: [e-mail]
> Subject: Re: (usr-tc) bad port locator
>
>
> I probably will as soon as I dig up the appropriate OID's...
>
>
> Mike Andrews (MA12) -=-=-  VP & Sysadmin, Digital Crescent,
> Frankfort KY
> [e-mail]  -=--=-  [e-mail]  -=--=-
> http://www.bit0.com
> "If you're not part of the solution.... you're part of the
> precipitate."
>
> On Fri, 6 Aug 1999, Jim Johnson wrote:
>
> >
> > Thanks for the post.
> >
> > I was wondering if anyone has anything written that uses PERL and
> > SNMP_Session.pm for the SNMP access.
> >
> > Jim
> >
> > Pete Ashdown wrote:
> > >
> > > My apologies.  I couldn't find this in the archive,
> although I have a
> > > distinct memory of posting it to the list.  Oh well.
> Here it is anyway:
> > >
> > > #!/usr/local/bin/perl
> > >
> > > # hdmcheck
> > > #
> > > # Checks the individual HDM stats in order to find stuck
> modems.  If the
> > > # total number of calls is greater than $minimum and the
> failed calls is
> > > # greater than the $threshold percentage of established
> calls, an external
> > > # script is called.  This script busy-outs the span and
> pages me.  How you
> > > # deal with the card after that point is your own voodoo.
> > > #
> > > # Stuck modems will exhibit themselves as RNA,
> wrong-carrier, and fast-busies.
> > > # No fun for your callers, and even less fun for you.
> > > #
> > > # If you crontab this script, be sure to run it in
> periods larger than the
> > > # time it takes "hdmreset" to run (ie: approximately 2 hours).
> > > #
> > > # Like many of my other scripts, this comes with no
> guarantee or warranty.
> > > # This script was crafted in a few hours in an attempt to
> workaround a
> > > # 3com/USR bug.
> > > #
> > > # This script requires the UNIX version of 3com/USR's TCM.
> > > # Questions or comments can be directed to [e-mail]
> > >
> > > # User definable variables
> > > # Location of your UNIX TCM
> > > $ENV{'TCMHOME'} = "/usr/local/lib/tcm";
> > > $ENV{'LD_LIBRARY_PATH'} = "/usr/local/lib";
> > >
> > > # Your SNMP read variable
> > > $readsnmp = "public";
> > >
> > > # Your SNMP write variable
> > > $writesnmp = "private";
> > >
> > > # Percentage of established calls that failed calls must exceed
> > > $threshold = 75;
> > >
> > > # Minimum number of calls that need to have been attempted
> > > $minimum = 25;
> > >
> > > # If you want to see things in action (set to 0 for crontab use)
> > > $debug = 0;
> > >
> > > # Where the hdmreset script is located
> > > $hdmreset = "/home/users/pashdown/usr/hdmreset";
> > >
> > > # Don't change these two unless you know what you're doing.
> > > $tcmperf = "$ENV{'TCMHOME'}/bin/tcmperf -s 1 -c $readsnmp ";
> > > $threshold = $threshold / 100;
> > >
> > > if (-e "/tmp/.hdmcheck") {
> > >     system ("/usr/local/bin/sendpage -q -p pete 'hdmcheck
> stuck'");
> > >     exit;
> > > }
> > > else {
> > >     system ("touch /tmp/.hdmcheck");
> > > }
> > >
> > > # Define these for each of your HIPER racks
> > >
> > > foreach $i ( 1 .. 11 ) {
> > >     &check_channels (slc1,$i);
> > > }
> > >
> > > foreach $i ( 1 .. 11 ) {
> > >     &check_channels (slc2,$i);
> > > }
> > >
> > > foreach $i ( 1 .. 11 ) {
> > >     &check_channels (slc3,$i);
> > > }
> > >
> > > foreach $i ( 1 .. 11 ) {
> > >     &check_channels (slc4,$i);
> > > }
> > >
> > > foreach $i ( 1 .. 11 ) {
> > >     &check_channels (slc5,$i);
> > > }
> > >
> > > foreach $i ( 1 .. 6 ) {
> > >     &check_channels (bond,$i);
> > > }
> > >
> > > unlink ("/tmp/.hdmcheck");
> > >
> > > exit;
> > >
> > > # check_channels(NMC name, span #)
> > > # assumes NMC is "city-snmp"
> > > #
> > > sub check_channels {
> > >
> > >     ($rack,$span) = @_;
> > >
> > >     print ("Rack: $rack\tSpan: $span\n") if $debug;
> > >
> > >     open ( TCMPERF, "$tcmperf -G \"Modem Events\"
> \"Incoming Connections Established\" -G \"Modem Events\"
> \"Incoming Connections Failed\" ${rack}-snmp:s${span}c1-23 2>&1 |");
> > >     while (<TCMPERF>) {
> > >         chop;
> > >         if (/Incoming Connections Established\s+(.*)/) {
> > >             @established = split (/\s+/,  $1);
> > >         }
> > >         if (/Incoming Connections Failed\s+(.*)/) {
> > >             @failed = split (/\s+/, $1);
> > >         }
> > >     }
> > >
> > >     $badcard = 0;
> > >
> > >     foreach $channel ( 0 .. $#established ) {
> > >         printf ("Channel %d\t Est: %d\tFail: %d",
> > >                 $channel+1, $established[$channel],
> $failed[$channel])
> > >             if $debug;
> > >         if (($established[$channel] + $failed[$channel] >
> $minimum) &&
> > >             ($failed[$channel] > $established[$channel] *
> $threshold)) {
> > >             printf ("Channel %d\t Est: %d\tFail: %d",
> > >                     $channel+1, $established[$channel],
> $failed[$channel]);
> > >             printf ("\tStuck Modem! %d > %d\n",
> > >                     $failed[$channel],
> ($established[$channel] * $threshold));
> > >             $badcard = 1;
> > >         }
> > >         print ("\n") if $debug;
> > >
> > >     }
> > >     if ($badcard) {
> > >         print ("Resetting $rack $span!\n") if $debug;
> > >         system ("$hdmreset $rack $readsnmp $writesnmp $span &");
> > >     }
> > >     print ("\n") if $debug;
> > > }
> > >
> > >
> --------------------------------------------------------------
> ----------------
> > > #!/bin/csh
> > >
> > > # hdmreset - reset an HDM card and give enough time for
> people to get off
> > > # Usage: hdmset target read write card
> > >
> > > # note - This used to reset the card when it actually
> helped.  I have found
> > > # that this doesn't cure everything, so now it just pages me.
> > >
> > > setenv LD_LIBRARY_PATH "/usr/local/lib"
> > > setenv TCMHOME "/usr/local/lib/tcm"
> > > set target=$1
> > > set read=$2
> > > set write=$3
> > > set card=$4
> > >
> > > # Busy out the card
> > > $TCMHOME/bin/tcmcmd -E "local out of service" -G commands
> -C $write -c $read ${target}-snmp:s${card}c25
> > >
> > > # sleep two hours
> > > sleep 7200
> > >
> > > # Reset the card
> > > #$TCMHOME/bin/tcmcmd -E "hardware reset" -G "hardware
> commands" -C $write -c $read ${target}-snmp:s${card}
> > >
> > > # Page someone
> > > /usr/local/bin/sendpage -q -p pete "reset modem card
> ${target} slot ${card}"
> > >
> > > -
> > >  To unsubscribe to usr-tc, send an email to
> "[e-mail]"
> > >  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 "[e-mail]"
> >  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 "[e-mail]"
>  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 "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) bad port locator
Date: 11 Aug 1999 14:55:48 -0400 (EDT)

Thus spake Blake Fithen
>I hate to be annoying and reopen this thread but we seem
>to be having similar problem with all of our ARC/DSP chassis.
>The symptoms are:  user dials-in, handshaking starts, a few
>seconds later a solid monotone ringing is heard.  On the ARC
>side it looks like this:

>slot:3/mod:7            DIALIN INVALID 00-   -0000 00:00:00

Well...the "DIALIN INVALID" is normal.  This is the state that the port
is in while the modem is handshaking...this is a normal occurance, and
after a successful connect, the port would move on to other states.
However, obviously you are having bad connects and there's a real
problem there to fix, but this isn't an effect of it.  :)
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Eric Billeter" <[e-mail]>
Subject: RE: (usr-tc) bad port locator
Date: 11 Aug 1999 11:56:53 -0700

I also see this more frequently with the v2.0.81 code.
More so than the previous code versions, although it
did happen occasionally with the 1.43 code (rarely).

It seems like I'm rebooting a card about 3 or four times
a week vs maybe once or twice a month.  This is out of a
total of  80 dsp cards.

I am in the process of hacking out a perl script to
report calls est, calls term, call fail and success ratio.

Eric Billeter
Internet Engineer
Cable One, Inc.

[e-mail]
602-364-6462

-----Original Message-----
[mailto:[e-mail]]On Behalf Of Blake Fithen
Sent: Wednesday, August 11, 1999 11:47 AM


I hate to be annoying and reopen this thread but we seem
to be having similar problem with all of our ARC/DSP chassis.
The symptoms are:  user dials-in, handshaking starts, a few
seconds later a solid monotone ringing is heard.  On the ARC
side it looks like this:

slot:3/mod:7            DIALIN INVALID 00-   -0000 00:00:00

and the call never completes.  If you look in Performance
Monitor, select the modems, choose "modem events" functional
group, choose "Incoming connections est.", "Incoming
connections terminated", and "Incoming connections failed"
you will see the failed connection number WAY higher than
the connections est. or terminated.  The only way to correct
the modem is to reboot the card - rebooting the individual
modem does not work.  After rebooting the card the modem
takes the call without a problem.

We have quad modem chassis on the same set of PRI circuits
without any problems.

Does anyone have any advice on this?

Thanks for your time.


> -----Original Message-----
> From: Mike Andrews [mailto:[e-mail]]
> Sent: Friday, August 06, 1999 4:35 PM
> To: [e-mail]
> Subject: Re: (usr-tc) bad port locator
>
>
> I probably will as soon as I dig up the appropriate OID's...
>
>
> Mike Andrews (MA12) -=-=-  VP & Sysadmin, Digital Crescent,
> Frankfort KY
> [e-mail]  -=--=-  [e-mail]  -=--=-
> http://www.bit0.com
> "If you're not part of the solution.... you're part of the
> precipitate."
>
> On Fri, 6 Aug 1999, Jim Johnson wrote:
>
> >
> > Thanks for the post.
> >
> > I was wondering if anyone has anything written that uses PERL and
> > SNMP_Session.pm for the SNMP access.
> >
> > Jim
> >
> > Pete Ashdown wrote:
> > >
> > > My apologies.  I couldn't find this in the archive,
> although I have a
> > > distinct memory of posting it to the list.  Oh well.
> Here it is anyway:
> > >
> > > #!/usr/local/bin/perl
> > >
> > > # hdmcheck
> > > #
> > > # Checks the individual HDM stats in order to find stuck
> modems.  If the
> > > # total number of calls is greater than $minimum and the
> failed calls is
> > > # greater than the $threshold percentage of established
> calls, an external
> > > # script is called.  This script busy-outs the span and
> pages me.  How you
> > > # deal with the card after that point is your own voodoo.
> > > #
> > > # Stuck modems will exhibit themselves as RNA,
> wrong-carrier, and fast-busies.
> > > # No fun for your callers, and even less fun for you.
> > > #
> > > # If you crontab this script, be sure to run it in
> periods larger than the
> > > # time it takes "hdmreset" to run (ie: approximately 2 hours).
> > > #
> > > # Like many of my other scripts, this comes with no
> guarantee or warranty.
> > > # This script was crafted in a few hours in an attempt to
> workaround a
> > > # 3com/USR bug.
> > > #
> > > # This script requires the UNIX version of 3com/USR's TCM.
> > > # Questions or comments can be directed to [e-mail]
> > >
> > > # User definable variables
> > > # Location of your UNIX TCM
> > > $ENV{'TCMHOME'} = "/usr/local/lib/tcm";
> > > $ENV{'LD_LIBRARY_PATH'} = "/usr/local/lib";
> > >
> > > # Your SNMP read variable
> > > $readsnmp = "public";
> > >
> > > # Your SNMP write variable
> > > $writesnmp = "private";
> > >
> > > # Percentage of established calls that failed calls must exceed
> > > $threshold = 75;
> > >
> > > # Minimum number of calls that need to have been attempted
> > > $minimum = 25;
> > >
> > > # If you want to see things in action (set to 0 for crontab use)
> > > $debug = 0;
> > >
> > > # Where the hdmreset script is located
> > > $hdmreset = "/home/users/pashdown/usr/hdmreset";
> > >
> > > # Don't change these two unless you know what you're doing.
> > > $tcmperf = "$ENV{'TCMHOME'}/bin/tcmperf -s 1 -c $readsnmp ";
> > > $threshold = $threshold / 100;
> > >
> > > if (-e "/tmp/.hdmcheck") {
> > >     system ("/usr/local/bin/sendpage -q -p pete 'hdmcheck
> stuck'");
> > >     exit;
> > > }
> > > else {
> > >     system ("touch /tmp/.hdmcheck");
> > > }
> > >
> > > # Define these for each of your HIPER racks
> > >
> > > foreach $i ( 1 .. 11 ) {
> > >     &check_channels (slc1,$i);
> > > }
> > >
> > > foreach $i ( 1 .. 11 ) {
> > >     &check_channels (slc2,$i);
> > > }
> > >
> > > foreach $i ( 1 .. 11 ) {
> > >     &check_channels (slc3,$i);
> > > }
> > >
> > > foreach $i ( 1 .. 11 ) {
> > >     &check_channels (slc4,$i);
> > > }
> > >
> > > foreach $i ( 1 .. 11 ) {
> > >     &check_channels (slc5,$i);
> > > }
> > >
> > > foreach $i ( 1 .. 6 ) {
> > >     &check_channels (bond,$i);
> > > }
> > >
> > > unlink ("/tmp/.hdmcheck");
> > >
> > > exit;
> > >
> > > # check_channels(NMC name, span #)
> > > # assumes NMC is "city-snmp"
> > > #
> > > sub check_channels {
> > >
> > >     ($rack,$span) = @_;
> > >
> > >     print ("Rack: $rack\tSpan: $span\n") if $debug;
> > >
> > >     open ( TCMPERF, "$tcmperf -G \"Modem Events\"
> \"Incoming Connections Established\" -G \"Modem Events\"
> \"Incoming Connections Failed\" ${rack}-snmp:s${span}c1-23 2>&1 |");
> > >     while (<TCMPERF>) {
> > >         chop;
> > >         if (/Incoming Connections Established\s+(.*)/) {
> > >             @established = split (/\s+/,  $1);
> > >         }
> > >         if (/Incoming Connections Failed\s+(.*)/) {
> > >             @failed = split (/\s+/, $1);
> > >         }
> > >     }
> > >
> > >     $badcard = 0;
> > >
> > >     foreach $channel ( 0 .. $#established ) {
> > >         printf ("Channel %d\t Est: %d\tFail: %d",
> > >                 $channel+1, $established[$channel],
> $failed[$channel])
> > >             if $debug;
> > >         if (($established[$channel] + $failed[$channel] >
> $minimum) &&
> > >             ($failed[$channel] > $established[$channel] *
> $threshold)) {
> > >             printf ("Channel %d\t Est: %d\tFail: %d",
> > >                     $channel+1, $established[$channel],
> $failed[$channel]);
> > >             printf ("\tStuck Modem! %d > %d\n",
> > >                     $failed[$channel],
> ($established[$channel] * $threshold));
> > >             $badcard = 1;
> > >         }
> > >         print ("\n") if $debug;
> > >
> > >     }
> > >     if ($badcard) {
> > >         print ("Resetting $rack $span!\n") if $debug;
> > >         system ("$hdmreset $rack $readsnmp $writesnmp $span &");
> > >     }
> > >     print ("\n") if $debug;
> > > }
> > >
> > >
> --------------------------------------------------------------
> ----------------
> > > #!/bin/csh
> > >
> > > # hdmreset - reset an HDM card and give enough time for
> people to get off
> > > # Usage: hdmset target read write card
> > >
> > > # note - This used to reset the card when it actually
> helped.  I have found
> > > # that this doesn't cure everything, so now it just pages me.
> > >
> > > setenv LD_LIBRARY_PATH "/usr/local/lib"
> > > setenv TCMHOME "/usr/local/lib/tcm"
> > > set target=$1
> > > set read=$2
> > > set write=$3
> > > set card=$4
> > >
> > > # Busy out the card
> > > $TCMHOME/bin/tcmcmd -E "local out of service" -G commands
> -C $write -c $read ${target}-snmp:s${card}c25
> > >
> > > # sleep two hours
> > > sleep 7200
> > >
> > > # Reset the card
> > > #$TCMHOME/bin/tcmcmd -E "hardware reset" -G "hardware
> commands" -C $write -c $read ${target}-snmp:s${card}
> > >
> > > # Page someone
> > > /usr/local/bin/sendpage -q -p pete "reset modem card
> ${target} slot ${card}"
> > >
> > > -
> > >  To unsubscribe to usr-tc, send an email to
> "[e-mail]"
> > >  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 "[e-mail]"
> >  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 "[e-mail]"
>  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 "[e-mail]"
 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 "[e-mail]"
 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: "Stainforth, Matthew" <[e-mail]>
Subject: RE: (usr-tc) bad port locator
Date: 11 Aug 1999 15:54:35 -0300


I had the same problem the other day too, had a look at the incoming
connections failed for all the modems on that card and the number for that
one modem was several hundred times higher than the others.  A reboot of the
card seems to have cleared it but it's interesting that more than one of us
are experiencing the problem.

On Wednesday, August 11, 1999 3:56 PM, Jeff Mcadams [SMTP:[e-mail]]
wrote:
> Thus spake Blake Fithen
> >I hate to be annoying and reopen this thread but we seem
> >to be having similar problem with all of our ARC/DSP chassis.
> >The symptoms are:  user dials-in, handshaking starts, a few
> >seconds later a solid monotone ringing is heard.  On the ARC
> >side it looks like this:
>
> >slot:3/mod:7            DIALIN INVALID 00-   -0000 00:00:00
>
> Well...the "DIALIN INVALID" is normal.  This is the state that the port
> is in while the modem is handshaking...this is a normal occurance, and
> after a successful connect, the port would move on to other states.
> However, obviously you are having bad connects and there's a real
> problem there to fix, but this isn't an effect of it.  :)
> --
> Jeff McAdams                            Email: [e-mail]
> Head Network Administrator              Voice: [phone]
> IgLou Internet Services                        [phone]
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: "Jamie Orzechowski" <[e-mail]>
Subject: Re: (usr-tc) bad port locator
Date: 11 Aug 1999 15:07:02 -0400

same here!! ... I have no idea what has happened with the latest code update
but this high pitched sound is occuring on every singl DSP we have (14
total) ... I reset the card and it's fine ... then 2 days later the problem
comes back ... user dials in...they get a hardshake starting then it goes
into a long tone and drops the call ...


----- Original Message -----
Sent: Wednesday, August 11, 1999 2:47 PM


> I hate to be annoying and reopen this thread but we seem
> to be having similar problem with all of our ARC/DSP chassis.
> The symptoms are:  user dials-in, handshaking starts, a few
> seconds later a solid monotone ringing is heard.  On the ARC
> side it looks like this:
>
> slot:3/mod:7            DIALIN INVALID 00-   -0000 00:00:00
>
> and the call never completes.  If you look in Performance
> Monitor, select the modems, choose "modem events" functional
> group, choose "Incoming connections est.", "Incoming
> connections terminated", and "Incoming connections failed"
> you will see the failed connection number WAY higher than
> the connections est. or terminated.  The only way to correct
> the modem is to reboot the card - rebooting the individual
> modem does not work.  After rebooting the card the modem
> takes the call without a problem.
>
> We have quad modem chassis on the same set of PRI circuits
> without any problems.
>
> Does anyone have any advice on this?
>
> Thanks for your time.
>
>
> > -----Original Message-----
> > From: Mike Andrews [mailto:[e-mail]]
> > Sent: Friday, August 06, 1999 4:35 PM
> > To: [e-mail]
> > Subject: Re: (usr-tc) bad port locator
> >
> >
> > I probably will as soon as I dig up the appropriate OID's...
> >
> >
> > Mike Andrews (MA12) -=-=-  VP & Sysadmin, Digital Crescent,
> > Frankfort KY
> > [e-mail]  -=--=-  [e-mail]  -=--=-
> > http://www.bit0.com
> > "If you're not part of the solution.... you're part of the
> > precipitate."
> >
> > On Fri, 6 Aug 1999, Jim Johnson wrote:
> >
> > >
> > > Thanks for the post.
> > >
> > > I was wondering if anyone has anything written that uses PERL and
> > > SNMP_Session.pm for the SNMP access.
> > >
> > > Jim
> > >
> > > Pete Ashdown wrote:
> > > >
> > > > My apologies.  I couldn't find this in the archive,
> > although I have a
> > > > distinct memory of posting it to the list.  Oh well.
> > Here it is anyway:
> > > >
> > > > #!/usr/local/bin/perl
> > > >
> > > > # hdmcheck
> > > > #
> > > > # Checks the individual HDM stats in order to find stuck
> > modems.  If the
> > > > # total number of calls is greater than $minimum and the
> > failed calls is
> > > > # greater than the $threshold percentage of established
> > calls, an external
> > > > # script is called.  This script busy-outs the span and
> > pages me.  How you
> > > > # deal with the card after that point is your own voodoo.
> > > > #
> > > > # Stuck modems will exhibit themselves as RNA,
> > wrong-carrier, and fast-busies.
> > > > # No fun for your callers, and even less fun for you.
> > > > #
> > > > # If you crontab this script, be sure to run it in
> > periods larger than the
> > > > # time it takes "hdmreset" to run (ie: approximately 2 hours).
> > > > #
> > > > # Like many of my other scripts, this comes with no
> > guarantee or warranty.
> > > > # This script was crafted in a few hours in an attempt to
> > workaround a
> > > > # 3com/USR bug.
> > > > #
> > > > # This script requires the UNIX version of 3com/USR's TCM.
> > > > # Questions or comments can be directed to [e-mail]
> > > >
> > > > # User definable variables
> > > > # Location of your UNIX TCM
> > > > $ENV{'TCMHOME'} = "/usr/local/lib/tcm";
> > > > $ENV{'LD_LIBRARY_PATH'} = "/usr/local/lib";
> > > >
> > > > # Your SNMP read variable
> > > > $readsnmp = "public";
> > > >
> > > > # Your SNMP write variable
> > > > $writesnmp = "private";
> > > >
> > > > # Percentage of established calls that failed calls must exceed
> > > > $threshold = 75;
> > > >
> > > > # Minimum number of calls that need to have been attempted
> > > > $minimum = 25;
> > > >
> > > > # If you want to see things in action (set to 0 for crontab use)
> > > > $debug = 0;
> > > >
> > > > # Where the hdmreset script is located
> > > > $hdmreset = "/home/users/pashdown/usr/hdmreset";
> > > >
> > > > # Don't change these two unless you know what you're doing.
> > > > $tcmperf = "$ENV{'TCMHOME'}/bin/tcmperf -s 1 -c $readsnmp ";
> > > > $threshold = $threshold / 100;
> > > >
> > > > if (-e "/tmp/.hdmcheck") {
> > > >     system ("/usr/local/bin/sendpage -q -p pete 'hdmcheck
> > stuck'");
> > > >     exit;
> > > > }
> > > > else {
> > > >     system ("touch /tmp/.hdmcheck");
> > > > }
> > > >
> > > > # Define these for each of your HIPER racks
> > > >
> > > > foreach $i ( 1 .. 11 ) {
> > > >     &check_channels (slc1,$i);
> > > > }
> > > >
> > > > foreach $i ( 1 .. 11 ) {
> > > >     &check_channels (slc2,$i);
> > > > }
> > > >
> > > > foreach $i ( 1 .. 11 ) {
> > > >     &check_channels (slc3,$i);
> > > > }
> > > >
> > > > foreach $i ( 1 .. 11 ) {
> > > >     &check_channels (slc4,$i);
> > > > }
> > > >
> > > > foreach $i ( 1 .. 11 ) {
> > > >     &check_channels (slc5,$i);
> > > > }
> > > >
> > > > foreach $i ( 1 .. 6 ) {
> > > >     &check_channels (bond,$i);
> > > > }
> > > >
> > > > unlink ("/tmp/.hdmcheck");
> > > >
> > > > exit;
> > > >
> > > > # check_channels(NMC name, span #)
> > > > # assumes NMC is "city-snmp"
> > > > #
> > > > sub check_channels {
> > > >
> > > >     ($rack,$span) = @_;
> > > >
> > > >     print ("Rack: $rack\tSpan: $span\n") if $debug;
> > > >
> > > >     open ( TCMPERF, "$tcmperf -G \"Modem Events\"
> > \"Incoming Connections Established\" -G \"Modem Events\"
> > \"Incoming Connections Failed\" ${rack}-snmp:s${span}c1-23 2>&1 |");
> > > >     while (<TCMPERF>) {
> > > >         chop;
> > > >         if (/Incoming Connections Established\s+(.*)/) {
> > > >             @established = split (/\s+/,  $1);
> > > >         }
> > > >         if (/Incoming Connections Failed\s+(.*)/) {
> > > >             @failed = split (/\s+/, $1);
> > > >         }
> > > >     }
> > > >
> > > >     $badcard = 0;
> > > >
> > > >     foreach $channel ( 0 .. $#established ) {
> > > >         printf ("Channel %d\t Est: %d\tFail: %d",
> > > >                 $channel+1, $established[$channel],
> > $failed[$channel])
> > > >             if $debug;
> > > >         if (($established[$channel] + $failed[$channel] >
> > $minimum) &&
> > > >             ($failed[$channel] > $established[$channel] *
> > $threshold)) {
> > > >             printf ("Channel %d\t Est: %d\tFail: %d",
> > > >                     $channel+1, $established[$channel],
> > $failed[$channel]);
> > > >             printf ("\tStuck Modem! %d > %d\n",
> > > >                     $failed[$channel],
> > ($established[$channel] * $threshold));
> > > >             $badcard = 1;
> > > >         }
> > > >         print ("\n") if $debug;
> > > >
> > > >     }
> > > >     if ($badcard) {
> > > >         print ("Resetting $rack $span!\n") if $debug;
> > > >         system ("$hdmreset $rack $readsnmp $writesnmp $span &");
> > > >     }
> > > >     print ("\n") if $debug;
> > > > }
> > > >
> > > >
> > --------------------------------------------------------------
> > ----------------
> > > > #!/bin/csh
> > > >
> > > > # hdmreset - reset an HDM card and give enough time for
> > people to get off
> > > > # Usage: hdmset target read write card
> > > >
> > > > # note - This used to reset the card when it actually
> > helped.  I have found
> > > > # that this doesn't cure everything, so now it just pages me.
> > > >
> > > > setenv LD_LIBRARY_PATH "/usr/local/lib"
> > > > setenv TCMHOME "/usr/local/lib/tcm"
> > > > set target=$1
> > > > set read=$2
> > > > set write=$3
> > > > set card=$4
> > > >
> > > > # Busy out the card
> > > > $TCMHOME/bin/tcmcmd -E "local out of service" -G commands
> > -C $write -c $read ${target}-snmp:s${card}c25
> > > >
> > > > # sleep two hours
> > > > sleep 7200
> > > >
> > > > # Reset the card
> > > > #$TCMHOME/bin/tcmcmd -E "hardware reset" -G "hardware
> > commands" -C $write -c $read ${target}-snmp:s${card}
> > > >
> > > > # Page someone
> > > > /usr/local/bin/sendpage -q -p pete "reset modem card
> > ${target} slot ${card}"
> > > >
> > > > -
> > > >  To unsubscribe to usr-tc, send an email to
> > "[e-mail]"
> > > >  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 "[e-mail]"
> > >  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 "[e-mail]"
> >  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 "[e-mail]"
>  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 "[e-mail]"
 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: Marty Elliott <[e-mail]>
Subject: (usr-tc) E1 File Needed
Date: 11 Aug 1999 12:11:19 -0700

We have a customer in Australia who purchased a used T1/E1 card from us.
Unfortunately the card sees itself as T1 and needs a file to become E1
(according to the "always friendly" 3Com support folks).  Neither card nor
chassis is under support contract.

The file needed is:

ep030105.zip

If anyone has access to this file, please let me know ASAP.  We'll gladly
pay for your time and trouble.

Thanks

Marty


====================
Marty Elliott
Managed Asset Recovery Specialists, Inc. (MARS)
2105 South 48th Street
Suite 104
Tempe, AZ  85282

602-426-8272
602-454-0770 fax
[e-mail]
www.2assetrecovery.com
====================

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Blake Fithen <[e-mail]>
Subject: RE: (usr-tc) bad port locator
Date: 11 Aug 1999 15:39:44 -0500

You're right.  What i meant to say is it doesn't go beyond
that for the port that is having problems.  I also forgot
to mention that this happens with PRI's provided by
Southwestern Bell, KMC Telecom (CLEC in Southeast), and
Channelized T1's from Sprint.

Any advice 3Com??

blake

> -----Original Message-----
> From: Jeff Mcadams [mailto:[e-mail]]
> Sent: Wednesday, August 11, 1999 1:56 PM
> To: [e-mail]
> Subject: Re: (usr-tc) bad port locator
>
>
> Thus spake Blake Fithen
> >I hate to be annoying and reopen this thread but we seem
> >to be having similar problem with all of our ARC/DSP chassis.
> >The symptoms are:  user dials-in, handshaking starts, a few
> >seconds later a solid monotone ringing is heard.  On the ARC
> >side it looks like this:
>
> >slot:3/mod:7            DIALIN INVALID 00-   -0000 00:00:00
>
> Well...the "DIALIN INVALID" is normal.  This is the state
> that the port
> is in while the modem is handshaking...this is a normal occurance, and
> after a successful connect, the port would move on to other states.
> However, obviously you are having bad connects and there's a real
> problem there to fix, but this isn't an effect of it.  :)
> --
> Jeff McAdams                            Email: [e-mail]
> Head Network Administrator              Voice: [phone]
> IgLou Internet Services                        [phone]
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: Mike Andrews <[e-mail]>
Subject: RE: (usr-tc) bad port locator
Date: 11 Aug 1999 17:37:53 -0400 (EDT)

I'm trying to write a Perl script to automate checking for this (using
SNMP instead of syslog), and I'm seeing that there's actually two
different counters for failed connections.  One is for "incoming
connections failed", the other is "connect attempt failure".

On Quads, they return the same number.

On DSP's, the "incoming connections failed" counter is a hell of a lot
higher -- almost all of my DSP channels return 0 for "connect attempt
failure", but almost none of them report 0 for "incoming connections
failed".  I'm guessing the "incoming" counter is for "normal" connect
failures (there is such a thing), like say the user hangs up on you before
training finishes, or someone made a voice call to your modem pool, or
something other than the DSP failure we're seeing here.

Can someone else check me on this?  Which one is everyone else looking at
to determine failures?

For now, I'm going to have the program scan all modems and print a warning
if it finds any DSP where "connect attempt failure" is non-zero.  So in a
healthy rack it should appear to do nothing; that way if you run it from
cron, it will only email you if there's a problem.  It'll be on my
usrtoys web page in a few minutes.


Mike Andrews (MA12) -=-=-  VP & Sysadmin, Digital Crescent, Frankfort KY
[e-mail]  -=--=-  [e-mail]  -=--=-  http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."

On Wed, 11 Aug 1999, Stainforth, Matthew wrote:

>
> I had the same problem the other day too, had a look at the incoming
> connections failed for all the modems on that card and the number for that
> one modem was several hundred times higher than the others.  A reboot of the
> card seems to have cleared it but it's interesting that more than one of us
> are experiencing the problem.
>
> On Wednesday, August 11, 1999 3:56 PM, Jeff Mcadams [SMTP:[e-mail]]
> wrote:
> > Thus spake Blake Fithen
> > >I hate to be annoying and reopen this thread but we seem
> > >to be having similar problem with all of our ARC/DSP chassis.
> > >The symptoms are:  user dials-in, handshaking starts, a few
> > >seconds later a solid monotone ringing is heard.  On the ARC
> > >side it looks like this:
> >
> > >slot:3/mod:7            DIALIN INVALID 00-   -0000 00:00:00
> >
> > Well...the "DIALIN INVALID" is normal.  This is the state that the port
> > is in while the modem is handshaking...this is a normal occurance, and
> > after a successful connect, the port would move on to other states.
> > However, obviously you are having bad connects and there's a real
> > problem there to fix, but this isn't an effect of it.  :)
> > --
> > Jeff McAdams                            Email: [e-mail]
> > Head Network Administrator              Voice: [phone]
> > IgLou Internet Services                        [phone]
> >
> > -
> >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> >  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 "[e-mail]"
>  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 "[e-mail]"
 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: Brian <[e-mail]>
Subject: Re: (usr-tc) Locating a bad port on DSP
Date: 11 Aug 1999 16:51:39 -0500 (CDT)


I posted it here before, it doesn't use snmp/oids but rather parses syslog
output.  No doubt snmp and oid's is the way to go, since this summary
information is available via the MIB (I believe.........at least tcm knows
about it).

Brian


On Thu, 5 Aug 1999, Jim Johnson wrote:

>
> Ken,
>
> Assuming that the script was written in PERL and uses SNMP that would be
> a useful script to have because it could probably be fairly easily
> modified to incorporate other OIDs for critical monitoring purposes.
>
> Would you be willing to email it to the list?
>
> Jim
>
> Ken Kirchner wrote:
> >
> > Our SysAdmin wrote a program that sends us an e-mail once a day containing
> > the total calls connected/failed and the ratio for each modem in our
> > chassis'.
> >
> > This lets us see which cards are not performing well in relation to the
> > rest of the cards in the chassis.  It also keeps us informed on a daily
> > basis. It's very helpful in troubleshooting.  I dont know if it's the
> > "best" way, but it works for us.
> >
> > Wouldnt it be nice if 3Com or someone would make some type of cross-over
> > cable and software to hook between two HDM's so you could use one to check
> > out the other?
> >
> > On Thu, 5 Aug 1999, Jim Johnson wrote:
> >
> > > I found the bad port(s) by using TCM to show Modem Events => Incoming
> > > Connections Failed   The numbers stood out like a sore thumb and it
> > > turned out to be two ports.  The hiper ports always go in pairs don't
> > > they?
> > >
> > > Fortunately, the problem went away with a software reset.
> > >
> > > But, back to the original question, is that the best way?
> >
> >   ___                                                         ___
> >  (___) Kenneth Kirchner    .o.  mailto:[e-mail]       (___)
> >   (__) Asst SysAdmin       .o.  Voice [phone] Ext 108 (__)
> >    (_) ShreveNet, Inc.     .o.  Fax   [phone]         (_)
> >
> > -
> >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> >  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 "[e-mail]"
>  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.
>

Brian Feeny (BF304)     [e-mail]
318-222-2638 x 109    http://www.shreve.net/~signal
Network Administrator   ShreveNet Inc. (ASN 11881)


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Brian <[e-mail]>
Subject: RE: (usr-tc) Locating a bad port on DSP
Date: 11 Aug 1999 16:54:56 -0500 (CDT)




On Thu, 5 Aug 1999, Randy Cosby wrote:

> Wouldn't it be nice if your admin  shared that program :)
>
> Randy
> InfoWest
>

I don't have a problem sharing it, but I do realize its ineffeciencies
being it doesn't use snmp.  But if you are already logging via syslog, it
works well.

#!/usr/bin/perl
# hdm-analyzer - Analyzes calls arrived vs. calls established
# from ARC syslog files.
# Usage: hdm-analyzer.pl <filename> <arc>
# <[e-mail]>

$|=1;
$==56;
$^L=" ";
$date=`date "+%x %X"`;

$file=$ARGV[0];
$choice=$ARGV[1];

open(FILE,"/var/log/shrevenet/$file");
while(<FILE>) {
    ($arc)=(split)[3];
#    if ($choice eq substr($arc,0,4)) {
     if ($choice eq $arc) {
        if(/call id = (\d+), has arrived on interface (\S+)/) {
          $idtrack{$1}=1;
          $slotmod_a{$2}++;;
        }  elsif((/call id (\d+), on interface (\S+)/) && ($idtrack{$1} == 1)) {
      $slotmod_e{$2}++;
     }
    }

close(FILE);

foreach (sort keys %slotmod_a) {
   $counter++;
   if(!$slotmod_e{$_}) { $slotmod_e{$_}=0 };
   $percent=((($slotmod_e{$_}/$slotmod_a{$_})*100));
   $failed=$slotmod_a{$_}-$slotmod_e{$_};
   write;
   $total+=$percent;

$total/=$counter;
print  "=================================\n";
printf "%.2f% average for chassis\n",$total;
print  "=================================\n";



format STDOUT_TOP =
@||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
"Modem Health Check - file: $file - chassis: $choice"
@||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
"$date"
slot:x/mod:y       Calls            Calls      Failed     Percent
        Arrived      Established    Attempts    Success
------------      -------      -----------    --------    -------


format STDOUT =
@<<<<<<<<<<<<<     @<<<<<<     @<<<<<<<<<<     @<<<<<<<    @###.##
$_,$slotmod_a{$_},$slotmod_e{$_},$failed,$percent




>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Ken Kirchner
> > Sent: Thursday, August 05, 1999 2:26 PM
> > To: [e-mail]
> > Subject: Re: (usr-tc) Locating a bad port on DSP
> >
> >
> > Our SysAdmin wrote a program that sends us an e-mail once a day containing
> > the total calls connected/failed and the ratio for each modem in our
> > chassis'.
> >
> > This lets us see which cards are not performing well in relation to the
> > rest of the cards in the chassis.  It also keeps us informed on a daily
> > basis. It's very helpful in troubleshooting.  I dont know if it's the
> > "best" way, but it works for us.
> >
> > Wouldnt it be nice if 3Com or someone would make some type of cross-over
> > cable and software to hook between two HDM's so you could use one to check
> > out the other?
> >
> > On Thu, 5 Aug 1999, Jim Johnson wrote:
> >
> > > I found the bad port(s) by using TCM to show Modem Events => Incoming
> > > Connections Failed   The numbers stood out like a sore thumb and it
> > > turned out to be two ports.  The hiper ports always go in pairs don't
> > > they?
> > >
> > > Fortunately, the problem went away with a software reset.
> > >
> > > But, back to the original question, is that the best way?
> >
> >   ___                                                         ___
> >  (___) Kenneth Kirchner    .o.  mailto:[e-mail]       (___)
> >   (__) Asst SysAdmin       .o.  Voice [phone] Ext 108 (__)
> >    (_) ShreveNet, Inc.     .o.  Fax   [phone]         (_)
> >
> >
> > -
> >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> >  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 "[e-mail]"
>  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.
>

Brian Feeny (BF304)     [e-mail]
318-222-2638 x 109    http://www.shreve.net/~signal
Network Administrator   ShreveNet Inc. (ASN 11881)


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Brian <[e-mail]>
Subject: Re: (usr-tc) Locating a bad port on DSP
Date: 11 Aug 1999 16:56:07 -0500 (CDT)

On Thu, 5 Aug 1999, Ken Kirchner wrote:

> On Thu, 5 Aug 1999, Pete Ashdown wrote:
>
> > Randy Cosby said once upon a time:
> > >
> > >Wouldn't it be nice if your admin  shared that program :)
> >
> > I posted it to the list when I wrote it several months ago.  Since we are
> > direct competitors Randy, I will leave it as an exercise to the reader to
> > extract it from the archives.
>
> Oops, my apologies if you are the author of the program, Mr. Ashdown.  I
> assumed Brian had written it.  I assume incorrectly a lot though. :)

I wrote the one we use, which probably looks nothing like Petes........I
didn't even know Pete had written one, but I posted mine just a few
messages ago.

Brian


>
>   ___                                                         ___
>  (___) Kenneth Kirchner    .o.  mailto:[e-mail]       (___)
>   (__) Asst SysAdmin       .o.  Voice [phone] Ext 108 (__)
>    (_) ShreveNet, Inc.     .o.  Fax   [phone]         (_)
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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.
>

Brian Feeny (BF304)     [e-mail]
318-222-2638 x 109    http://www.shreve.net/~signal
Network Administrator   ShreveNet Inc. (ASN 11881)


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Brett Murphy" <[e-mail]>
Subject: Re: (usr-tc) bad port locator
Date: 12 Aug 1999 10:39:13 +1000





>I hate to be annoying and reopen this thread but we seem
>to be having similar problem with all of our ARC/DSP chassis.
>The symptoms are:  user dials-in, handshaking starts, a few
>seconds later a solid monotone ringing is heard.  On the ARC
>side it looks like this:
>
>slot:3/mod:7            DIALIN INVALID 00-   -0000 00:00:00


Not sure, but I have been told that one in every 30 calls on E1 cards
fails due to a bug in the firmware.


>
>and the call never completes.  If you look in Performance
>Monitor, select the modems, choose "modem events" functional
>group, choose "Incoming connections est.", "Incoming
>connections terminated", and "Incoming connections failed"
>you will see the failed connection number WAY higher than
>the connections est. or terminated.  The only way to correct
>the modem is to reboot the card - rebooting the individual
>modem does not work.  After rebooting the card the modem
>takes the call without a problem.
>
>We have quad modem chassis on the same set of PRI circuits
>without any problems.
>
>Does anyone have any advice on this?
>
>Thanks for your time.
>
>
>> -----Original Message-----
>> From: Mike Andrews [mailto:[e-mail]]
>> Sent: Friday, August 06, 1999 4:35 PM
>> To: [e-mail]
>> Subject: Re: (usr-tc) bad port locator
>>
>>
>> I probably will as soon as I dig up the appropriate OID's...
>>
>>
>> Mike Andrews (MA12) -=-=-  VP & Sysadmin, Digital Crescent,
>> Frankfort KY
>> [e-mail]  -=--=-  [e-mail]  -=--=-
>> http://www.bit0.com
>> "If you're not part of the solution.... you're part of the
>> precipitate."
>>
>> On Fri, 6 Aug 1999, Jim Johnson wrote:
>>
>> >
>> > Thanks for the post.
>> >
>> > I was wondering if anyone has anything written that uses PERL and
>> > SNMP_Session.pm for the SNMP access.
>> >
>> > Jim
>> >
>> > Pete Ashdown wrote:
>> > >
>> > > My apologies.  I couldn't find this in the archive,
>> although I have a
>> > > distinct memory of posting it to the list.  Oh well.
>> Here it is anyway:
>> > >
>> > > #!/usr/local/bin/perl
>> > >
>> > > # hdmcheck
>> > > #
>> > > # Checks the individual HDM stats in order to find stuck
>> modems.  If the
>> > > # total number of calls is greater than $minimum and the
>> failed calls is
>> > > # greater than the $threshold percentage of established
>> calls, an external
>> > > # script is called.  This script busy-outs the span and
>> pages me.  How you
>> > > # deal with the card after that point is your own voodoo.
>> > > #
>> > > # Stuck modems will exhibit themselves as RNA,
>> wrong-carrier, and fast-busies.
>> > > # No fun for your callers, and even less fun for you.
>> > > #
>> > > # If you crontab this script, be sure to run it in
>> periods larger than the
>> > > # time it takes "hdmreset" to run (ie: approximately 2 hours).
>> > > #
>> > > # Like many of my other scripts, this comes with no
>> guarantee or warranty.
>> > > # This script was crafted in a few hours in an attempt to
>> workaround a
>> > > # 3com/USR bug.
>> > > #
>> > > # This script requires the UNIX version of 3com/USR's TCM.
>> > > # Questions or comments can be directed to [e-mail]
>> > >
>> > > # User definable variables
>> > > # Location of your UNIX TCM
>> > > $ENV{'TCMHOME'} = "/usr/local/lib/tcm";
>> > > $ENV{'LD_LIBRARY_PATH'} = "/usr/local/lib";
>> > >
>> > > # Your SNMP read variable
>> > > $readsnmp = "public";
>> > >
>> > > # Your SNMP write variable
>> > > $writesnmp = "private";
>> > >
>> > > # Percentage of established calls that failed calls must exceed
>> > > $threshold = 75;
>> > >
>> > > # Minimum number of calls that need to have been attempted
>> > > $minimum = 25;
>> > >
>> > > # If you want to see things in action (set to 0 for crontab use)
>> > > $debug = 0;
>> > >
>> > > # Where the hdmreset script is located
>> > > $hdmreset = "/home/users/pashdown/usr/hdmreset";
>> > >
>> > > # Don't change these two unless you know what you're doing.
>> > > $tcmperf = "$ENV{'TCMHOME'}/bin/tcmperf -s 1 -c $readsnmp ";
>> > > $threshold = $threshold / 100;
>> > >
>> > > if (-e "/tmp/.hdmcheck") {
>> > >     system ("/usr/local/bin/sendpage -q -p pete 'hdmcheck
>> stuck'");
>> > >     exit;
>> > > }
>> > > else {
>> > >     system ("touch /tmp/.hdmcheck");
>> > > }
>> > >
>> > > # Define these for each of your HIPER racks
>> > >
>> > > foreach $i ( 1 .. 11 ) {
>> > >     &check_channels (slc1,$i);
>> > > }
>> > >
>> > > foreach $i ( 1 .. 11 ) {
>> > >     &check_channels (slc2,$i);
>> > > }
>> > >
>> > > foreach $i ( 1 .. 11 ) {
>> > >     &check_channels (slc3,$i);
>> > > }
>> > >
>> > > foreach $i ( 1 .. 11 ) {
>> > >     &check_channels (slc4,$i);
>> > > }
>> > >
>> > > foreach $i ( 1 .. 11 ) {
>> > >     &check_channels (slc5,$i);
>> > > }
>> > >
>> > > foreach $i ( 1 .. 6 ) {
>> > >     &check_channels (bond,$i);
>> > > }
>> > >
>> > > unlink ("/tmp/.hdmcheck");
>> > >
>> > > exit;
>> > >
>> > > # check_channels(NMC name, span #)
>> > > # assumes NMC is "city-snmp"
>> > > #
>> > > sub check_channels {
>> > >
>> > >     ($rack,$span) = @_;
>> > >
>> > >     print ("Rack: $rack\tSpan: $span\n") if $debug;
>> > >
>> > >     open ( TCMPERF, "$tcmperf -G \"Modem Events\"
>> \"Incoming Connections Established\" -G \"Modem Events\"
>> \"Incoming Connections Failed\" ${rack}-snmp:s${span}c1-23 2>&1 |");
>> > >     while (<TCMPERF>) {
>> > >         chop;
>> > >         if (/Incoming Connections Established\s+(.*)/) {
>> > >             @established = split (/\s+/,  $1);
>> > >         }
>> > >         if (/Incoming Connections Failed\s+(.*)/) {
>> > >             @failed = split (/\s+/, $1);
>> > >         }
>> > >     }
>> > >
>> > >     $badcard = 0;
>> > >
>> > >     foreach $channel ( 0 .. $#established ) {
>> > >         printf ("Channel %d\t Est: %d\tFail: %d",
>> > >                 $channel+1, $established[$channel],
>> $failed[$channel])
>> > >             if $debug;
>> > >         if (($established[$channel] + $failed[$channel] >
>> $minimum) &&
>> > >             ($failed[$channel] > $established[$channel] *
>> $threshold)) {
>> > >             printf ("Channel %d\t Est: %d\tFail: %d",
>> > >                     $channel+1, $established[$channel],
>> $failed[$channel]);
>> > >             printf ("\tStuck Modem! %d > %d\n",
>> > >                     $failed[$channel],
>> ($established[$channel] * $threshold));
>> > >             $badcard = 1;
>> > >         }
>> > >         print ("\n") if $debug;
>> > >
>> > >     }
>> > >     if ($badcard) {
>> > >         print ("Resetting $rack $span!\n") if $debug;
>> > >         system ("$hdmreset $rack $readsnmp $writesnmp $span &");
>> > >     }
>> > >     print ("\n") if $debug;
>> > > }
>> > >
>> > >
>> --------------------------------------------------------------
>> ----------------
>> > > #!/bin/csh
>> > >
>> > > # hdmreset - reset an HDM card and give enough time for
>> people to get off
>> > > # Usage: hdmset target read write card
>> > >
>> > > # note - This used to reset the card when it actually
>> helped.  I have found
>> > > # that this doesn't cure everything, so now it just pages me.
>> > >
>> > > setenv LD_LIBRARY_PATH "/usr/local/lib"
>> > > setenv TCMHOME "/usr/local/lib/tcm"
>> > > set target=$1
>> > > set read=$2
>> > > set write=$3
>> > > set card=$4
>> > >
>> > > # Busy out the card
>> > > $TCMHOME/bin/tcmcmd -E "local out of service" -G commands
>> -C $write -c $read ${target}-snmp:s${card}c25
>> > >
>> > > # sleep two hours
>> > > sleep 7200
>> > >
>> > > # Reset the card
>> > > #$TCMHOME/bin/tcmcmd -E "hardware reset" -G "hardware
>> commands" -C $write -c $read ${target}-snmp:s${card}
>> > >
>> > > # Page someone
>> > > /usr/local/bin/sendpage -q -p pete "reset modem card
>> ${target} slot ${card}"
>> > >
>> > > -
>> > >  To unsubscribe to usr-tc, send an email to
>> "[e-mail]"
>> > >  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 "[e-mail]"
>> >  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 "[e-mail]"
>>  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 "[e-mail]"
> 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 "[e-mail]"
 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: "Brett Murphy" <[e-mail]>
Subject: Re: (usr-tc) bad port locator
Date: 12 Aug 1999 10:49:02 +1000


-----Original Message-----


>I'm trying to write a Perl script to automate checking for this (using
>SNMP instead of syslog), and I'm seeing that there's actually two
>different counters for failed connections.  One is for "incoming
>connections failed", the other is "connect attempt failure".


Does a call that fails after handshaking has been established count as an
"incoming call failed"? We have a large number of customers
complaining about disconnections after an initial period. (5 mins, 10 mins,
20 mins etc)


>
>On Quads, they return the same number.
>
>On DSP's, the "incoming connections failed" counter is a hell of a lot
>higher -- almost all of my DSP channels return 0 for "connect attempt
>failure", but almost none of them report 0 for "incoming connections
>failed".  I'm guessing the "incoming" counter is for "normal" connect
>failures (there is such a thing), like say the user hangs up on you before
>training finishes, or someone made a voice call to your modem pool, or
>something other than the DSP failure we're seeing here.
>
>Can someone else check me on this?  Which one is everyone else looking at
>to determine failures?
>
>For now, I'm going to have the program scan all modems and print a warning
>if it finds any DSP where "connect attempt failure" is non-zero.  So in a
>healthy rack it should appear to do nothing; that way if you run it from
>cron, it will only email you if there's a problem.  It'll be on my
>usrtoys web page in a few minutes.
>
>
>Mike Andrews (MA12) -=-=-  VP & Sysadmin, Digital Crescent, Frankfort KY
>[e-mail]  -=--=-  [e-mail]  -=--=-  http://www.bit0.com
>"If you're not part of the solution.... you're part of the precipitate."
>
>On Wed, 11 Aug 1999, Stainforth, Matthew wrote:
>
>>
>> I had the same problem the other day too, had a look at the incoming
>> connections failed for all the modems on that card and the number for
that
>> one modem was several hundred times higher than the others.  A reboot of
the
>> card seems to have cleared it but it's interesting that more than one of
us
>> are experiencing the problem.
>>
>> On Wednesday, August 11, 1999 3:56 PM, Jeff Mcadams
[SMTP:[e-mail]]
>> wrote:
>> > Thus spake Blake Fithen
>> > >I hate to be annoying and reopen this thread but we seem
>> > >to be having similar problem with all of our ARC/DSP chassis.
>> > >The symptoms are:  user dials-in, handshaking starts, a few
>> > >seconds later a solid monotone ringing is heard.  On the ARC
>> > >side it looks like this:
>> >
>> > >slot:3/mod:7            DIALIN INVALID 00-   -0000 00:00:00
>> >
>> > Well...the "DIALIN INVALID" is normal.  This is the state that the port
>> > is in while the modem is handshaking...this is a normal occurance, and
>> > after a successful connect, the port would move on to other states.
>> > However, obviously you are having bad connects and there's a real
>> > problem there to fix, but this isn't an effect of it.  :)
>> > --
>> > Jeff McAdams                            Email: [e-mail]
>> > Head Network Administrator              Voice: [phone]
>> > IgLou Internet Services                        [phone]
>> >
>> > -
>> >  To unsubscribe to usr-tc, send an email to "[e-mail]"
>> >  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 "[e-mail]"
>>  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 "[e-mail]"
> 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 "[e-mail]"
 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: Mike Andrews <[e-mail]>
Subject: Re: (usr-tc) bad port locator
Date: 11 Aug 1999 22:48:07 -0400 (EDT)

> >I'm trying to write a Perl script to automate checking for this (using
> >SNMP instead of syslog), and I'm seeing that there's actually two
> >different counters for failed connections.  One is for "incoming
> >connections failed", the other is "connect attempt failure".
>
>
> Does a call that fails after handshaking has been established count as an
> "incoming call failed"? We have a large number of customers
> complaining about disconnections after an initial period. (5 mins, 10 mins,
> 20 mins etc)

Don't think so.  But I haven't yet sat down and actually watched the
counters after every call.



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Brian <[e-mail]>
Subject: Re: (usr-tc) bad port locator
Date: 12 Aug 1999 08:01:45 -0500 (CDT)

On Thu, 12 Aug 1999, Brett Murphy wrote:

>
> -----Original Message-----
> From: Mike Andrews <[e-mail]>
> To: '[e-mail]' <[e-mail]>
> Date: Thursday, 12 August 1999 7:42
> Subject: RE: (usr-tc) bad port locator
>
>
> >I'm trying to write a Perl script to automate checking for this (using
> >SNMP instead of syslog), and I'm seeing that there's actually two
> >different counters for failed connections.  One is for "incoming
> >connections failed", the other is "connect attempt failure".
>
>
> Does a call that fails after handshaking has been established count as an
> "incoming call failed"? We have a large number of customers
> complaining about disconnections after an initial period. (5 mins, 10 mins,
> 20 mins etc)


No it does not.



Brian Feeny (BF304)     [e-mail]
318-222-2638 x 109    http://www.shreve.net/~signal
Network Administrator   ShreveNet Inc. (ASN 11881)


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Ralph Helfenberger <[e-mail]>
Subject: (usr-tc) Using both Ethernet interfaces on HiPer ARC
Date: 12 Aug 1999 17:34:54 +0200

I'd like to use both interfaces on the HiPer ARC (ETH:1 and ETH:2) on
the HiPer ARC. I have two applications in mind:

1. Redundancy
Both interfaces are connected to a different IP network with a different
default Gateway. If something on the first interface goes down (e.g. the
default gateway connected to  that interface is no longer working) all
traffic should automatically be forwared through the second interface.
As far as I can see this only works if the interface physically goes
down (means somebody takes the ethernet cable out).Has anyone solved
this problem?

2. Load sharing
I would also like to make some kind of load sharing between the two
interfaces: Same scenario as above: two interfaces, two default
gateways. It would be nice if the traffic could be distributed more or
less equally on both interfaces! Any ideas?

Thanks

Ralph

--
==========================================================================

R. Helfenberger                Internet  [e-mail]
Comlight AG                    Tel  [phone]
Tennisweg 21                   Fax  [phone]
3178 Boesingen
Switzerland                    www.comlight.ch
==========================================================================




-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) Using both Ethernet interfaces on HiPer ARC
Date: 12 Aug 1999 11:40:42 -0400 (EDT)

Thus spake Ralph Helfenberger
>I'd like to use both interfaces on the HiPer ARC (ETH:1 and ETH:2) on
>the HiPer ARC. I have two applications in mind:

>1. Redundancy
>Both interfaces are connected to a different IP network with a different
>default Gateway. If something on the first interface goes down (e.g. the
>default gateway connected to  that interface is no longer working) all
>traffic should automatically be forwared through the second interface.
>As far as I can see this only works if the interface physically goes
>down (means somebody takes the ethernet cable out).Has anyone solved
>this problem?

Advertise your default route in your routing protocol.

>2. Load sharing
>I would also like to make some kind of load sharing between the two
>interfaces: Same scenario as above: two interfaces, two default
>gateways. It would be nice if the traffic could be distributed more or
>less equally on both interfaces! Any ideas?

Not sure if the Arcs will handle equal cost load balancing...haven't
tried it...should be easy enough to test out...set up the second
ethernet port and slap a second default route in there and see what it
does.  I suspect it'll work, but not sure.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Brice Ligget <[e-mail]>
Subject: (usr-tc) Changing dial up.
Date: 12 Aug 1999 12:41:10 -0600

We are switching phone companies therefore dial up numbers.  Does anybody
know how to make a file/program that I can email to my users that will
switch their dial up phone number?  Even if it only works under 95/98 it
will be a VAST help.  Thank you!


--
Brice Ligget
Chief Operations Officer
Two Alpha Net is a complete Internet Service Provider based in Billings
Montana.
"Connect to the world"
406 628 1500

http://www.twoalpha.net


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) Changing dial up.
Date: 12 Aug 1999 14:57:24 -0400 (EDT)

Thus spake Brice Ligget
>We are switching phone companies therefore dial up numbers.  Does anybody
>know how to make a file/program that I can email to my users that will
>switch their dial up phone number?  Even if it only works under 95/98 it
>will be a VAST help.  Thank you!

According to the telecom reform act of 1996, you should be able to take
your phone number with you when you switch telephone companies.  Check
into it...it'll make your coming nightmare (that's ultimately worth it
in the end) into only a minor disturbing noise in the night.  :)
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Hofmann <[e-mail]>
Subject: RE: (usr-tc) Changing dial up.
Date: 12 Aug 1999 15:02:07 -0400

I'm not sure that this is the end all answer, but we had played with the
idea of sending a floppy that would just reconfigure machines that already
had a good browser.  Here is a link to the company that had the software.
 Specifically, we looked at the constructor product.
http://www.grvconsulting.com/~software/




We are switching phone companies therefore dial up numbers.  Does anybody
know how to make a file/program that I can email to my users that will
switch their dial up phone number?  Even if it only works under 95/98 it
will be a VAST help.  Thank you!

Jay Hofmann                                     Email: [e-mail]
Technical Support Team Leader               Voice: [phone]
IgLou Internet Services                            [phone]



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Brice Ligget <[e-mail]>
Subject: Re: (usr-tc) Changing dial up.
Date: 12 Aug 1999 13:51:22 -0600

That's somewhat amusing if it wasn't so tragic.  We were a US Waste
customer.  I won't do anything that would depend on their cooperation.  The
stories I could tell....  But that's for a different list.


At 02:57 PM 08/12/1999 -0400, you wrote:

>According to the telecom reform act of 1996, you should be able to take
>your phone number with you when you switch telephone companies.  Check
>into it...it'll make your coming nightmare (that's ultimately worth it
>in the end) into only a minor disturbing noise in the night.  :)
>--
>Jeff McAdams                            Email: [e-mail]
>Head Network Administrator              Voice: [phone]
>IgLou Internet Services                        [phone]


--
Brice Ligget
Billings MT
[e-mail]
http://www.twoalpha.net/~bligget
DoD#2159

I will not aim for the head.

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Hostmaster Soho Solutions - Javier Szyszlican" <[e-mail]>
Subject: (usr-tc) OT: Filters
Date: 12 Aug 1999 17:43:45 -0300

Hi,

Sorry...

But how do I set Filters (ie.. to make a user can only connect to a host)
I had it con a Netserver
But now I have a HiPer ARC....

Javier


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: [e-mail] (David Swearingin)
Subject: (usr-tc) Idle time
Date: 12 Aug 1999 15:51:14 -0500

Is there a command in HiPerARC to show idle time as there was with
NetServer?  I understood it was a feature to be added soon.

David
__________________________________________________
David Swearingin ([e-mail])
CARROLLTON INTERNET SERVICE (www.carolnet.com)
First Financial Group, Inc.
11 N. Folger, Carrollton, MO  64633
660-542-3002   Fax [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Scott Trautman <[e-mail]>
Subject: (usr-tc) Okay, the Prime is in, up and good....a couple more questions...a
Date: 12 Aug 1999 17:39:11 -0500

Two things--

1. Equivilent of Netserver "set reported x.x.x.x" on HiperARC? Many routers
need that stable destination in order to dial on demand. Negotiated doesn't
trigger the dial.

2. Modem group functionality. I monitor our POTS dialup with TSMON; I can
include/exclude "ports"
on this. I want to make sure my ISDN users come in on a specific range of
ports so I can exclude them from the TSMON reporting. set modem_group ?????
command of some sort?
The way I'm handling it other than this site is use a PM3, so it's a
completely separate unit and not a problem. Here the ISDN is "mixed in" with
the ordinary dialup users and I need to separate them back out somehow.

Thanks in advance!

SMT

Scott M. Trautman               800-482-4638
Global Dialog Internet          608-240-4638,4637fax
2810 Crossroads, STE LL2         [e-mail]
Madison WI 53718                    http://www.gdinet.com

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) Okay, the Prime is in, up and good....a couple more questions...a
Date: 12 Aug 1999 21:06:46 -0400 (EDT)

Thus spake Scott Trautman
>Two things--

>1. Equivilent of Netserver "set reported x.x.x.x" on HiperARC? Many
>routers need that stable destination in order to dial on demand.
>Negotiated doesn't trigger the dial.

IMHO, they're broken if they can't handle dial on demand with a dynamic
gateway address, and even its own PPP address...

but to answer your question:
set ip unnumbered_link local_address w.x.y.z

>2. Modem group functionality. I monitor our POTS dialup with TSMON; I
>can include/exclude "ports" on this. I want to make sure my ISDN users
>come in on a specific range of ports so I can exclude them from the
>TSMON reporting. set modem_group ?????  command of some sort?  The way
>I'm handling it other than this site is use a PM3, so it's a completely
>separate unit and not a problem. Here the ISDN is "mixed in" with the
>ordinary dialup users and I need to separate them back out somehow.

Oh, ick...not sure this can be done...maybe there's a way, but I can't
seem to come up with anything at the moment.  I don't think the
modem_groups will help you though...they are basically used for
configurating batches of ports at once...a convenience factor basically.

The HiPer Arc just handles calls on ports...it really doesn't make much
distinction between isdn and analog...they still come in on the same
port (ie, slot:x/mod:y).  You *might* be able to fiddle with the DSP's
to arrange the calls in a certain way, but I'm not sure that's going to
help either since there's limited call routing support within the DSP
(first available, next available, fixed assignment is about the extent
of it I think), and even if you could route them more
specifically...you've got 23 ds0's of calls coming in and basically the
same number of modems to deal with, eventually the calls will get mixed
in with each other.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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" <[e-mail]>
Subject: Re: (usr-tc) Routing (?) problems
Date: 13 Aug 1999 07:04:27 -0500

I have posted recently a routing problem that seems to be a larger issue
than I first realized.  Some of you have privately e-mailed me, and the
count seems to be growing each day.  I have a case number with 3-Com (opened
on 8/11/99).  The case number is 145336.

They have yet to respond, but I will keep the group posted.  If you have
read my previous post and are experiencing similar problems, please post or
e-mail me privately and I will add you to the list of affected ISPs.

Have a great day.

Samuel S. Lowe
Director, Data Services
UniversalCom, Inc.
[e-mail]



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Jamie Orzechowski" <[e-mail]>
Subject: (usr-tc) HiperARC security hole
Date: 13 Aug 1999 19:06:16 -0400

Just reading my Securityfocus email list and attacked was a new "Remote
HiPER ARC nuking program"

I have the source if anyone cares to have it ...

----- Original Message -----
Sent: Thursday, August 12, 1999 6:10 PM


> Hello,
>
> The attached program will reboot a 3com HiperARC.  I made an attempt to
> contact 3com before posting this report, however, I received no response.
> By flooding the telnet port of a 3com HiperARC using the provided program,
> the HiperARC unconditionally reboots.  This program is effective over all
> interfaces, including a dialup.
>
> Regards,
>
> Jonathan Chapman
> Director of Network Security
> FIRST Incorporated
> [e-mail]  www.1st.net



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Ed Taylor" <[e-mail]>
Subject: (usr-tc) HiperARC - Dangerous HiperBomb
Date: 13 Aug 1999 19:50:05 -0400

For HiperBomb code check out:

http://www.securityfocus.com/templates/archive.pike?list=1

It is very serious and reboots the HiperArc's from anywhere.


Ed


---------- Original Message ----------------------------------
Reply-To: [e-mail]

>Just reading my Securityfocus email list and attacked was a new "Remote
HiPER ARC nuking program"

I have the source if anyone cares to have it ...

----- Original Message -----
Sent: Thursday, August 12, 1999 6:10 PM


> Hello,
>
> The attached program will reboot a 3com HiperARC.  I made an attempt to
> contact 3com before posting this report, however, I received no response.
> By flooding the telnet port of a 3com HiperARC using the provided program,
> the HiperARC unconditionally reboots.  This program is effective over all
> interfaces, including a dialup.
>
> Regards,
>
> Jonathan Chapman
> Director of Network Security
> FIRST Incorporated
> [e-mail]  www.1st.net



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 "[e-mail]"
 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: Tatai SV Krishnan <[e-mail]>
Subject: Re: (usr-tc) HiperARC security hole
Date: 13 Aug 1999 07:10:17 -0500 (CDT)

Could you send me the source?

krish

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

On Fri, 13 Aug 1999, Jamie Orzechowski wrote:

> Just reading my Securityfocus email list and attacked was a new "Remote
> HiPER ARC nuking program"
>
> I have the source if anyone cares to have it ...
>
> ----- Original Message -----
> From: Jonathan Chapman <[e-mail]>
> To: <[e-mail]>
> Sent: Thursday, August 12, 1999 6:10 PM
> Subject: 3com hiperarch flaw [hiperbomb.c]
>
>
> > Hello,
> >
> > The attached program will reboot a 3com HiperARC.  I made an attempt to
> > contact 3com before posting this report, however, I received no response.
> > By flooding the telnet port of a 3com HiperARC using the provided program,
> > the HiperARC unconditionally reboots.  This program is effective over all
> > interfaces, including a dialup.
> >
> > Regards,
> >
> > Jonathan Chapman
> > Director of Network Security
> > FIRST Incorporated
> > [e-mail]  www.1st.net
>
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) HiperARC security hole
Date: 13 Aug 1999 21:35:56 -0400 (EDT)

Thus spake Tatai SV Krishnan
>Could you send me the source?

I'll assume Jamie is sending it to you...let me know if you don't get it
soon...I snagged it off BUGTRAQ as well and can easily forward it on.

Anyone tested this on 4.2.29?  I'm assuming it works, but don't have an
Arc actually in a chassis, power'ed up and with a network connected that
I can through this at it to check.  If I don't hear from anyone by
tomorrow, I'm gonna head into the office and pop one in (have an Arc
with 4.2.29 on it, just not powered up) and check it out.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Jamie Orzechowski" <[e-mail]>
Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
Date: 13 Aug 1999 21:57:21 -0400

I have blocked telnet access to the Class C which my arcs site on as a
temporary fix ...

----- Original Message -----
Sent: Friday, August 13, 1999 7:50 PM


> For HiperBomb code check out:
>
> http://www.securityfocus.com/templates/archive.pike?list=1
>
> It is very serious and reboots the HiperArc's from anywhere.
>
>
> Ed
>
>
> ---------- Original Message ----------------------------------
> From: "Jamie Orzechowski" <[e-mail]>
> Reply-To: [e-mail]
> Date:     Fri, 13 Aug 1999 19:03:36 -0400
>
> >Just reading my Securityfocus email list and attacked was a new "Remote
> HiPER ARC nuking program"
>
> I have the source if anyone cares to have it ...
>
> ----- Original Message -----
> From: Jonathan Chapman <[e-mail]>
> To: <[e-mail]>
> Sent: Thursday, August 12, 1999 6:10 PM
> Subject: 3com hiperarch flaw [hiperbomb.c]
>
>
> > Hello,
> >
> > The attached program will reboot a 3com HiperARC.  I made an attempt to
> > contact 3com before posting this report, however, I received no
response.
> > By flooding the telnet port of a 3com HiperARC using the provided
program,
> > the HiperARC unconditionally reboots.  This program is effective over
all
> > interfaces, including a dialup.
> >
> > Regards,
> >
> > Jonathan Chapman
> > Director of Network Security
> > FIRST Incorporated
> > [e-mail]  www.1st.net
>
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
>  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 "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
Date: 13 Aug 1999 22:02:27 -0400 (EDT)

Thus spake Jamie Orzechowski
>I have blocked telnet access to the Class C which my arcs site on as a
>temporary fix ...

Another possible fix (I assume...haven't tested for sure) would be to
disable the telnet service....that has the obvious side affect of making
them unavailable to network management via the CLI though...If you can
get by with SNMP management, that could work...just remember my previous
notice about elevated SNMP access if you have multiple access levels
defined on the Arc's SNMP agent.  Best bet I guess would be to relay
SNMP requests via the NMC...slows things down, but is the securest
method at this point I 'spect.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Rick <[e-mail]>
Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
Date: 13 Aug 1999 23:06:59 -0400

I can confirm this security-bug EXISTS. I compiled the source of hyper-nuke and
did indeed reboot some of my arcs (4.1.59-6).

As others have stated I would suggest implementing accesslists on your routers
that deny all telnet (tcp-25) traffic to your arcs.


Ed Taylor wrote:

> For HiperBomb code check out:
>
> http://www.securityfocus.com/templates/archive.pike?list=1
>
> It is very serious and reboots the HiperArc's from anywhere.
>
> Ed
>
> ---------- Original Message ----------------------------------
> From: "Jamie Orzechowski" <[e-mail]>
> Reply-To: [e-mail]
> Date:     Fri, 13 Aug 1999 19:03:36 -0400
>
> >Just reading my Securityfocus email list and attacked was a new "Remote
> HiPER ARC nuking program"
>
> I have the source if anyone cares to have it ...
>
> ----- Original Message -----
> From: Jonathan Chapman <[e-mail]>
> To: <[e-mail]>
> Sent: Thursday, August 12, 1999 6:10 PM
> Subject: 3com hiperarch flaw [hiperbomb.c]
>
> > Hello,
> >
> > The attached program will reboot a 3com HiperARC.  I made an attempt to
> > contact 3com before posting this report, however, I received no response.
> > By flooding the telnet port of a 3com HiperARC using the provided program,
> > the HiperARC unconditionally reboots.  This program is effective over all
> > interfaces, including a dialup.
> >
> > Regards,
> >
> > Jonathan Chapman
> > Director of Network Security
> > FIRST Incorporated
> > [e-mail]  www.1st.net
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
>  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.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rick Allan / [e-mail] | Connect to a Backbone not a Wishbone
Head of Network Engineering    |    Monmouth Internet Corporation
732-842-5366=====extension 102 |      http://www.monmouth.com
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Rick <[e-mail]>
Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
Date: 13 Aug 1999 23:15:52 -0400

typo in my last message. It should read "deny all telnet traffic (tcp-23)"




Rick wrote:

> I can confirm this security-bug EXISTS. I compiled the source of hyper-nuke and
> did indeed reboot some of my arcs (4.1.59-6).
>
> As others have stated I would suggest implementing accesslists on your routers
> that deny all telnet (tcp-25) traffic to your arcs.
>
> Ed Taylor wrote:
>
> > For HiperBomb code check out:
> >
> > http://www.securityfocus.com/templates/archive.pike?list=1
> >
> > It is very serious and reboots the HiperArc's from anywhere.
> >
> > Ed
> >
> > ---------- Original Message ----------------------------------
> > From: "Jamie Orzechowski" <[e-mail]>
> > Reply-To: [e-mail]
> > Date:     Fri, 13 Aug 1999 19:03:36 -0400
> >
> > >Just reading my Securityfocus email list and attacked was a new "Remote
> > HiPER ARC nuking program"
> >
> > I have the source if anyone cares to have it ...
> >
> > ----- Original Message -----
> > From: Jonathan Chapman <[e-mail]>
> > To: <[e-mail]>
> > Sent: Thursday, August 12, 1999 6:10 PM
> > Subject: 3com hiperarch flaw [hiperbomb.c]
> >
> > > Hello,
> > >
> > > The attached program will reboot a 3com HiperARC.  I made an attempt to
> > > contact 3com before posting this report, however, I received no response.
> > > By flooding the telnet port of a 3com HiperARC using the provided program,
> > > the HiperARC unconditionally reboots.  This program is effective over all
> > > interfaces, including a dialup.
> > >
> > > Regards,
> > >
> > > Jonathan Chapman
> > > Director of Network Security
> > > FIRST Incorporated
> > > [e-mail]  www.1st.net
> >
> > -
> >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> >  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 "[e-mail]"
> >  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.
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Rick Allan / [e-mail] | Connect to a Backbone not a Wishbone
> Head of Network Engineering    |    Monmouth Internet Corporation
> 732-842-5366=====extension 102 |      http://www.monmouth.com
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rick Allan / [e-mail] | Connect to a Backbone not a Wishbone
Head of Network Engineering    |    Monmouth Internet Corporation
732-842-5366=====extension 102 |      http://www.monmouth.com
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Marshall Morgan" <[e-mail]>
Subject: RE: (usr-tc) HiperARC - Dangerous HiperBomb
Date: 14 Aug 1999 01:09:46 -0500

But your own customers can still reboot them via dialup to that NAS.

Marshall Morgan

Internet Doorway, Inc. (aka NETDOOR)

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Rick
> Sent: Friday, August 13, 1999 10:07 PM
> To: [e-mail]
> Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
>
>
> I can confirm this security-bug EXISTS. I compiled the source of
> hyper-nuke and
> did indeed reboot some of my arcs (4.1.59-6).
>
> As others have stated I would suggest implementing accesslists on
> your routers
> that deny all telnet (tcp-25) traffic to your arcs.
>
>
> Ed Taylor wrote:
>
> > For HiperBomb code check out:
> >
> > http://www.securityfocus.com/templates/archive.pike?list=1
> >
> > It is very serious and reboots the HiperArc's from anywhere.
> >
> > Ed
> >
> > ---------- Original Message ----------------------------------
> > From: "Jamie Orzechowski" <[e-mail]>
> > Reply-To: [e-mail]
> > Date:     Fri, 13 Aug 1999 19:03:36 -0400
> >
> > >Just reading my Securityfocus email list and attacked was a new "Remote
> > HiPER ARC nuking program"
> >
> > I have the source if anyone cares to have it ...
> >
> > ----- Original Message -----
> > From: Jonathan Chapman <[e-mail]>
> > To: <[e-mail]>
> > Sent: Thursday, August 12, 1999 6:10 PM
> > Subject: 3com hiperarch flaw [hiperbomb.c]
> >
> > > Hello,
> > >
> > > The attached program will reboot a 3com HiperARC.  I made an attempt to
> > > contact 3com before posting this report, however, I received no
> response.
> > > By flooding the telnet port of a 3com HiperARC using the
> provided program,
> > > the HiperARC unconditionally reboots.  This program is
> effective over all
> > > interfaces, including a dialup.
> > >
> > > Regards,
> > >
> > > Jonathan Chapman
> > > Director of Network Security
> > > FIRST Incorporated
> > > [e-mail]  www.1st.net
> >
> > -
> >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> >  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 "[e-mail]"
> >  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.
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Rick Allan / [e-mail] | Connect to a Backbone not a Wishbone
> Head of Network Engineering    |    Monmouth Internet Corporation
> 732-842-5366=====extension 102 |      http://www.monmouth.com
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: "Ed" <[e-mail]>
Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
Date: 14 Aug 1999 02:38:35 -0400

There is a solution to that... but no true fix (outside of disabling Telnet)
until 3com fixes the code in the ARCs. It probably wouldn't hurt to also
make the code a little more robust and fix V90 too.


Ed

----- Original Message -----
Sent: Saturday, August 14, 1999 2:09 AM


But your own customers can still reboot them via dialup to that NAS.

Marshall Morgan

Internet Doorway, Inc. (aka NETDOOR)

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Rick
> Sent: Friday, August 13, 1999 10:07 PM
> To: [e-mail]
> Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
>
>
> I can confirm this security-bug EXISTS. I compiled the source of
> hyper-nuke and
> did indeed reboot some of my arcs (4.1.59-6).
>
> As others have stated I would suggest implementing accesslists on
> your routers
> that deny all telnet (tcp-25) traffic to your arcs.
>
>
> Ed Taylor wrote:
>
> > For HiperBomb code check out:
> >
> > http://www.securityfocus.com/templates/archive.pike?list=1
> >
> > It is very serious and reboots the HiperArc's from anywhere.
> >
> > Ed
> >
> > ---------- Original Message ----------------------------------
> > From: "Jamie Orzechowski" <[e-mail]>
> > Reply-To: [e-mail]
> > Date:     Fri, 13 Aug 1999 19:03:36 -0400
> >
> > >Just reading my Securityfocus email list and attacked was a new "Remote
> > HiPER ARC nuking program"
> >
> > I have the source if anyone cares to have it ...
> >
> > ----- Original Message -----
> > From: Jonathan Chapman <[e-mail]>
> > To: <[e-mail]>
> > Sent: Thursday, August 12, 1999 6:10 PM
> > Subject: 3com hiperarch flaw [hiperbomb.c]
> >
> > > Hello,
> > >
> > > The attached program will reboot a 3com HiperARC.  I made an attempt
to
> > > contact 3com before posting this report, however, I received no
> response.
> > > By flooding the telnet port of a 3com HiperARC using the
> provided program,
> > > the HiperARC unconditionally reboots.  This program is
> effective over all
> > > interfaces, including a dialup.
> > >
> > > Regards,
> > >
> > > Jonathan Chapman
> > > Director of Network Security
> > > FIRST Incorporated
> > > [e-mail]  www.1st.net
> >
> > -
> >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> >  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 "[e-mail]"
> >  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.
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Rick Allan / [e-mail] | Connect to a Backbone not a Wishbone
> Head of Network Engineering    |    Monmouth Internet Corporation
> 732-842-5366=====extension 102 |      http://www.monmouth.com
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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 "[e-mail]"
 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: Len Pikulski <[e-mail]>
Subject: (usr-tc) Need X2 keys for NMC
Date: 14 Aug 1999 03:07:26 -0400 (EDT)

Any resources would be greatly appreciated.

Thanks
<*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*>
 Len Pikulski            [e-mail]           [phone]
                      http://www.nothinbut.net


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Jamie Orzechowski" <[e-mail]>
Subject: (usr-tc) disabling telnet
Date: 14 Aug 1999 08:00:45 -0400

what is the command to disable telnet on an arc anyways??



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) disabling telnet
Date: 14 Aug 1999 08:20:12 -0400 (EDT)

Thus spake Jamie Orzechowski
>what is the command to disable telnet on an arc anyways??

disable network service telnetd

This assumes its the default named telnet service, of course.  :)

Something else you could do...to at least stop script kiddies from
getting you would be to put your telnet server on a different port
number.  Not really any real security, but the exploit program out there
is hard coded for port 23, so you can at least make them look.

add network service telnet server_type telnetd enabled yes socket xxx

should do it.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: <[e-mail]>
Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
Date: 14 Aug 1999 09:21:42 -0400 (EDT)


    Is there a way to deny access to the port, but allow only certain
IPS to telnet to it?

==============================================================================
Phillip Ferraro                WorldNet Access, Inc
[e-mail]    Onslow County's PREMIER InterNet Service
Voice [phone]            824 Gumbranch Square, Suite R3
FAX   [phone]             Jacksonville, Nc  28540-6269
==============================================================================

On Fri, 13 Aug 1999, Ed Taylor wrote:

> For HiperBomb code check out:
>
> http://www.securityfocus.com/templates/archive.pike?list=1
>
> It is very serious and reboots the HiperArc's from anywhere.
>
>
> Ed
>
>
> ---------- Original Message ----------------------------------
> From: "Jamie Orzechowski" <[e-mail]>
> Reply-To: [e-mail]
> Date:     Fri, 13 Aug 1999 19:03:36 -0400
>
> >Just reading my Securityfocus email list and attacked was a new "Remote
> HiPER ARC nuking program"
>
> I have the source if anyone cares to have it ...
>
> ----- Original Message -----
> From: Jonathan Chapman <[e-mail]>
> To: <[e-mail]>
> Sent: Thursday, August 12, 1999 6:10 PM
> Subject: 3com hiperarch flaw [hiperbomb.c]
>
>
> > Hello,
> >
> > The attached program will reboot a 3com HiperARC.  I made an attempt to
> > contact 3com before posting this report, however, I received no response.
> > By flooding the telnet port of a 3com HiperARC using the provided program,
> > the HiperARC unconditionally reboots.  This program is effective over all
> > interfaces, including a dialup.
> >
> > Regards,
> >
> > Jonathan Chapman
> > Director of Network Security
> > FIRST Incorporated
> > [e-mail]  www.1st.net
>
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
>  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 "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
Date: 14 Aug 1999 09:52:21 -0400 (EDT)

Thus spake [e-mail]
>    Is there a way to deny access to the port, but allow only certain
>IPS to telnet to it?

I *think* this would work...would need to be an input filter of
course...I *think* input filters filter data for packets destined for
the system itself.  I know IOS on cisco's doesn't do this, but I think
the HiPer Arcs do.  Keep in mind that to be sure, you'd also have to put
this filter on all your dialup interfaces as well...

I'll try to check this out in more depth today when I go to the office.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Peter <[e-mail]>
Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
Date: 14 Aug 1999 23:09:06 +0900

Jeff Mcadams <[e-mail]> wrote
> Thus spake [e-mail]
> >    Is there a way to deny access to the port, but allow only certain
> >IPS to telnet to it?

> I *think* this would work...would need to be an input filter of
> course...I *think* input filters filter data for packets destined for
> the system itself.  I know IOS on cisco's doesn't do this, but I think
> the HiPer Arcs do.  Keep in mind that to be sure, you'd also have to put
> this filter on all your dialup interfaces as well...

    cisco does, you can apply an ACL to the vty's.

    eg:

access-list 199 permit ip 10.216.0.0 0.0.0.255 any log-input
access-list 199 deny ip any any log-input

line vty 0 4
  access-group 199 in



    now, does anyone know if the anti-spoof filters in hiper
    syslog? ^^; (I dont manage them myself)


    P
    ----*

--
My words, my mail, my meaning.

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
Date: 14 Aug 1999 10:28:40 -0400 (EDT)

Thus spake Peter
>Jeff Mcadams <[e-mail]> wrote
>> Thus spake [e-mail]
>> >    Is there a way to deny access to the port, but allow only certain
>> >IPS to telnet to it?

>> I *think* this would work...would need to be an input filter of
>> course...I *think* input filters filter data for packets destined for
>> the system itself.  I know IOS on cisco's doesn't do this, but I think
>> the HiPer Arcs do.  Keep in mind that to be sure, you'd also have to put
>> this filter on all your dialup interfaces as well...

>    cisco does, you can apply an ACL to the vty's.

Well...true...but an ACL on the regular interface doesn't do it...which
was what I was implying...sorry about the non-clarity.  :)
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Tatai SV Krishnan <[e-mail]>
Subject: RE: (usr-tc) HiperARC - Dangerous HiperBomb
Date: 14 Aug 1999 00:39:36 -0500 (CDT)

The workaround for this problem is setting up telnet clients on the hiper
arc  and enabling telnet client access.  This program all it does is
tries to open tcp connections, so on the hiper arc do this

add telnet client <ip address of single host or subnet that you want to
allow access to the hiper arc via telnet>

enable telnet cli

This will tell the hiper arc to have access only from trusted hosts and
this program will not cause any crash if some one tries to use it from
different hosts.


This hower is a work around only - We do understand that this is a
serious issue and would come up with a fix.

regards

krish

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

On Sat, 14 Aug 1999, Marshall Morgan wrote:

> But your own customers can still reboot them via dialup to that NAS.
>
> Marshall Morgan
>
> Internet Doorway, Inc. (aka NETDOOR)
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Rick
> > Sent: Friday, August 13, 1999 10:07 PM
> > To: [e-mail]
> > Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
> >
> >
> > I can confirm this security-bug EXISTS. I compiled the source of
> > hyper-nuke and
> > did indeed reboot some of my arcs (4.1.59-6).
> >
> > As others have stated I would suggest implementing accesslists on
> > your routers
> > that deny all telnet (tcp-25) traffic to your arcs.
> >
> >
> > Ed Taylor wrote:
> >
> > > For HiperBomb code check out:
> > >
> > > http://www.securityfocus.com/templates/archive.pike?list=1
> > >
> > > It is very serious and reboots the HiperArc's from anywhere.
> > >
> > > Ed
> > >
> > > ---------- Original Message ----------------------------------
> > > From: "Jamie Orzechowski" <[e-mail]>
> > > Reply-To: [e-mail]
> > > Date:     Fri, 13 Aug 1999 19:03:36 -0400
> > >
> > > >Just reading my Securityfocus email list and attacked was a new "Remote
> > > HiPER ARC nuking program"
> > >
> > > I have the source if anyone cares to have it ...
> > >
> > > ----- Original Message -----
> > > From: Jonathan Chapman <[e-mail]>
> > > To: <[e-mail]>
> > > Sent: Thursday, August 12, 1999 6:10 PM
> > > Subject: 3com hiperarch flaw [hiperbomb.c]
> > >
> > > > Hello,
> > > >
> > > > The attached program will reboot a 3com HiperARC.  I made an attempt to
> > > > contact 3com before posting this report, however, I received no
> > response.
> > > > By flooding the telnet port of a 3com HiperARC using the
> > provided program,
> > > > the HiperARC unconditionally reboots.  This program is
> > effective over all
> > > > interfaces, including a dialup.
> > > >
> > > > Regards,
> > > >
> > > > Jonathan Chapman
> > > > Director of Network Security
> > > > FIRST Incorporated
> > > > [e-mail]  www.1st.net
> > >
> > > -
> > >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> > >  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 "[e-mail]"
> > >  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.
> >
> > --
> > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > Rick Allan / [e-mail] | Connect to a Backbone not a Wishbone
> > Head of Network Engineering    |    Monmouth Internet Corporation
> > 732-842-5366=====extension 102 |      http://www.monmouth.com
> > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> >
> >
> >
> > -
> >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> >  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 "[e-mail]"
>  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 "[e-mail]"
 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: Tatai SV Krishnan <[e-mail]>
Subject: Re: (usr-tc) Need X2 keys for NMC
Date: 14 Aug 1999 00:41:06 -0500 (CDT)

Just call support and ask for the same - It should be quite easy to get
it.  If you have problems let me know.

krish

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

On Sat, 14 Aug 1999, Len Pikulski wrote:

> Any resources would be greatly appreciated.
>
> Thanks
> <*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*>
>  Len Pikulski            [e-mail]           [phone]
>                       http://www.nothinbut.net
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: Tatai SV Krishnan <[e-mail]>
Subject: Re: (usr-tc) disabling telnet
Date: 14 Aug 1999 00:42:49 -0500 (CDT)

On Sat, 14 Aug 1999, Jamie Orzechowski wrote:

> what is the command to disable telnet on an arc anyways??

Telnet is a deamon service on the hiper arc - you will have to disable
the network service telnetd - you can always create another service on a
different port  if you want.

However if the question is to just avoid being hiperbombed, just add
telnet clients and enable telnet client access - for now.

krish

>
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
Date: 14 Aug 1999 14:00:22 -0400 (EDT)

Thus spake Tatai SV Krishnan
>add telnet client <ip address of single host or subnet that you want to
>allow access to the hiper arc via telnet>

>enable telnet cli

wow...learn something new every day.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Brian M. Gordon" <[e-mail]>
Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
Date: 14 Aug 1999 18:26:47 -0400

How would I add a range of ips?

----- Original Message -----
Cc: <[e-mail]>
Sent: Saturday, August 14, 1999 1:39 AM


> The workaround for this problem is setting up telnet clients on the hiper
> arc  and enabling telnet client access.  This program all it does is
> tries to open tcp connections, so on the hiper arc do this
>
> add telnet client <ip address of single host or subnet that you want to
> allow access to the hiper arc via telnet>
>
> enable telnet cli
>
> This will tell the hiper arc to have access only from trusted hosts and
> this program will not cause any crash if some one tries to use it from
> different hosts.
>
>
> This hower is a work around only - We do understand that this is a
> serious issue and would come up with a fix.
>
> regards
>
> krish
>
> -----------------------------------------
> \ T.S.V. Krishnan  \
> \      Network System Engineer \ ( : - : )
>   \     3Com ............   \
> ----------------------------------------------/
> [e-mail]
> ----------------------------/ http://interproc.ae.usr.com ----/
> -------------------------------------------------------------------------\
> Any Sufficiently advanced bug is indistinguishable for a feature.
> - Rick Kulawiec
> -------------------------------------------------------------------------/
>
> On Sat, 14 Aug 1999, Marshall Morgan wrote:
>
> > But your own customers can still reboot them via dialup to that NAS.
> >
> > Marshall Morgan
> >
> > Internet Doorway, Inc. (aka NETDOOR)
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]]On Behalf Of Rick
> > > Sent: Friday, August 13, 1999 10:07 PM
> > > To: [e-mail]
> > > Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
> > >
> > >
> > > I can confirm this security-bug EXISTS. I compiled the source of
> > > hyper-nuke and
> > > did indeed reboot some of my arcs (4.1.59-6).
> > >
> > > As others have stated I would suggest implementing accesslists on
> > > your routers
> > > that deny all telnet (tcp-25) traffic to your arcs.
> > >
> > >
> > > Ed Taylor wrote:
> > >
> > > > For HiperBomb code check out:
> > > >
> > > > http://www.securityfocus.com/templates/archive.pike?list=1
> > > >
> > > > It is very serious and reboots the HiperArc's from anywhere.
> > > >
> > > > Ed
> > > >
> > > > ---------- Original Message ----------------------------------
> > > > From: "Jamie Orzechowski" <[e-mail]>
> > > > Reply-To: [e-mail]
> > > > Date:     Fri, 13 Aug 1999 19:03:36 -0400
> > > >
> > > > >Just reading my Securityfocus email list and attacked was a new
"Remote
> > > > HiPER ARC nuking program"
> > > >
> > > > I have the source if anyone cares to have it ...
> > > >
> > > > ----- Original Message -----
> > > > From: Jonathan Chapman <[e-mail]>
> > > > To: <[e-mail]>
> > > > Sent: Thursday, August 12, 1999 6:10 PM
> > > > Subject: 3com hiperarch flaw [hiperbomb.c]
> > > >
> > > > > Hello,
> > > > >
> > > > > The attached program will reboot a 3com HiperARC.  I made an
attempt to
> > > > > contact 3com before posting this report, however, I received no
> > > response.
> > > > > By flooding the telnet port of a 3com HiperARC using the
> > > provided program,
> > > > > the HiperARC unconditionally reboots.  This program is
> > > effective over all
> > > > > interfaces, including a dialup.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Jonathan Chapman
> > > > > Director of Network Security
> > > > > FIRST Incorporated
> > > > > [e-mail]  www.1st.net
> > > >
> > > > -
> > > >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> > > >  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 "[e-mail]"
> > > >  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.
> > >
> > > --
> > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > > Rick Allan / [e-mail] | Connect to a Backbone not a Wishbone
> > > Head of Network Engineering    |    Monmouth Internet Corporation
> > > 732-842-5366=====extension 102 |      http://www.monmouth.com
> > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > >
> > >
> > >
> > > -
> > >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> > >  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 "[e-mail]"
> >  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 "[e-mail]"
>  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 "[e-mail]"
 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: "Jamie Orzechowski" <[e-mail]>
Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
Date: 14 Aug 1999 21:28:17 -0400

I did a disable telnet client_access but I can still telnet in after I do
this???


----- Original Message -----
Sent: Saturday, August 14, 1999 2:00 PM


> Thus spake Tatai SV Krishnan
> >add telnet client <ip address of single host or subnet that you want to
> >allow access to the hiper arc via telnet>
>
> >enable telnet cli
>
> wow...learn something new every day.
> --
> Jeff McAdams                            Email: [e-mail]
> Head Network Administrator              Voice: [phone]
> IgLou Internet Services                        [phone]
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: "Brian M. Gordon" <[e-mail]>
Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
Date: 14 Aug 1999 22:15:05 -0400

enable not disable.

----- Original Message -----
Sent: Saturday, August 14, 1999 9:28 PM


> I did a disable telnet client_access but I can still telnet in after I do
> this???
>
>
> ----- Original Message -----
> From: Jeff Mcadams <[e-mail]>
> To: <[e-mail]>
> Sent: Saturday, August 14, 1999 2:00 PM
> Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
>
>
> > Thus spake Tatai SV Krishnan
> > >add telnet client <ip address of single host or subnet that you want to
> > >allow access to the hiper arc via telnet>
> >
> > >enable telnet cli
> >
> > wow...learn something new every day.
> > --
> > Jeff McAdams                            Email: [e-mail]
> > Head Network Administrator              Voice: [phone]
> > IgLou Internet Services                        [phone]
> >
> > -
> >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> >  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 "[e-mail]"
>  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 "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
Date: 14 Aug 1999 23:22:39 -0400 (EDT)

Thus spake Jamie Orzechowski
>I did a disable telnet client_access but I can still telnet in after I do
>this???

You need to enable it, not disable.  this is basically the setting that
tells the telnet service to check the client access table to check to
see if that system is allowed to check...if you disable this setting, it
doesn't check the table and assumes everyone is allowed to connect.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Tatai SV Krishnan <[e-mail]>
Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
Date: 14 Aug 1999 21:35:31 -0500 (CDT)

On Sat, 14 Aug 1999, Brian M. Gordon wrote:

> How would I add a range of ips?
>
Individual hosts

add telnet client <ip address>
...
...

A subnet of address

add telnet client ip address netmask
add telnet client 10.10.0.0/24

...
..
etc


krish


> ----- Original Message -----
> From: Tatai SV Krishnan <[e-mail]>
> To: Marshall Morgan <[e-mail]>
> Cc: <[e-mail]>
> Sent: Saturday, August 14, 1999 1:39 AM
> Subject: RE: (usr-tc) HiperARC - Dangerous HiperBomb
>
>
> > The workaround for this problem is setting up telnet clients on the hiper
> > arc  and enabling telnet client access.  This program all it does is
> > tries to open tcp connections, so on the hiper arc do this
> >
> > add telnet client <ip address of single host or subnet that you want to
> > allow access to the hiper arc via telnet>
> >
> > enable telnet cli
> >
> > This will tell the hiper arc to have access only from trusted hosts and
> > this program will not cause any crash if some one tries to use it from
> > different hosts.
> >
> >
> > This hower is a work around only - We do understand that this is a
> > serious issue and would come up with a fix.
> >
> > regards
> >
> > krish
> >
> > -----------------------------------------
> > \ T.S.V. Krishnan  \
> > \      Network System Engineer \ ( : - : )
> >   \     3Com ............   \
> > ----------------------------------------------/
> > [e-mail]
> > ----------------------------/ http://interproc.ae.usr.com ----/
> > -------------------------------------------------------------------------\
> > Any Sufficiently advanced bug is indistinguishable for a feature.
> > - Rick Kulawiec
> > -------------------------------------------------------------------------/
> >
> > On Sat, 14 Aug 1999, Marshall Morgan wrote:
> >
> > > But your own customers can still reboot them via dialup to that NAS.
> > >
> > > Marshall Morgan
> > >
> > > Internet Doorway, Inc. (aka NETDOOR)
> > >
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > > [mailto:[e-mail]]On Behalf Of Rick
> > > > Sent: Friday, August 13, 1999 10:07 PM
> > > > To: [e-mail]
> > > > Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
> > > >
> > > >
> > > > I can confirm this security-bug EXISTS. I compiled the source of
> > > > hyper-nuke and
> > > > did indeed reboot some of my arcs (4.1.59-6).
> > > >
> > > > As others have stated I would suggest implementing accesslists on
> > > > your routers
> > > > that deny all telnet (tcp-25) traffic to your arcs.
> > > >
> > > >
> > > > Ed Taylor wrote:
> > > >
> > > > > For HiperBomb code check out:
> > > > >
> > > > > http://www.securityfocus.com/templates/archive.pike?list=1
> > > > >
> > > > > It is very serious and reboots the HiperArc's from anywhere.
> > > > >
> > > > > Ed
> > > > >
> > > > > ---------- Original Message ----------------------------------
> > > > > From: "Jamie Orzechowski" <[e-mail]>
> > > > > Reply-To: [e-mail]
> > > > > Date:     Fri, 13 Aug 1999 19:03:36 -0400
> > > > >
> > > > > >Just reading my Securityfocus email list and attacked was a new
> "Remote
> > > > > HiPER ARC nuking program"
> > > > >
> > > > > I have the source if anyone cares to have it ...
> > > > >
> > > > > ----- Original Message -----
> > > > > From: Jonathan Chapman <[e-mail]>
> > > > > To: <[e-mail]>
> > > > > Sent: Thursday, August 12, 1999 6:10 PM
> > > > > Subject: 3com hiperarch flaw [hiperbomb.c]
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > The attached program will reboot a 3com HiperARC.  I made an
> attempt to
> > > > > > contact 3com before posting this report, however, I received no
> > > > response.
> > > > > > By flooding the telnet port of a 3com HiperARC using the
> > > > provided program,
> > > > > > the HiperARC unconditionally reboots.  This program is
> > > > effective over all
> > > > > > interfaces, including a dialup.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Jonathan Chapman
> > > > > > Director of Network Security
> > > > > > FIRST Incorporated
> > > > > > [e-mail]  www.1st.net
> > > > >
> > > > > -
> > > > >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> > > > >  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 "[e-mail]"
> > > > >  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.
> > > >
> > > > --
> > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > > > Rick Allan / [e-mail] | Connect to a Backbone not a Wishbone
> > > > Head of Network Engineering    |    Monmouth Internet Corporation
> > > > 732-842-5366=====extension 102 |      http://www.monmouth.com
> > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > > >
> > > >
> > > >
> > > > -
> > > >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> > > >  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 "[e-mail]"
> > >  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 "[e-mail]"
> >  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 "[e-mail]"
>  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 "[e-mail]"
 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: Tatai SV Krishnan <[e-mail]>
Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
Date: 14 Aug 1999 21:40:23 -0500 (CDT)

Here is the steps.

Add the telnet client <ip>
then
enable telnet client_access

if you disable the same you will be able to telnet into the hiper arc.

krish

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

On Sat, 14 Aug 1999, Jamie Orzechowski wrote:

> I did a disable telnet client_access but I can still telnet in after I do
> this???
>
>
> ----- Original Message -----
> From: Jeff Mcadams <[e-mail]>
> To: <[e-mail]>
> Sent: Saturday, August 14, 1999 2:00 PM
> Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
>
>
> > Thus spake Tatai SV Krishnan
> > >add telnet client <ip address of single host or subnet that you want to
> > >allow access to the hiper arc via telnet>
> >
> > >enable telnet cli
> >
> > wow...learn something new every day.
> > --
> > Jeff McAdams                            Email: [e-mail]
> > Head Network Administrator              Voice: [phone]
> > IgLou Internet Services                        [phone]
> >
> > -
> >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> >  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 "[e-mail]"
>  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 "[e-mail]"
 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: Dale Hege <[e-mail]>
Subject: (usr-tc) Link dead after 8 Days
Date: 15 Aug 1999 11:10:00 -0400 (EDT)


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 "[e-mail]"
 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: "Howard Reeves" <[e-mail]>
Subject: (usr-tc) Security and Accounting Server vs. SAM questions
Date: 15 Aug 1999 11:45:09 -0500

I am trying to decide whether to enter my users in the Security and
Accounting database or to proxy against the NT database.

I am currently entering the username in both NT and S&A and using the NT
password. I did this because my only server at the time had been setup as a
standalone server instead of a PDC so I could not proxy to the NT database.
Also, I use NT Mail and by using the NT database, NT Mail could authenicate
against the NT database.

I am now adding an additional server that has been setup as a PDC. I plan to
reconfigure the standalone server as a BDC when I have the new server up and
running. This is why I am currently contemplating this question. I want to
make the best decision that I can so that it works now and in the future as
I add to the network. I do not want to just do what is easiest right now.
However, I can not afford to invest in new RADIUS software at this time
which is what I would probably really like to do, and do not now enough
about Liniux to switch which is what I would probably really really like to
do.

My reasons for wanting to use NT database.

1. NT Mail can authenicate against NT database reducing the amount of setup
required for each user.

2. Can remotely administer username and passwords with web interface.

3. Can operate a back up server.

My reasons for not wanting to use NT database.

1. I have no way that I know of to print information about users i.e.
username, Name, Address, Telephone Number, etc.

2. No way to limit concurrent users.

3. Concerns about the security of using NT database.

My reasons for wanting to use S&A

1. Can print information about users from access reports.

2. Supposedly can limit concurrent users.

3. Believe that it is more secure than using NT database.

My reasons for not wanting to use S&A

1. Can not administer user names and passwords through a web interface.

2. Not sure if I can operate a backup server.

3. Do not know how to set NT Mail to authenicate against S&A database. I
believe that it can be done with a DLL file, but I have not found any
documentation to explain how to do it.

I am very open to any ideas or suggestion that anyone might have including
other RADIUS software that might meet my needs. Any help will be
appreciated.

Howard Reeves
[e-mail]




-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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" <[e-mail]>
Subject: Re: (usr-tc) Link dead after 8 Days
Date: 15 Aug 1999 20:11:54 -0500

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 -----
Sent: Sunday, August 15, 1999 10:10 AM


>
> 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 "[e-mail]"
>  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 "[e-mail]"
 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: K Mitchell <[e-mail]>
Subject: Re: (usr-tc) Link dead after 8 Days
Date: 15 Aug 1999 22:18:51 -0400

At 08:11 PM 8/15/99 -0500, you wrote:
>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.

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        [e-mail]
Keystone Connect                     Unlock Your World
Altoona, PA   814-941-5000      http://www.keyconn.net


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Tatai SV Krishnan <[e-mail]>
Subject: Re: (usr-tc) Link dead after 8 Days
Date: 15 Aug 1999 10:25:32 -0500 (CDT)

On Sun, 15 Aug 1999, K Mitchell wrote:

> At 08:11 PM 8/15/99 -0500, you wrote:
> >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

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.

> >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.
>
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


> 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        [e-mail]
> Keystone Connect                     Unlock Your World
> Altoona, PA   814-941-5000      http://www.keyconn.net
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: "Jamie Orzechowski" <[e-mail]>
Subject: (usr-tc) stalling
Date: 16 Aug 1999 07:01:09 -0400

Many of our users seem to be having a "stalling" problem.

They will be going fine and all of the sudden there is a 2 minute stop.
They are not disconnected ... they bytes in/out just stop ... then 2 minutes
later it picks up again and everything is fine ... then another stoppage at
a random time ...

any ideas??

DSP -> 2.0.70
ARC -> 4.2.29




-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Tatai SV Krishnan <[e-mail]>
Subject: Re: (usr-tc) stalling
Date: 15 Aug 1999 19:25:56 -0500 (CDT)

On Mon, 16 Aug 1999, Jamie Orzechowski wrote:

> Many of our users seem to be having a "stalling" problem.
>
> They will be going fine and all of the sudden there is a 2 minute stop.
> They are not disconnected ... they bytes in/out just stop ... then 2 minutes
> later it picks up again and everything is fine ... then another stoppage at
> a random time ...
>
> any ideas??
>
> DSP -> 2.0.70
> ARC -> 4.2.29
^^^^^^^^^^^^^^^  This code is not very stable - One of the reason it is
locked in totalservice.  I would recommend not to use and wait for the
new release of 4.2.x code. If you still want to debug it do a mon ppp on
the user and get the trace - we can see what is happening.

krish


>
>
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: Kevin Benton <[e-mail]>
Subject: RE: (usr-tc) HiperARC - Dangerous HiperBomb
Date: 16 Aug 1999 10:23:25 -0400 (EDT)

On Sat, 14 Aug 1999, Tatai SV Krishnan wrote:

> The workaround for this problem is setting up telnet clients on the hiper
> arc  and enabling telnet client access.  This program all it does is
> tries to open tcp connections, so on the hiper arc do this
>
> add telnet client <ip address of single host or subnet that you want to
> allow access to the hiper arc via telnet>
>
> enable telnet cli
>
> This will tell the hiper arc to have access only from trusted hosts and
> this program will not cause any crash if some one tries to use it from
> different hosts.
>
>
> This hower is a work around only - We do understand that this is a
> serious issue and would come up with a fix.

This is a bit more than slightly irritating.  I just got back from
vacation and found this message here and saw that the WeeklyService Update
did not include any field service reports or any warnings about the fact
that this *known* bug has been found.  As far as I'm concerned, this
should have been posted on CERT.

Kevin Benton
SOTA Technologies


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
Date: 16 Aug 1999 10:30:32 -0400 (EDT)

Thus spake Kevin Benton
>This is a bit more than slightly irritating.  I just got back from
>vacation and found this message here and saw that the WeeklyService Update
>did not include any field service reports or any warnings about the fact
>that this *known* bug has been found.  As far as I'm concerned, this
>should have been posted on CERT.

Heh...who's to say that it won't be....with CERT's blisteringly fast
response time </sarcasm> they may come out with an alert 6 weeks from
now.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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" <[e-mail]>
Subject: Re: (usr-tc) Link dead after 8 Days
Date: 16 Aug 1999 11:33:00 -0500

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 -----
Cc: <[e-mail]>
Sent: Sunday, August 15, 1999 10:25 AM


>


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Tatai SV Krishnan <[e-mail]>
Subject: Re: (usr-tc) Link dead after 8 Days
Date: 15 Aug 1999 23:29:43 -0500 (CDT)


On Mon, 16 Aug 1999, Sam Lowe wrote:

> 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.
>
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.

> 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.
>
I would be more than willing to call you but the above phone number is
not correct.
Send me the correct the number.

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

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Ken Kirchner <[e-mail]>
Subject: Re: (usr-tc) Link dead after 8 Days
Date: 16 Aug 1999 12:31:22 -0500 (CDT)

On Sun, 15 Aug 1999, Tatai SV Krishnan wrote:

> > 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.
> >
> 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.

> > 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.

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. :)

> > 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.

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

> > 4.  We have implemented the  MTU change.  If Krish can contact me
> > (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:[e-mail]       (___)
  (__) Asst SysAdmin       .o.  Voice [phone] Ext 108 (__)
   (_) ShreveNet, Inc.     .o.  Fax   [phone]         (_)


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Tatai SV Krishnan <[e-mail]>
Subject: Re: (usr-tc) Link dead after 8 Days
Date: 16 Aug 1999 01:40:58 -0500 (CDT)

On Mon, 16 Aug 1999, Ken Kirchner wrote:

>
> 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.
>

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.

> > > 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.
>
> 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. :)
>
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.


> > > 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.
>
> Well, thankfully Krish is here now.  I hope we can give him something to
> work with.
>
> > > 4.  We have implemented the  MTU change.  If Krish can contact me
> > > (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?)
>
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



>   ___                                                         ___
>  (___) Kenneth Kirchner    .o.  mailto:[e-mail]       (___)
>   (__) Asst SysAdmin       .o.  Voice [phone] Ext 108 (__)
>    (_) ShreveNet, Inc.     .o.  Fax   [phone]         (_)
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: Aaron Nabil <[e-mail]>
Subject: Re: (usr-tc) stalling
Date: 16 Aug 1999 11:59:11 -0700 (PDT)

Jamie Orzechowski writes...
>Many of our users seem to be having a "stalling" problem.
>
>They will be going fine and all of the sudden there is a 2 minute stop.
>They are not disconnected ... they bytes in/out just stop ... then 2 minutes
>later it picks up again and everything is fine ... then another stoppage at
>a random time ...
>
>any ideas??

Routing problem in your network, RIP holddown timers, etc.


--
Aaron Nabil

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Stainforth, Matthew" <[e-mail]>
Subject: (usr-tc) simple question
Date: 16 Aug 1999 16:31:34 -0300


Ok, at the risk of sounding stupid, how do I change the NMC community names
from TCM and make them stick?  I have tried changing them in the Security,
Community Names box and telling the NMC to Save Chassis to NVRAM but they
always go back to the previous values for some reason.  I have always done
this with the CLI before installing the chassis but, in this case, I want to
avoid the 3 hour drive if possible.  I had a quick look on 3KB and the TCM
guide and nothing jumped out at me...

Thanks,

Matthew...

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Scott Trautman <[e-mail]>
Subject: (usr-tc) Perhaps another simple question - HiperARC initial configuration/
Date: 16 Aug 1999 14:58:47 -0500

I just got 3 new HiperARC's. Yippee for me.

My means of configuring them is usually to put the console cable on and
configure from there.
And I've done several other ARC's this way.

This batch, however, I am getting as far as PROM vers 1.16 made June 16
1998..., Loading System .....OK
and that's the last I see---

So I'm rather stuck. Per my NMC, it does load okay (all green), yet I can't
get into it to set anything.
Tried the usual disconnect, reconnect to the comm port, nope
Tried the also usual Control-C,D,X,[,] for some kind of breakout

Nothing...nada....NMC says it's all good, but no more console output or
input happening...

Any ideas? I'm hoping it's just as stupid a problem as I feel.
Short work once I'm in....

SMT






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 "[e-mail]"
 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: "Eric Billeter" <[e-mail]>
Subject: RE: (usr-tc) simple question
Date: 16 Aug 1999 13:02:36 -0700

Make your changes
Highlight NMC
Actions
Save UI to EEPROM

Eric Billeter
Internet Engineer
Cable One, Inc.

[e-mail]
602-364-6462
-----Original Message-----
[mailto:[e-mail]]On Behalf Of Stainforth, Matthew
Sent: Monday, August 16, 1999 12:32 PM



Ok, at the risk of sounding stupid, how do I change the NMC community names
from TCM and make them stick?  I have tried changing them in the Security,
Community Names box and telling the NMC to Save Chassis to NVRAM but they
always go back to the previous values for some reason.  I have always done
this with the CLI before installing the chassis but, in this case, I want to
avoid the 3 hour drive if possible.  I had a quick look on 3KB and the TCM
guide and nothing jumped out at me...

Thanks,

Matthew...

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 "[e-mail]"
 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: Mike Andrews <[e-mail]>
Subject: Re: (usr-tc) Perhaps another simple question - HiperARC initial
Date: 16 Aug 1999 16:06:47 -0400 (EDT)

Turn on dip switch 6, especially if you made your own serial cable...


Mike Andrews (MA12) -=-=-  VP & Sysadmin, Digital Crescent, Frankfort KY
[e-mail]  -=--=-  [e-mail]  -=--=-  http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."

On Mon, 16 Aug 1999, Scott Trautman wrote:

> I just got 3 new HiperARC's. Yippee for me.
>
> My means of configuring them is usually to put the console cable on and
> configure from there.
> And I've done several other ARC's this way.
>
> This batch, however, I am getting as far as PROM vers 1.16 made June 16
> 1998..., Loading System .....OK
> and that's the last I see---
>
> So I'm rather stuck. Per my NMC, it does load okay (all green), yet I can't
> get into it to set anything.
> Tried the usual disconnect, reconnect to the comm port, nope
> Tried the also usual Control-C,D,X,[,] for some kind of breakout
>
> Nothing...nada....NMC says it's all good, but no more console output or
> input happening...
>
> Any ideas? I'm hoping it's just as stupid a problem as I feel.
> Short work once I'm in....
>
> SMT
>
>
>
>
>
>
> 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 "[e-mail]"
>  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 "[e-mail]"
 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: Mike Andrews <[e-mail]>
Subject: Re: (usr-tc) Perhaps another simple question - HiperARC initial
Date: 16 Aug 1999 16:10:03 -0400 (EDT)

Ooops.  Make that Dip Switch *5*.  Not 6.

Dip Switch 5 overrides the need for things like carrier detect on the
cable.  We cooked up custom cables on ours (so we could hook them to a
terminal server for reverse telnet) and ran into this on ARC 4.1.x
releases.  Your other ARCs were probably set up with 4.0.x software which
didn't care.


Mike Andrews (MA12) -=-=-  VP & Sysadmin, Digital Crescent, Frankfort KY
[e-mail]  -=--=-  [e-mail]  -=--=-  http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."

On Mon, 16 Aug 1999, Mike Andrews wrote:

> Turn on dip switch 6, especially if you made your own serial cable...
>
> On Mon, 16 Aug 1999, Scott Trautman wrote:
>
> > I just got 3 new HiperARC's. Yippee for me.
> >
> > My means of configuring them is usually to put the console cable on and
> > configure from there.
> > And I've done several other ARC's this way.
> >
> > This batch, however, I am getting as far as PROM vers 1.16 made June 16
> > 1998..., Loading System .....OK
> > and that's the last I see---
> >
> > So I'm rather stuck. Per my NMC, it does load okay (all green), yet I can't
> > get into it to set anything.
> > Tried the usual disconnect, reconnect to the comm port, nope
> > Tried the also usual Control-C,D,X,[,] for some kind of breakout
> >
> > Nothing...nada....NMC says it's all good, but no more console output or
> > input happening...
> >
> > Any ideas? I'm hoping it's just as stupid a problem as I feel.
> > Short work once I'm in....
> >
> > SMT
> >
> >
> >
> >
> >
> >
> > 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 "[e-mail]"
> >  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 "[e-mail]"
 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: Scott Trautman <[e-mail]>
Subject: RE: (usr-tc) Perhaps another simple question - HiperARC initial c
Date: 16 Aug 1999 15:39:19 -0500

You are godlike. That did the trick. DS 5 is the one!

SMT

-----Original Message-----
Sent: Monday, August 16, 1999 3:10 PM
configuration/ console cable


Ooops.  Make that Dip Switch *5*.  Not 6.

Dip Switch 5 overrides the need for things like carrier detect on the
cable.  We cooked up custom cables on ours (so we could hook them to a
terminal server for reverse telnet) and ran into this on ARC 4.1.x
releases.  Your other ARCs were probably set up with 4.0.x software which
didn't care.


Mike Andrews (MA12) -=-=-  VP & Sysadmin, Digital Crescent, Frankfort KY
[e-mail]  -=--=-  [e-mail]  -=--=-  http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."

On Mon, 16 Aug 1999, Mike Andrews wrote:

> Turn on dip switch 6, especially if you made your own serial cable...
>
> On Mon, 16 Aug 1999, Scott Trautman wrote:
>
> > I just got 3 new HiperARC's. Yippee for me.
> >
> > My means of configuring them is usually to put the console cable on and
> > configure from there.
> > And I've done several other ARC's this way.
> >
> > This batch, however, I am getting as far as PROM vers 1.16 made June 16
> > 1998..., Loading System .....OK
> > and that's the last I see---
> >
> > So I'm rather stuck. Per my NMC, it does load okay (all green), yet I
can't
> > get into it to set anything.
> > Tried the usual disconnect, reconnect to the comm port, nope
> > Tried the also usual Control-C,D,X,[,] for some kind of breakout
> >
> > Nothing...nada....NMC says it's all good, but no more console output or
> > input happening...
> >
> > Any ideas? I'm hoping it's just as stupid a problem as I feel.
> > Short work once I'm in....
> >
> > SMT
> >
> >
> >
> >
> >
> >
> > 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 "[e-mail]"
> >  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 "[e-mail]"
 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 "[e-mail]"
 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: Marty Elliott <[e-mail]>
Subject: RE: (usr-tc) Perhaps another simple question - HiperARC
Date: 16 Aug 1999 13:52:31 -0700

Scott -- as the vendor, I'm glad to see the cards are OK!  Just got a
shipment from 3Com that's the wrong cards and they are blaming me.  Of
course they forgot the fact that they told me the p/n to order!  Much
better support on the list than from 3Com!

Thanks for the business!

Regards,

Marty





At 03:39 PM 8/16/99 -0500, you wrote:
>You are godlike. That did the trick. DS 5 is the one!
>
>SMT
>
>-----Original Message-----
>From: Mike Andrews [mailto:[e-mail]]
>Sent: Monday, August 16, 1999 3:10 PM
>To: [e-mail]
>Subject: Re: (usr-tc) Perhaps another simple question - HiperARC initial
>configuration/ console cable
>
>
>Ooops.  Make that Dip Switch *5*.  Not 6.
>
>Dip Switch 5 overrides the need for things like carrier detect on the
>cable.  We cooked up custom cables on ours (so we could hook them to a
>terminal server for reverse telnet) and ran into this on ARC 4.1.x
>releases.  Your other ARCs were probably set up with 4.0.x software which
>didn't care.
>
>
>Mike Andrews (MA12) -=-=-  VP & Sysadmin, Digital Crescent, Frankfort KY
>[e-mail]  -=--=-  [e-mail]  -=--=-  http://www.bit0.com
>"If you're not part of the solution.... you're part of the precipitate."
>
>On Mon, 16 Aug 1999, Mike Andrews wrote:
>
>> Turn on dip switch 6, especially if you made your own serial cable...
>>
>> On Mon, 16 Aug 1999, Scott Trautman wrote:
>>
>> > I just got 3 new HiperARC's. Yippee for me.
>> >
>> > My means of configuring them is usually to put the console cable on and
>> > configure from there.
>> > And I've done several other ARC's this way.
>> >
>> > This batch, however, I am getting as far as PROM vers 1.16 made June 16
>> > 1998..., Loading System .....OK
>> > and that's the last I see---
>> >
>> > So I'm rather stuck. Per my NMC, it does load okay (all green), yet I
>can't
>> > get into it to set anything.
>> > Tried the usual disconnect, reconnect to the comm port, nope
>> > Tried the also usual Control-C,D,X,[,] for some kind of breakout
>> >
>> > Nothing...nada....NMC says it's all good, but no more console output or
>> > input happening...
>> >
>> > Any ideas? I'm hoping it's just as stupid a problem as I feel.
>> > Short work once I'm in....
>> >
>> > SMT
>> >
>> >
>> >
>> >
>> >
>> >
>> > 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 "[e-mail]"
>> >  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 "[e-mail]"
> 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 "[e-mail]"
> 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 "[e-mail]"
 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: "Jamie Orzechowski" <[e-mail]>
Subject: (usr-tc) 2 ARC's - one chassis
Date: 16 Aug 1999 17:06:59 -0400

Could someone please give me a config to setup load balancing between 2
arc's

I will have 14 DSP's in one chassis with 2 ARC's controlling them.




-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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" <[e-mail]>
Subject: Re: (usr-tc) Link dead after 8 Days
Date: 16 Aug 1999 16:23:00 -0500

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
[e-mail]


----- Original Message -----
Cc: <[e-mail]>
Sent: Sunday, August 15, 1999 11:29 PM


>
> On Mon, 16 Aug 1999, Sam Lowe wrote:
>
> > 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.
> >
> 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.
>
> > 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.
> >
> I would be more than willing to call you but the above phone number is
> not correct.
> Send me the correct the number.
>
> krish
> >
> >
> > ----- Original Message -----
> > From: Tatai SV Krishnan <[e-mail]>
> > To: K Mitchell <[e-mail]>
> > Cc: <[e-mail]>
> > Sent: Sunday, August 15, 1999 10:25 AM
> > Subject: Re: (usr-tc) Link dead after 8 Days
> >
> >
> > >
> >
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: Blake Fithen <[e-mail]>
Subject: RE: (usr-tc) Link dead after 8 Days
Date: 16 Aug 1999 16:57:33 -0500

Identical problems here with PRI's from Southwestern Bell and
KMC Telecom. On a fully loaded chassis/one ARC two PS's Running
DSP 1.2.5,1.2.59 and ARC 4.1.59.  Started about a month ago and
it's really pissing customers off.  We can't find any patterns
of failure.

blake


> -----Original Message-----
> From: Clint R. Sparks [mailto:[e-mail]]
> Sent: Monday, August 16, 1999 4:23 PM
> To: [e-mail]
> Subject: Re: (usr-tc) Link dead after 8 Days
>
>
> 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
> [e-mail]
>
>
> ----- Original Message -----
> From: Tatai SV Krishnan <[e-mail]>
> To: Sam Lowe <[e-mail]>
> Cc: <[e-mail]>
> Sent: Sunday, August 15, 1999 11:29 PM
> Subject: Re: (usr-tc) Link dead after 8 Days
>
>
> >
> > On Mon, 16 Aug 1999, Sam Lowe wrote:
> >
> > > 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.
> > >
> > 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.
> >
> > > 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.
> > >
> > I would be more than willing to call you but the above
> phone number is
> > not correct.
> > Send me the correct the number.
> >
> > krish
> > >
> > >
> > > ----- Original Message -----
> > > From: Tatai SV Krishnan <[e-mail]>
> > > To: K Mitchell <[e-mail]>
> > > Cc: <[e-mail]>
> > > Sent: Sunday, August 15, 1999 10:25 AM
> > > Subject: Re: (usr-tc) Link dead after 8 Days
> > >
> > >
> > > >
> > >
> >
> > -
> >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> >  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 "[e-mail]"
>  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 "[e-mail]"
 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: Ken Kirchner <[e-mail]>
Subject: Re: (usr-tc) Link dead after 8 Days
Date: 16 Aug 1999 17:00:55 -0500 (CDT)

On Mon, 16 Aug 1999, Tatai SV Krishnan wrote:

> 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.

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.

> 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.

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.

> > 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?)
> >
> So the problem is there irrespective of compression enabled or not correct?

Yes, I believe that to be the case.

> 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.

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.

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

I will definately keep you posted.

-Ken
  ___                                                         ___
 (___) Kenneth Kirchner    .o.  mailto:[e-mail]       (___)
  (__) Asst SysAdmin       .o.  Voice [phone] Ext 108 (__)
   (_) ShreveNet, Inc.     .o.  Fax   [phone]         (_)


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Ken Kirchner <[e-mail]>
Subject: RE: (usr-tc) Link dead after 8 Days
Date: 16 Aug 1999 17:03:44 -0500 (CDT)

On Mon, 16 Aug 1999, Blake Fithen wrote:

> Identical problems here with PRI's from Southwestern Bell and
> KMC Telecom. On a fully loaded chassis/one ARC two PS's Running
> DSP 1.2.5,1.2.59 and ARC 4.1.59.  Started about a month ago and
> it's really pissing customers off.  We can't find any patterns
> of failure.
>
> blake

When our modems act stupid we re-software download, followed by a hard
reset.  This brings the majority of problems to a halt. FWIW
  ___                                                         ___
 (___) Kenneth Kirchner    .o.  mailto:[e-mail]       (___)
  (__) Asst SysAdmin       .o.  Voice [phone] Ext 108 (__)
   (_) ShreveNet, Inc.     .o.  Fax   [phone]         (_)


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Tatai SV Krishnan <[e-mail]>
Subject: Re: (usr-tc) Link dead after 8 Days
Date: 16 Aug 1999 10:23:09 -0500 (CDT)

On Mon, 16 Aug 1999, Clint R. Sparks wrote:

> 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?
>

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

> Any insight you can give would be appreciated.
>
> Thank you,
>
> Clint R. Sparks
> ComQuest Internet Services
> [e-mail]
>
>
> ----- Original Message -----
> From: Tatai SV Krishnan <[e-mail]>
> To: Sam Lowe <[e-mail]>
> Cc: <[e-mail]>
> Sent: Sunday, August 15, 1999 11:29 PM
> Subject: Re: (usr-tc) Link dead after 8 Days
>
>
> >
> > On Mon, 16 Aug 1999, Sam Lowe wrote:
> >
> > > 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.
> > >
> > 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.
> >
> > > 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.
> > >
> > I would be more than willing to call you but the above phone number is
> > not correct.
> > Send me the correct the number.
> >
> > krish
> > >
> > >
> > > ----- Original Message -----
> > > From: Tatai SV Krishnan <[e-mail]>
> > > To: K Mitchell <[e-mail]>
> > > Cc: <[e-mail]>
> > > Sent: Sunday, August 15, 1999 10:25 AM
> > > Subject: Re: (usr-tc) Link dead after 8 Days
> > >
> > >
> > > >
> > >
> >
> > -
> >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> >  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 "[e-mail]"
>  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 "[e-mail]"
 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: Tatai SV Krishnan <[e-mail]>
Subject: Re: (usr-tc) Link dead after 8 Days
Date: 16 Aug 1999 10:27:18 -0500 (CDT)

On Mon, 16 Aug 1999, Ken Kirchner wrote:

>
> 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.
>
STac is what I was talking about also.

> 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.
>

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

> > If you have a setup where the problem is currently happening send me
> > note, will be glad to take a look at it.
> >
> > krish
>
> I will definately keep you posted.
>
> -Ken
>   ___                                                         ___
>  (___) Kenneth Kirchner    .o.  mailto:[e-mail]       (___)
>   (__) Asst SysAdmin       .o.  Voice [phone] Ext 108 (__)
>    (_) ShreveNet, Inc.     .o.  Fax   [phone]         (_)
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: Stephen Amadei <[e-mail]>
Subject: (usr-tc) Telnet exploit round 2...
Date: 17 Aug 1999 00:03:33 -0400 (EDT)


O.K.  I did the 'enable telnet cli' stuff with a nice
brief 'add telnet cli xxx.xxx.xxx.xxx' list.  I did a 'save all'.

Everything worked correctly until I rebooted my TCs.  Now they won't
accept telnet access from anywhere.

Anyone else notice this?  I haven't been able to log into the local
console yet to check the damage, but at least the equipment is working
(well, except the telnet access).

                    ----Steve
Stephen Amadei
Director of MIS
Dandy Connections, Inc.
Atlantic City, NJ


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) Link dead after 8 Days
Date: 17 Aug 1999 00:45:28 -0400 (EDT)

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 [phone]
[e-mail]

On Mon, 16 Aug 1999, Ken Kirchner wrote:

> On Mon, 16 Aug 1999, Tatai SV Krishnan wrote:
>
> > 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.
>
> 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.


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Brian <[e-mail]>
Subject: Re: (usr-tc) 2 ARC's - one chassis
Date: 17 Aug 1999 09:06:01 -0500 (CDT)

On Mon, 16 Aug 1999, Jamie Orzechowski wrote:

> Could someone please give me a config to setup load balancing between 2
> arc's
>
> I will have 14 DSP's in one chassis with 2 ARC's controlling them.

All you do is assign the first 7 modems to arc 1, and then the next 7 to
arc 2.  Make their configs the same, except for the ip address of the arc,
and the modem pools.

Brian


>
>
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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.
>

Brian Feeny (BF304)     [e-mail]
318-222-2638 x 109    http://www.shreve.net/~signal
Network Administrator   ShreveNet Inc. (ASN 11881)


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: [e-mail]
Subject: Re: (usr-tc) 2 ARC's - one chassis
Date: 17 Aug 1999 11:13:02 -0400



The automated way to do this is with NMC chassis awareness, dynamic slot
assignment and dsa idle rebalancing.

On the Arcs...make sure neither are set as owners of any of the cards,
then do the following on both:

enable nmc chassis_awareness
enable nmc dynamic_slot_assignment
enable nmc dsa_idle_rebalancing

Then the Arc's (with the help of the NMC) should have worked out who
controls what modem cards (this is a slow process - have patience).  If one
of the Arcs fails the other Arc should pick up the modem assignments.

As far as IP pool assignment...the best way to get this to work with the
above setup is to set each Arc with two ip pools and

set:
disable ip address_pool_round_robin

Then set the first arc with pool 1 first, pool 2 second, and the second
arc with pool 2 first and pool 1 second.

I haven't tested all this out thoroughly...specifically not the ip pool
setup...but I
have done a bit of playing with the chassis_awareness, dsa and
dsa_idle_rebalancing...it worked...slowly (like 20 minutes for a failover).

Hope this helps,

FN




"Jamie Orzechowski" <[e-mail]> on 08/16/99 05:06:59 PM

Please respond to [e-mail]

Sent by:  "Jamie Orzechowski" <[e-mail]>


cc:    (Florin Neamtu/US/3Com)




Could someone please give me a config to setup load balancing between 2
arc's

I will have 14 DSP's in one chassis with 2 ARC's controlling them.




-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 "[e-mail]"
 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: Marcelo Souza <[e-mail]>
Subject: Re: (usr-tc) Telnet exploit round 2...
Date: 17 Aug 1999 12:23:41 -0300 (EST)

Hi,

    Have you tried to dial to TC and log as administrative user, then
use de MANAGE command ?

- Marcelo

On Tue, 17 Aug 1999, Stephen Amadei wrote:

|O.K.  I did the 'enable telnet cli' stuff with a nice
|brief 'add telnet cli xxx.xxx.xxx.xxx' list.  I did a 'save all'.
|
|Everything worked correctly until I rebooted my TCs.  Now they won't
|accept telnet access from anywhere.
|
|Anyone else notice this?  I haven't been able to log into the local
|console yet to check the damage, but at least the equipment is working
|(well, except the telnet access).
|
|                    ----Steve
|Stephen Amadei
|Director of MIS
|Dandy Connections, Inc.
|Atlantic City, NJ
|
|
|-
| To unsubscribe to usr-tc, send an email to "[e-mail]"
| 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


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Mike Wronski" <[e-mail]>
Subject: RE: (usr-tc) Telnet exploit round 2...
Date: 17 Aug 1999 10:41:50 -0500

What code version did you do this on? I have tested with 4.1.59-6. and 4.2.x and
not found any problems after a
reboot...

-M

|-----Original Message-----
|From: [e-mail]
|[mailto:[e-mail]]On Behalf Of Stephen Amadei
|Sent: Monday, August 16, 1999 11:04 PM
|To: [e-mail]
|Subject: (usr-tc) Telnet exploit round 2...
|
|
|
|O.K.  I did the 'enable telnet cli' stuff with a nice
|brief 'add telnet cli xxx.xxx.xxx.xxx' list.  I did a 'save all'.
|
|Everything worked correctly until I rebooted my TCs.  Now they won't
|accept telnet access from anywhere.
|
|Anyone else notice this?  I haven't been able to log into the local
|console yet to check the damage, but at least the equipment is working
|(well, except the telnet access).
|
to the same address.  Do not use quotes in your message.
|


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Boggs, Scott" <[e-mail]>
Subject: RE: (usr-tc) 2 ARC's - one chassis
Date: 17 Aug 1999 13:28:43 -0400

I did it last May.  I got these tips from [e-mail]
The only thing is that these are static assignments.
Not real-time balancing.  My PRI channels go round-robin
so that evens the load on arc's enough to suit me.
use this as a reference

The first step is to turn off chassis awareness and re-boot:
     disable nmc chassis_awareness
     save all
     reboot

The next step is to tell the HARC what slots it owns and what the cards are:
     set chassis slot 2-16 owner yes
     set chassis slot 2-16 card_type hdm_24
     set chassis slot 2-16 ports 23
     save all



> -----Original Message-----
> From:    Jamie Orzechowski [SMTP:[e-mail]]
> Sent:    Monday, August 16, 1999 5:07 PM
> To:    [e-mail]
> Subject:    (usr-tc) 2 ARC's - one chassis
>
> Could someone please give me a config to setup load balancing between 2
> arc's
>
> I will have 14 DSP's in one chassis with 2 ARC's controlling them.
>
>

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Scott Trautman <[e-mail]>
Subject: RE: (usr-tc) Perhaps another simple question - HiperARC initial c
Date: 17 Aug 1999 13:39:23 -0500

Really.....someone with the time to do it (maybe me...who knows...) ought
try this
simple experiment.

post to this list, call 3Com support at the same time with a medium-hard
type question.
This question would have been perfect.

Any wagers as to where the first <correct> answer comes from?
Also count number of reboots (not less than 3 and always during peak use),
ask same question, phone system navigations, dolts you talk to in the
evaluation, escalations, waits for callbacks, suggestions that it's "the
chassis" & what's your freakin' contract number....

Remember I said <simple> experiment, not easy on the stress level.....:)

I only call 3Com when I've already convinced myself I have bad equipment;
then proceed
directly to RMA dept.

Really, let's not get into the whole bitching thing on 3Com support; it is
what it is. The RMA process
really is decent enough, pretty good turnaround, know that you ought to be
keeping spare equipment around anyway, and with this list, get everything
answered, so "no worries".
Leave 3Com support/contracts for the clueless corporate people with
time&money to burn for the most part.
The TC's really are the best thing out there, dings and all, from what I've
seen.

'nuff said!

SMT

PS: A composite "gems of wisdom" document with many of the
problems/solutions here would be really really cool....if someone had the
time (right!) to put one together....


-----Original Message-----
Sent: Monday, August 16, 1999 3:53 PM
configuration/ console cable


Scott -- as the vendor, I'm glad to see the cards are OK!  Just got a
shipment from 3Com that's the wrong cards and they are blaming me.  Of
course they forgot the fact that they told me the p/n to order!  Much
better support on the list than from 3Com!

Thanks for the business!

Regards,

Marty





At 03:39 PM 8/16/99 -0500, you wrote:
>You are godlike. That did the trick. DS 5 is the one!
>
>SMT
>
>-----Original Message-----
>From: Mike Andrews [mailto:[e-mail]]
>Sent: Monday, August 16, 1999 3:10 PM
>To: [e-mail]
>Subject: Re: (usr-tc) Perhaps another simple question - HiperARC initial
>configuration/ console cable
>
>
>Ooops.  Make that Dip Switch *5*.  Not 6.
>
>Dip Switch 5 overrides the need for things like carrier detect on the
>cable.  We cooked up custom cables on ours (so we could hook them to a
>terminal server for reverse telnet) and ran into this on ARC 4.1.x
>releases.  Your other ARCs were probably set up with 4.0.x software which
>didn't care.
>
>
>Mike Andrews (MA12) -=-=-  VP & Sysadmin, Digital Crescent, Frankfort KY
>[e-mail]  -=--=-  [e-mail]  -=--=-  http://www.bit0.com
>"If you're not part of the solution.... you're part of the precipitate."
>
>On Mon, 16 Aug 1999, Mike Andrews wrote:
>
>> Turn on dip switch 6, especially if you made your own serial cable...
>>
>> On Mon, 16 Aug 1999, Scott Trautman wrote:
>>
>> > I just got 3 new HiperARC's. Yippee for me.
>> >
>> > My means of configuring them is usually to put the console cable on and
>> > configure from there.
>> > And I've done several other ARC's this way.
>> >
>> > This batch, however, I am getting as far as PROM vers 1.16 made June 16
>> > 1998..., Loading System .....OK
>> > and that's the last I see---
>> >
>> > So I'm rather stuck. Per my NMC, it does load okay (all green), yet I
>can't
>> > get into it to set anything.
>> > Tried the usual disconnect, reconnect to the comm port, nope
>> > Tried the also usual Control-C,D,X,[,] for some kind of breakout
>> >
>> > Nothing...nada....NMC says it's all good, but no more console output or
>> > input happening...
>> >
>> > Any ideas? I'm hoping it's just as stupid a problem as I feel.
>> > Short work once I'm in....
>> >
>> > SMT
>> >
>> >
>> >
>> >
>> >
>> >
>> > 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 "[e-mail]"
>> >  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 "[e-mail]"
> 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 "[e-mail]"
> 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 "[e-mail]"
 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 "[e-mail]"
 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 <[e-mail]>
Subject: (usr-tc) NMC event logging
Date: 17 Aug 1999 14:50:32 -0400 (EDT)

Started using RADIUS logging from the NMC's to get logging information
from the modems...Some pretty useful stuff in here.

Here's the deal though...trying to track down a likely telco issue
(telco trunking between CO's) so trying to get logging on failed calls
of ANI info.  Quads I can do ok...other than having to get the modems
idle to be able to set the trap-enables...which is annoying, but
doable...the DSP's logging events on failed calls don't seem to have any
way to snag ANI information.  There's no equivalent to the dual-t1/pri
card's callarriveevent either, so I can't grab it from there...

Am I missing something here?
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Aaron Nabil <[e-mail]>
Subject: (usr-tc) Mulitcasting (mbone)
Date: 17 Aug 1999 13:00:43 -0700 (PDT)


If anyone has mbone working, a sample config would be
appreciated.  The one in the manual doesn't seem to work,
and I know everything else is working (works OK with my
dial-in clients thru our Ascend Maxes, just not the 3com
chassis).

Thanks,


--
Aaron Nabil

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Aaron Nabil <[e-mail]>
Subject: Re: (usr-tc) 2 ARC's - one chassis
Date: 17 Aug 1999 14:46:36 -0700 (PDT)

[e-mail] writes...
>The automated way to do this is with NMC chassis awareness, dynamic slot
>assignment and dsa idle rebalancing.
>
> . . .
>
>As far as IP pool assignment...the best way to get this to work with the
>above setup is to set each Arc with two ip pools and
>
>set:
>disable ip address_pool_round_robin
>
>Then set the first arc with pool 1 first, pool 2 second, and the second
>arc with pool 2 first and pool 1 second.

Unless you set these as no_aggregate, both ARC's will announce routes for
both pools.  And even if you do set them no_aggregate, replacing the failed
ARC will cause it start using addresses the other backup ARC had been
assigning (assuming it used up all of it's first pool).

In any case, this doesn't sound like such a good idea.

The only obvious solution is to assign 2x the number of addresses to each
ARC, or use some kind of radius-based IP address resource allocation.


--
Aaron Nabil

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) 2 ARC's - one chassis
Date: 17 Aug 1999 18:19:04 -0400 (EDT)

Thus spake Aaron Nabil
>>As far as IP pool assignment...the best way to get this to work with the
>>above setup is to set each Arc with two ip pools and

>>set:
>>disable ip address_pool_round_robin

>>Then set the first arc with pool 1 first, pool 2 second, and the second
>>arc with pool 2 first and pool 1 second.

>Unless you set these as no_aggregate, both ARC's will announce routes for
>both pools.  And even if you do set them no_aggregate, replacing the failed
>ARC will cause it start using addresses the other backup ARC had been
>assigning (assuming it used up all of it's first pool).

Replacing the failed Arc is problematic, yeah...but there are ways to
work around that...ie, have a pool of addresses available total for this
situation (could use this one pool for all of your network, not just the
chassis)...then set this as the new pool on the new chassis that you're
using to replace the failed one.  As the dsa idle rebalancing moves
cards back over to the new chassis, this will free up the second pool on
the first Arc, which can then be added back to the replacement arc.  At
this point, you can also then add the primary pool on the other arc back
(again...make sure you have the round robin pool assignment disabled),
then delete the temporary pool from the replaced arc (note, you can do
this will addresses from that pool are still in use...the arcs are
intelligent about this) and it'll switch back to your original
situation.

>In any case, this doesn't sound like such a good idea.

>The only obvious solution is to assign 2x the number of addresses to each
>ARC, or use some kind of radius-based IP address resource allocation.

Ugh...I can't handle double the number of addresses...I think my
solution above should work (assuming your network uses at least RIP
routing for your IP pools), and drastically lowers the IP address
consumption....maybe not *quite* as easy to manage a switch over, but
should be transparent to end users and not as wasteful of IP addresses.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: <[e-mail]>
Subject: (usr-tc) radiusd and CHAP authentication
Date: 17 Aug 1999 18:29:06 -0400 (EDT)


    We are using Merit radius for our NAS's...  Is there something
that we need to do with the radius in order for it to use chap
authentication?

  Just shut down the rest of our analog lines and the server
authenticating them did CHAP...  I would assume there is a file that we
need to refer to for the radius.

==============================================================================
Phillip Ferraro                WorldNet Access, Inc
[e-mail]    Onslow County's PREMIER InterNet Service
Voice [phone]            824 Gumbranch Square, Suite R3
FAX   [phone]             Jacksonville, Nc  28540-6269
==============================================================================



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Eric Billeter" <[e-mail]>
Subject: (usr-tc) Bad Modem monitoring
Date: 17 Aug 1999 16:31:06 -0700

If you have PERL running

AND

You have MRTG running

AND

you want to be able to monitor modem call failures on the Hiper DSP cards

Email me.  I have some scripts in beta currently and would like your
feedback.  When completed I will release them to the lists.

Eric Billeter
Internet Engineer
Cable One, Inc.

[e-mail]
602-364-6462




-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Stephen Amadei <[e-mail]>
Subject: RE: (usr-tc) Telnet exploit round 2...
Date: 17 Aug 1999 19:40:30 -0400 (EDT)

On Tue, 17 Aug 1999, Mike Wronski wrote:

> What code version did you do this on? I have tested with 4.1.59-6. and 4.2.x and
> not found any problems after a
> reboot...

It's the wierdest thing... after logging into the console on my spare
TC, all 4 of my ARC equipped TCs started working... but I have 3 employees
that tried desperately to get in for over 16 hours... and I tried
repeatedly, so I really happened.

I have tried to recreate the problem with my spare TC, but I can't
duplicate it.  *Shrug*  Oh, well...

As long as they work now, I haved bigger fires to put out...

                    ----Steve
Stephen Amadei
Director of MIS
Dandy Connections, Inc.
Atlantic City, NJ


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Jamie Orzechowski" <[e-mail]>
Subject: Re: (usr-tc) Bad Modem monitoring
Date: 17 Aug 1999 20:08:55 -0400

I would love to have these scripts ... I have mrtg monitoring my calls on
the DSP's ... would like a failiure graph ...

----- Original Message -----
Sent: Tuesday, August 17, 1999 7:31 PM


> If you have PERL running
>
> AND
>
> You have MRTG running
>
> AND
>
> you want to be able to monitor modem call failures on the Hiper DSP cards
>
> Email me.  I have some scripts in beta currently and would like your
> feedback.  When completed I will release them to the lists.
>
> Eric Billeter
> Internet Engineer
> Cable One, Inc.
>
> [e-mail]
> 602-364-6462
>
>
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: "Eric Billeter" <[e-mail]>
Subject: RE: (usr-tc) Bad Modem monitoring
Date: 17 Aug 1999 18:20:39 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_134D_01BEE8DD.366E0930
Content-Type: text/plain;
    charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

What I have now is an external script which polls all modems in the chassis
(DSPs)

It then outputs to a file in HTML format.
You can see a result of the output at http://24.116.0.46\phx-fail.htm
Modems which are failing would be highlighted in red.

I am next going to work on trying to alert via email when a modem is in
errored status, and also rework the error conditional.  I have only worked
on
this today, and I figure on giving it about another day this week.

Because the SNMP walk takes a considerable amount of time I am running this
via a scheduled process and outputting the information to a file, rather
than having it dynamic and run when the page is requested.  Also this will
make the alerting function more practical.

If there are any perl programmers who would like to work on this with me it
would be greatly appreciated.  I am not a perl programmer, although I can do
a pretty good job at cutting and pasting from other scripts.  The current
scripts use some of the modules included with MRTG, as well as a hacked up
version of my hiperdsp.pl script for the snmp walk.

Plug in the community, ip address, and output file into the script then run
it.
Please let me know the results or if you have any suggestions.

Thanks
Eric Billeter
Internet Engineer
Cable One, Inc.

[e-mail]
602-364-6462

-----Original Message-----
[mailto:[e-mail]]On Behalf Of Jamie Orzechowski
Sent: Tuesday, August 17, 1999 5:09 PM


I would love to have these scripts ... I have mrtg monitoring my calls on
the DSP's ... would like a failiure graph ...

----- Original Message -----
Sent: Tuesday, August 17, 1999 7:31 PM


> If you have PERL running
>
> AND
>
> You have MRTG running
>
> AND
>
> you want to be able to monitor modem call failures on the Hiper DSP cards
>
> Email me.  I have some scripts in beta currently and would like your
> feedback.  When completed I will release them to the lists.
>
> Eric Billeter
> Internet Engineer
> Cable One, Inc.
>
> [e-mail]
> 602-364-6462
>
>
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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.

------=_NextPart_000_134D_01BEE8DD.366E0930
Content-Type: application/octet-stream;
    name="modemfail.pl"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
    filename="modemfail.pl"

#!c:\perl\bin

# modemfail.pl
#


use SNMP_Session;
use BER;
use Socket;
use strict;

%snmpget::OIDS =3D (  'OID1' =3D>  '1.3.6.1.4.1.429.1.6.10.1.1.24',
                    'OID2' =3D>  '1.3.6.1.4.1.429.1.6.10.1.1.4',
                 );
my $community=3D"public";
my $router =3D "127.0.0.1";
my $outputfile=3D"modem-fail.htm";



my @callok;
my @callfail;
my($sysName,$sysUptime,$interfaces,$value1,$value2) =3D
    =
snmpgettable($router,$community,'OID1'),snmpgettable2($router,$community,=
'OID2');
my $i;
my $slot;
my $modem;
my $modemcount =3D @callok + 0 ;
open FILE, ">$outputfile";

print FILE  "<HEAD><TITLE>Modem Report for My Modems</TITLE></HEAD>\n";
print FILE  "<BODY><HTML>\n";
print FILE "<TABLE>";
print FILE "<TR><TD width=3D15%>Slot</TD><TD width=3D10%></TD><TD =
width=3D15%>Modem<TD width=3D20%></TD><TD width=3D15%>Incoming</TD><TD =
width=3D25%>Failed</TD></TR>";
print FILE =
"<TR><TD></TD><TD></TD><TD><TD></TD><TD>Calls</TD><TD>Calls</TD></TR>";=20
print FILE "<TR></TR>";
for $i ( 1 .. $modemcount) {

    $slot=3Dint (($i-1)/24)+1;
    $modem=3Dint ($i-(($slot-1)*24));

        if (@callfail[$i-1] > @callok[$i-1]) {
        print FILE  "<TR bgcolor=3D#ff6600><TD><b>";
        }

        else {
        print FILE "<TR><TD>";
        }

    print FILE  "SLOT</TD><TD> ",$slot,"</TD><TD>";
    print FILE  "     Modem</TD><TD> ",$modem,"</TD><TD>";
    print FILE  @callok[$i-1],"</TD><TD>",@callfail[$i-1],;
=09
    if (@callfail[$i-1] > @callok[$i-1]) {
    print FILE  "</b>";
    }

    print FILE  "\n</TD></TR>";
    }

print FILE  "</TABLE></html></body>";
close FILE;

exit(0);

sub snmpgettable{
  my($host,$community,$var) =3D @_;
  my($next_oid,$enoid,$orig_oid,=20
     $response, $bindings, $binding, $value, $inoid,$outoid,
     $upoid,$oid,@table,$tempo);
  die "Unknown SNMP var $var\n"=20
    unless $snmpget::OIDS{$var};
 =20
  $orig_oid =3D encode_oid(split /\./, $snmpget::OIDS{$var});
  $enoid=3D$orig_oid;
  srand();
  my $session =3D SNMP_Session->open ($host ,
                                 $community,=20
                                 161);
  for(;;)  {
    if ($session->getnext_request_response(($enoid))) {
      $response =3D $session->pdu_buffer;
      ($bindings) =3D $session->decode_get_response ($response);
      ($binding,$bindings) =3D decode_sequence ($bindings);
      ($next_oid,$value) =3D decode_by_template ($binding, "%O%@");
      # quit once we are outside the table
      last unless BER::encoded_oid_prefix_p($orig_oid,$next_oid);
      $tempo =3D pretty_print($value);
     #   print $tempo,"\n";
    push @callfail, $tempo;
        $value1=3D$value1 + $tempo ;

      $tempo=3D~s/\t/ /g;
      $tempo=3D~s/\n/ /g;
      $tempo=3D~s/^\s+//;
      $tempo=3D~s/\s+$//;
      push @table, $tempo;
    } else {
      die "No answer from $ARGV[0]\n";
    }
    $enoid=3D$next_oid;
  }
  $session->close ();=20
if( $value1 eq ''){$value1 =3D 0 };
#     print "$value1\n";
  return (@table);
}
sub snmpgettable2{
  my($host,$community,$var) =3D @_;
  my($next_oid,$enoid,$orig_oid,=20
     $response, $bindings, $binding, $value, $inoid,$outoid,
     $upoid,$oid,@table,$tempo);
  die "Unknown SNMP var $var\n"=20
    unless $snmpget::OIDS{$var};
 =20
  $orig_oid =3D encode_oid(split /\./, $snmpget::OIDS{$var});
  $enoid=3D$orig_oid;
  srand();
  my $session =3D SNMP_Session->open ($host ,
                                 $community,=20
                                 161);
  for(;;)  {
    if ($session->getnext_request_response(($enoid))) {
      $response =3D $session->pdu_buffer;
      ($bindings) =3D $session->decode_get_response ($response);
      ($binding,$bindings) =3D decode_sequence ($bindings);
      ($next_oid,$value) =3D decode_by_template ($binding, "%O%@");
      # quit once we are outside the table
      last unless BER::encoded_oid_prefix_p($orig_oid,$next_oid);
      $tempo =3D pretty_print($value);
#       print $tempo,"\n";
    push @callok, $tempo;
      $value2=3D$value2 + $tempo ;
      $tempo=3D~s/\t/ /g;
      $tempo=3D~s/\n/ /g;
      $tempo=3D~s/^\s+//;
      $tempo=3D~s/\s+$//;
      push @table, $tempo;
    } else {
      die "No answer from $ARGV[0]\n";
    }
    $enoid=3D$next_oid;
  }
  $session->close ();=20
if( $value2 eq ''){$value2 =3D 0 };
#     print "$value2\n";
  return (@table);
}


------=_NextPart_000_134D_01BEE8DD.366E0930--




-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Jamie Orzechowski" <[e-mail]>
Subject: Re: (usr-tc) Bad Modem monitoring
Date: 17 Aug 1999 21:32:45 -0400

my "bad" or "high pitched sound" modem problem has disappeared since I have
flashed the test code (2.0.70) from 3com ... I have not had one problem with
it since I got it up and running on 15 DSP's last week ... if anyone has a
problem with high pitched sound I would recommend contacting a 3com tech for
the code ...

----- Original Message -----
Sent: Tuesday, August 17, 1999 9:20 PM


> What I have now is an external script which polls all modems in the
chassis
> (DSPs)
>
> It then outputs to a file in HTML format.
> You can see a result of the output at http://24.116.0.46\phx-fail.htm
> Modems which are failing would be highlighted in red.
>
> I am next going to work on trying to alert via email when a modem is in
> errored status, and also rework the error conditional.  I have only worked
> on
> this today, and I figure on giving it about another day this week.
>
> Because the SNMP walk takes a considerable amount of time I am running
this
> via a scheduled process and outputting the information to a file, rather
> than having it dynamic and run when the page is requested.  Also this will
> make the alerting function more practical.
>
> If there are any perl programmers who would like to work on this with me
it
> would be greatly appreciated.  I am not a perl programmer, although I can
do
> a pretty good job at cutting and pasting from other scripts.  The current
> scripts use some of the modules included with MRTG, as well as a hacked up
> version of my hiperdsp.pl script for the snmp walk.
>
> Plug in the community, ip address, and output file into the script then
run
> it.
> Please let me know the results or if you have any suggestions.
>
> Thanks
> Eric Billeter
> Internet Engineer
> Cable One, Inc.
>
> [e-mail]
> 602-364-6462
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Jamie Orzechowski
> Sent: Tuesday, August 17, 1999 5:09 PM
> To: [e-mail]
> Subject: Re: (usr-tc) Bad Modem monitoring
>
>
> I would love to have these scripts ... I have mrtg monitoring my calls on
> the DSP's ... would like a failiure graph ...
>
> ----- Original Message -----
> From: Eric Billeter <[e-mail]>
> To: <[e-mail]>
> Sent: Tuesday, August 17, 1999 7:31 PM
> Subject: (usr-tc) Bad Modem monitoring
>
>
> > If you have PERL running
> >
> > AND
> >
> > You have MRTG running
> >
> > AND
> >
> > you want to be able to monitor modem call failures on the Hiper DSP
cards
> >
> > Email me.  I have some scripts in beta currently and would like your
> > feedback.  When completed I will release them to the lists.
> >
> > Eric Billeter
> > Internet Engineer
> > Cable One, Inc.
> >
> > [e-mail]
> > 602-364-6462
> >
> >
> >
> >
> > -
> >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> >  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 "[e-mail]"
>  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 "[e-mail]"
 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: Aaron Nabil <[e-mail]>
Subject: Re: (usr-tc) 2 ARC's - one chassis
Date: 17 Aug 1999 18:59:47 -0700 (PDT)

Jeff Mcadams writes...
>Thus spake Aaron Nabil
>>The only obvious solution is to assign 2x the number of addresses to each
>>ARC, or use some kind of radius-based IP address resource allocation.
>
>Ugh...I can't handle double the number of addresses...I think my
>solution above should work (assuming your network uses at least RIP
>routing for your IP pools), and drastically lowers the IP address
>consumption....maybe not *quite* as easy to manage a switch over, but
>should be transparent to end users and not as wasteful of IP addresses.

Your plan requires to much manual intervention (ie, work) to
be practical for me. :)  I'd much rather just unplug or disable the
DSP's corresponding to the failed ARC until the replacement came
in than risk screwing with the pools.  Major potential recipe for
disaster.

Using Radius to handle this is probably the easiest, although the
version I use (Radiator) doesn't support any of the resource-management
extensions (at least I don't think it does).  A very simple work around
(and I think the latest version of Radiator supports this) is to map
each specific modem to it's own IP address.  OSPF should make this
much less painful.


--
Aaron Nabil

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Tatai SV Krishnan <[e-mail]>
Subject: Re: (usr-tc) radiusd and CHAP authentication
Date: 17 Aug 1999 09:03:23 -0500 (CDT)

On Tue, 17 Aug 1999 [e-mail] wrote:

>
>     We are using Merit radius for our NAS's...  Is there something
> that we need to do with the radius in order for it to use chap
> authentication?
>

For chap first off all your user password list should be in a text format
on the server.  You cannot use any database of unix passwords.

krish

>   Just shut down the rest of our analog lines and the server
> authenticating them did CHAP...  I would assume there is a file that we
> need to refer to for the radius.
>
> ==============================================================================
> Phillip Ferraro                WorldNet Access, Inc
> [e-mail]    Onslow County's PREMIER InterNet Service
> Voice [phone]            824 Gumbranch Square, Suite R3
> FAX   [phone]             Jacksonville, Nc  28540-6269
> ==============================================================================
>
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: "Brett Murphy" <[e-mail]>
Subject: Re: (usr-tc) Bad Modem monitoring
Date: 18 Aug 1999 12:16:03 +1000




-----Original Message-----


>my "bad" or "high pitched sound" modem problem has disappeared since I have
>flashed the test code (2.0.70) from 3com ... I have not had one problem
with
>it since I got it up and running on 15 DSP's last week ... if anyone has a
>problem with high pitched sound I would recommend contacting a 3com tech
for
>the code ...


I have had problems with 2.0.70 and the bad tones/increasing calls failed
syndrome (we need a more generic term for it) .

>
>----- Original Message -----
>From: Eric Billeter <[e-mail]>
>To: <[e-mail]>
>Sent: Tuesday, August 17, 1999 9:20 PM
>Subject: RE: (usr-tc) Bad Modem monitoring
>
>
>> What I have now is an external script which polls all modems in the
>chassis
>> (DSPs)
>>
>> It then outputs to a file in HTML format.
>> You can see a result of the output at http://24.116.0.46\phx-fail.htm
>> Modems which are failing would be highlighted in red.
>>
>> I am next going to work on trying to alert via email when a modem is in
>> errored status, and also rework the error conditional.  I have only
worked
>> on
>> this today, and I figure on giving it about another day this week.
>>
>> Because the SNMP walk takes a considerable amount of time I am running
>this
>> via a scheduled process and outputting the information to a file, rather
>> than having it dynamic and run when the page is requested.  Also this
will
>> make the alerting function more practical.
>>
>> If there are any perl programmers who would like to work on this with me
>it
>> would be greatly appreciated.  I am not a perl programmer, although I can
>do
>> a pretty good job at cutting and pasting from other scripts.  The current
>> scripts use some of the modules included with MRTG, as well as a hacked
up
>> version of my hiperdsp.pl script for the snmp walk.
>>
>> Plug in the community, ip address, and output file into the script then
>run
>> it.
>> Please let me know the results or if you have any suggestions.
>>
>> Thanks
>> Eric Billeter
>> Internet Engineer
>> Cable One, Inc.
>>
>> [e-mail]
>> 602-364-6462
>>
>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]]On Behalf Of Jamie Orzechowski
>> Sent: Tuesday, August 17, 1999 5:09 PM
>> To: [e-mail]
>> Subject: Re: (usr-tc) Bad Modem monitoring
>>
>>
>> I would love to have these scripts ... I have mrtg monitoring my calls on
>> the DSP's ... would like a failiure graph ...
>>
>> ----- Original Message -----
>> From: Eric Billeter <[e-mail]>
>> To: <[e-mail]>
>> Sent: Tuesday, August 17, 1999 7:31 PM
>> Subject: (usr-tc) Bad Modem monitoring
>>
>>
>> > If you have PERL running
>> >
>> > AND
>> >
>> > You have MRTG running
>> >
>> > AND
>> >
>> > you want to be able to monitor modem call failures on the Hiper DSP
>cards
>> >
>> > Email me.  I have some scripts in beta currently and would like your
>> > feedback.  When completed I will release them to the lists.
>> >
>> > Eric Billeter
>> > Internet Engineer
>> > Cable One, Inc.
>> >
>> > [e-mail]
>> > 602-364-6462
>> >
>> >
>> >
>> >
>> > -
>> >  To unsubscribe to usr-tc, send an email to "[e-mail]"
>> >  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 "[e-mail]"
>>  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 "[e-mail]"
> 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 "[e-mail]"
 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: "Jamie Orzechowski" <[e-mail]>
Subject: Re: (usr-tc) 2 ARC's - one chassis
Date: 17 Aug 1999 22:18:36 -0400

I would just like to know if one ARC can even handle 14 DSP's or should I
use 2 ARCS?


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Tatai SV Krishnan <[e-mail]>
Subject: Re: (usr-tc) 2 ARC's - one chassis
Date: 17 Aug 1999 09:47:32 -0500 (CDT)

On Tue, 17 Aug 1999, Jamie Orzechowski wrote:

> I would just like to know if one ARC can even handle 14 DSP's or should I
> use 2 ARCS?
>

A single ARC can handle 14 DSP as long as you are not using IPX.  With
IPX enabled (IP and IPX both) we recommend only 7 DSP per ARC.

krish

>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: "Jason Kelton" <[e-mail]>
Subject: Re: (usr-tc) 2 ARC's - one chassis
Date: 18 Aug 1999 14:39:59 +1000

Aaron,

> The only obvious solution is to assign 2x the number of addresses to each
> ARC, or use some kind of radius-based IP address resource allocation.

Resource Assignement via Radius would appear to be more appropriate these
days in any case.  It means you handle the entire client-side's access and
IP Assignment from within Radius.

Seems to me like a more centralised approach!

- Jason.


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: [e-mail] (mingkai)
Subject: (usr-tc) Acct-Terminate-Cause
Date: 18 Aug 1999 14:12:54 +0800 (SGT)

Hi,

    I would like to find out under what circumstances do the Hiperarc
(with HiperDSP cards) send out accounting stop packets with the attribute
Acct-Terminate-Cause set to Lost-Carrier. Is this terminaate-cause send
only when the HiperDSP modems detect a loss of DCD (carrier) before a LCP
termination packet is received ? Or are there other circumstances under
which the HiperAARCs will send a RADIUS stop packet with this terminate
cause? Any advise will be greatly appreciated. Thanks.

Ming Kai
Network Engineer
Pacific Internet Ltd



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Jamie Orzechowski" <[e-mail]>
Subject: (usr-tc) 1 ARC - 14 DSPS
Date: 18 Aug 1999 06:16:23 -0400

Should PPP Offloading be enabled with 14 DSPS being control by one chassis??

and 14 DSPS takes up more than one class C ... so would I have my first IP
pool (entre class c) sent on eth0 and then have the remaning IP's on eth1??
or can you have 2 ippools on the same interface?


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) 1 ARC - 14 DSPS
Date: 18 Aug 1999 07:31:19 -0400 (EDT)

Thus spake Jamie Orzechowski
>Should PPP Offloading be enabled with 14 DSPS being control by one chassis??

Probably.  :)

>and 14 DSPS takes up more than one class C ... so would I have my first IP
>pool (entre class c) sent on eth0 and then have the remaning IP's on eth1??
>or can you have 2 ippools on the same interface?

Bah...forget that classful addressing thinking...its only going to get
you into trouble.

Regardless though...ip pools aren't assigned to an interface, they're
just defined on the Arc.  If you're depending on the Arc to proxy arp
for the ip addresses in the pools, then you'll need to define another
network on the ethernet interface that includes the second ip pool.
Personally, I'd suggest going with RIPv2 though and just don't worry
about it.  You can define multiple networks on a single ethernet
interface, so there's no reason that you would have to use the second
ethernet interface for this.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Jim Johnson <[e-mail]>
Subject: Re: (usr-tc) 2 ARC's - one chassis
Date: 18 Aug 1999 08:29:38 -0400


Maybe 3COM should look at the concept of a real Fault tolerant
configuration.

It could be as easy as put a second card in and identify it as a
BACKUP.

    set chassis slot 2 ARC_Backup

The other ARC could mirror its config onto the backup automatically.

If the primary failed, the backup takes over as a clone of the primary.

Jim


Jason Kelton wrote:
>
> Aaron,
>
> > The only obvious solution is to assign 2x the number of addresses to each
> > ARC, or use some kind of radius-based IP address resource allocation.
>
> Resource Assignement via Radius would appear to be more appropriate these
> days in any case.  It means you handle the entire client-side's access and
> IP Assignment from within Radius.
>
> Seems to me like a more centralised approach!
>
> - Jason.
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: "Stainforth, Matthew" <[e-mail]>
Subject: (usr-tc) NFAS on DSPs
Date: 18 Aug 1999 09:58:10 -0300


I just swapped out a dual PRI card and a set of quads for two DSPs and I'm
trying to do NFAS.  The telco sees the D channel up and the channels are all
supposedly up and idle but the second card is reporting the D channel is
down.  Is this normal since the D channel is on the first PRI span or does
it indicate a problem?

At first I had the NFAS ID wrong on the second DSP.  When I brought it up,
it was reporting all channels were in service and idle.  I thought that was
rather strange and I knew it was wrong since I verified this with the telco.
I set it to the correct value, rebooted the card, and it is still reporting
all channels in service and idle.

I'm still waiting on hold to get the switch techs to try putting some
channels into IMB and see if I see them go out of service on this end
(which, to me, would indicate that the second card is getting the signalling
information ok) but surely there's an easier way to see if signalling is
getting to the second card or not...

Matthew...

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Jim Johnson <[e-mail]>
Subject: (usr-tc) Internic
Date: 18 Aug 1999 09:32:06 -0400



This being my most technically capable mailing list :), I thought I
would ask this off-topic qustion.  Has anyone else observed problems
with Internic the last few days.  Root servers are timing out, domains
are being dropped off the servers.  We had 20 domains yesterday that
were just gone from the root servers that we complained to Internic
about.  Today, the list is down to five.  Our support people have heard
from people of many domains that have been unreachable the last couple
days.  Seems like these widespread problems would have been headline
news.


Jim

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Tatai SV Krishnan <[e-mail]>
Subject: Re: (usr-tc) 1 ARC - 14 DSPS
Date: 17 Aug 1999 20:29:43 -0500 (CDT)

On Wed, 18 Aug 1999, Jamie Orzechowski wrote:

> Should PPP Offloading be enabled with 14 DSPS being control by one chassis??
>

We had issues with old versions of DSP code with ppp enabling with 2.x
code it is all fixed - PPP should be enabled.

> and 14 DSPS takes up more than one class C ... so would I have my first IP
> pool (entre class c) sent on eth0 and then have the remaning IP's on eth1??
> or can you have 2 ippools on the same interface?
>

Thats up to you on how well you want to do it and depends a lot on your
network design.

krish

>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: Hofmann <[e-mail]>
Subject: RE: (usr-tc) Internic
Date: 18 Aug 1999 09:40:09 -0400

What we've seen the last couple days has been attributed to folks not paying the internic bill.  Go figure, they want you to pay to play :)


This being my most technically capable mailing list :), I thought I
would ask this off-topic qustion.  Has anyone else observed problems
with Internic the last few days.  Root servers are timing out, domains
are being dropped off the servers.  We had 20 domains yesterday that
were just gone from the root servers that we complained to Internic
about.  Today, the list is down to five.  Our support people have heard
from people of many domains that have been unreachable the last couple
days.  Seems like these widespread problems would have been headline
news.

Jay Hofmann                                     Email: [e-mail]
Technical Support Team Leader               Voice: [phone]
IgLou Internet Services                            [phone]




-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: <[e-mail]>
Subject: Re: (usr-tc) NFAS on DSPs
Date: 18 Aug 1999 09:40:51 -0400 (EDT)


    Matt,

  We are currently running 3 DSPs with NFAS.  It was very simple to set
up...  You do need to make sure that the DSPs are in the same NFAS Group.
We identified the first ones a 1.  I believe 3Com say 0, but it does NOT
matter as long as all the DSPs are inthe same NFAS group.  The NFAS ID is
also important.  Make sure your have the 24th span set to NONE

  Hope this helps!

==============================================================================
Phillip Ferraro                WorldNet Access, Inc
[e-mail]    Onslow County's PREMIER InterNet Service
Voice [phone]            824 Gumbranch Square, Suite R3
FAX   [phone]             Jacksonville, Nc  28540-6269
==============================================================================

On Wed, 18 Aug 1999, Stainforth, Matthew wrote:

>
> I just swapped out a dual PRI card and a set of quads for two DSPs and I'm
> trying to do NFAS.  The telco sees the D channel up and the channels are all
> supposedly up and idle but the second card is reporting the D channel is
> down.  Is this normal since the D channel is on the first PRI span or does
> it indicate a problem?
>
> At first I had the NFAS ID wrong on the second DSP.  When I brought it up,
> it was reporting all channels were in service and idle.  I thought that was
> rather strange and I knew it was wrong since I verified this with the telco.
> I set it to the correct value, rebooted the card, and it is still reporting
> all channels in service and idle.
>
> I'm still waiting on hold to get the switch techs to try putting some
> channels into IMB and see if I see them go out of service on this end
> (which, to me, would indicate that the second card is getting the signalling
> information ok) but surely there's an easier way to see if signalling is
> getting to the second card or not...
>
> Matthew...
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: Jim Johnson <[e-mail]>
Subject: Re: (usr-tc) Internic
Date: 18 Aug 1999 09:45:22 -0400



I don't think that is what we have been seeing.  I miss the status field
they use to display on WHOIS. :(

Jim

Hofmann wrote:
>
> What we've seen the last couple days has been attributed to folks not paying the internic bill.  Go figure, they want you to pay to play :)
>
> This being my most technically capable mailing list :), I thought I
> would ask this off-topic qustion.  Has anyone else observed problems
> with Internic the last few days.  Root servers are timing out, domains
> are being dropped off the servers.  We had 20 domains yesterday that
> were just gone from the root servers that we complained to Internic
> about.  Today, the list is down to five.  Our support people have heard
> from people of many domains that have been unreachable the last couple
> days.  Seems like these widespread problems would have been headline
> news.
>
> Jay Hofmann                                             Email: [e-mail]
> Technical Support Team Leader                   Voice: [phone]
> IgLou Internet Services                         [phone]
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: "John Verreault" <[e-mail]>
Subject: (usr-tc) 1 ARC - 14 DSP's
Date: 18 Aug 1999 09:56:06 -0400

Are there any performance degradations with 1 ARC & 14 DSP's.
ie. What kind of performance hit do you take with this config as opposed to
2 ARC's & 14 DSP's.

Also, at what point does 1 ARC degrade in performance (6 DSP's, 10 DSP's
,....???)

This is assuming IP traffic only.

Thanks
John

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Tatai SV Krishnan
> Sent: Tuesday, August 17, 1999 10:48 AM
> To: Jamie Orzechowski
> Cc: [e-mail]
> Subject: Re: (usr-tc) 2 ARC's - one chassis
>
>
> On Tue, 17 Aug 1999, Jamie Orzechowski wrote:
>
> > I would just like to know if one ARC can even handle 14 DSP's
> or should I
> > use 2 ARCS?
> >
>
> A single ARC can handle 14 DSP as long as you are not using IPX.  With
> IPX enabled (IP and IPX both) we recommend only 7 DSP per ARC.
>
> krish
>
> >
> > -
> >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> >  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 "[e-mail]"
>  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 "[e-mail]"
 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: Kevin Benton <[e-mail]>
Subject: (usr-tc) DSP Signal Levels
Date: 18 Aug 1999 10:34:56 -0400 (EDT)

For those who didn't know, the DSP's finally have the ability to adjust
the transmit gain level.  We've been having problems with *some* cities
where the levels appear to be too high when calling locally, but when
calling via an IXC, things work fine (probably because the IXC's equipment
is padding the signal 3db).  Since we now have this ability, we've been
able to resolve problems with signal coming from our equipment that's been
too hot for the customer's modems.

Kevin Benton
SOTA Technologies

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


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Robert von Bismarck <[e-mail]>
Subject: RE: (usr-tc) Internic
Date: 18 Aug 1999 17:02:56 +0200

Yeah, same here, some root servers know about a domain, some don't. =
They
seem out of synch. Little reboot needed I'd say ;-)

Robert

    -----Original Message-----
    From:    Jim Johnson [SMTP:[e-mail]]
    Sent:    mercredi, 18. ao=FBt 1999 15:45
    To:    [e-mail]
    Subject:    Re: (usr-tc) Internic



    I don't think that is what we have been seeing.  I miss the status
field
    they use to display on WHOIS. :(

    Jim

    Hofmann wrote:
    >=20
    > What we've seen the last couple days has been attributed to folks
not paying the internic bill.  Go figure, they want you to pay to play =
:)
    >=20
    > This being my most technically capable mailing list :), I thought
I
    > would ask this off-topic qustion.  Has anyone else observed
problems
    > with Internic the last few days.  Root servers are timing out,
domains
    > are being dropped off the servers.  We had 20 domains yesterday
that
    > were just gone from the root servers that we complained to
Internic
    > about.  Today, the list is down to five.  Our support people have
heard
    > from people of many domains that have been unreachable the last
couple
    > days.  Seems like these widespread problems would have been
headline
    > news.
    >=20
    > Jay Hofmann                                             Email:
[e-mail]
    > Technical Support Team Leader                   Voice: (502)
966-3848
    > IgLou Internet Services                         [phone]
    >=20
    > -
    >  To unsubscribe to usr-tc, send an email to
"[e-mail]"
    >  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 "[e-mail]"
     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 "[e-mail]"
 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: "Mike Wronski" <[e-mail]>
Subject: RE: (usr-tc) 1 ARC - 14 DSPS
Date: 18 Aug 1999 10:16:54 -0500


|Regardless though...ip pools aren't assigned to an interface, they're
|just defined on the Arc.  If you're depending on the Arc to proxy arp
|for the ip addresses in the pools, then you'll need to define another
|network on the ethernet interface that includes the second ip pool.

Whats that about? You dont need to define another network. Just tell the HARC to
proxy-arp for all of its pool addresses "ENABLE IP PROXY_ARP_ALL_DIALIN".

-M


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Jamie Orzechowski" <[e-mail]>
Subject: Re: (usr-tc) 2 ARC's - one chassis
Date: 18 Aug 1999 11:26:05 -0400

DITTO!!

----- Original Message -----
Sent: Wednesday, August 18, 1999 8:29 AM


>
> Maybe 3COM should look at the concept of a real Fault tolerant
> configuration.
>
> It could be as easy as put a second card in and identify it as a
> BACKUP.
>
>     set chassis slot 2 ARC_Backup
>
> The other ARC could mirror its config onto the backup automatically.
>
> If the primary failed, the backup takes over as a clone of the primary.
>
> Jim
>
>
> Jason Kelton wrote:
> >
> > Aaron,
> >
> > > The only obvious solution is to assign 2x the number of addresses to
each
> > > ARC, or use some kind of radius-based IP address resource allocation.
> >
> > Resource Assignement via Radius would appear to be more appropriate
these
> > days in any case.  It means you handle the entire client-side's access
and
> > IP Assignment from within Radius.
> >
> > Seems to me like a more centralised approach!
> >
> > - Jason.
> >
> > -
> >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> >  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 "[e-mail]"
>  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 "[e-mail]"
 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: "Marshall Morgan" <[e-mail]>
Subject: (usr-tc) DNIS not working on PRI
Date: 18 Aug 1999 10:24:37 -0500

We are using Bellsouth provided PRI's in 6 different cities and cannot seem to
get DNIS information sent to us over many of them.  Modems are DSP 2.0.81 and
DualPRI 3.1.5 on ARC 4.1.59-6.  I haved talked to them on many occasions but
cannot seem to get anywhere.  What should I look to first?  The DSP/DPI cards
are set at factory defaults and there is no difference in code/settings between
city1 and city4 but one works?!

Looks like telco to me but I would like to know if over PRI anything else needs
to be checked on my side.  Any ideas?

City1:
        Calling-Station-Id = "2288977988"
        Called-Station-Id = ""

City2:
        Calling-Station-Id = "6014854289"
        Called-Station-Id = ""

City3:
        Calling-Station-Id = "6012667011"
        Called-Station-Id = ""

City4:
        Calling-Station-Id = "6629632985"
        Called-Station-Id = "8426002"

City5:
        Calling-Station-Id = "6017316412"
        Called-Station-Id = ""

City6:
        Calling-Station-Id = "6622366776"
        Called-Station-Id = ""

Marshall Morgan

Internet Doorway, Inc (aka NETDOOR)
http://www.netdoor.com



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) 1 ARC - 14 DSPS
Date: 18 Aug 1999 11:26:46 -0400 (EDT)

Thus spake Mike Wronski
>|Regardless though...ip pools aren't assigned to an interface, they're
>|just defined on the Arc.  If you're depending on the Arc to proxy arp
>|for the ip addresses in the pools, then you'll need to define another
>|network on the ethernet interface that includes the second ip pool.

>Whats that about? You dont need to define another network. Just tell
>the HARC to proxy-arp for all of its pool addresses "ENABLE IP
>PROXY_ARP_ALL_DIALIN".

Hrmm...I guess that's my thing to learn for today.  :)
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Michael DeMan" <[e-mail]>
Subject: (usr-tc) ARC flash going bad
Date: 18 Aug 1999 08:28:00 -0700

We've had a problem in the past two days with our flash going bad in our
HiperArc unit.  Is this indiciative of a failing card or is there perhaps
another issue we can look into.  This happened two evenings ago, and just
about an hour ago this morning (Wednesday).

We are running ARC 4.1.59, with hardware revision 19.0.0.

- mike

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Mike Andrews <[e-mail]>
Subject: Re: (usr-tc) 1 ARC - 14 DSPS
Date: 18 Aug 1999 11:30:15 -0400 (EDT)

On Wed, 18 Aug 1999, Jamie Orzechowski wrote:

> and 14 DSPS takes up more than one class C ... so would I have my first IP
> pool (entre class c) sent on eth0 and then have the remaning IP's on eth1??
> or can you have 2 ippools on the same interface?

I've had 3 IP pools on one interface without having to do anything
special.  Just add the pool and set 'route aggregate' on each one.  The
ARC announces an aggregate route for the pool via OSPF (yes, I'm living
dangerously on 4.2.29 still) so everything just does the right thing.
Before OSPF I was using static routes on a Cisco to get it there because I
didn't really feel like screwing with RIPv2 at that level.

For 14 DSP's, I figure three pools of a /24, a /26, and a /28 would cover
everything efficiently plus a little wiggle room left over.  That's for
PRI though, CT1 would need more I guess... haven't worked out that one
because we don't use CT1 anywhere.


Mike Andrews (MA12) -=-=-  VP & Sysadmin, Digital Crescent, Frankfort KY
[e-mail]  -=--=-  [e-mail]  -=--=-  http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Mike Wronski" <[e-mail]>
Subject: (usr-tc) RE: ARC flash going bad
Date: 18 Aug 1999 10:36:32 -0500



|-----Original Message-----
|From: [e-mail]
|[mailto:[e-mail]]On Behalf Of Michael DeMan
|Sent: Wednesday, August 18, 1999 10:28 AM
|To: [e-mail]
|Subject: (usr-tc) ARC flash going bad
|
|
|We've had a problem in the past two days with our flash going bad in our
|HiperArc unit.  Is this indiciative of a failing card or is there perhaps
|another issue we can look into.  This happened two evenings ago, and just
|about an hour ago this morning (Wednesday).
|
|We are running ARC 4.1.59, with hardware revision 19.0.0.
|

How are you determining that the flash is "bad"? Are you losing configs? Seeing
strange behavior?
The are cases where flash can get corrurpted. This rarly happens, but you can
correct it by flashing code to the card via the console port and using the token
"AT{ZF}" instead of "AT{Z}" to start the Z-Modem SDL2 download..
You will have to reconfigure the card after this procedure.

-M


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: (usr-tc) TRAP disconnect reasons
Date: 18 Aug 1999 12:26:26 -0400 (EDT)

Anyone figure out why ALL modem failure reasons are always 0?

enterprises.usr.nas.mdm.mdmCs.mdmCsTable.mdmCsEntry.mdmCsConnectFailReason.1
= 0,

The reference chp 24 "Modem Disconnect and Fail to Connect Reasons" starts
at drtDrop(1) and is only for the Quad modems????

TCM reports a variety of call failure types, but traps don't.


Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax [phone]
[e-mail]


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Michael DeMan" <[e-mail]>
Subject: Re: (usr-tc) RE: ARC flash going bad
Date: 18 Aug 1999 09:32:01 -0700

Yes,

    The flash was corrupted to the point where the card wouldn't boot - we
have had to do a tftp download to restore the flash twice now.  Basically it
boots up through the ROM, but when it gets to 'autoloading flash' it fails.
After the first failure it ran for about 24 hours, and then started
rebooting by itself again - the reboots again resulting in problems with the
flash - CRC checks on it.  I was able to recover the system quickly the
second time (1/2 hour) but obviously this isn't the solution.  We've never
had this happen before, and have been running the 4.1.59 code for over a
month so I don't think it's a problem with that.

    We had also thought that maybe it was the new 'telnet' hack being
exploited, but I have telnet shut off completely as of yesterday and am
coming into the unit via the serial port.

    I seem to recall some postings somewhere a long time ago (6 mos?) about
a similar problem with the flash getting corrupted but can't find them in
any archives.

----------
>From: "Mike Wronski" <[e-mail]>
>To: <[e-mail]>
>Subject: (usr-tc) RE: ARC flash going bad
>Date: Wed, Aug 18, 1999, 8:36 AM
>

>
>
>|-----Original Message-----
>|From: [e-mail]
>|[mailto:[e-mail]]On Behalf Of Michael DeMan
>|Sent: Wednesday, August 18, 1999 10:28 AM
>|To: [e-mail]
>|Subject: (usr-tc) ARC flash going bad
>|
>|
>|We've had a problem in the past two days with our flash going bad in our
>|HiperArc unit.  Is this indiciative of a failing card or is there perhaps
>|another issue we can look into.  This happened two evenings ago, and just
>|about an hour ago this morning (Wednesday).
>|
>|We are running ARC 4.1.59, with hardware revision 19.0.0.
>|
>
>How are you determining that the flash is "bad"? Are you losing configs? Seeing
>strange behavior?
>The are cases where flash can get corrurpted. This rarly happens, but you can
>correct it by flashing code to the card via the console port and using the token
>"AT{ZF}" instead of "AT{Z}" to start the Z-Modem SDL2 download..
>You will have to reconfigure the card after this procedure.
>
>-M
>
>
>-
> To unsubscribe to usr-tc, send an email to "[e-mail]"
> 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 "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) TRAP disconnect reasons
Date: 18 Aug 1999 12:32:32 -0400 (EDT)

Thus spake Paul Farber
>Anyone figure out why ALL modem failure reasons are always 0?

>enterprises.usr.nas.mdm.mdmCs.mdmCsTable.mdmCsEntry.mdmCsConnectFailReason.1
>= 0,

Well...not sure exactly what you're getting at here, but keep in mind
that the mdmCs tree is for the current or last call.  Basically, these
values are reset at the beginning of each call, so if there is a call
currently connected, the connectfailreason will be none because the
current call didn't fail to connect.  If the modem is idle, the
connectfailreason will be none if the last call did successfully
connect, but will be something different if the last call was a failed
call.

(Note...I haven't experienced this personally...going on my
understanding of how the mib trees function within the TC equipment)

>The reference chp 24 "Modem Disconnect and Fail to Connect Reasons" starts
>at drtDrop(1) and is only for the Quad modems????

Not sure what you mean by "is only for the Quad modems."  I believe at
least the 1.2.43 code has an off-by-error in it for these values...you
have to subtract one from the value being reported via snmp to get the
actual value from DSP's.  I *think* the quads report it correctly (ie,
not off-by-one)
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Scott Trautman <[e-mail]>
Subject: (usr-tc) Interface load SNMP data on Netservers?
Date: 18 Aug 1999 11:48:07 -0500

Sooo...to explain the inevitable question about why using a Netserver rather
than ARC's for this...

I tried PRIME on HiperDSP/ARC for ISDN. Beyond some really strange behavior
whereby ISDN customers w/two channels would be admin reset about every 2
minutes, figured out that using TSMON for ISDN and modems together would be
pretty much impossible with the way TSMON works and way ARC's show user
connections anyway. Oh well.

I've put the PRIME (for ISDN only mind you) on a chassis with Netserver,
Dual T1 card. Workin' like a charm. But, we'd desire to get byte flow
information from the individual interfaces, as we do via PM*'s, and actually
no problem with ARC's, but just can't seem to get much of any SNMP response
from Netservers even though SNMP is turned on.

Any ideas? Zat just the way it works? In the next release of Netserver code?
(joke..I make joke...I know I know already..)

Thanks!

SMT


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 "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) TRAP disconnect reasons
Date: 18 Aug 1999 12:53:42 -0400 (EDT)

But wouldn't the trap have to have the correct call fail reason?  The call
failure is what triggered the trap.

As for off by on.. that would make the vaule -1 (0 - 1 = -1).

TCM seems to have at least different reasons for call failures... no way
to be sure they are correct... but at least they change.

Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax [phone]
[e-mail]

On Wed, 18 Aug 1999, Jeff Mcadams wrote:

> Thus spake Paul Farber
> >Anyone figure out why ALL modem failure reasons are always 0?
>
> >enterprises.usr.nas.mdm.mdmCs.mdmCsTable.mdmCsEntry.mdmCsConnectFailReason.1
> >= 0,
>
> Well...not sure exactly what you're getting at here, but keep in mind
> that the mdmCs tree is for the current or last call.  Basically, these
> values are reset at the beginning of each call, so if there is a call
> currently connected, the connectfailreason will be none because the
> current call didn't fail to connect.  If the modem is idle, the
> connectfailreason will be none if the last call did successfully
> connect, but will be something different if the last call was a failed
> call.
>
> (Note...I haven't experienced this personally...going on my
> understanding of how the mib trees function within the TC equipment)
>
> >The reference chp 24 "Modem Disconnect and Fail to Connect Reasons" starts
> >at drtDrop(1) and is only for the Quad modems????
>
> Not sure what you mean by "is only for the Quad modems."  I believe at
> least the 1.2.43 code has an off-by-error in it for these values...you
> have to subtract one from the value being reported via snmp to get the
> actual value from DSP's.  I *think* the quads report it correctly (ie,
> not off-by-one)
> --
> Jeff McAdams                            Email: [e-mail]
> Head Network Administrator              Voice: [phone]
> IgLou Internet Services                        [phone]
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) Interface load SNMP data on Netservers?
Date: 18 Aug 1999 13:07:37 -0400 (EDT)

Thus spake Scott Trautman
>I've put the PRIME (for ISDN only mind you) on a chassis with Netserver,
>Dual T1 card. Workin' like a charm. But, we'd desire to get byte flow
>information from the individual interfaces, as we do via PM*'s, and actually
>no problem with ARC's, but just can't seem to get much of any SNMP response
>from Netservers even though SNMP is turned on.

>Any ideas? Zat just the way it works? In the next release of Netserver code?
>(joke..I make joke...I know I know already..)

Heh...good joke...too bad its on all of us.  :)

To answer your question....the NETServer only supports bare-bones
MIB-II, so you'll get nothing out of the enterprises tree at all.  I
believe MIB-II does include byte counts on interfaces...though its
cumulative, so you'll have to figure out how to correlate that to
individual users.  :/  Not pretty, but you might be able to do what you
need with it.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) TRAP disconnect reasons
Date: 18 Aug 1999 13:18:35 -0400 (EDT)

Thus spake Paul Farber
>But wouldn't the trap have to have the correct call fail reason?  The call
>failure is what triggered the trap.

Ah...you're dealing with traps...I missed that part....

I don't see any traps that include mdmCsConnectFailReason in them...
RADIUS logging from the NMC includes the equivalent value in there with
some of its logs, but it doesn't seem to be sent with any actual SNMP
traps from what I can see...perhaps I'm wrong though.

>As for off by on.. that would make the vaule -1 (0 - 1 = -1).

But the number in the mib file that I have starts with 1, not
0...perhaps we're looking at different mib files?  not sure.  We seem to
be talking past each other, but I'm not sure why...

>TCM seems to have at least different reasons for call failures... no way
>to be sure they are correct... but at least they change.

Hrmm...I'm pretty sure TCM doesn't pull it from traps, it just polls,
but I'm not sure what its pulling.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Eric Billeter" <[e-mail]>
Subject: RE: (usr-tc) Bad Modem monitoring
Date: 18 Aug 1999 10:17:08 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_1E23_01BEE962.D4ED9780
Content-Type: text/plain;
    charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Here is an updated version with mail notification.

I am using ntsendmail.pm which is available at
You will need to place ntsendmail.pm in your \perl\lib directory.

http://www.alliancestudio.com/tk/ntsendmail/

Modify the values in the script for each site you want to monitor

$ENV{"NTsendmail"} = "My.mailserver.com";       #Enter your Mail Server Here

my $community="public";                         # Your community String
my $router = "127.0.0.1";                       # IP Address of NMC
my $outputfile = "modem-fail.htm";              # File to output to
my $location = "Phoenix";                       # Location Descriptor
my $sender = "tech\@mycompany.com";             # Mail From (use \@ in mail
address)
my $recipient = "tech\@mycompany.com";          # Mail To (use \@ in mail
address)
my $subject = "$location modems";               # Mail Subject

For errored status I'm using 15% for my threshold.  You can change it on
this line.

        if (@callfail[$i-1] > (@callok[$i-1])*.15) {


Again.. if there are any perl guru's out there who could clean this up it
would be appreciated.

Thanks


Eric Billeter
Internet Engineer
Cable One, Inc.

[e-mail]
602-364-6462

------=_NextPart_000_1E23_01BEE962.D4ED9780
Content-Type: application/octet-stream;
    name="badmodems.pl"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
    filename="badmodems.pl"

#!c:\perl\bin

# badmodems.pl
# Checks to see if more than 15 % of calls have failed.
# Will email to $recipient an alert with information on failed modems



use SNMP_Session;
use BER;
use Socket;
use strict;
use NTsendmail;


$ENV{"NTsendmail"} =3D "My.mailserver.com";       #Enter your Mail =
Server Here
my $mail =3D new NTsendmail;                      #Do not change this =
line




%snmpget::OIDS =3D (  'OID1' =3D>  '1.3.6.1.4.1.429.1.6.10.1.1.24',
                    'OID2' =3D>  '1.3.6.1.4.1.429.1.6.10.1.1.4',
                 );
my $community=3D"public";                         # Your community =
String
my $router =3D "127.0.0.1";                       # IP Address of NMC
my $outputfile =3D "modem-fail.htm";              # File to output to=20
my $location =3D "Phoenix";                       # Location Descriptor
my $sender =3D "tech\@mycompany.com";             # Mail From (use \@ in =
mail address)
my $recipient =3D "tech\@mycompany.com";          # Mail To (use \@ in =
mail address)
my $subject =3D "$location modems";               # Mail Subject=20


my @callok;
my @callfail;
my($sysName,$sysUptime,$interfaces,$value1,$value2) =3D
    =
snmpgettable($router,$community,'OID1'),snmpgettable2($router,$community,=
'OID2');
my $i;
my $slot;
my $modem;
my $modemcount =3D @callok + 0 ;
open FILE, ">$outputfile";
#print FILE "Content-Type: text/html\n\n";=09
print FILE  "<HEAD><TITLE>Modem Report for $location</TITLE></HEAD>\n";
print FILE  "<BODY><HTML>\n";
print FILE "<TABLE>";
print FILE "<TR><TD width=3D15%>Slot</TD><TD width=3D10%></TD><TD =
width=3D15%>Modem<TD width=3D20%></TD><TD width=3D15%>Incoming</TD><TD =
width=3D25%>Failed</TD></TR>";
print FILE =
"<TR><TD></TD><TD></TD><TD><TD></TD><TD>Calls</TD><TD>Calls</TD></TR>";=20
print FILE "<TR></TR>";
for $i ( 1 .. $modemcount) {

    $slot=3Dint (($i-1)/24)+1;
    $modem=3Dint ($i-(($slot-1)*24));

        if (@callfail[$i-1] > (@callok[$i-1])*.15) {
        print FILE  "<TR bgcolor=3D#ff6600><TD><b>";
        my $message=3D"$location Slot $slot Modem $modem is failing";
        $mail->send($sender, $recipient, $subject, $message);=20

        }

        else {
        print FILE "<TR><TD>";
        }

    print FILE  "SLOT</TD><TD> ",$slot,"</TD><TD>";
    print FILE  "     Modem</TD><TD> ",$modem,"</TD><TD>";
    print FILE  @callok[$i-1],"</TD><TD>",@callfail[$i-1],;
=09
#    if (@callfail[$i-1] > @callok[$i-1]) {
#    print FILE  "</b>";
#    }

    print FILE  "\n</TD></TR>";
    }

print FILE  "</TABLE></html></body>";
close FILE;

exit(0);

sub snmpgettable{
  my($host,$community,$var) =3D @_;
  my($next_oid,$enoid,$orig_oid,=20
     $response, $bindings, $binding, $value, $inoid,$outoid,
     $upoid,$oid,@table,$tempo);
  die "Unknown SNMP var $var\n"=20
    unless $snmpget::OIDS{$var};
 =20
  $orig_oid =3D encode_oid(split /\./, $snmpget::OIDS{$var});
  $enoid=3D$orig_oid;
  srand();
  my $session =3D SNMP_Session->open ($host ,
                                 $community,=20
                                 161);
  for(;;)  {
    if ($session->getnext_request_response(($enoid))) {
      $response =3D $session->pdu_buffer;
      ($bindings) =3D $session->decode_get_response ($response);
      ($binding,$bindings) =3D decode_sequence ($bindings);
      ($next_oid,$value) =3D decode_by_template ($binding, "%O%@");
      # quit once we are outside the table
      last unless BER::encoded_oid_prefix_p($orig_oid,$next_oid);
      $tempo =3D pretty_print($value);
    push @callfail, $tempo;
        $value1=3D$value1 + $tempo ;

      $tempo=3D~s/\t/ /g;
      $tempo=3D~s/\n/ /g;
      $tempo=3D~s/^\s+//;
      $tempo=3D~s/\s+$//;
      push @table, $tempo;
    } else {
      die "No answer from $ARGV[0]\n";
    }
    $enoid=3D$next_oid;
  }
  $session->close ();=20
if( $value1 eq ''){$value1 =3D 0 };
  return (@table);
}
sub snmpgettable2{
  my($host,$community,$var) =3D @_;
  my($next_oid,$enoid,$orig_oid,=20
     $response, $bindings, $binding, $value, $inoid,$outoid,
     $upoid,$oid,@table,$tempo);
  die "Unknown SNMP var $var\n"=20
    unless $snmpget::OIDS{$var};
 =20
  $orig_oid =3D encode_oid(split /\./, $snmpget::OIDS{$var});
  $enoid=3D$orig_oid;
  srand();
  my $session =3D SNMP_Session->open ($host ,
                                 $community,=20
                                 161);
  for(;;)  {
    if ($session->getnext_request_response(($enoid))) {
      $response =3D $session->pdu_buffer;
      ($bindings) =3D $session->decode_get_response ($response);
      ($binding,$bindings) =3D decode_sequence ($bindings);
      ($next_oid,$value) =3D decode_by_template ($binding, "%O%@");
      # quit once we are outside the table
      last unless BER::encoded_oid_prefix_p($orig_oid,$next_oid);
      $tempo =3D pretty_print($value);
    push @callok, $tempo;
      $value2=3D$value2 + $tempo ;
      $tempo=3D~s/\t/ /g;
      $tempo=3D~s/\n/ /g;
      $tempo=3D~s/^\s+//;
      $tempo=3D~s/\s+$//;
      push @table, $tempo;
    } else {
      die "No answer from $ARGV[0]\n";
    }
    $enoid=3D$next_oid;
  }
  $session->close ();=20
if( $value2 eq ''){$value2 =3D 0 };
  return (@table);
}


------=_NextPart_000_1E23_01BEE962.D4ED9780--




-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Marcelo Souza <[e-mail]>
Subject: (usr-tc) PPP login failed
Date: 18 Aug 1999 14:40:58 -0300 (EST)


Recently I note systematic CRITICAL messages on my HARC syslog like this:


Facility "PPP", Level "CRITICAL":: PPP  login failed on slot:6/mod:13 id:
84677053 username: user

    It comes from all my DSPs on this TC, what does it means?

    HARC 4.1.59-6

- Marcelo


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Mike Wronski" <[e-mail]>
Subject: RE: (usr-tc) RE: ARC flash going bad
Date: 18 Aug 1999 12:55:33 -0500

From your description it sounds like you have defective hardware. Flash ROM chips
are known to fail. I would recommend that you return the card for servicing.

-M


|-----Original Message-----
|From: [e-mail]
|[mailto:[e-mail]]On Behalf Of Michael DeMan
|Sent: Wednesday, August 18, 1999 11:32 AM
|To: [e-mail]
|Subject: Re: (usr-tc) RE: ARC flash going bad
|
|
|Yes,
|
|    The flash was corrupted to the point where the card wouldn't boot - we
|have had to do a tftp download to restore the flash twice now.  Basically it
|boots up through the ROM, but when it gets to 'autoloading flash' it fails.
|After the first failure it ran for about 24 hours, and then started
|rebooting by itself again - the reboots again resulting in problems with the
|flash - CRC checks on it.  I was able to recover the system quickly the
|second time (1/2 hour) but obviously this isn't the solution.  We've never
|had this happen before, and have been running the 4.1.59 code for over a
|month so I don't think it's a problem with that.
|
|    We had also thought that maybe it was the new 'telnet' hack being
|exploited, but I have telnet shut off completely as of yesterday and am
|coming into the unit via the serial port.
|
|    I seem to recall some postings somewhere a long time ago (6 mos?) about
|a similar problem with the flash getting corrupted but can't find them in
|any archives.
|
|----------
|>From: "Mike Wronski" <[e-mail]>
|>To: <[e-mail]>
|>Subject: (usr-tc) RE: ARC flash going bad
|>Date: Wed, Aug 18, 1999, 8:36 AM
|>
|
|>
|>
|>|-----Original Message-----
|>|From: [e-mail]
|>|[mailto:[e-mail]]On Behalf Of Michael DeMan
|>|Sent: Wednesday, August 18, 1999 10:28 AM
|>|To: [e-mail]
|>|Subject: (usr-tc) ARC flash going bad
|>|
|>|
|>|We've had a problem in the past two days with our flash going bad in our
|>|HiperArc unit.  Is this indiciative of a failing card or is there perhaps
|>|another issue we can look into.  This happened two evenings ago, and just
|>|about an hour ago this morning (Wednesday).
|>|
|>|We are running ARC 4.1.59, with hardware revision 19.0.0.
|>|
|>
|>How are you determining that the flash is "bad"? Are you losing configs? Seeing
|>strange behavior?
|>The are cases where flash can get corrurpted. This rarly happens, but you can
|>correct it by flashing code to the card via the console port and using
|the token
|>"AT{ZF}" instead of "AT{Z}" to start the Z-Modem SDL2 download..
|>You will have to reconfigure the card after this procedure.
|>
|>-M
|>
|>
|>-
|> To unsubscribe to usr-tc, send an email to "[e-mail]"
|> 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 "[e-mail]"
| 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 "[e-mail]"
 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: Aaron Nabil <[e-mail]>
Subject: Re: (usr-tc) DSP Signal Levels
Date: 18 Aug 1999 14:02:42 -0700 (PDT)

Kevin Benton writes...
>For those who didn't know, the DSP's finally have the ability to adjust
>the transmit gain level.  We've been having problems with *some* cities
>where the levels appear to be too high when calling locally, but when
>calling via an IXC, things work fine (probably because the IXC's equipment
>is padding the signal 3db).  Since we now have this ability, we've been
>able to resolve problems with signal coming from our equipment that's been
>too hot for the customer's modems.

IXCs don't pad.  The LEC pads the trunks coming in from the IXC, the
spec is 6db.  So when you call through a IXC, you get padding, but it's
not the IXC.

The LEC is supposed to pad your local trunks 3db.  In the cities you are
having problems, what's probably happening is they don't have any
padding for you where it should be.

I'm sorry to say it will be virtually impossible (for purely NON-technical
reasons, alas) for you to get this fixed.

--
Aaron Nabil

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: K Mitchell <[e-mail]>
Subject: (usr-tc) Another dead ISDN link
Date: 18 Aug 1999 17:10:22 -0400

  ISDN connection with a Cisco 804 on a static IP address. He has the IP
assigned to him, but the connection can't seem to pass any traffic.
Terminated the connection and reconnected, still nothing. Actually there is
traffic on the line per MON PPP, but pings aren't going either way and the
customer claims to be unable to pass any http traffic either.
  Running
DSP 1.2.60
ARC 4.1.59-6

Any ideas?
Thanks,
Kirk


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


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) Another dead ISDN link
Date: 18 Aug 1999 17:18:16 -0400 (EDT)

Thus spake K Mitchell
>  ISDN connection with a Cisco 804 on a static IP address. He has the IP
>assigned to him, but the connection can't seem to pass any traffic.
>Terminated the connection and reconnected, still nothing. Actually there is
>traffic on the line per MON PPP, but pings aren't going either way and the
>customer claims to be unable to pass any http traffic either.
>  Running
>DSP 1.2.60
>ARC 4.1.59-6

I'm curious what mon ppp is showing....care to paste some of it?  Don't
know if it'll help, but I'd be curious as to what's there.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: K Mitchell <[e-mail]>
Subject: Re: (usr-tc) Another dead ISDN link
Date: 18 Aug 1999 17:43:23 -0400

At 05:18 PM 8/18/99 -0400, Jeff wrote:
>I'm curious what mon ppp is showing....care to paste some of it?  Don't
>know if it'll help, but I'd be curious as to what's there.

Happy to if it'll help  :)

Decode tracing started, press ESCAPE to stop; press X for hex tracing.

Incoming PPP Data on interface: slot:1/mod:11
    LCP        ECHO_REQ          6b 76 33 95 00 00 00 00 cc ab 1f 7c

Outgoing PPP Data on interface: slot:1/mod:11
    LCP        ECHO_RPLY         66 f8 8c 7d 00 00 00 00

Incoming PPP Data on interface: slot:1/mod:11
    LCP        ECHO_REQ          6b 76 33 95 00 00 00 00 cc ab 1f 96

Outgoing PPP Data on interface: slot:1/mod:11
    LCP        ECHO_RPLY         66 f8 8c 7d 00 00 00 00
Tracing changed to hex dumps; press Escape to stop; press D for decode
tracing.

Incoming PPP Data on interface: slot:1/mod:11
    ff 03 c0 21 09 18 00 0c 6b 76 33 95 00 00 00 00 |   !    kv3     |


Outgoing PPP Data on interface: slot:1/mod:11
    ff 03 c0 21 0a 18 00 0c 66 f8 8c 7d 00 00 00 00 |   !    f  }    |


Incoming PPP Data on interface: slot:1/mod:11
    ff 03 00 21 45 00 02 1c 73 9e 00 00 7f 11 74 4b |   !E   s     tK|
    cc ab 1f c9 01 02 64 71 0b fd 0b fd 02 08 6d dc |      dq      m |
    fe 00 23 31 37 32 2e 31 36 00 00 00 00 00 00 00 |  #172.16       |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 31 37 32 2e 31 36 2e 31 2e 31 30 00 00 |   172.16.1.10  |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 33 30 36 39 00 00 00 00 00 00 00 00 00 |   3069         |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |


Outgoing PPP Data on interface: slot:1/mod:11
    ff 03 00 21 45 00 00 38 1f 41 00 00 fc 01 6b bf |   !E  8 A    k |
    82 5e c4 f1 cc ab 1f c9 03 01 75 20 00 00 00 00 | ^        u     |
    45 00 02 1c 73 9e 00 00 7b 11 78 4b cc ab 1f c9 |E   s   { xK    |
    01 02 64 71 0b fd 0b fd 02 08 6d dc             |  dq      m     |


Incoming PPP Data on interface: slot:1/mod:11
    ff 03 c0 21 09 19 00 0c 6b 76 33 95 00 00 00 00 |   !    kv3     |


Outgoing PPP Data on interface: slot:1/mod:11
    ff 03 c0 21 0a 19 00 0c 66 f8 8c 7d 00 00 00 00 |   !    f  }    |

Tracing stopped, Return/Enter to re-start, ESCAPE to quit.
Hex tracing started, press ESCAPE to stop; press D for decode tracing.

Outgoing PPP Data on interface: slot:1/mod:11
    ff 03 00 21 45 00 00 4c e2 7f 00 00 7f 01 81 06 |   !E  L        |
    cc ab 1f 0b cc ab 1f c9 08 00 eb ff 01 00 0b 00 |                |
    aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa |                |
    aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa |                |
    aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa |                |


Incoming PPP Data on interface: slot:1/mod:11
    ff 03 c0 21 09 1b 00 0c 6b 76 33 95 00 00 00 00 |   !    kv3     |


Outgoing PPP Data on interface: slot:1/mod:11
    ff 03 c0 21 0a 1b 00 0c 66 f8 8c 7d 00 00 00 00 |   !    f  }    |


Outgoing PPP Data on interface: slot:1/mod:11
    ff 03 00 21 45 00 00 4c 05 80 00 00 7f 01 5e 06 |   !E  L      ^ |
    cc ab 1f 0b cc ab 1f c9 08 00 ea ff 01 00 0c 00 |                |
    aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa |                |
    aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa |                |
    aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa |                |

Tracing stopped, Return/Enter to re-start, ESCAPE to quit.
Hex tracing started, press ESCAPE to stop; press D for decode tracing.

Outgoing PPP Data on interface: slot:1/mod:11
    ff 03 00 21 45 00 00 4c 08 80 00 00 7f 01 5b 06 |   !E  L      [ |
    cc ab 1f 0b cc ab 1f c9 08 00 e7 ff 01 00 0f 00 |                |
    aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa |                |
    aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa |                |
    aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa |                |


Incoming PPP Data on interface: slot:1/mod:11
    ff 03 c0 21 09 1d 00 0c 6b 76 33 95 00 00 00 00 |   !    kv3     |


Outgoing PPP Data on interface: slot:1/mod:11
    ff 03 c0 21 0a 1d 00 0c 66 f8 8c 7d 00 00 00 00 |   !    f  }    |


Outgoing PPP Data on interface: slot:1/mod:11
    ff 03 00 21 45 00 00 4c 09 80 00 00 7f 01 5a 06 |   !E  L      Z |
    cc ab 1f 0b cc ab 1f c9 08 00 e6 ff 01 00 10 00 |                |
    aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa |                |
    aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa |                |
    aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa |                |


Incoming PPP Data on interface: slot:1/mod:11
    ff 03 00 21 45 00 02 1c 03 9f 00 00 7f 11 e4 4a |   !E          J|
    cc ab 1f c9 01 02 64 71 0b fd 0b fd 02 08 6d dc |      dq      m |
    fe 00 23 31 37 32 2e 31 36 00 00 00 00 00 00 00 |  #172.16       |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 31 37 32 2e 31 36 2e 31 2e 31 30 00 00 |   172.16.1.10  |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 33 30 36 39 00 00 00 00 00 00 00 00 00 |   3069         |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |                |


Outgoing PPP Data on interface: slot:1/mod:11
    ff 03 00 21 45 00 00 38 20 d8 00 00 fc 01 6a 28 |   !E  8      j(|
    82 5e c4 f1 cc ab 1f c9 03 01 75 20 00 00 00 00 | ^        u     |
    45 00 02 1c 03 9f 00 00 7b 11 e8 4a cc ab 1f c9 |E       {  J    |
    01 02 64 71 0b fd 0b fd 02 08 6d dc             |  dq      m     |


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


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Bryan Wann <[e-mail]>
Subject: Re: (usr-tc) RE: ARC flash going bad
Date: 18 Aug 1999 18:24:17 -0500 (CDT)

On Wed, 18 Aug 1999, Michael DeMan wrote:

>     The flash was corrupted to the point where the card wouldn't boot - we
> have had to do a tftp download to restore the flash twice now.  Basically it
> boots up through the ROM, but when it gets to 'autoloading flash' it fails.
> After the first failure it ran for about 24 hours, and then started
> rebooting by itself again - the reboots again resulting in problems with the
> flash - CRC checks on it.  I was able to recover the system quickly the
> second time (1/2 hour) but obviously this isn't the solution.  We've never
> had this happen before, and have been running the 4.1.59 code for over a
> month so I don't think it's a problem with that.
>
>     We had also thought that maybe it was the new 'telnet' hack being
> exploited, but I have telnet shut off completely as of yesterday and am
> coming into the unit via the serial port.
>
>     I seem to recall some postings somewhere a long time ago (6 mos?) about
> a similar problem with the flash getting corrupted but can't find them in
> any archives.


    We had similar problems on a ARC... it just 'forgot' its entire
flash and kept rebooting.  Re-uploaded 4.1.59 to it, worked fine for a few
months, then it happened again.  Only this time, we never could revive
it.. tried tftp, AT{Z}, AT{FZ}, never would stay there, it kept rebooting.
I RMA'd the card, whenever I got it back, repair notes said "Performed ECO
16570, updated code to 4.2.29".  Since then it has worked fine without
problems.  (/me crosses fingers)

    I'm curious, what is "ECO 16570" ?  Sounds like either a
diagnostics test or flash wipe.

    FWIW, 4.2.29 seems to work fine for us, I recall seeing a post
yesterday about it being very unstable.  Handling two DSPs, RIPv2 only,
only about 1/4 channels being used.    (/me crosses fingers again)





---
Bryan Wann        [e-mail]
CWIS Internet Services    http://www.cwis.net


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Brett Murphy" <[e-mail]>
Subject: Re: (usr-tc) Bad Modem monitoring
Date: 19 Aug 1999 10:34:05 +1000

Excuse my ignorance, but my perl doesnt have SNMP_Session, where can I get
it from?

All the best,
Brett Murphy
Technical Manager, Alphalink (Australia) PTY LTD
ph: [phone]  fax: [phone]
email: [e-mail]

The contents of this email message may not be quoted,
copied, reproduced or published in part or in whole,
without the written authorization of Brett Murphy,
Director, Alphalink (Australia) Pty Ltd.
-----Original Message-----


>Here is an updated version with mail notification.
>
>I am using ntsendmail.pm which is available at
>You will need to place ntsendmail.pm in your \perl\lib directory.
>
>http://www.alliancestudio.com/tk/ntsendmail/
>
>Modify the values in the script for each site you want to monitor
>
>$ENV{"NTsendmail"} = "My.mailserver.com";       #Enter your Mail Server
Here
>
>my $community="public";                         # Your community String
>my $router = "127.0.0.1";                       # IP Address of NMC
>my $outputfile = "modem-fail.htm";              # File to output to
>my $location = "Phoenix";                       # Location Descriptor
>my $sender = "tech\@mycompany.com";             # Mail From (use \@ in mail
>address)
>my $recipient = "tech\@mycompany.com";          # Mail To (use \@ in mail
>address)
>my $subject = "$location modems";               # Mail Subject
>
>For errored status I'm using 15% for my threshold.  You can change it on
>this line.
>
> if (@callfail[$i-1] > (@callok[$i-1])*.15) {
>
>
>Again.. if there are any perl guru's out there who could clean this up it
>would be appreciated.
>
>Thanks
>
>
>Eric Billeter
>Internet Engineer
>Cable One, Inc.
>
>[e-mail]
>602-364-6462
>


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) RE: ARC flash going bad
Date: 18 Aug 1999 20:59:37 -0400 (EDT)

Thus spake Bryan Wann
>    I'm curious, what is "ECO 16570" ?  Sounds like either a
>diagnostics test or flash wipe.

I believe ECO stands for "Engineering Change Order."  Typically means a
change in the circuit board or something was made and the ECO is the
"documentation" of sorts about what that change is.  However, not being
an electical engineer, I'm not exactly clear on it.  What this specific
ECO does?  Your guess is as good as mine.  :)
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Ronald Kushner <[e-mail]>
Subject: Re: (usr-tc) RE: ARC flash going bad
Date: 18 Aug 1999 23:09:17 -0400



Bryan Wann wrote:

>
>         I'm curious, what is "ECO 16570" ?  Sounds like either a
> diagnostics test or flash wipe.

ECO is usually an engineering change order #. It's like a service bulletin
for the auto dealers. You follow the directions, and it should fix the
problem.

If they have an ECO, there must have been a run of cards with a problem that
has been identified. It could be anything from a bad IC to a trace needing
to be replaced with a jumper wire because an internal trace was drilled
through in production.

-Ron
GLISnet, Inc.
+1 810/939.9885

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Jason Kelton" <[e-mail]>
Subject: Re: (usr-tc) 2 ARC's - one chassis
Date: 19 Aug 1999 16:01:07 +1000

I have the feeling that true failover (without the loss of calls) could be a
hardware limitation of the chassis.  For true failover, you wouldn't have
everything run across the packetbus - you'd need to create a dual-bus to
pass redundant data to in the event the first arc should fail.  I mean, its
possible, but prolly not within a realistic timeframe...

- Jason...
----- Original Message -----
Sent: Wednesday, August 18, 1999 10:29 PM


>
> Maybe 3COM should look at the concept of a real Fault tolerant
> configuration.
>
> It could be as easy as put a second card in and identify it as a
> BACKUP.
>
>     set chassis slot 2 ARC_Backup
>
> The other ARC could mirror its config onto the backup automatically.
>
> If the primary failed, the backup takes over as a clone of the primary.
>
> Jim
>
>
> Jason Kelton wrote:
> >
> > Aaron,
> >
> > > The only obvious solution is to assign 2x the number of addresses to
each
> > > ARC, or use some kind of radius-based IP address resource allocation.
> >
> > Resource Assignement via Radius would appear to be more appropriate
these
> > days in any case.  It means you handle the entire client-side's access
and
> > IP Assignment from within Radius.
> >
> > Seems to me like a more centralised approach!
> >
> > - Jason.
> >
> > -
> >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> >  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 "[e-mail]"
>  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 "[e-mail]"
 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: Jim Johnson <[e-mail]>
Subject: Re: (usr-tc) 2 ARC's - one chassis
Date: 19 Aug 1999 08:33:57 -0400


True.  But I don't care about keeping the calls open, although that
would be great ;).

I can live with having the backup card actually go through a reboot
cycle if it were necesarry.

Regards,

JIm

Jason Kelton wrote:
>
> I have the feeling that true failover (without the loss of calls) could be a
> hardware limitation of the chassis.  For true failover, you wouldn't have
> everything run across the packetbus - you'd need to create a dual-bus to
> pass redundant data to in the event the first arc should fail.  I mean, its
> possible, but prolly not within a realistic timeframe...
>
> - Jason...
> ----- Original Message -----
> From: Jim Johnson <[e-mail]>
> To: <[e-mail]>
> Sent: Wednesday, August 18, 1999 10:29 PM
> Subject: Re: (usr-tc) 2 ARC's - one chassis
>
> >
> > Maybe 3COM should look at the concept of a real Fault tolerant
> > configuration.
> >
> > It could be as easy as put a second card in and identify it as a
> > BACKUP.
> >
> >     set chassis slot 2 ARC_Backup
> >
> > The other ARC could mirror its config onto the backup automatically.
> >
> > If the primary failed, the backup takes over as a clone of the primary.
> >
> > Jim
> >
> >
> > Jason Kelton wrote:
> > >
> > > Aaron,
> > >
> > > > The only obvious solution is to assign 2x the number of addresses to
> each
> > > > ARC, or use some kind of radius-based IP address resource allocation.
> > >
> > > Resource Assignement via Radius would appear to be more appropriate
> these
> > > days in any case.  It means you handle the entire client-side's access
> and
> > > IP Assignment from within Radius.
> > >
> > > Seems to me like a more centralised approach!
> > >
> > > - Jason.
> > >
> > > -
> > >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> > >  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 "[e-mail]"
> >  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 "[e-mail]"
>  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 "[e-mail]"
 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: Jim Johnson <[e-mail]>
Subject: (usr-tc) Idle-Timeout & Session-Timeout
Date: 19 Aug 1999 12:09:57 -0400



Does the HiperARC suppport Idle-Timeout & Session-Timeout radius
attributes?

Idle-Timeout = max length of time with no activity in secs (I know you
can do this with the default user)
Session-Timeout = max length of time for session in secs

Thanks,

Jim

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Eric Billeter" <[e-mail]>
Subject: RE: (usr-tc) Bad Modem monitoring
Date: 19 Aug 1999 09:57:38 -0700

The SNMP_session and some others are included with MRTG. That's where
I got them from

Eric Billeter
Internet Engineer
Cable One, Inc.

[e-mail]
602-364-6462

-----Original Message-----
[mailto:[e-mail]]On Behalf Of Brett Murphy
Sent: Wednesday, August 18, 1999 5:34 PM


Excuse my ignorance, but my perl doesnt have SNMP_Session, where can I get
it from?

All the best,
Brett Murphy
Technical Manager, Alphalink (Australia) PTY LTD
ph: [phone]  fax: [phone]
email: [e-mail]

The contents of this email message may not be quoted,
copied, reproduced or published in part or in whole,
without the written authorization of Brett Murphy,
Director, Alphalink (Australia) Pty Ltd.
-----Original Message-----


>Here is an updated version with mail notification.
>
>I am using ntsendmail.pm which is available at
>You will need to place ntsendmail.pm in your \perl\lib directory.
>
>http://www.alliancestudio.com/tk/ntsendmail/
>
>Modify the values in the script for each site you want to monitor
>
>$ENV{"NTsendmail"} = "My.mailserver.com";       #Enter your Mail Server
Here
>
>my $community="public";                         # Your community String
>my $router = "127.0.0.1";                       # IP Address of NMC
>my $outputfile = "modem-fail.htm";              # File to output to
>my $location = "Phoenix";                       # Location Descriptor
>my $sender = "tech\@mycompany.com";             # Mail From (use \@ in mail
>address)
>my $recipient = "tech\@mycompany.com";          # Mail To (use \@ in mail
>address)
>my $subject = "$location modems";               # Mail Subject
>
>For errored status I'm using 15% for my threshold.  You can change it on
>this line.
>
> if (@callfail[$i-1] > (@callok[$i-1])*.15) {
>
>
>Again.. if there are any perl guru's out there who could clean this up it
>would be appreciated.
>
>Thanks
>
>
>Eric Billeter
>Internet Engineer
>Cable One, Inc.
>
>[e-mail]
>602-364-6462
>


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 "[e-mail]"
 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: Pete Ashdown <[e-mail]>
Subject: (usr-tc) ISDN callback
Date: 19 Aug 1999 12:02:12 -0600 (MDT)

Has anyone managed to get ISDN callback on the HiPer to work in any form?
Here is a RADIUS entry for our test account:

techmgr       Authentication-Type = Unix-PW
              Framed-IP-Address = 204.228.152.46,
              Framed-IP-Netmask = 255.255.255.255,
              Port-Limit = 3,
              Service-Type = Dialback-Framed,
              Dialback-No = 5551212,
              Idle-Timeout = 0

It dials back just fine, but getting the connection to work at that point
is somewhat of a mystery.

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: <[e-mail]>
Subject: (usr-tc) Idle time
Date: 19 Aug 1999 17:27:07 -0400 (EDT)

Can someone tell how to set up a idle time for a profile that was set up
on the USR itself instead of a UNIX server.

Thanks
Vito


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) Idle time
Date: 19 Aug 1999 17:31:38 -0400 (EDT)

Thus spake [e-mail]
>Can someone tell how to set up a idle time for a profile that was set up
>on the USR itself instead of a UNIX server.

set user bob idle_timeout x
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Jim Johnson <[e-mail]>
Subject: Re: (usr-tc) Idle time
Date: 19 Aug 1999 17:34:15 -0400



Yea.  But why can't I get the ARC to do it from radius?

Jim

Jeff Mcadams wrote:
>
> Thus spake [e-mail]
> >Can someone tell how to set up a idle time for a profile that was set up
> >on the USR itself instead of a UNIX server.
>
> set user bob idle_timeout x
> --
> Jeff McAdams                            Email: [e-mail]
> Head Network Administrator              Voice: [phone]
> IgLou Internet Services                        [phone]
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) Idle time
Date: 19 Aug 1999 17:37:39 -0400 (EDT)

Thus spake Jim Johnson
>Yea.  But why can't I get the ARC to do it from radius?

Well...Vito was specifically asking about setting it up in the USR
directly, not via RADIUS.

Idle-Timeout works marvelously in RADIUS for me.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Ken Kirchner <[e-mail]>
Subject: Re: (usr-tc) Link dead after 8 Days
Date: 19 Aug 1999 17:32:29 -0500 (CDT)

On Tue, 17 Aug 1999, Paul Farber wrote:

> 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.

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.

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

Like a mentioned above, why now?

> 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).

So you just accept this? :)

  ___                                                         ___
 (___) Kenneth Kirchner    .o.  mailto:[e-mail]       (___)
  (__) Asst SysAdmin       .o.  Voice [phone] Ext 108 (__)
   (_) ShreveNet, Inc.     .o.  Fax   [phone]         (_)


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: K Mitchell <[e-mail]>
Subject: Re: (usr-tc) Another dead ISDN link
Date: 20 Aug 1999 07:16:56 -0400

At 05:10 PM 8/18/99 -0400, you wrote:
>  ISDN connection with a Cisco 804 on a static IP address. He has the IP
>assigned to him, but the connection can't seem to pass any traffic.
>Terminated the connection and reconnected, still nothing. Actually there is
>traffic on the line per MON PPP, but pings aren't going either way and the
>customer claims to be unable to pass any http traffic either.

  After an hour on the phone with 3Com support yesterday, this appears to
be a Cisco issue, not the HiPer. Anybody familiar with Cisco 804
configuration know what might be causing this?
  Another weird part of it...Pings won't go either way through the
connection, but traceroutes work fine.

Thanks,
Kirk

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


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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" <[e-mail]>
Subject: (usr-tc) Out Calling
Date: 20 Aug 1999 06:43:38 -0500

This is a multi-part message in MIME format.

------=_NextPart_000_0080_01BEEAD7.552FB250
Content-Type: text/plain;
    charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Ever since we have used out TCs I have been told the it is not possible =
to make on outbound ISDN call.

One of my competitor's is touting this ability (using a =
"state-of-the-art Total Control") and I wonder if I have overlooked =
something.

Any one with knowledge of how to do this?

Samuel S. Lowe
Director, Data Services
UniversalCom, Inc.
[e-mail]


------=_NextPart_000_0080_01BEEAD7.552FB250
Content-Type: text/html;
    charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Ever since we have used out TCs I have been told the =
it is not=20
possible to make on outbound ISDN call.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>One of my competitor's is touting this ability =
(using a=20
"state-of-the-art Total Control") and I wonder if I have overlooked=20
something.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>Any one with knowledge of how to do =
this?</FONT></DIV>
<DIV><FONT size=3D2><BR>Samuel S. Lowe<BR>Director, Data =
Services<BR>UniversalCom,=20
Inc.<BR><A=20
href=3D"mailto:[e-mail]">[e-mail]</A><BR></FO=
NT></DIV></BODY></HTML>

------=_NextPart_000_0080_01BEEAD7.552FB250--


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Jim Johnson <[e-mail]>
Subject: Re: (usr-tc) Idle time
Date: 20 Aug 1999 08:13:41 -0400


What is the dictionary entry for your Idle-Time Attribute?

Jim

Jeff Mcadams wrote:
>
> Thus spake Jim Johnson
> >Yea.  But why can't I get the ARC to do it from radius?
>
> Well...Vito was specifically asking about setting it up in the USR
> directly, not via RADIUS.
>
> Idle-Timeout works marvelously in RADIUS for me.
> --
> Jeff McAdams                            Email: [e-mail]
> Head Network Administrator              Voice: [phone]
> IgLou Internet Services                        [phone]
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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" <[e-mail]>
Subject: Re: (usr-tc) Another dead ISDN link
Date: 20 Aug 1999 07:18:06 -0500

Kirk,

If you'll send me the running-config (sh ru from #prompt) and I'll see if I
can help you.  If might be that you have and access or deny list configured
incorrectly.  It does not sound like a TC problem to me either.

Samuel S. Lowe
Director, Data Services
UniversalCom, Inc.
[e-mail]

----- Original Message -----
Sent: Friday, August 20, 1999 6:16 AM


> At 05:10 PM 8/18/99 -0400, you wrote:
> >  ISDN connection with a Cisco 804 on a static IP address. He has the IP
> >assigned to him, but the connection can't seem to pass any traffic.
> >Terminated the connection and reconnected, still nothing. Actually there
is
> >traffic on the line per MON PPP, but pings aren't going either way and
the
> >customer claims to be unable to pass any http traffic either.
>
>   After an hour on the phone with 3Com support yesterday, this appears to
> be a Cisco issue, not the HiPer. Anybody familiar with Cisco 804
> configuration know what might be causing this?
>   Another weird part of it...Pings won't go either way through the
> connection, but traceroutes work fine.
>
> Thanks,
> Kirk
>
> --
> Kirk Mitchell-General Manager        [e-mail]
> Keystone Connect                     Unlock Your World
> Altoona, PA   814-941-5000      http://www.keyconn.net
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) Idle time
Date: 20 Aug 1999 08:49:05 -0400 (EDT)

Thus spake Jim Johnson
>What is the dictionary entry for your Idle-Time Attribute?

Merit 3.6 something or other.

ATTRIBUTE       Idle-Timeout            28      integer (1, 0)
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Jim Johnson <[e-mail]>
Subject: Re: (usr-tc) Idle time
Date: 20 Aug 1999 09:14:31 -0400


Oh well, that's what we have in our file.

I just started palying with the setting yesterday, and I was trying to
use MON RAD to watch the packets come back for a user and I was not
seeing these attributes sent back.  Shouldn't they show up in the
monitor interface?  Maybe they are being set, but how can you tell short
of just seeing if a conneciton is terminated.

Jim

Jeff Mcadams wrote:
>
> Thus spake Jim Johnson
> >What is the dictionary entry for your Idle-Time Attribute?
>
> Merit 3.6 something or other.
>
> ATTRIBUTE       Idle-Timeout            28      integer (1, 0)
> --
> Jeff McAdams                            Email: [e-mail]
> Head Network Administrator              Voice: [phone]
> IgLou Internet Services                        [phone]
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: Tatai SV Krishnan <[e-mail]>
Subject: Re: (usr-tc) Out Calling
Date: 19 Aug 1999 20:03:54 -0500 (CDT)

On Fri, 20 Aug 1999, Sam Lowe wrote:

> Ever since we have used out TCs I have been told the it is not possible =
> to make on outbound ISDN call.

No you can make an outbound call - In the earlier versions of the hiper
DSP code the autodetection of call type for outbound call was broken, so
you had exclusively set the modem to a particular ISDN type - either sync
or v120 etc.  This has thus been fixed in 2.x release.

krish

>
> One of my competitor's is touting this ability (using a =
> "state-of-the-art Total Control") and I wonder if I have overlooked =
> something.
>
> Any one with knowledge of how to do this?
>
> Samuel S. Lowe
> Director, Data Services
> UniversalCom, Inc.
> [e-mail]
>
>

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) Link dead after 8 Days
Date: 20 Aug 1999 09:41:27 -0400 (EDT)

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 [phone]
[e-mail]

On Thu, 19 Aug 1999, Ken Kirchner wrote:

> On Tue, 17 Aug 1999, Paul Farber wrote:
>
> > 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.
>
> 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.
>
> > I message to netgear tech got me a "reload the flash".. not to helpful.
> > It's not your DSP's... its the Netgear.
>
> Like a mentioned above, why now?
>
> > 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).
>
> So you just accept this? :)
>
>   ___                                                         ___
>  (___) Kenneth Kirchner    .o.  mailto:[e-mail]       (___)
>   (__) Asst SysAdmin       .o.  Voice [phone] Ext 108 (__)
>    (_) ShreveNet, Inc.     .o.  Fax   [phone]         (_)
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: Jim Johnson <[e-mail]>
Subject: Re: (usr-tc) Idle time
Date: 20 Aug 1999 10:04:44 -0400



After idling a connected machine, the Idle-Timeout attribute did work so
I assume the Session-Timeout also works.

I still don't understand why these wouldn't show up in Mon Rad.

Jim

Jim Johnson wrote:
>
> Oh well, that's what we have in our file.
>
> I just started palying with the setting yesterday, and I was trying to
> use MON RAD to watch the packets come back for a user and I was not
> seeing these attributes sent back.  Shouldn't they show up in the
> monitor interface?  Maybe they are being set, but how can you tell short
> of just seeing if a conneciton is terminated.
>
> Jim
>
> Jeff Mcadams wrote:
> >
> > Thus spake Jim Johnson
> > >What is the dictionary entry for your Idle-Time Attribute?
> >
> > Merit 3.6 something or other.
> >
> > ATTRIBUTE       Idle-Timeout            28      integer (1, 0)
> > --
> > Jeff McAdams                            Email: [e-mail]
> > Head Network Administrator              Voice: [phone]
> > IgLou Internet Services                        [phone]
> >
> > -
> >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> >  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 "[e-mail]"
>  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 "[e-mail]"
 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: Brice Ligget <[e-mail]>
Subject: (usr-tc) Modem errors.
Date: 20 Aug 1999 08:28:00 -0600

<html>
I have a customer that is getting a lot of errors on their router box
(it's a dos router)  This is what he gets:<br>
<br>
<font face="arial" size=2>sl0 - NAT in drop: rcvd pkt can't xlat<br>
   udp 208.23.93.4:520 208.23.93.175:520 ( number here )<br>
</font> <br>
 <br>
<font face="arial" size=2>ok the sl0 is the serial interface....<br>
</font> <br>
<font face="arial" size=2>the NAT is Network Address Translation...<br>
</font> <br>
<font face="arial" size=2>the 175 is the address I received from
you....<br>
</font> <br>
<font face="arial" size=2>the 520 ?????<br>
 <br>
the number here is a changing number some of them are.....
332, 72, 532, 392, 92, 52, 412.... and others...<br>
<br>
I took a look at his connection this morning and found the following
stats<br>
<br>
Transmit speed the modem connected at:   52000(45)<br>
Receive speed the modem connected at   31K(23)<br>
Current transmit link rate   52000(45)<br>
Current receive link rate   31K(23)<br>
Modulation Type Used   v90Digital(34)<br>
Error control type Used   ccittv42(4)<br>
Data Compression Used   ccittv42bis(2)<br>
Equalization Type Used   long(1)<br>
Line Fallback Negotiated   disable(1)<br>
Number of Characters Sent   3902896<br>
Number of Characters Received   262141<br>
Number of Resent blocks   288<br>
HST back Channel speed   bps450(1)<br>
Link Block Errors   388<br>
Link Protocol timeouts   175<br>
Link Speed Fallbacks   106<br>
Link speed Upshifts   0<br>
Number of NAKS Sent   30<br>
Cll durations   10:38:49<br>
<br>
I also pinged the IP he was given.  No go.  I haven't found out
yet if his box responds to pings.  A monitor ppp shows that he is
passing data.  Does anybody have any ideas what this error is and
what it means?</font><br>
<br>
<br>
<div>--</div>
<div>Brice Ligget</div>
<div>Chief Operations Officer</div>
<div>Two Alpha Net is a complete Internet Service Provider based in
Billings Montana.</div>
<div>"Connect to the world"</div>
<div>406 628 1500</div>
<br>
<div><a href="http://www.twoalpha.net/" EUDORA=AUTOURL>http://www.twoalpha.net</a></div>
</html>


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Mike Wronski" <[e-mail]>
Subject: RE: (usr-tc) Idle time
Date: 20 Aug 1999 09:30:42 -0500

Idle-timout will show up in the RADIUS monitor.. This is a STD attribute and
should be part of any RADIUS implementation.. If you miss it in RAD MON you can
also type the command "SHOW REMOTE USER <X>" to see all the attributes that have
been received from RADIUS for that user.

-M


|-----Original Message-----
|From: [e-mail]
|[mailto:[e-mail]]On Behalf Of Jim Johnson
|Sent: Friday, August 20, 1999 8:15 AM
|To: [e-mail]
|Subject: Re: (usr-tc) Idle time
|
|
|
|Oh well, that's what we have in our file.
|
|I just started palying with the setting yesterday, and I was trying to
|use MON RAD to watch the packets come back for a user and I was not
|seeing these attributes sent back.  Shouldn't they show up in the
|monitor interface?  Maybe they are being set, but how can you tell short
|of just seeing if a conneciton is terminated.
|
|Jim
|
|Jeff Mcadams wrote:
|>
|> Thus spake Jim Johnson
|> >What is the dictionary entry for your Idle-Time Attribute?
|>
|> Merit 3.6 something or other.
|>
|> ATTRIBUTE       Idle-Timeout            28      integer (1, 0)
|> --
|> Jeff McAdams                            Email: [e-mail]
|> Head Network Administrator              Voice: [phone]
|> IgLou Internet Services                        [phone]
|>
|> -
|>  To unsubscribe to usr-tc, send an email to "[e-mail]"
|>  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 "[e-mail]"
| 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 "[e-mail]"
 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: K Mitchell <[e-mail]>
Subject: Re: (usr-tc) Another dead ISDN link
Date: 20 Aug 1999 10:48:29 -0400

At 07:18 AM 8/20/99 -0500, you wrote:
>Kirk,
>
>If you'll send me the running-config (sh ru from #prompt) and I'll see if I
>can help you.  If might be that you have and access or deny list configured
>incorrectly.  It does not sound like a TC problem to me either.

  I don't have access to the unit, but just talked to the customer and it's
working now. It appears that the Cisco had reverted to an incorrect switch
type and SPID on it's own. They reloaded the config, saved, and
reconnected...working fine now.
  Nobody should have had access to it to make any changes, but the tech
cabn't be sure as he's offsite, so we're monitoring the connection for
further problems. Do you happen to have an IOD that I could use to point
mrtg at it from this end?

Thanks,
Kirk

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


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Jim Johnson <[e-mail]>
Subject: Re: (usr-tc) Idle time
Date: 20 Aug 1999 11:31:04 -0400


Thanks.

Jim

Mike Wronski wrote:
>
> Idle-timout will show up in the RADIUS monitor.. This is a STD attribute and
> should be part of any RADIUS implementation.. If you miss it in RAD MON you can
> also type the command "SHOW REMOTE USER <X>" to see all the attributes that have
> been received from RADIUS for that user.
>
> -M
>
> |-----Original Message-----
> |From: [e-mail]
> |[mailto:[e-mail]]On Behalf Of Jim Johnson
> |Sent: Friday, August 20, 1999 8:15 AM
> |To: [e-mail]
> |Subject: Re: (usr-tc) Idle time
> |
> |
> |
> |Oh well, that's what we have in our file.
> |
> |I just started palying with the setting yesterday, and I was trying to
> |use MON RAD to watch the packets come back for a user and I was not
> |seeing these attributes sent back.  Shouldn't they show up in the
> |monitor interface?  Maybe they are being set, but how can you tell short
> |of just seeing if a conneciton is terminated.
> |
> |Jim
> |
> |Jeff Mcadams wrote:
> |>
> |> Thus spake Jim Johnson
> |> >What is the dictionary entry for your Idle-Time Attribute?
> |>
> |> Merit 3.6 something or other.
> |>
> |> ATTRIBUTE       Idle-Timeout            28      integer (1, 0)
> |> --
> |> Jeff McAdams                            Email: [e-mail]
> |> Head Network Administrator              Voice: [phone]
> |> IgLou Internet Services                        [phone]
> |>
> |> -
> |>  To unsubscribe to usr-tc, send an email to "[e-mail]"
> |>  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 "[e-mail]"
> | 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 "[e-mail]"
>  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 "[e-mail]"
 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: "Eric Billeter" <[e-mail]>
Subject: (usr-tc) Modem Failure monitor
Date: 20 Aug 1999 09:58:03 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_3F9A_01BEEAF2.7F08F030
Content-Type: text/plain;
    charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Modified version

Includes call failure ratio on web page
Single email per chassis rather than 1 email per modem failure
better method of determining failed modems
        Failure ratio of 15% and more than 20 failures

Any input or feedback is appreciated

Eric Billeter
Internet Engineer
Cable One, Inc.

[e-mail]
602-364-6462
------=_NextPart_000_3F9A_01BEEAF2.7F08F030
Content-Type: application/octet-stream;
    name="modemfail.pl"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
    filename="modemfail.pl"

#!c:\perl\bin

# modemfail.pl
#


use SNMP_Session;
use BER;
use Socket;
use strict;
use NTsendmail;
$ENV{"NTsendmail"} =3D "mail.mycompany.com";   #Enter your Mail Server =
Here
my $mail =3D new NTsendmail;




%snmpget::OIDS =3D (  'OID1' =3D>  '1.3.6.1.4.1.429.1.6.10.1.1.24',
                    'OID2' =3D>  '1.3.6.1.4.1.429.1.6.10.1.1.4',
                 );
my $community=3D"public";                      # Your community String
my $router =3D "127.0.0.1";                    # IP Address of NMC
my $outputfile =3D "modem-fail.htm";           # File to output to=20
my $location =3D "My Pop Location";            # Location Descriptor
my $sender =3D "email\@mycompany.com";         # Mail From (use \@ not =
just @ in address)
my $recipient =3D "email\@mycompany.com";      # Mail To (use \@ not =
just @ in address)
my $subject =3D "$location modems";            # Mail Subject
my $message;

my @callok;
my @callfail;
my($sysName,$sysUptime,$interfaces,$value1,$value2) =3D
    =
snmpgettable($router,$community,'OID1'),snmpgettable2($router,$community,=
'OID2');
my $i;
my $slot;
my $modem;
my $callratio;
my $modemcount =3D @callok + 0 ;
open FILE, ">$outputfile";
#print FILE "Content-Type: text/html\n\n";=09
print FILE  "<HEAD><TITLE>Modem Report for $location</TITLE></HEAD>\n";
print FILE  "<BODY><HTML>\n";
print FILE "<TABLE>";
print FILE "<TR><TD width=3D10%>Slot</TD><TD width=3D5%></TD><TD =
width=3D15%>Modem<TD width=3D20%></TD><TD width=3D15%>Incoming</TD><TD =
width=3D25%>Failed</TD><TD>Faiure</TD></TR>";
print FILE =
"<TR><TD></TD><TD></TD><TD><TD></TD><TD>Calls</TD><TD>Calls</TD><TD>Ratio=
</TD></TR>";=20
print FILE "<TR></TR>";
for $i ( 1 .. $modemcount) {

    $slot=3Dint (($i-1)/24)+1;
    $modem=3Dint ($i-(($slot-1)*24));

        if ((@callfail[$i-1] > 20) and (@callfail[$i-1] > =
(@callok[$i-1])*.15)) {
        print FILE  "<TR bgcolor=3D#ff6600><TD>";
        $message=3D"$message $location Slot $slot Modem $modem is failing\n";

        }

        else {
        print FILE "<TR><TD>";
        }

    print FILE  "SLOT</TD><TD> ",$slot,"</TD><TD>";
    print FILE  "     Modem</TD><TD> ",$modem,"</TD><TD>";
    print FILE  @callok[$i-1],"</TD><TD>",@callfail[$i-1],;

if (@callfail[$i-1]=3D=3D0 and @callok[$i-1]>=3D0) {
$callratio=3D0;
}

else {
$callratio=3D(@callfail[$i-1]/(@callfail[$i-1]+@callok[$i-1]))*100;
}
    print FILE  "\n</TD><TD>";
    printf FILE "%5.2f\n", $callratio;
    print FILE "</TD></TR>";
    }

print FILE  "</TABLE></html></body>";
close FILE;
=09
    if (length $message > 0){
    print "mail sent";
    $mail->send($sender, $recipient, $subject, $message);=20
    }
    else {
    print "OK";

    }
exit(0);

sub snmpgettable{
  my($host,$community,$var) =3D @_;
  my($next_oid,$enoid,$orig_oid,=20
     $response, $bindings, $binding, $value, $inoid,$outoid,
     $upoid,$oid,@table,$tempo);
  die "Unknown SNMP var $var\n"=20
    unless $snmpget::OIDS{$var};
 =20
  $orig_oid =3D encode_oid(split /\./, $snmpget::OIDS{$var});
  $enoid=3D$orig_oid;
  srand();
  my $session =3D SNMP_Session->open ($host ,
                                 $community,=20
                                 161);
  for(;;)  {
    if ($session->getnext_request_response(($enoid))) {
      $response =3D $session->pdu_buffer;
      ($bindings) =3D $session->decode_get_response ($response);
      ($binding,$bindings) =3D decode_sequence ($bindings);
      ($next_oid,$value) =3D decode_by_template ($binding, "%O%@");
      # quit once we are outside the table
      last unless BER::encoded_oid_prefix_p($orig_oid,$next_oid);
      $tempo =3D pretty_print($value);
     #   print $tempo,"\n";
    push @callfail, $tempo;
        $value1=3D$value1 + $tempo ;

      $tempo=3D~s/\t/ /g;
      $tempo=3D~s/\n/ /g;
      $tempo=3D~s/^\s+//;
      $tempo=3D~s/\s+$//;
      push @table, $tempo;
    } else {
      die "No answer from $ARGV[0]\n";
    }
    $enoid=3D$next_oid;
  }
  $session->close ();=20
if( $value1 eq ''){$value1 =3D 0 };
#     print "$value1\n";
  return (@table);
}
sub snmpgettable2{
  my($host,$community,$var) =3D @_;
  my($next_oid,$enoid,$orig_oid,=20
     $response, $bindings, $binding, $value, $inoid,$outoid,
     $upoid,$oid,@table,$tempo);
  die "Unknown SNMP var $var\n"=20
    unless $snmpget::OIDS{$var};
 =20
  $orig_oid =3D encode_oid(split /\./, $snmpget::OIDS{$var});
  $enoid=3D$orig_oid;
  srand();
  my $session =3D SNMP_Session->open ($host ,
                                 $community,=20
                                 161);
  for(;;)  {
    if ($session->getnext_request_response(($enoid))) {
      $response =3D $session->pdu_buffer;
      ($bindings) =3D $session->decode_get_response ($response);
      ($binding,$bindings) =3D decode_sequence ($bindings);
      ($next_oid,$value) =3D decode_by_template ($binding, "%O%@");
      # quit once we are outside the table
      last unless BER::encoded_oid_prefix_p($orig_oid,$next_oid);
      $tempo =3D pretty_print($value);
#       print $tempo,"\n";
    push @callok, $tempo;
      $value2=3D$value2 + $tempo ;
      $tempo=3D~s/\t/ /g;
      $tempo=3D~s/\n/ /g;
      $tempo=3D~s/^\s+//;
      $tempo=3D~s/\s+$//;
      push @table, $tempo;
    } else {
      die "No answer from $ARGV[0]\n";
    }
    $enoid=3D$next_oid;
  }
  $session->close ();=20
if( $value2 eq ''){$value2 =3D 0 };
#     print "$value2\n";
  return (@table);
}


------=_NextPart_000_3F9A_01BEEAF2.7F08F030--




-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Scot Desort" <[e-mail]>
Subject: RE: (usr-tc) Idle time
Date: 20 Aug 1999 15:51:41 -0400

Is 'SESSION-TIMEOUT' also in seconds, or is it in minutes?


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Jim Johnson
> Sent: Friday, August 20, 1999 10:05 AM
> To: [e-mail]
> Subject: Re: (usr-tc) Idle time
>
>
>
>
> After idling a connected machine, the Idle-Timeout attribute did work so
> I assume the Session-Timeout also works.
>
> I still don't understand why these wouldn't show up in Mon Rad.
>
> Jim


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Jason Cropper <[e-mail]>
Subject: Re: (usr-tc) Idle time
Date: 20 Aug 1999 15:01:06 -0500

Sessesion-Timeout is specified in seconds.

_jason

Scot Desort wrote:
>
> Is 'SESSION-TIMEOUT' also in seconds, or is it in minutes?
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Jim Johnson
> > Sent: Friday, August 20, 1999 10:05 AM
> > To: [e-mail]
> > Subject: Re: (usr-tc) Idle time
> >
> >
> >
> >
> > After idling a connected machine, the Idle-Timeout attribute did work so
> > I assume the Session-Timeout also works.
> >
> > I still don't understand why these wouldn't show up in Mon Rad.
> >
> > Jim
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: [e-mail] (David Swearingin)
Subject: Re: (usr-tc) Idle time
Date: 20 Aug 1999 15:06:23 -0500

Is there a command to show the current idle time of users?  Not what it is
set at, but the actual idle time accrued during the current session.

David

At 03:01 PM 8/20/99 -0500, you wrote:
>Sessesion-Timeout is specified in seconds.
>
>_jason
>
>Scot Desort wrote:
>>
>> Is 'SESSION-TIMEOUT' also in seconds, or is it in minutes?
>>
>> > -----Original Message-----
>> > From: [e-mail]
>> > [mailto:[e-mail]]On Behalf Of Jim Johnson
>> > Sent: Friday, August 20, 1999 10:05 AM
>> > To: [e-mail]
>> > Subject: Re: (usr-tc) Idle time
>> >
>> >
>> >
>> >
>> > After idling a connected machine, the Idle-Timeout attribute did work so
>> > I assume the Session-Timeout also works.
>> >
>> > I still don't understand why these wouldn't show up in Mon Rad.
>> >
>> > Jim
>>
>>
>> -
>>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>>  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 "[e-mail]"
> 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.
>
__________________________________________________
David Swearingin ([e-mail])
CARROLLTON INTERNET SERVICE (www.carolnet.com)
First Financial Group, Inc.
11 N. Folger, Carrollton, MO  64633
660-542-3002   Fax [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Rick <[e-mail]>
Subject: (usr-tc) allowing one user to auth on one channel...
Date: 21 Aug 1999 10:24:32 -0400

All,
Was wondering if anyone has any idea's on whether this will work:

we have gotten a single telephone number assigned to a single channel of one of our T1's.
Then we used the "set switched interface Slot:x/mod:y user_name" and "set switched interface slot:x/mod:y password",
commands in an attempt to allow ONLY that user to dial into that channel and authenticate on it. However, ANY valid user
showing up in radius can authenticate on that channel as well.

Should this work, as long as we have our call routing method set to fixed assignment? Anyone else ever do this?

Thanks in advance,
Rick


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 Lynch <[e-mail]>
Subject: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 21 Aug 1999 09:26:11 -0500 (CDT)

On Tue, 10 Aug 1999, Allen Marsalis wrote:

> At 01:24 AM 8/10/99 -0400, Ed wrote:
> >3com not doing V.90 as well as Ascend's.....
> >
> >We have tested and found it to be true that Ascend's authenticate and work
> >at V.90 speeds much more often than 3com. It even happens when using a
> >3com/USR modem. It takes certain a certain situation for this to happen but
> >it does happen...
> >
> >Just wondered if others out there have noticed it or had their competitors
> >using Ascend's have customers that say "Well I get 56K speeds on so and so
> >Internet Service, why not yours?"
>
> We have been 100% USR/3COM for 3 years and we recently received a Max
> TNT for eval to address the above problem..  Both chassis will be
> at the same NOC.  2 new PRI's for the TNT should be up this week..
> I'll keep you posted as to the results and try to provide some statistical
> data..

Sorry for the length here, but I think it's a good read, eventhough I did
write it myself :)

We did some churn analysis for customers that are no longer active or no
longer customers.  We looked at at customers lost since March 1999 because
of:

a) reported problems connecting, staying connected, or poor  performance
b) unexplained non-payers/dead-beats
c) customers cancelled but did not give a reason (and did not
   return our calls when we tried to followed up).

We had 103 total cancellations for these reasons since March 1999.

We had enough data to determine that 57% of these 103 had problems were
directly attributable to connection quality. Of these 59 (103*0.57)
customers lost:

  50% of them had not established a connection in 1999 (many of
     them reported this trouble)

  40% had a large number of <1 minute connections, and showed a pattern
     of having to redial when they did stay on longer than a few minutes

  10% had connect speeds that varied more than a few "rungs" between
     2400-52000


Let's see...If we had an alternate modem pool with a different NAS type,
we might have saved these 59 customers. That's about $1000/month at an
average revenue of $17/customer/month. We are still likely to continue
loosing more if we don't take action.

Alternatively Scot Desort <[e-mail]>, wrote:

 "When all else
  fails, pull $35 out of petty cash and send the customer a Paradise
  Winmodem (LT chipset, PCI), for free. These things are GREAT, will save
  you hours of tech support headaches, and inevitably win you over a
  customer that, in the long run, is worth a lot more than the $35 you
  spent  on the modem. We even offer to install it for free if they bring
  the box in.  Let's remember that the goal is to KEEP the customer a
  PAYING customer.  And nothing makes them more warm and fuzzy then getting
  something for free."

This is interesting. Upgrading these customer's modems would have cost us
$2065 in hardware and perhaps $400-500 in labor estimated to retain the
$1000/month in revenue if this actually fixed the problem. I can see
several problems though. You could get a considerable number of calls from
unhappy customers like "my friend got a free modem now he gets 52K but I
only get 42K or 28.8K. I want one too." The customer's computer needs to
be sufficiently powered to run with a winmodem. How much time is spent
explaining that only certain customers qualify and how exactly are those
qualifications set? This also doesn't account for telco line issues. Many
customers now can't even tell you what kind of modem they have or what
processor they have, others may guess or argue that their's _should_
qualify for the free upgrade. For the program to not piss off any other
customers, it needs to be made available to everyone. Otherwise trouble
seems inevitable.

On the other hand, although it takes some capital (not much with eq
leasing and zero install PRIs) and increases network complexity a little,
it's not that big of a deal for a reasonably clued provider to add another
NAS and move PRIs over to them in a separate hunt or just install a couple
new PRIs and gradually grow the alternate modem pool. But really doesn't
add much cost to the operation in the long run and the customers are
retained as well. Also:

1) it's available to everyone,
2) it only takes a minute to help them change phone numbers
3) and in most cases, if this doesn't solve the problem, they're not
   likely to be satisfied with anyone else and helps prove the problem
   is theirs, motivating them to follow your recommedations.

The main thing that tweaks me is having to take this action in the first
place. Not to mention that we've got 7 or 8 hdsps from quad trades and arc
upgrades and such that we are paying for but won't be using this year now,
depending on the demand for the alternate pool. Cost of doing business.

Time to get a MAX on eval and give it a whirl.

============================================================================
Jeffrey A. Lynch        | JORSM Internet, Regional Internet Services
email: [e-mail]        | 7 Area Codes in Chicagoland and NW Indiana
Voice: [phone]        | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN
Autoresponse: [e-mail]    | Quality Service, Affordable Prices
http://www.jorsm.com        | Serving Gov, Biz, Indivds Since 1995






-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Tatai SV Krishnan <[e-mail]>
Subject: Re: (usr-tc) allowing one user to auth on one channel...
Date: 20 Aug 1999 21:37:52 -0500 (CDT)

On Sat, 21 Aug 1999, Rick wrote:

> All,
> Was wondering if anyone has any idea's on whether this will work:
>
> we have gotten a single telephone number assigned to a single channel of one of our T1's.
> Then we used the "set switched interface Slot:x/mod:y user_name" and "set switched interface slot:x/mod:y password",
> commands in an attempt to allow ONLY that user to dial into that channel and authenticate on it. However, ANY valid user
Well what you have done here is quite contrary to what you are thinking.
By setting a usernam and password for the interface - what you have done
is told the hiper arc and if any one calls irrespective on who it is the
username is going to be - what ever that is set on this particular
interface and the password is also set is this particular interface.  So
essentially any joe can dial and authenticate as long as the username and
password that you set on the interface is a valid user name.

The hiper arc is doing exactly what you set it for.


krish


> showing up in radius can authenticate on that channel as well.
>
> Should this work, as long as we have our call routing method set to fixed assignment? Anyone else ever do this?
>
> Thanks in advance,
> Rick
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: "Ed" <[e-mail]>
Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 21 Aug 1999 11:05:16 -0400

You are correct... it is not an option as I stated to give away Modems to
customers to solve this problem.

3com has confirmed there are issues with the current V90 in their chassis'.
We raised their attention to this issue and they are currently working on
the code for connection issues such as the ones mentioned.

We have an Ascend MAX that we acquired from an aqcuistition and this is how
we came to find out that 3com wasn't all that it was cracked up to be. We
kinda have a feeling of betrayal... told for years that 3com was the
absolute best in 56K/V90 and other connections and then all of a sudden find
out that the wool was pulled over our eyes. At least they could have
continued to improve their server V90 code... instead of denying there were
any issues with the V90 or blaming it solely on the client side. People have
been telling us for months that they dialup AOsmell, Earthstink, or
Mindsling and connect at 53,333 and can't understand why they have such
problems with our system... well now we know... those guys use Ascend!

For now we will stick with 3com... however everyday that goes by it becomes
more difficult to justify...


Ed

----- Original Message -----
Sent: Saturday, August 21, 1999 10:26 AM


On Tue, 10 Aug 1999, Allen Marsalis wrote:

> At 01:24 AM 8/10/99 -0400, Ed wrote:
> >3com not doing V.90 as well as Ascend's.....
> >
> >We have tested and found it to be true that Ascend's authenticate and
work
> >at V.90 speeds much more often than 3com. It even happens when using a
> >3com/USR modem. It takes certain a certain situation for this to happen
but
> >it does happen...
> >
> >Just wondered if others out there have noticed it or had their
competitors
> >using Ascend's have customers that say "Well I get 56K speeds on so and
so
> >Internet Service, why not yours?"
>
> We have been 100% USR/3COM for 3 years and we recently received a Max
> TNT for eval to address the above problem..  Both chassis will be
> at the same NOC.  2 new PRI's for the TNT should be up this week..
> I'll keep you posted as to the results and try to provide some statistical
> data..

Sorry for the length here, but I think it's a good read, eventhough I did
write it myself :)

We did some churn analysis for customers that are no longer active or no
longer customers.  We looked at at customers lost since March 1999 because
of:

a) reported problems connecting, staying connected, or poor  performance
b) unexplained non-payers/dead-beats
c) customers cancelled but did not give a reason (and did not
   return our calls when we tried to followed up).

We had 103 total cancellations for these reasons since March 1999.

We had enough data to determine that 57% of these 103 had problems were
directly attributable to connection quality. Of these 59 (103*0.57)
customers lost:

  50% of them had not established a connection in 1999 (many of
     them reported this trouble)

  40% had a large number of <1 minute connections, and showed a pattern
     of having to redial when they did stay on longer than a few minutes

  10% had connect speeds that varied more than a few "rungs" between
     2400-52000


Let's see...If we had an alternate modem pool with a different NAS type,
we might have saved these 59 customers. That's about $1000/month at an
average revenue of $17/customer/month. We are still likely to continue
loosing more if we don't take action.

Alternatively Scot Desort <[e-mail]>, wrote:

 "When all else
  fails, pull $35 out of petty cash and send the customer a Paradise
  Winmodem (LT chipset, PCI), for free. These things are GREAT, will save
  you hours of tech support headaches, and inevitably win you over a
  customer that, in the long run, is worth a lot more than the $35 you
  spent  on the modem. We even offer to install it for free if they bring
  the box in.  Let's remember that the goal is to KEEP the customer a
  PAYING customer.  And nothing makes them more warm and fuzzy then getting
  something for free."

This is interesting. Upgrading these customer's modems would have cost us
$2065 in hardware and perhaps $400-500 in labor estimated to retain the
$1000/month in revenue if this actually fixed the problem. I can see
several problems though. You could get a considerable number of calls from
unhappy customers like "my friend got a free modem now he gets 52K but I
only get 42K or 28.8K. I want one too." The customer's computer needs to
be sufficiently powered to run with a winmodem. How much time is spent
explaining that only certain customers qualify and how exactly are those
qualifications set? This also doesn't account for telco line issues. Many
customers now can't even tell you what kind of modem they have or what
processor they have, others may guess or argue that their's _should_
qualify for the free upgrade. For the program to not piss off any other
customers, it needs to be made available to everyone. Otherwise trouble
seems inevitable.

On the other hand, although it takes some capital (not much with eq
leasing and zero install PRIs) and increases network complexity a little,
it's not that big of a deal for a reasonably clued provider to add another
NAS and move PRIs over to them in a separate hunt or just install a couple
new PRIs and gradually grow the alternate modem pool. But really doesn't
add much cost to the operation in the long run and the customers are
retained as well. Also:

1) it's available to everyone,
2) it only takes a minute to help them change phone numbers
3) and in most cases, if this doesn't solve the problem, they're not
   likely to be satisfied with anyone else and helps prove the problem
   is theirs, motivating them to follow your recommedations.

The main thing that tweaks me is having to take this action in the first
place. Not to mention that we've got 7 or 8 hdsps from quad trades and arc
upgrades and such that we are paying for but won't be using this year now,
depending on the demand for the alternate pool. Cost of doing business.

Time to get a MAX on eval and give it a whirl.

============================================================================
Jeffrey A. Lynch | JORSM Internet, Regional Internet Services
email: [e-mail] | 7 Area Codes in Chicagoland and NW Indiana
Voice: [phone] | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN
Autoresponse: [e-mail] | Quality Service, Affordable Prices
http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995






-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 "[e-mail]"
 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: Jim Johnson <[e-mail]>
Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 21 Aug 1999 11:10:17 -0400


I always thought that AOL was 3COM's biggest NAS account.

JJ

Ed wrote:
>
> You are correct... it is not an option as I stated to give away Modems to
> customers to solve this problem.
>
> 3com has confirmed there are issues with the current V90 in their chassis'.
> We raised their attention to this issue and they are currently working on
> the code for connection issues such as the ones mentioned.
>
> We have an Ascend MAX that we acquired from an aqcuistition and this is how
> we came to find out that 3com wasn't all that it was cracked up to be. We
> kinda have a feeling of betrayal... told for years that 3com was the
> absolute best in 56K/V90 and other connections and then all of a sudden find
> out that the wool was pulled over our eyes. At least they could have
> continued to improve their server V90 code... instead of denying there were
> any issues with the V90 or blaming it solely on the client side. People have
> been telling us for months that they dialup AOsmell, Earthstink, or
> Mindsling and connect at 53,333 and can't understand why they have such
> problems with our system... well now we know... those guys use Ascend!
>
> For now we will stick with 3com... however everyday that goes by it becomes
> more difficult to justify...
>
> Ed
>
> ----- Original Message -----
> From: Jeff Lynch <[e-mail]>
> To: <[e-mail]>
> Sent: Saturday, August 21, 1999 10:26 AM
> Subject: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
>
> On Tue, 10 Aug 1999, Allen Marsalis wrote:
>
> > At 01:24 AM 8/10/99 -0400, Ed wrote:
> > >3com not doing V.90 as well as Ascend's.....
> > >
> > >We have tested and found it to be true that Ascend's authenticate and
> work
> > >at V.90 speeds much more often than 3com. It even happens when using a
> > >3com/USR modem. It takes certain a certain situation for this to happen
> but
> > >it does happen...
> > >
> > >Just wondered if others out there have noticed it or had their
> competitors
> > >using Ascend's have customers that say "Well I get 56K speeds on so and
> so
> > >Internet Service, why not yours?"
> >
> > We have been 100% USR/3COM for 3 years and we recently received a Max
> > TNT for eval to address the above problem..  Both chassis will be
> > at the same NOC.  2 new PRI's for the TNT should be up this week..
> > I'll keep you posted as to the results and try to provide some statistical
> > data..
>
> Sorry for the length here, but I think it's a good read, eventhough I did
> write it myself :)
>
> We did some churn analysis for customers that are no longer active or no
> longer customers.  We looked at at customers lost since March 1999 because
> of:
>
> a) reported problems connecting, staying connected, or poor  performance
> b) unexplained non-payers/dead-beats
> c) customers cancelled but did not give a reason (and did not
>    return our calls when we tried to followed up).
>
> We had 103 total cancellations for these reasons since March 1999.
>
> We had enough data to determine that 57% of these 103 had problems were
> directly attributable to connection quality. Of these 59 (103*0.57)
> customers lost:
>
>   50% of them had not established a connection in 1999 (many of
>      them reported this trouble)
>
>   40% had a large number of <1 minute connections, and showed a pattern
>      of having to redial when they did stay on longer than a few minutes
>
>   10% had connect speeds that varied more than a few "rungs" between
>      2400-52000
>
> Let's see...If we had an alternate modem pool with a different NAS type,
> we might have saved these 59 customers. That's about $1000/month at an
> average revenue of $17/customer/month. We are still likely to continue
> loosing more if we don't take action.
>
> Alternatively Scot Desort <[e-mail]>, wrote:
>
>  "When all else
>   fails, pull $35 out of petty cash and send the customer a Paradise
>   Winmodem (LT chipset, PCI), for free. These things are GREAT, will save
>   you hours of tech support headaches, and inevitably win you over a
>   customer that, in the long run, is worth a lot more than the $35 you
>   spent  on the modem. We even offer to install it for free if they bring
>   the box in.  Let's remember that the goal is to KEEP the customer a
>   PAYING customer.  And nothing makes them more warm and fuzzy then getting
>   something for free."
>
> This is interesting. Upgrading these customer's modems would have cost us
> $2065 in hardware and perhaps $400-500 in labor estimated to retain the
> $1000/month in revenue if this actually fixed the problem. I can see
> several problems though. You could get a considerable number of calls from
> unhappy customers like "my friend got a free modem now he gets 52K but I
> only get 42K or 28.8K. I want one too." The customer's computer needs to
> be sufficiently powered to run with a winmodem. How much time is spent
> explaining that only certain customers qualify and how exactly are those
> qualifications set? This also doesn't account for telco line issues. Many
> customers now can't even tell you what kind of modem they have or what
> processor they have, others may guess or argue that their's _should_
> qualify for the free upgrade. For the program to not piss off any other
> customers, it needs to be made available to everyone. Otherwise trouble
> seems inevitable.
>
> On the other hand, although it takes some capital (not much with eq
> leasing and zero install PRIs) and increases network complexity a little,
> it's not that big of a deal for a reasonably clued provider to add another
> NAS and move PRIs over to them in a separate hunt or just install a couple
> new PRIs and gradually grow the alternate modem pool. But really doesn't
> add much cost to the operation in the long run and the customers are
> retained as well. Also:
>
> 1) it's available to everyone,
> 2) it only takes a minute to help them change phone numbers
> 3) and in most cases, if this doesn't solve the problem, they're not
>    likely to be satisfied with anyone else and helps prove the problem
>    is theirs, motivating them to follow your recommedations.
>
> The main thing that tweaks me is having to take this action in the first
> place. Not to mention that we've got 7 or 8 hdsps from quad trades and arc
> upgrades and such that we are paying for but won't be using this year now,
> depending on the demand for the alternate pool. Cost of doing business.
>
> Time to get a MAX on eval and give it a whirl.
>
> ============================================================================
> Jeffrey A. Lynch | JORSM Internet, Regional Internet Services
> email: [e-mail] | 7 Area Codes in Chicagoland and NW Indiana
> Voice: [phone] | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN
> Autoresponse: [e-mail] | Quality Service, Affordable Prices
> http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
>  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 "[e-mail]"
 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 Lynch <[e-mail]>
Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 21 Aug 1999 10:37:23 -0500 (CDT)

On Sat, 21 Aug 1999, Ed wrote:

> You are correct... it is not an option as I stated to give away Modems to
> customers to solve this problem.
>
> 3com has confirmed there are issues with the current V90 in their chassis'.
> We raised their attention to this issue and they are currently working on
> the code for connection issues such as the ones mentioned.

Did I miss a post regarding this, or did you learn this through private
conversation? I feel an official response is called for at this time. An
appropriate response from 3COM on this, could delay or event prevent our
multi-vendor deployment if a timely solution is in the works.

--jeff

============================================================================
Jeffrey A. Lynch        | JORSM Internet, Regional Internet Services
email: [e-mail]        | 7 Area Codes in Chicagoland and NW Indiana
Voice: [phone]        | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN
Autoresponse: [e-mail]    | Quality Service, Affordable Prices
http://www.jorsm.com        | Serving Gov, Biz, Indivds Since 1995


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Ed" <[e-mail]>
Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 21 Aug 1999 11:52:01 -0400

Yes they probably are considering AOL's size but AOL also uses third party
POP's to my knowledge and in our area it is Ascend because it has Ascends
pre-tone.


Ed

----- Original Message -----
Sent: Saturday, August 21, 1999 11:10 AM



I always thought that AOL was 3COM's biggest NAS account.

JJ

Ed wrote:
>
> You are correct... it is not an option as I stated to give away Modems to
> customers to solve this problem.
>
> 3com has confirmed there are issues with the current V90 in their
chassis'.
> We raised their attention to this issue and they are currently working on
> the code for connection issues such as the ones mentioned.
>
> We have an Ascend MAX that we acquired from an aqcuistition and this is
how
> we came to find out that 3com wasn't all that it was cracked up to be. We
> kinda have a feeling of betrayal... told for years that 3com was the
> absolute best in 56K/V90 and other connections and then all of a sudden
find
> out that the wool was pulled over our eyes. At least they could have
> continued to improve their server V90 code... instead of denying there
were
> any issues with the V90 or blaming it solely on the client side. People
have
> been telling us for months that they dialup AOsmell, Earthstink, or
> Mindsling and connect at 53,333 and can't understand why they have such
> problems with our system... well now we know... those guys use Ascend!
>
> For now we will stick with 3com... however everyday that goes by it
becomes
> more difficult to justify...
>
> Ed
>
> ----- Original Message -----
> From: Jeff Lynch <[e-mail]>
> To: <[e-mail]>
> Sent: Saturday, August 21, 1999 10:26 AM
> Subject: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
>
> On Tue, 10 Aug 1999, Allen Marsalis wrote:
>
> > At 01:24 AM 8/10/99 -0400, Ed wrote:
> > >3com not doing V.90 as well as Ascend's.....
> > >
> > >We have tested and found it to be true that Ascend's authenticate and
> work
> > >at V.90 speeds much more often than 3com. It even happens when using a
> > >3com/USR modem. It takes certain a certain situation for this to happen
> but
> > >it does happen...
> > >
> > >Just wondered if others out there have noticed it or had their
> competitors
> > >using Ascend's have customers that say "Well I get 56K speeds on so and
> so
> > >Internet Service, why not yours?"
> >
> > We have been 100% USR/3COM for 3 years and we recently received a Max
> > TNT for eval to address the above problem..  Both chassis will be
> > at the same NOC.  2 new PRI's for the TNT should be up this week..
> > I'll keep you posted as to the results and try to provide some
statistical
> > data..
>
> Sorry for the length here, but I think it's a good read, eventhough I did
> write it myself :)
>
> We did some churn analysis for customers that are no longer active or no
> longer customers.  We looked at at customers lost since March 1999 because
> of:
>
> a) reported problems connecting, staying connected, or poor  performance
> b) unexplained non-payers/dead-beats
> c) customers cancelled but did not give a reason (and did not
>    return our calls when we tried to followed up).
>
> We had 103 total cancellations for these reasons since March 1999.
>
> We had enough data to determine that 57% of these 103 had problems were
> directly attributable to connection quality. Of these 59 (103*0.57)
> customers lost:
>
>   50% of them had not established a connection in 1999 (many of
>      them reported this trouble)
>
>   40% had a large number of <1 minute connections, and showed a pattern
>      of having to redial when they did stay on longer than a few minutes
>
>   10% had connect speeds that varied more than a few "rungs" between
>      2400-52000
>
> Let's see...If we had an alternate modem pool with a different NAS type,
> we might have saved these 59 customers. That's about $1000/month at an
> average revenue of $17/customer/month. We are still likely to continue
> loosing more if we don't take action.
>
> Alternatively Scot Desort <[e-mail]>, wrote:
>
>  "When all else
>   fails, pull $35 out of petty cash and send the customer a Paradise
>   Winmodem (LT chipset, PCI), for free. These things are GREAT, will save
>   you hours of tech support headaches, and inevitably win you over a
>   customer that, in the long run, is worth a lot more than the $35 you
>   spent  on the modem. We even offer to install it for free if they bring
>   the box in.  Let's remember that the goal is to KEEP the customer a
>   PAYING customer.  And nothing makes them more warm and fuzzy then
getting
>   something for free."
>
> This is interesting. Upgrading these customer's modems would have cost us
> $2065 in hardware and perhaps $400-500 in labor estimated to retain the
> $1000/month in revenue if this actually fixed the problem. I can see
> several problems though. You could get a considerable number of calls from
> unhappy customers like "my friend got a free modem now he gets 52K but I
> only get 42K or 28.8K. I want one too." The customer's computer needs to
> be sufficiently powered to run with a winmodem. How much time is spent
> explaining that only certain customers qualify and how exactly are those
> qualifications set? This also doesn't account for telco line issues. Many
> customers now can't even tell you what kind of modem they have or what
> processor they have, others may guess or argue that their's _should_
> qualify for the free upgrade. For the program to not piss off any other
> customers, it needs to be made available to everyone. Otherwise trouble
> seems inevitable.
>
> On the other hand, although it takes some capital (not much with eq
> leasing and zero install PRIs) and increases network complexity a little,
> it's not that big of a deal for a reasonably clued provider to add another
> NAS and move PRIs over to them in a separate hunt or just install a couple
> new PRIs and gradually grow the alternate modem pool. But really doesn't
> add much cost to the operation in the long run and the customers are
> retained as well. Also:
>
> 1) it's available to everyone,
> 2) it only takes a minute to help them change phone numbers
> 3) and in most cases, if this doesn't solve the problem, they're not
>    likely to be satisfied with anyone else and helps prove the problem
>    is theirs, motivating them to follow your recommedations.
>
> The main thing that tweaks me is having to take this action in the first
> place. Not to mention that we've got 7 or 8 hdsps from quad trades and arc
> upgrades and such that we are paying for but won't be using this year now,
> depending on the demand for the alternate pool. Cost of doing business.
>
> Time to get a MAX on eval and give it a whirl.
>
>
============================================================================
> Jeffrey A. Lynch | JORSM Internet, Regional Internet Services
> email: [e-mail] | 7 Area Codes in Chicagoland and NW Indiana
> Voice: [phone] | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN
> Autoresponse: [e-mail] | Quality Service, Affordable Prices
> http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
>  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 "[e-mail]"
 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 "[e-mail]"
 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: "Ed" <[e-mail]>
Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 21 Aug 1999 11:59:57 -0400

Yes you must have...I started the whole discussion "3com not doing V.90 as
well as Ascends" weeks ago.

We had to prove to 3com that V90 wasn't working properly on their systems.
They are now actively pursuing a resolution to the issue. We can only HOPE
it blows Ascends doors off....best of both worlds is our hope. Wouldn't it
be amazing if all the 3com ISP's started connecting better than all the
Ascend ISP's? I would image that this would incourage other ISP's to switch
to 3com and thus 3com would benefit... wonder why they didn't think of that?
;-)


Ed

----- Original Message -----
Sent: Saturday, August 21, 1999 11:37 AM


On Sat, 21 Aug 1999, Ed wrote:

> You are correct... it is not an option as I stated to give away Modems to
> customers to solve this problem.
>
> 3com has confirmed there are issues with the current V90 in their
chassis'.
> We raised their attention to this issue and they are currently working on
> the code for connection issues such as the ones mentioned.

Did I miss a post regarding this, or did you learn this through private
conversation? I feel an official response is called for at this time. An
appropriate response from 3COM on this, could delay or event prevent our
multi-vendor deployment if a timely solution is in the works.

--jeff

============================================================================
Jeffrey A. Lynch | JORSM Internet, Regional Internet Services
email: [e-mail] | 7 Area Codes in Chicagoland and NW Indiana
Voice: [phone] | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN
Autoresponse: [e-mail] | Quality Service, Affordable Prices
http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 "[e-mail]"
 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: Charles Sprickman <[e-mail]>
Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 21 Aug 1999 14:22:59 -0400 (EDT)

On Sat, 21 Aug 1999, Ed wrote:

> People have
> been telling us for months that they dialup AOsmell, Earthstink, or
> Mindsling and connect at 53,333 and can't understand why they have such
> problems with our system... well now we know... those guys use Ascend!

As for AOL, I understood they were USR, but they actually just signed a
big deal with Cisco.  The last article I saw about Mindspring in one of
those trade rags showed their CTO standing in front of huge banks of USR
stuff...  The only one I know is mostly Ascend is Earthlink.  RCN is an
Ascend shop as well...

Keep in mind most of those problems can also be attributed to your lines.
Our CLEC is currently in the process of retesting all of their trunks out
to the tandems and end-offices as they've found the ILEC is misconfiguring
lots of them.  Symptoms are very similar, but the standout is if you see
more errors in one direction; there's a 80-some percent chance there's a
line coding mismatche somewhere.

Charles

> For now we will stick with 3com... however everyday that goes by it becomes
> more difficult to justify...
>
>
> Ed
>
> ----- Original Message -----
> From: Jeff Lynch <[e-mail]>
> To: <[e-mail]>
> Sent: Saturday, August 21, 1999 10:26 AM
> Subject: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
>
>
> On Tue, 10 Aug 1999, Allen Marsalis wrote:
>
> > At 01:24 AM 8/10/99 -0400, Ed wrote:
> > >3com not doing V.90 as well as Ascend's.....
> > >
> > >We have tested and found it to be true that Ascend's authenticate and
> work
> > >at V.90 speeds much more often than 3com. It even happens when using a
> > >3com/USR modem. It takes certain a certain situation for this to happen
> but
> > >it does happen...
> > >
> > >Just wondered if others out there have noticed it or had their
> competitors
> > >using Ascend's have customers that say "Well I get 56K speeds on so and
> so
> > >Internet Service, why not yours?"
> >
> > We have been 100% USR/3COM for 3 years and we recently received a Max
> > TNT for eval to address the above problem..  Both chassis will be
> > at the same NOC.  2 new PRI's for the TNT should be up this week..
> > I'll keep you posted as to the results and try to provide some statistical
> > data..
>
> Sorry for the length here, but I think it's a good read, eventhough I did
> write it myself :)
>
> We did some churn analysis for customers that are no longer active or no
> longer customers.  We looked at at customers lost since March 1999 because
> of:
>
> a) reported problems connecting, staying connected, or poor  performance
> b) unexplained non-payers/dead-beats
> c) customers cancelled but did not give a reason (and did not
>    return our calls when we tried to followed up).
>
> We had 103 total cancellations for these reasons since March 1999.
>
> We had enough data to determine that 57% of these 103 had problems were
> directly attributable to connection quality. Of these 59 (103*0.57)
> customers lost:
>
>   50% of them had not established a connection in 1999 (many of
>      them reported this trouble)
>
>   40% had a large number of <1 minute connections, and showed a pattern
>      of having to redial when they did stay on longer than a few minutes
>
>   10% had connect speeds that varied more than a few "rungs" between
>      2400-52000
>
>
> Let's see...If we had an alternate modem pool with a different NAS type,
> we might have saved these 59 customers. That's about $1000/month at an
> average revenue of $17/customer/month. We are still likely to continue
> loosing more if we don't take action.
>
> Alternatively Scot Desort <[e-mail]>, wrote:
>
>  "When all else
>   fails, pull $35 out of petty cash and send the customer a Paradise
>   Winmodem (LT chipset, PCI), for free. These things are GREAT, will save
>   you hours of tech support headaches, and inevitably win you over a
>   customer that, in the long run, is worth a lot more than the $35 you
>   spent  on the modem. We even offer to install it for free if they bring
>   the box in.  Let's remember that the goal is to KEEP the customer a
>   PAYING customer.  And nothing makes them more warm and fuzzy then getting
>   something for free."
>
> This is interesting. Upgrading these customer's modems would have cost us
> $2065 in hardware and perhaps $400-500 in labor estimated to retain the
> $1000/month in revenue if this actually fixed the problem. I can see
> several problems though. You could get a considerable number of calls from
> unhappy customers like "my friend got a free modem now he gets 52K but I
> only get 42K or 28.8K. I want one too." The customer's computer needs to
> be sufficiently powered to run with a winmodem. How much time is spent
> explaining that only certain customers qualify and how exactly are those
> qualifications set? This also doesn't account for telco line issues. Many
> customers now can't even tell you what kind of modem they have or what
> processor they have, others may guess or argue that their's _should_
> qualify for the free upgrade. For the program to not piss off any other
> customers, it needs to be made available to everyone. Otherwise trouble
> seems inevitable.
>
> On the other hand, although it takes some capital (not much with eq
> leasing and zero install PRIs) and increases network complexity a little,
> it's not that big of a deal for a reasonably clued provider to add another
> NAS and move PRIs over to them in a separate hunt or just install a couple
> new PRIs and gradually grow the alternate modem pool. But really doesn't
> add much cost to the operation in the long run and the customers are
> retained as well. Also:
>
> 1) it's available to everyone,
> 2) it only takes a minute to help them change phone numbers
> 3) and in most cases, if this doesn't solve the problem, they're not
>    likely to be satisfied with anyone else and helps prove the problem
>    is theirs, motivating them to follow your recommedations.
>
> The main thing that tweaks me is having to take this action in the first
> place. Not to mention that we've got 7 or 8 hdsps from quad trades and arc
> upgrades and such that we are paying for but won't be using this year now,
> depending on the demand for the alternate pool. Cost of doing business.
>
> Time to get a MAX on eval and give it a whirl.
>
> ============================================================================
> Jeffrey A. Lynch | JORSM Internet, Regional Internet Services
> email: [e-mail] | 7 Area Codes in Chicagoland and NW Indiana
> Voice: [phone] | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN
> Autoresponse: [e-mail] | Quality Service, Affordable Prices
> http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995
>
>
>
>
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
>  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 "[e-mail]"
 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: "Ed" <[e-mail]>
Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 21 Aug 1999 14:44:30 -0400

Man trust me... I know the difference. I am speaking of proven facts not
Hypotheses. 3com has definitely got an issue. And they are working on it.
Please don't stand up and speak about line issues when we know it's not line
issues... We ran test after test and even sat the Ascends right beside the
3com's... unplugged the T1 from the 3com and put it in the Ascend and what
do you know the person connected at V90 speeds (NOT KFLEX OR X2) everytime.
The 3com would hit V90 about every 10th try if they were lucky. Also there
was no stability issues with the Ascends where as the 3com had some. We
tested with 3com Sportsters, Supra's, and generic modems. Connected fine
with Ascend and faltered with 3com. And all this was confirmed by 3com...

AOL, Earthlink and Mindspring ALL use Ascend in our area. Ascend has a
distinct pre-tone... I know they are Ascends. These guys don't run their own
POPs in most cases and whore out the business through third party POP
vendors... that could be using anything.

So what do you say now Mr. Sprickman?

Ed

----- Original Message -----
Sent: Saturday, August 21, 1999 2:22 PM


On Sat, 21 Aug 1999, Ed wrote:

> People have
> been telling us for months that they dialup AOsmell, Earthstink, or
> Mindsling and connect at 53,333 and can't understand why they have such
> problems with our system... well now we know... those guys use Ascend!

As for AOL, I understood they were USR, but they actually just signed a
big deal with Cisco.  The last article I saw about Mindspring in one of
those trade rags showed their CTO standing in front of huge banks of USR
stuff...  The only one I know is mostly Ascend is Earthlink.  RCN is an
Ascend shop as well...

Keep in mind most of those problems can also be attributed to your lines.
Our CLEC is currently in the process of retesting all of their trunks out
to the tandems and end-offices as they've found the ILEC is misconfiguring
lots of them.  Symptoms are very similar, but the standout is if you see
more errors in one direction; there's a 80-some percent chance there's a
line coding mismatche somewhere.

Charles

> For now we will stick with 3com... however everyday that goes by it
becomes
> more difficult to justify...
>
>
> Ed
>
> ----- Original Message -----
> From: Jeff Lynch <[e-mail]>
> To: <[e-mail]>
> Sent: Saturday, August 21, 1999 10:26 AM
> Subject: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
>
>
> On Tue, 10 Aug 1999, Allen Marsalis wrote:
>
> > At 01:24 AM 8/10/99 -0400, Ed wrote:
> > >3com not doing V.90 as well as Ascend's.....
> > >
> > >We have tested and found it to be true that Ascend's authenticate and
> work
> > >at V.90 speeds much more often than 3com. It even happens when using a
> > >3com/USR modem. It takes certain a certain situation for this to happen
> but
> > >it does happen...
> > >
> > >Just wondered if others out there have noticed it or had their
> competitors
> > >using Ascend's have customers that say "Well I get 56K speeds on so and
> so
> > >Internet Service, why not yours?"
> >
> > We have been 100% USR/3COM for 3 years and we recently received a Max
> > TNT for eval to address the above problem..  Both chassis will be
> > at the same NOC.  2 new PRI's for the TNT should be up this week..
> > I'll keep you posted as to the results and try to provide some
statistical
> > data..
>
> Sorry for the length here, but I think it's a good read, eventhough I did
> write it myself :)
>
> We did some churn analysis for customers that are no longer active or no
> longer customers.  We looked at at customers lost since March 1999 because
> of:
>
> a) reported problems connecting, staying connected, or poor  performance
> b) unexplained non-payers/dead-beats
> c) customers cancelled but did not give a reason (and did not
>    return our calls when we tried to followed up).
>
> We had 103 total cancellations for these reasons since March 1999.
>
> We had enough data to determine that 57% of these 103 had problems were
> directly attributable to connection quality. Of these 59 (103*0.57)
> customers lost:
>
>   50% of them had not established a connection in 1999 (many of
>      them reported this trouble)
>
>   40% had a large number of <1 minute connections, and showed a pattern
>      of having to redial when they did stay on longer than a few minutes
>
>   10% had connect speeds that varied more than a few "rungs" between
>      2400-52000
>
>
> Let's see...If we had an alternate modem pool with a different NAS type,
> we might have saved these 59 customers. That's about $1000/month at an
> average revenue of $17/customer/month. We are still likely to continue
> loosing more if we don't take action.
>
> Alternatively Scot Desort <[e-mail]>, wrote:
>
>  "When all else
>   fails, pull $35 out of petty cash and send the customer a Paradise
>   Winmodem (LT chipset, PCI), for free. These things are GREAT, will save
>   you hours of tech support headaches, and inevitably win you over a
>   customer that, in the long run, is worth a lot more than the $35 you
>   spent  on the modem. We even offer to install it for free if they bring
>   the box in.  Let's remember that the goal is to KEEP the customer a
>   PAYING customer.  And nothing makes them more warm and fuzzy then
getting
>   something for free."
>
> This is interesting. Upgrading these customer's modems would have cost us
> $2065 in hardware and perhaps $400-500 in labor estimated to retain the
> $1000/month in revenue if this actually fixed the problem. I can see
> several problems though. You could get a considerable number of calls from
> unhappy customers like "my friend got a free modem now he gets 52K but I
> only get 42K or 28.8K. I want one too." The customer's computer needs to
> be sufficiently powered to run with a winmodem. How much time is spent
> explaining that only certain customers qualify and how exactly are those
> qualifications set? This also doesn't account for telco line issues. Many
> customers now can't even tell you what kind of modem they have or what
> processor they have, others may guess or argue that their's _should_
> qualify for the free upgrade. For the program to not piss off any other
> customers, it needs to be made available to everyone. Otherwise trouble
> seems inevitable.
>
> On the other hand, although it takes some capital (not much with eq
> leasing and zero install PRIs) and increases network complexity a little,
> it's not that big of a deal for a reasonably clued provider to add another
> NAS and move PRIs over to them in a separate hunt or just install a couple
> new PRIs and gradually grow the alternate modem pool. But really doesn't
> add much cost to the operation in the long run and the customers are
> retained as well. Also:
>
> 1) it's available to everyone,
> 2) it only takes a minute to help them change phone numbers
> 3) and in most cases, if this doesn't solve the problem, they're not
>    likely to be satisfied with anyone else and helps prove the problem
>    is theirs, motivating them to follow your recommedations.
>
> The main thing that tweaks me is having to take this action in the first
> place. Not to mention that we've got 7 or 8 hdsps from quad trades and arc
> upgrades and such that we are paying for but won't be using this year now,
> depending on the demand for the alternate pool. Cost of doing business.
>
> Time to get a MAX on eval and give it a whirl.
>
>
============================================================================
> Jeffrey A. Lynch | JORSM Internet, Regional Internet Services
> email: [e-mail] | 7 Area Codes in Chicagoland and NW Indiana
> Voice: [phone] | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN
> Autoresponse: [e-mail] | Quality Service, Affordable Prices
> http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995
>
>
>
>
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
>  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 "[e-mail]"
 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 "[e-mail]"
 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: Greg Coffey <[e-mail]>
Subject: (usr-tc) Need help with Netserver 8i
Date: 21 Aug 1999 13:48:42 -0600

We have been having a problem with a netserver 8i and flashed it remotely
to the newest ver 4.2.0 today. Prior to this flash, it had been working but
a modem was hanging on a regular basis.  We thought the newer ver might fix
the modem problem but it broke the dialup connections.  We can still telnet
to it and connect via modem but not login through the phone link.  We
flashed it back to an earlier ver 4.1.77 but still cannot establish a
dialup link.  Of course, it is in a town over 100 miles away and we are not
able to resolve the problem.  Anyone care to take a chance with it?  Email
me directly if you can help.
Thanks, Greg Coffey  <[e-mail]>
Visionary Communications     V 307-234-5443    F 307-234-5446
==================================================
142 S. Center St.      Casper, Cheyenne, Gillette, Sheridan, Laramie
Casper, WY  82601   Evanston, Rawlins, Powell, Rock Springs, Cody
WWW.VCN.COM      Douglas, Chugwater, Pinedale, & Lander, Wy

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Charles Sprickman <[e-mail]>
Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 21 Aug 1999 22:26:22 -0400 (EDT)

On Sat, 21 Aug 1999, Ed wrote:

> So what do you say now Mr. Sprickman?

The same thing, I guess.  Our CLEC has ISP customers using 3Com, Ascend,
Cisco, Livingston, and Bay gear.  They all have problems because large
numbers of trunks out to the ILEC are misconfigured.  It's a fairly common
problem in fast growing areas.

Charles

> Ed
>
> ----- Original Message -----
> From: Charles Sprickman <[e-mail]>
> To: <[e-mail]>
> Sent: Saturday, August 21, 1999 2:22 PM
> Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
>
>
> On Sat, 21 Aug 1999, Ed wrote:
>
> > People have
> > been telling us for months that they dialup AOsmell, Earthstink, or
> > Mindsling and connect at 53,333 and can't understand why they have such
> > problems with our system... well now we know... those guys use Ascend!
>
> As for AOL, I understood they were USR, but they actually just signed a
> big deal with Cisco.  The last article I saw about Mindspring in one of
> those trade rags showed their CTO standing in front of huge banks of USR
> stuff...  The only one I know is mostly Ascend is Earthlink.  RCN is an
> Ascend shop as well...
>
> Keep in mind most of those problems can also be attributed to your lines.
> Our CLEC is currently in the process of retesting all of their trunks out
> to the tandems and end-offices as they've found the ILEC is misconfiguring
> lots of them.  Symptoms are very similar, but the standout is if you see
> more errors in one direction; there's a 80-some percent chance there's a
> line coding mismatche somewhere.
>
> Charles
>
> > For now we will stick with 3com... however everyday that goes by it
> becomes
> > more difficult to justify...
> >
> >
> > Ed
> >
> > ----- Original Message -----
> > From: Jeff Lynch <[e-mail]>
> > To: <[e-mail]>
> > Sent: Saturday, August 21, 1999 10:26 AM
> > Subject: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
> >
> >
> > On Tue, 10 Aug 1999, Allen Marsalis wrote:
> >
> > > At 01:24 AM 8/10/99 -0400, Ed wrote:
> > > >3com not doing V.90 as well as Ascend's.....
> > > >
> > > >We have tested and found it to be true that Ascend's authenticate and
> > work
> > > >at V.90 speeds much more often than 3com. It even happens when using a
> > > >3com/USR modem. It takes certain a certain situation for this to happen
> > but
> > > >it does happen...
> > > >
> > > >Just wondered if others out there have noticed it or had their
> > competitors
> > > >using Ascend's have customers that say "Well I get 56K speeds on so and
> > so
> > > >Internet Service, why not yours?"
> > >
> > > We have been 100% USR/3COM for 3 years and we recently received a Max
> > > TNT for eval to address the above problem..  Both chassis will be
> > > at the same NOC.  2 new PRI's for the TNT should be up this week..
> > > I'll keep you posted as to the results and try to provide some
> statistical
> > > data..
> >
> > Sorry for the length here, but I think it's a good read, eventhough I did
> > write it myself :)
> >
> > We did some churn analysis for customers that are no longer active or no
> > longer customers.  We looked at at customers lost since March 1999 because
> > of:
> >
> > a) reported problems connecting, staying connected, or poor  performance
> > b) unexplained non-payers/dead-beats
> > c) customers cancelled but did not give a reason (and did not
> >    return our calls when we tried to followed up).
> >
> > We had 103 total cancellations for these reasons since March 1999.
> >
> > We had enough data to determine that 57% of these 103 had problems were
> > directly attributable to connection quality. Of these 59 (103*0.57)
> > customers lost:
> >
> >   50% of them had not established a connection in 1999 (many of
> >      them reported this trouble)
> >
> >   40% had a large number of <1 minute connections, and showed a pattern
> >      of having to redial when they did stay on longer than a few minutes
> >
> >   10% had connect speeds that varied more than a few "rungs" between
> >      2400-52000
> >
> >
> > Let's see...If we had an alternate modem pool with a different NAS type,
> > we might have saved these 59 customers. That's about $1000/month at an
> > average revenue of $17/customer/month. We are still likely to continue
> > loosing more if we don't take action.
> >
> > Alternatively Scot Desort <[e-mail]>, wrote:
> >
> >  "When all else
> >   fails, pull $35 out of petty cash and send the customer a Paradise
> >   Winmodem (LT chipset, PCI), for free. These things are GREAT, will save
> >   you hours of tech support headaches, and inevitably win you over a
> >   customer that, in the long run, is worth a lot more than the $35 you
> >   spent  on the modem. We even offer to install it for free if they bring
> >   the box in.  Let's remember that the goal is to KEEP the customer a
> >   PAYING customer.  And nothing makes them more warm and fuzzy then
> getting
> >   something for free."
> >
> > This is interesting. Upgrading these customer's modems would have cost us
> > $2065 in hardware and perhaps $400-500 in labor estimated to retain the
> > $1000/month in revenue if this actually fixed the problem. I can see
> > several problems though. You could get a considerable number of calls from
> > unhappy customers like "my friend got a free modem now he gets 52K but I
> > only get 42K or 28.8K. I want one too." The customer's computer needs to
> > be sufficiently powered to run with a winmodem. How much time is spent
> > explaining that only certain customers qualify and how exactly are those
> > qualifications set? This also doesn't account for telco line issues. Many
> > customers now can't even tell you what kind of modem they have or what
> > processor they have, others may guess or argue that their's _should_
> > qualify for the free upgrade. For the program to not piss off any other
> > customers, it needs to be made available to everyone. Otherwise trouble
> > seems inevitable.
> >
> > On the other hand, although it takes some capital (not much with eq
> > leasing and zero install PRIs) and increases network complexity a little,
> > it's not that big of a deal for a reasonably clued provider to add another
> > NAS and move PRIs over to them in a separate hunt or just install a couple
> > new PRIs and gradually grow the alternate modem pool. But really doesn't
> > add much cost to the operation in the long run and the customers are
> > retained as well. Also:
> >
> > 1) it's available to everyone,
> > 2) it only takes a minute to help them change phone numbers
> > 3) and in most cases, if this doesn't solve the problem, they're not
> >    likely to be satisfied with anyone else and helps prove the problem
> >    is theirs, motivating them to follow your recommedations.
> >
> > The main thing that tweaks me is having to take this action in the first
> > place. Not to mention that we've got 7 or 8 hdsps from quad trades and arc
> > upgrades and such that we are paying for but won't be using this year now,
> > depending on the demand for the alternate pool. Cost of doing business.
> >
> > Time to get a MAX on eval and give it a whirl.
> >
> >
> ============================================================================
> > Jeffrey A. Lynch | JORSM Internet, Regional Internet Services
> > email: [e-mail] | 7 Area Codes in Chicagoland and NW Indiana
> > Voice: [phone] | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN
> > Autoresponse: [e-mail] | Quality Service, Affordable Prices
> > http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995
> >
> >
> >
> >
> >
> >
> > -
> >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> >  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 "[e-mail]"
> >  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 "[e-mail]"
>  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 "[e-mail]"
>  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 "[e-mail]"
 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: Rick <[e-mail]>
Subject: RE: (usr-tc) allowing one user to auth on one channel...
Date: 21 Aug 1999 23:32:15 -0400

Krish,
Thanks for the reply, but IS there a way of allowing only one particular
user to authenticate on a channel we have a dial-in number set up for
specifically, and no one else?

Thanks in advance,
Rick

-----Original Message-----
Sent:    Friday, August 20, 1999 10:38 PM
Cc:    [e-mail]

On Sat, 21 Aug 1999, Rick wrote:

> All,
> Was wondering if anyone has any idea's on whether this will work:
>
> we have gotten a single telephone number assigned to a single channel of
one of our T1's.
> Then we used the "set switched interface Slot:x/mod:y user_name" and "set
switched interface slot:x/mod:y password",
> commands in an attempt to allow ONLY that user to dial into that channel
and authenticate on it. However, ANY valid user
Well what you have done here is quite contrary to what you are thinking.
By setting a usernam and password for the interface - what you have done
is told the hiper arc and if any one calls irrespective on who it is the
username is going to be - what ever that is set on this particular
interface and the password is also set is this particular interface.  So
essentially any joe can dial and authenticate as long as the username and
password that you set on the interface is a valid user name.

The hiper arc is doing exactly what you set it for.


krish


> showing up in radius can authenticate on that channel as well.
>
> Should this work, as long as we have our call routing method set to fixed
assignment? Anyone else ever do this?
>
> Thanks in advance,
> Rick
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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.

begin 600 WINMAIL.DAT
M>)\^(B #`0:0" `$```````!``$``0>0!@`(````Y 0```````#H``$(@ <`
M& ```$E032Y-:6-R;W-O9G0@36%I;"Y.;W1E`#$(`0V ! `"`````@`"``$$
MD 8`T $```$````0`````P``, (````+``\.``````(!_P\!````40``````
M``"!*Q^DOJ,0&9UN`-T!#U0"`````'5S<BUT8T!L:7-T<RYX;6ES<VEO;BYC
M;VT`4TU44 !U<W(M=&- ;&ES=',N>&UI<W-I;VXN8V]M`````!X``C !````
M!0```%--5% `````'@`#, $````:````=7-R+71C0&QI<W1S+GAM:7-S:6]N
M+F-O;0````,`%0P!`````P#^#P8````>``$P`0```!P````G=7-R+71C0&QI
M<W1S+GAM:7-S:6]N+F-O;2<``@$+, $````?````4TU44#I54U(M5$- 3$E3
M5%,N6$U)4U-)3TXN0T]-```#```Y``````L`0#H!````'@#V7P$````:````
M=7-R+71C0&QI<W1S+GAM:7-S:6]N+F-O;0````(!]U\!````40````````"!
M*Q^DOJ,0&9UN`-T!#U0"`````'5S<BUT8T!L:7-T<RYX;6ES<VEO;BYC;VT`
M4TU44 !U<W(M=&- ;&ES=',N>&UI<W-I;VXN8V]M``````,`_5\!`````P#_
M7P`````"`?8/`0````0````````"^6@!!( !`#D```!213H@*'5S<BUT8RD@
M86QL;W=I;F<@;VYE('5S97(@=&\@875T:"!O;B!O;F4@8VAA;FYE;"XN+@`5
M$P$%@ ,`#@```,\'" `5`!<`( `/``8`/P$!(( #``X```#/!P@`%0`7`!P`
M*0`&`%4!`0F `0`A````0C-%0C0S1$4Q1C4X1#,Q,3@T,C P,#8P.3<Y149$
M,D8`+0<!`Y &`#@)```A````"P`"``$````+`",```````,`)@``````"P`I
M```````#`"X```````,`-@``````0 `Y``!K&>Y.[+X!'@!P``$````Y````
M4D4Z("AU<W(M=&,I(&%L;&]W:6YG(&]N92!U<V5R('1O(&%U=&@@;VX@;VYE
M(&-H86YN96PN+BX``````@%Q``$````6`````;[L3NX(WD/KM%@?$=.$( !@
MEY[]+P``'@`># $````%````4TU44 `````>`!\,`0```!8```!R:6-K>7I
M;6EN9'-P<FEN9RYC;VT````#``8067%LJ@,`!Q##!@``'@`($ $```!E````
M2U))4T@L5$A!3DM31D]25$A%4D503%DL0E5425-42$5214%705E/1D%,3$]7
M24Y'3TY,64].15!!4E1)0U5,05)54T525$]!551(14Y424-!5$5/3D%#2$%.
M3D5,5T5(059%00`````"`0D0`0```/<%``#S!0```0L``$Q:1G4LMQ^C`P`*
M`')C<&<Q,C46,@#X"V!N#A P,S.=`?<@`J0#XP(`8V@*P.!S970P( <3`H,`
M4*$0=G!R<3(1=GT*@-D(R" ["6\.,#4"@ J!;'5C`% +`V,2$@O$(&)+!1!S
M:"P*H@J 5#D1`&YK!" "$ 7 =&@,92 )< M0>2P@8LIU!4%U`R!)4QFQ$6 #
M&+()<"!A('=A>>@@;V8:P&P)``/P#R"]&R!N&3 ;X1C@"K%T#>#;&< *P741
M,!BA;QK &8#G&- ", W@8708X (@&L%M$/%N'% #('<8X!$`=A4:LF0',2T+
M@"!N=2\&T!U1$3$=(' 8<W-POP60!I >(1MP&4$`<&0@8.\=D!Q"'R 1,#\7
MM!>[($%(861V`'!C91>@;.L+@!C@4@W@:R-Z"O0E8+PS-@% %I !0!+ ;QY0
MA&-T$@0Q-B M*+)Z3P409PN !T %T >0<_AA9V4HLR-V)\0GD0L3P2?&:2TQ
M-#0!0"5@.#$X, % #- L4V(@JD8#83H,@V(18%0>0#L+< 8`5A=$*5 #H%M3
M0$U44#IT:R\40 $9<&)B82YA92[)'3!R+@6@;5TC=2V SP9@`C MYRV@:60;
M`!E0>$%U9QTP!4 !T!E0,08Y-# T$# Z,S@@Y%!-,9=4;RWG);DM@ Q#8RWG
M,1$M=&- 0R5@,[!S+GAM! %I;P(@,4(QF#"0:B?Q-:AEZ#H@*#>T*1M:&. =
M.O<><AQ"'M4N/B J7RMJ)Q1;"[87PT\#H 80=!E0,OXQ,V(T$QE0);(:X"?"
M+> ](XD^$7 ;<!>E1!!787T$('<"( 2!&[(&D")A>3\<0A$`!"!&`220`0!A
M)_L$(!Z!=QC0&G(8L00`&N#W`Q ?,06P:T-%1!!#MA]6OF<GT!Y0'I(`D \@
M;!C@\QY02U!P:!Q"('5%``"0_F<<4"*0'8)+!A[6&S$<0O=.8@AP+F Q1S ^
M1400&!#?2L$?41TQ30$8T2(@X@/AGS?P&- BD N 'E!R9@#031C@4PD`,E!X
M+P1A.ML;$!TR7RE0!X B(F-1+SU2-7-2N@JP!!!(L60B=T1G,5$#@60DA!Z1
M2J%M!P4Q'8(;<B!/3DQ9_QBQ'D =)Q_R4?(=D%HC'M9'(G(=OE30+B!(&Y!E
M]1^@<C-13EH`)/ E8"*0>QTR%[17'R ?,5HR1B!UG1]T9$8S&I)(,7%U5-#[
M/9$"(7(*P!L0'8%@!PK OTMA2" 80!NQ7<!)=4(;$/\1,1RP&\$:T!TR4\$B
M8U:V^QAW4@@M7_\<41>T2#$=@)YL4,1(("&@3'%R8R)C[T74/60;822!<@EP
M(9(<L/\?H4=C'9!4T&%R&,(7M&6%_V%C2H ;LAV!(*!GYEX26A3_2#$@XAZ!
M2!,<B6E%4A<B<N\8PF9'2#$'0',=D"#B;</W<>Q2!V0A4QV0%[0IH1WR\R(2
M1J-J;VO2`Z!:\UQO_T4!"0!E,FW4;I<B<A>T9D?_6B-@4G%79SITTEZI(&!3
MT3\^1Q?4:DI(,6#@&[)E>/T`T'0<$6@7=5,%0!B!@,O_%[0P`X3/1 $7@!N4
M(2$@0?]B4!_P'3!Y0QV^6YQ%$5_!^T^'0[932] 9P%#"2#)(P?\B47L('U9/
M`B("&/ (8&43OP> &, $<"#3'8$AX'A,\?=,E > `C _$7!&%",B<'3_8.!(
M`R-E26@D/T1G);A):/]#MBI%1! U<1T@`( PD 3R_V_A'8$WM!E0>#%<@0.@
M6/#W"W #(!V!(@# >1 +( -P=&] .(HBE[=4P3T@(K^8>C>T5 `@01C"!N!D
M&Q/_&,('@2G"3X<MD 6Q"X 8@?\`P!RP/4,?X2G@.$$;( 7 ]PEP8D (D'8;
MLB'@2U!&DK\BD&GBG]5Q,B* E[<B&- \;'!4`%MC5<%\,V1D]VQQ.& :4$0=
MD"*P6E-AH?\GT22#8%$%P)_>(WHJ19@__YE/FE^;;ZKUG0^>'Y\O@+;_H-^A
M[Z+_I ^E%:6OIK^GSQ>HWPJ $X$`O0```P`0$ `````#`!$0`0````,`@!#_
M____0 `',,##E&Y.[+X!0 `(,,##E&Y.[+X!"P`D@ @@!@``````P ``````
M`$8``````X4````````#`"6 "" &``````# ````````1@`````0A0``````
M``,`)H (( 8``````, ```````!&`````%*%``"W#0``'@`G@ @@!@``````
MP ```````$8`````5(4```$````$````."XP``,`*( (( 8``````, `````
M``!&``````&%````````"P`I@ @@!@``````P ```````$8`````#H4`````
M```#`"J "" &``````# ````````1@`````1A0````````,`*X (( 8`````
M`, ```````!&`````!B%````````'@`L@ @@!@``````P ```````$8`````
M-H4```$````!`````````!X`+8 (( 8``````, ```````!&`````#>%```!
M`````0`````````>`"Z "" &``````# ````````1@`````XA0```0````$`
D````````'@`]``$````%````4D4Z( `````#``TT_3<``->*
`
end


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Aaron Nabil <[e-mail]>
Subject: (usr-tc) looking for info on CFM file format from File MIB
Date: 22 Aug 1999 04:16:52 -0700 (PDT)


I'd like to be able to parse and decode a CFM file, but there
doesn't seem to be enough information in the docs to do this.

Anyone have any help or pointers?

thx,

--
Aaron Nabil

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 22 Aug 1999 09:11:09 -0400 (EDT)

My apologies for replying to a reply of what I wanted to reply to (did
that make sense?).  I blew away Ed's post before I realized what I had
done.  :/

I also want to apologize in advance for being a bit off topic here.

>On Sat, 21 Aug 1999, Ed wrote:
>> So what do you say now Mr. Sprickman?

Well...I'm not "Mr. Sprickman", but if you don't mind, I think I'll
reply here as well.

I say, "Perhaps you'd like to take that chip off your shoulder."

3Com has acknowledged that there is a problem and is working on a fix,
apparently.  What on earth do you want out of them?  So far, on this
list, you've basically done nothing but complain about 3Com, insult
other people on the list, and just generally be a twit.

You haven't been posting here long, I haven't a clue how long you lurked
before you posted, but I suspect it hasn't been terribly long.  If it
had, you'd know that 3Com's responsiveness to our complaints has
improved several orders of magnitudes.  No, its not perfect; yes, they
still have some work to do, overall, things are improving though.

And before you jump all over my case for not seeing problems that are
there, or not being willing to complain to 3Com, I'd suggest you go look
at the archives of the list (there's one at usr-tc.datasys.net that
groups posts by author) and check out some of my previous posts on here.
You, sir, aren't even close to being the biggest complainer about 3Com
in the history of this list.  You aren't even in the same league.  I
think, with all humility, that I probably take that title hands down.

Now, let me give you a few suggestions that will probably help in your
tenure on this list.

1)  Complain about 3Com when you have something to complain about.  I
think you probably have this one down.  :)

2)  Acknowledge when 3Com has addressed or is addressing the situation.

3)  Be helpful to others.  The major reason for this lists original
creation (hoping not to usurp Pete Ashdown here) was for usr-tc owners
to help usr-tc owners.  That there are 3Com employees and engineers on
the list and are extremely helpful here (outside of the basic job duties
as I understand it) is a wonderful bonus.

4)  Don't expect this to be the perfect avenue of communication to 3Com.
Its really not intended to be.  You probably should attempt (as I
understand you did with the v.90 issues) to contact 3Com directly,
first, this list and the totalservice fora would probably be a second
avenue to get 3Com's attention.  BUGTRAQ (in reference to the hiperbomb
thing) probably shouldn't be notified until the preceding steps are
taken.  (Jumping directly from directly contacting 3Com to BUGTRAQ
seemed, at least to me, to be a bit of a slight to other usr-tc owners
who largely could have been notified about the problem via this list and
totalservice before posting it far and wide on BUGTRAQ...this would have
given us a chance to put protective measures in place before everybody
and their brother knew about it).

And now...a (hopefully short) commentary to 3Com (largely stuff I've
said before, but I think bears repeating).

1)  Just because a customer doesn't have a support contract, doesn't
mean they can't find problems with the usr-tc stuff.  Last time I found
a (major) bug in the code, tech support wouldn't even talk to me because
I didn't have a support contract, even though I *clearly* indicated that
I wanted to report a bug.

2)  I'm sure your probably working on this already, but make the MNS
certification more convenient to obtain.  I'm not saying water down the
qualifications in any way, as that would be counter-productive...but
it'd be nice to be able to take the test someplace other than in MA.  :)

3)  It seems that USR modem code is sliding a bit.  While improvements
are being made, USR has long been known as having bar none the best
modem code around.  I fear that with the emphasis (understandable) of
getting the access server/router code up to par, that the engineering on
the modem code has fallen by the wayside a bit.  Quad modems are
incredible...the DSP's definitely still need some work.  I understand
that its not trivial, but this is important.  :)

4)  (and this is getting rather far afield from the original topic)  Try
to think "outside of the box" a bit more...I've sent several feature
request ideas to George Ebert (the SE for my region), and while I
haven't heard back any information about whether these ideas will be
implemented, my ideas that I've sent in really only scratch the surface
of the possibilities of the TC rack...  I'll try and write up some ideas
of what I think would be cool in the coming day or so and post them here
(as well as send them to George)...for other's comments.

Thanks!
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Aaron Nabil <[e-mail]>
Subject: (usr-tc) anyone tell me what these attributes are?
Date: 22 Aug 1999 06:17:38 -0700 (PDT)


I'm getting the following VSA's that aren't in any dictionary
I have a copy of.  Does anyone know what they are?

Authentication:
    0x9889    (39049)

Accounting:
    0x9856    (38998)
    0x9858    (39000)
    0x9859    (39001)
    0x986c    (39020)

--
Aaron Nabil

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Tatai SV Krishnan <[e-mail]>
Subject: RE: (usr-tc) allowing one user to auth on one channel...
Date: 21 Aug 1999 20:17:27 -0500 (CDT)

On Sat, 21 Aug 1999, Rick wrote:

> Krish,
> Thanks for the reply, but IS there a way of allowing only one particular
> user to authenticate on a channel we have a dial-in number set up for
> specifically, and no one else?

So what you are looking for is to allow only this particular user to use
the particular modem (slot/mod).  OK, does this user have a special DNIS
number to dial?  Or does is this user going to user a particular ANI only
when is connects?  You would need something mostlikely ANI to distiguish
the user, and then you have to setup the ANI for that particular slot/mod
thus user only with that ANI will be able to login.  You can do that with
DNIS also as long as no one else uses that DNIS.

Those are the only two ways you can do it currently, everything else that
you would need would be a CRA.

krish

>
> Thanks in advance,
> Rick
>
> -----Original Message-----
> From:    Tatai SV Krishnan [SMTP:[e-mail]]
> Sent:    Friday, August 20, 1999 10:38 PM
> To:    Rick
> Cc:    [e-mail]
> Subject:    Re: (usr-tc) allowing one user to auth on one channel...
>
> On Sat, 21 Aug 1999, Rick wrote:
>
> > All,
> > Was wondering if anyone has any idea's on whether this will work:
> >
> > we have gotten a single telephone number assigned to a single channel of
> one of our T1's.
> > Then we used the "set switched interface Slot:x/mod:y user_name" and "set
> switched interface slot:x/mod:y password",
> > commands in an attempt to allow ONLY that user to dial into that channel
> and authenticate on it. However, ANY valid user
> Well what you have done here is quite contrary to what you are thinking.
> By setting a usernam and password for the interface - what you have done
> is told the hiper arc and if any one calls irrespective on who it is the
> username is going to be - what ever that is set on this particular
> interface and the password is also set is this particular interface.  So
> essentially any joe can dial and authenticate as long as the username and
> password that you set on the interface is a valid user name.
>
> The hiper arc is doing exactly what you set it for.
>
>
> krish
>
>
> > showing up in radius can authenticate on that channel as well.
> >
> > Should this work, as long as we have our call routing method set to fixed
> assignment? Anyone else ever do this?
> >
> > Thanks in advance,
> > Rick
> >
> >
> > -
> >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> >  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 "[e-mail]"
>  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.
>
> begin 600 WINMAIL.DAT
> M>)\^(B #`0:0" `$```````!``$``0>0!@`(````Y 0```````#H``$(@ <`
> M& ```$E032Y-:6-R;W-O9G0@36%I;"Y.;W1E`#$(`0V ! `"`````@`"``$$
> MD 8`T $```$````0`````P``, (````+``\.``````(!_P\!````40``````
> M``"!*Q^DOJ,0&9UN`-T!#U0"`````'5S<BUT8T!L:7-T<RYX;6ES<VEO;BYC
> M;VT`4TU44 !U<W(M=&- ;&ES=',N>&UI<W-I;VXN8V]M`````!X``C !````
> M!0```%--5% `````'@`#, $````:````=7-R+71C0&QI<W1S+GAM:7-S:6]N
> M+F-O;0````,`%0P!`````P#^#P8````>``$P`0```!P````G=7-R+71C0&QI
> M<W1S+GAM:7-S:6]N+F-O;2<``@$+, $````?````4TU44#I54U(M5$- 3$E3
> M5%,N6$U)4U-)3TXN0T]-```#```Y``````L`0#H!````'@#V7P$````:````
> M=7-R+71C0&QI<W1S+GAM:7-S:6]N+F-O;0````(!]U\!````40````````"!
> M*Q^DOJ,0&9UN`-T!#U0"`````'5S<BUT8T!L:7-T<RYX;6ES<VEO;BYC;VT`
> M4TU44 !U<W(M=&- ;&ES=',N>&UI<W-I;VXN8V]M``````,`_5\!`````P#_
> M7P`````"`?8/`0````0````````"^6@!!( !`#D```!213H@*'5S<BUT8RD@
> M86QL;W=I;F<@;VYE('5S97(@=&\@875T:"!O;B!O;F4@8VAA;FYE;"XN+@`5
> M$P$%@ ,`#@```,\'" `5`!<`( `/``8`/P$!(( #``X```#/!P@`%0`7`!P`
> M*0`&`%4!`0F `0`A````0C-%0C0S1$4Q1C4X1#,Q,3@T,C P,#8P.3<Y149$
> M,D8`+0<!`Y &`#@)```A````"P`"``$````+`",```````,`)@``````"P`I
> M```````#`"X```````,`-@``````0 `Y``!K&>Y.[+X!'@!P``$````Y````
> M4D4Z("AU<W(M=&,I(&%L;&]W:6YG(&]N92!U<V5R('1O(&%U=&@@;VX@;VYE
> M(&-H86YN96PN+BX``````@%Q``$````6`````;[L3NX(WD/KM%@?$=.$( !@
> MEY[]+P``'@`># $````%````4TU44 `````>`!\,`0```!8```!R:6-K>7I
> M;6EN9'-P<FEN9RYC;VT````#``8067%LJ@,`!Q##!@``'@`($ $```!E````
> M2U))4T@L5$A!3DM31D]25$A%4D503%DL0E5425-42$5214%705E/1D%,3$]7
> M24Y'3TY,64].15!!4E1)0U5,05)54T525$]!551(14Y424-!5$5/3D%#2$%.
> M3D5,5T5(059%00`````"`0D0`0```/<%``#S!0```0L``$Q:1G4LMQ^C`P`*
> M`')C<&<Q,C46,@#X"V!N#A P,S.=`?<@`J0#XP(`8V@*P.!S970P( <3`H,`
> M4*$0=G!R<3(1=GT*@-D(R" ["6\.,#4"@ J!;'5C`% +`V,2$@O$(&)+!1!S
> M:"P*H@J 5#D1`&YK!" "$ 7 =&@,92 )< M0>2P@8LIU!4%U`R!)4QFQ$6 #
> M&+()<"!A('=A>>@@;V8:P&P)``/P#R"]&R!N&3 ;X1C@"K%T#>#;&< *P741
> M,!BA;QK &8#G&- ", W@8708X (@&L%M$/%N'% #('<8X!$`=A4:LF0',2T+
> M@"!N=2\&T!U1$3$=(' 8<W-POP60!I >(1MP&4$`<&0@8.\=D!Q"'R 1,#\7
> MM!>[($%(861V`'!C91>@;.L+@!C@4@W@:R-Z"O0E8+PS-@% %I !0!+ ;QY0
> MA&-T$@0Q-B M*+)Z3P409PN !T %T >0<_AA9V4HLR-V)\0GD0L3P2?&:2TQ
> M-#0!0"5@.#$X, % #- L4V(@JD8#83H,@V(18%0>0#L+< 8`5A=$*5 #H%M3
> M0$U44#IT:R\40 $9<&)B82YA92[)'3!R+@6@;5TC=2V SP9@`C MYRV@:60;
> M`!E0>$%U9QTP!4 !T!E0,08Y-# T$# Z,S@@Y%!-,9=4;RWG);DM@ Q#8RWG
> M,1$M=&- 0R5@,[!S+GAM! %I;P(@,4(QF#"0:B?Q-:AEZ#H@*#>T*1M:&. =
> M.O<><AQ"'M4N/B J7RMJ)Q1;"[87PT\#H 80=!E0,OXQ,V(T$QE0);(:X"?"
> M+> ](XD^$7 ;<!>E1!!787T$('<"( 2!&[(&D")A>3\<0A$`!"!&`220`0!A
> M)_L$(!Z!=QC0&G(8L00`&N#W`Q ?,06P:T-%1!!#MA]6OF<GT!Y0'I(`D \@
> M;!C@\QY02U!P:!Q"('5%``"0_F<<4"*0'8)+!A[6&S$<0O=.8@AP+F Q1S ^
> M1400&!#?2L$?41TQ30$8T2(@X@/AGS?P&- BD N 'E!R9@#031C@4PD`,E!X
> M+P1A.ML;$!TR7RE0!X B(F-1+SU2-7-2N@JP!!!(L60B=T1G,5$#@60DA!Z1
> M2J%M!P4Q'8(;<B!/3DQ9_QBQ'D =)Q_R4?(=D%HC'M9'(G(=OE30+B!(&Y!E
> M]1^@<C-13EH`)/ E8"*0>QTR%[17'R ?,5HR1B!UG1]T9$8S&I)(,7%U5-#[
> M/9$"(7(*P!L0'8%@!PK OTMA2" 80!NQ7<!)=4(;$/\1,1RP&\$:T!TR4\$B
> M8U:V^QAW4@@M7_\<41>T2#$=@)YL4,1(("&@3'%R8R)C[T74/60;822!<@EP
> M(9(<L/\?H4=C'9!4T&%R&,(7M&6%_V%C2H ;LAV!(*!GYEX26A3_2#$@XAZ!
> M2!,<B6E%4A<B<N\8PF9'2#$'0',=D"#B;</W<>Q2!V0A4QV0%[0IH1WR\R(2
> M1J-J;VO2`Z!:\UQO_T4!"0!E,FW4;I<B<A>T9D?_6B-@4G%79SITTEZI(&!3
> MT3\^1Q?4:DI(,6#@&[)E>/T`T'0<$6@7=5,%0!B!@,O_%[0P`X3/1 $7@!N4
> M(2$@0?]B4!_P'3!Y0QV^6YQ%$5_!^T^'0[932] 9P%#"2#)(P?\B47L('U9/
> M`B("&/ (8&43OP> &, $<"#3'8$AX'A,\?=,E > `C _$7!&%",B<'3_8.!(
> M`R-E26@D/T1G);A):/]#MBI%1! U<1T@`( PD 3R_V_A'8$WM!E0>#%<@0.@
> M6/#W"W #(!V!(@# >1 +( -P=&] .(HBE[=4P3T@(K^8>C>T5 `@01C"!N!D
> M&Q/_&,('@2G"3X<MD 6Q"X 8@?\`P!RP/4,?X2G@.$$;( 7 ]PEP8D (D'8;
> MLB'@2U!&DK\BD&GBG]5Q,B* E[<B&- \;'!4`%MC5<%\,V1D]VQQ.& :4$0=
> MD"*P6E-AH?\GT22#8%$%P)_>(WHJ19@__YE/FE^;;ZKUG0^>'Y\O@+;_H-^A
> M[Z+_I ^E%:6OIK^GSQ>HWPJ $X$`O0```P`0$ `````#`!$0`0````,`@!#_
> M____0 `',,##E&Y.[+X!0 `(,,##E&Y.[+X!"P`D@ @@!@``````P ``````
> M`$8``````X4````````#`"6 "" &``````# ````````1@`````0A0``````
> M``,`)H (( 8``````, ```````!&`````%*%``"W#0``'@`G@ @@!@``````
> MP ```````$8`````5(4```$````$````."XP``,`*( (( 8``````, `````
> M``!&``````&%````````"P`I@ @@!@``````P ```````$8`````#H4`````
> M```#`"J "" &``````# ````````1@`````1A0````````,`*X (( 8`````
> M`, ```````!&`````!B%````````'@`L@ @@!@``````P ```````$8`````
> M-H4```$````!`````````!X`+8 (( 8``````, ```````!&`````#>%```!
> M`````0`````````>`"Z "" &``````# ````````1@`````XA0```0````$`
> D````````'@`]``$````%````4D4Z( `````#``TT_3<``->*
> `
> end
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: "Scot Desort" <[e-mail]>
Subject: RE: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 22 Aug 1999 11:20:38 -0400

Well done, Jeff.

-Scot Desort
NJ Internet Access


-----Original Message-----
[mailto:[e-mail]]On Behalf Of Jeff Mcadams
Sent: Sunday, August 22, 1999 9:11 AM


My apologies for replying to a reply of what I wanted to reply to (did
that make sense?).  I blew away Ed's post before I realized what I had
done.  :/

I also want to apologize in advance for being a bit off topic here.

>On Sat, 21 Aug 1999, Ed wrote:
>> So what do you say now Mr. Sprickman?

Well...I'm not "Mr. Sprickman", but if you don't mind, I think I'll
reply here as well.

I say, "Perhaps you'd like to take that chip off your shoulder."

3Com has acknowledged that there is a problem and is working on a fix,
apparently.  What on earth do you want out of them?  So far, on this
list, you've basically done nothing but complain about 3Com, insult
other people on the list, and just generally be a twit.

You haven't been posting here long, I haven't a clue how long you lurked
before you posted, but I suspect it hasn't been terribly long.  If it
had, you'd know that 3Com's responsiveness to our complaints has
improved several orders of magnitudes.  No, its not perfect; yes, they
still have some work to do, overall, things are improving though.

And before you jump all over my case for not seeing problems that are
there, or not being willing to complain to 3Com, I'd suggest you go look
at the archives of the list (there's one at usr-tc.datasys.net that
groups posts by author) and check out some of my previous posts on here.
You, sir, aren't even close to being the biggest complainer about 3Com
in the history of this list.  You aren't even in the same league.  I
think, with all humility, that I probably take that title hands down.

Now, let me give you a few suggestions that will probably help in your
tenure on this list.

1)  Complain about 3Com when you have something to complain about.  I
think you probably have this one down.  :)

2)  Acknowledge when 3Com has addressed or is addressing the situation.

3)  Be helpful to others.  The major reason for this lists original
creation (hoping not to usurp Pete Ashdown here) was for usr-tc owners
to help usr-tc owners.  That there are 3Com employees and engineers on
the list and are extremely helpful here (outside of the basic job duties
as I understand it) is a wonderful bonus.

4)  Don't expect this to be the perfect avenue of communication to 3Com.
Its really not intended to be.  You probably should attempt (as I
understand you did with the v.90 issues) to contact 3Com directly,
first, this list and the totalservice fora would probably be a second
avenue to get 3Com's attention.  BUGTRAQ (in reference to the hiperbomb
thing) probably shouldn't be notified until the preceding steps are
taken.  (Jumping directly from directly contacting 3Com to BUGTRAQ
seemed, at least to me, to be a bit of a slight to other usr-tc owners
who largely could have been notified about the problem via this list and
totalservice before posting it far and wide on BUGTRAQ...this would have
given us a chance to put protective measures in place before everybody
and their brother knew about it).

And now...a (hopefully short) commentary to 3Com (largely stuff I've
said before, but I think bears repeating).

1)  Just because a customer doesn't have a support contract, doesn't
mean they can't find problems with the usr-tc stuff.  Last time I found
a (major) bug in the code, tech support wouldn't even talk to me because
I didn't have a support contract, even though I *clearly* indicated that
I wanted to report a bug.

2)  I'm sure your probably working on this already, but make the MNS
certification more convenient to obtain.  I'm not saying water down the
qualifications in any way, as that would be counter-productive...but
it'd be nice to be able to take the test someplace other than in MA.  :)

3)  It seems that USR modem code is sliding a bit.  While improvements
are being made, USR has long been known as having bar none the best
modem code around.  I fear that with the emphasis (understandable) of
getting the access server/router code up to par, that the engineering on
the modem code has fallen by the wayside a bit.  Quad modems are
incredible...the DSP's definitely still need some work.  I understand
that its not trivial, but this is important.  :)

4)  (and this is getting rather far afield from the original topic)  Try
to think "outside of the box" a bit more...I've sent several feature
request ideas to George Ebert (the SE for my region), and while I
haven't heard back any information about whether these ideas will be
implemented, my ideas that I've sent in really only scratch the surface
of the possibilities of the TC rack...  I'll try and write up some ideas
of what I think would be cool in the coming day or so and post them here
(as well as send them to George)...for other's comments.

Thanks!
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Ed" <[e-mail]>
Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 22 Aug 1999 13:49:09 -0400

Jeff that was well said....

I have to agree with you. I originally posted the "3com not doing V.90 as
well as Ascends" and had hoped to get others to realize the problem. Wanted
support from other 3com users to let 3com know there is a major concern.
When someone countered the issue I got a little defensive because I knew
there was definitely an issue and not to take it lightly or water it down
with the "line" or "client modem" thing. This is a real concern to me and
should be to everyone...

I apologize. TouchΘ on the "twit" comment ;-)

I am glad you also realize there are issues with 3com. Yes I have seen some
of your posts... you have got me beat hands down on complaints.


Ed

----- Original Message -----
Sent: Sunday, August 22, 1999 9:11 AM


My apologies for replying to a reply of what I wanted to reply to (did
that make sense?).  I blew away Ed's post before I realized what I had
done.  :/

I also want to apologize in advance for being a bit off topic here.

>On Sat, 21 Aug 1999, Ed wrote:
>> So what do you say now Mr. Sprickman?

Well...I'm not "Mr. Sprickman", but if you don't mind, I think I'll
reply here as well.

I say, "Perhaps you'd like to take that chip off your shoulder."

3Com has acknowledged that there is a problem and is working on a fix,
apparently.  What on earth do you want out of them?  So far, on this
list, you've basically done nothing but complain about 3Com, insult
other people on the list, and just generally be a twit.

You haven't been posting here long, I haven't a clue how long you lurked
before you posted, but I suspect it hasn't been terribly long.  If it
had, you'd know that 3Com's responsiveness to our complaints has
improved several orders of magnitudes.  No, its not perfect; yes, they
still have some work to do, overall, things are improving though.

And before you jump all over my case for not seeing problems that are
there, or not being willing to complain to 3Com, I'd suggest you go look
at the archives of the list (there's one at usr-tc.datasys.net that
groups posts by author) and check out some of my previous posts on here.
You, sir, aren't even close to being the biggest complainer about 3Com
in the history of this list.  You aren't even in the same league.  I
think, with all humility, that I probably take that title hands down.

Now, let me give you a few suggestions that will probably help in your
tenure on this list.

1)  Complain about 3Com when you have something to complain about.  I
think you probably have this one down.  :)

2)  Acknowledge when 3Com has addressed or is addressing the situation.

3)  Be helpful to others.  The major reason for this lists original
creation (hoping not to usurp Pete Ashdown here) was for usr-tc owners
to help usr-tc owners.  That there are 3Com employees and engineers on
the list and are extremely helpful here (outside of the basic job duties
as I understand it) is a wonderful bonus.

4)  Don't expect this to be the perfect avenue of communication to 3Com.
Its really not intended to be.  You probably should attempt (as I
understand you did with the v.90 issues) to contact 3Com directly,
first, this list and the totalservice fora would probably be a second
avenue to get 3Com's attention.  BUGTRAQ (in reference to the hiperbomb
thing) probably shouldn't be notified until the preceding steps are
taken.  (Jumping directly from directly contacting 3Com to BUGTRAQ
seemed, at least to me, to be a bit of a slight to other usr-tc owners
who largely could have been notified about the problem via this list and
totalservice before posting it far and wide on BUGTRAQ...this would have
given us a chance to put protective measures in place before everybody
and their brother knew about it).

And now...a (hopefully short) commentary to 3Com (largely stuff I've
said before, but I think bears repeating).

1)  Just because a customer doesn't have a support contract, doesn't
mean they can't find problems with the usr-tc stuff.  Last time I found
a (major) bug in the code, tech support wouldn't even talk to me because
I didn't have a support contract, even though I *clearly* indicated that
I wanted to report a bug.

2)  I'm sure your probably working on this already, but make the MNS
certification more convenient to obtain.  I'm not saying water down the
qualifications in any way, as that would be counter-productive...but
it'd be nice to be able to take the test someplace other than in MA.  :)

3)  It seems that USR modem code is sliding a bit.  While improvements
are being made, USR has long been known as having bar none the best
modem code around.  I fear that with the emphasis (understandable) of
getting the access server/router code up to par, that the engineering on
the modem code has fallen by the wayside a bit.  Quad modems are
incredible...the DSP's definitely still need some work.  I understand
that its not trivial, but this is important.  :)

4)  (and this is getting rather far afield from the original topic)  Try
to think "outside of the box" a bit more...I've sent several feature
request ideas to George Ebert (the SE for my region), and while I
haven't heard back any information about whether these ideas will be
implemented, my ideas that I've sent in really only scratch the surface
of the possibilities of the TC rack...  I'll try and write up some ideas
of what I think would be cool in the coming day or so and post them here
(as well as send them to George)...for other's comments.

Thanks!
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 "[e-mail]"
 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: Nicolas St-Pierre <[e-mail]>
Subject: Re: (usr-tc) anyone tell me what these attributes are?
Date: 22 Aug 1999 18:49:34 -0400

Hello AAron,


> Authentication:
>         0x9889  (39049)
No Clue on this one perhaps a new one. Can't see it in the 3Com Radius
dictionary file.


>
> Accounting:
>         0x9856  (38998)
VSA USR  VTS-Session-Key        0x9856   string
VSA USR  Orig-NAS-Type                  0x9857   string
VSA USR  Call-Arrival-Time              0x9858   integer
VSA USR  Call-End-Time                  0x9859   integer


>         0x9858  (39000)
>         0x9859  (39001)
>         0x986c  (39020)

VSA USR  Tunnel-Auth-Hostname        0x986b   string
VSA USR  Acct-Reason-Code            0x986c   integer



Hope this helps.  Cheers,


Nick



--
Nicolas St-Pierre
Systems Engineer
Internet Access Solutions Ltd.
Tel [phone]
Fax [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: das <[e-mail]>
Subject: (usr-tc) HiperARC redundancy
Date: 23 Aug 1999 12:19:19 +0900

I saw this question quite awhile ago on this list, but I never saw an
answer to it.  So, I thought I would post it myself to see if anyone
knew about it.

Is there a way to provide redundancy by putting a second hiperarc in
a chassis so that when the first hiperarc fails, the second one automatically
steps in and picks up where the other left off?

Thanks

das

--
____________________________________________
Alex Substanley       Global OnLine Japan
                Engineering Department
Das Man               TEL: [phone]
Systems Engineer      FAX: [phone]
  The Highest Quality Service, Bar None
____________________________________________

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) HiperARC redundancy
Date: 23 Aug 1999 00:44:12 -0400 (EDT)

Thus spake das
>I saw this question quite awhile ago on this list, but I never saw an
>answer to it.  So, I thought I would post it myself to see if anyone
>knew about it.

>Is there a way to provide redundancy by putting a second hiperarc in
>a chassis so that when the first hiperarc fails, the second one automatically
>steps in and picks up where the other left off?

On the second Arc:
enable nmc chassis_awareness
enable nmc dynamic_slot_assignment
enable nmc dsa_idle_rebalancing

When the first Arc dies, the modems will then be seen as unassigned, and
after some amount of time (not immediate :/ ) be dynamically reassigned
to the second Arc...once they are assigned to the second Arc, assuming
the second Arc is fully configured to take calls and do everything you
need of it...the second Arc should start taking the calls.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: das <[e-mail]>
Subject: Re: (usr-tc) HiperARC redundancy
Date: 23 Aug 1999 14:39:01 +0900

Thanks for the response, Jeff.

OK, considering this won't happen unless the first harc dies,
I assume it to be safe to use the same ip pools for both harcs.
Can you foresee any problems with that?

das

Jeff Mcadams ([e-mail]) spake:

> Thus spake das
> >I saw this question quite awhile ago on this list, but I never saw an
> >answer to it.  So, I thought I would post it myself to see if anyone
> >knew about it.
>
> >Is there a way to provide redundancy by putting a second hiperarc in
> >a chassis so that when the first hiperarc fails, the second one automatically
> >steps in and picks up where the other left off?
>
> On the second Arc:
> enable nmc chassis_awareness
> enable nmc dynamic_slot_assignment
> enable nmc dsa_idle_rebalancing
>
> When the first Arc dies, the modems will then be seen as unassigned, and
> after some amount of time (not immediate :/ ) be dynamically reassigned
> to the second Arc...once they are assigned to the second Arc, assuming
> the second Arc is fully configured to take calls and do everything you
> need of it...the second Arc should start taking the calls.
> --
> Jeff McAdams                            Email: [e-mail]
> Head Network Administrator              Voice: [phone]
> IgLou Internet Services                        [phone]
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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.

--
____________________________________________
Alex Substanley       Global OnLine Japan
                Engineering Department
Das Man               TEL: [phone]
Systems Engineer      FAX: [phone]
  The Highest Quality Service, Bar None
____________________________________________

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Jamie Orzechowski" <[e-mail]>
Subject: (usr-tc) Radius questions
Date: 23 Aug 1999 08:04:49 -0400

I was wondering if anyone has any info on the following

I have a PRIMARY and SECONDARY radius server online.  The secondary will
authenticate anything if the primary is down.  THis is to save on all the
calls if something goes wrong.  The problem is that when the primary server
goes down the ARC will mke my secondary active.  This is fine ... then my
primary comes back up and it does not set the primary active.  I have to
telnet into the ARC and set authentication secondary_server 0.0.0.0 then set
authentication secondary_server x.x.x.x and it will force it back to use the
primary as active.  Is there any way for the ARC to check if the primary
comes back up and force it back to be active???


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) HiperARC redundancy
Date: 23 Aug 1999 08:04:56 -0400 (EDT)

Thus spake das
>Thanks for the response, Jeff.

>OK, considering this won't happen unless the first harc dies,
>I assume it to be safe to use the same ip pools for both harcs.
>Can you foresee any problems with that?

Nope, as long as you're using it to provide redundancy, you should be
fine with that.  If you were using it to do load balancing, things would
get a bit tougher.  :)
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) Radius questions
Date: 23 Aug 1999 08:16:26 -0400 (EDT)

Thus spake Jamie Orzechowski
>I was wondering if anyone has any info on the following

>I have a PRIMARY and SECONDARY radius server online.  The secondary will
>authenticate anything if the primary is down.  THis is to save on all the
>calls if something goes wrong.  The problem is that when the primary server
>goes down the ARC will mke my secondary active.  This is fine ... then my
>primary comes back up and it does not set the primary active.  I have to
>telnet into the ARC and set authentication secondary_server 0.0.0.0 then set
>authentication secondary_server x.x.x.x and it will force it back to use the
>primary as active.  Is there any way for the ARC to check if the primary
>comes back up and force it back to be active???

set radius authentication_algorithm fall_through
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Brian Gordon" <[e-mail]>
Subject: Re: (usr-tc) HiperARC redundancy
Date: 23 Aug 1999 09:14:01 -0400

Okay question about this....

Any problems running load balancing and hiper arc redundancy?

Brian Gordon
[e-mail]
----- Original Message -----
Sent: Monday, August 23, 1999 8:04 AM


> Thus spake das
> >Thanks for the response, Jeff.
>
> >OK, considering this won't happen unless the first harc dies,
> >I assume it to be safe to use the same ip pools for both harcs.
> >Can you foresee any problems with that?
>
> Nope, as long as you're using it to provide redundancy, you should be
> fine with that.  If you were using it to do load balancing, things would
> get a bit tougher.  :)
> --
> Jeff McAdams                            Email: [e-mail]
> Head Network Administrator              Voice: [phone]
> IgLou Internet Services                        [phone]
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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 <[e-mail]>
Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 23 Aug 1999 09:20:20 -0400 (EDT)

Ok... so what are the proper configuration for CT-1's and PRI's?  These
misterious "miconfigured lines" statement comes up all the time.  But
other than B8ZS/ESF... what other items can be misconfigured?

Anybody *really* know?

Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax [phone]
[e-mail]

On Sat, 21 Aug 1999, Charles Sprickman wrote:

> On Sat, 21 Aug 1999, Ed wrote:
>
> > So what do you say now Mr. Sprickman?
>
> The same thing, I guess.  Our CLEC has ISP customers using 3Com, Ascend,
> Cisco, Livingston, and Bay gear.  They all have problems because large
> numbers of trunks out to the ILEC are misconfigured.  It's a fairly common
> problem in fast growing areas.
>
> Charles
>
> > Ed
> >
> > ----- Original Message -----
> > From: Charles Sprickman <[e-mail]>
> > To: <[e-mail]>
> > Sent: Saturday, August 21, 1999 2:22 PM
> > Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
> >
> >
> > On Sat, 21 Aug 1999, Ed wrote:
> >
> > > People have
> > > been telling us for months that they dialup AOsmell, Earthstink, or
> > > Mindsling and connect at 53,333 and can't understand why they have such
> > > problems with our system... well now we know... those guys use Ascend!
> >
> > As for AOL, I understood they were USR, but they actually just signed a
> > big deal with Cisco.  The last article I saw about Mindspring in one of
> > those trade rags showed their CTO standing in front of huge banks of USR
> > stuff...  The only one I know is mostly Ascend is Earthlink.  RCN is an
> > Ascend shop as well...
> >
> > Keep in mind most of those problems can also be attributed to your lines.
> > Our CLEC is currently in the process of retesting all of their trunks out
> > to the tandems and end-offices as they've found the ILEC is misconfiguring
> > lots of them.  Symptoms are very similar, but the standout is if you see
> > more errors in one direction; there's a 80-some percent chance there's a
> > line coding mismatche somewhere.
> >
> > Charles
> >
> > > For now we will stick with 3com... however everyday that goes by it
> > becomes
> > > more difficult to justify...
> > >
> > >
> > > Ed
> > >
> > > ----- Original Message -----
> > > From: Jeff Lynch <[e-mail]>
> > > To: <[e-mail]>
> > > Sent: Saturday, August 21, 1999 10:26 AM
> > > Subject: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
> > >
> > >
> > > On Tue, 10 Aug 1999, Allen Marsalis wrote:
> > >
> > > > At 01:24 AM 8/10/99 -0400, Ed wrote:
> > > > >3com not doing V.90 as well as Ascend's.....
> > > > >
> > > > >We have tested and found it to be true that Ascend's authenticate and
> > > work
> > > > >at V.90 speeds much more often than 3com. It even happens when using a
> > > > >3com/USR modem. It takes certain a certain situation for this to happen
> > > but
> > > > >it does happen...
> > > > >
> > > > >Just wondered if others out there have noticed it or had their
> > > competitors
> > > > >using Ascend's have customers that say "Well I get 56K speeds on so and
> > > so
> > > > >Internet Service, why not yours?"
> > > >
> > > > We have been 100% USR/3COM for 3 years and we recently received a Max
> > > > TNT for eval to address the above problem..  Both chassis will be
> > > > at the same NOC.  2 new PRI's for the TNT should be up this week..
> > > > I'll keep you posted as to the results and try to provide some
> > statistical
> > > > data..
> > >
> > > Sorry for the length here, but I think it's a good read, eventhough I did
> > > write it myself :)
> > >
> > > We did some churn analysis for customers that are no longer active or no
> > > longer customers.  We looked at at customers lost since March 1999 because
> > > of:
> > >
> > > a) reported problems connecting, staying connected, or poor  performance
> > > b) unexplained non-payers/dead-beats
> > > c) customers cancelled but did not give a reason (and did not
> > >    return our calls when we tried to followed up).
> > >
> > > We had 103 total cancellations for these reasons since March 1999.
> > >
> > > We had enough data to determine that 57% of these 103 had problems were
> > > directly attributable to connection quality. Of these 59 (103*0.57)
> > > customers lost:
> > >
> > >   50% of them had not established a connection in 1999 (many of
> > >      them reported this trouble)
> > >
> > >   40% had a large number of <1 minute connections, and showed a pattern
> > >      of having to redial when they did stay on longer than a few minutes
> > >
> > >   10% had connect speeds that varied more than a few "rungs" between
> > >      2400-52000
> > >
> > >
> > > Let's see...If we had an alternate modem pool with a different NAS type,
> > > we might have saved these 59 customers. That's about $1000/month at an
> > > average revenue of $17/customer/month. We are still likely to continue
> > > loosing more if we don't take action.
> > >
> > > Alternatively Scot Desort <[e-mail]>, wrote:
> > >
> > >  "When all else
> > >   fails, pull $35 out of petty cash and send the customer a Paradise
> > >   Winmodem (LT chipset, PCI), for free. These things are GREAT, will save
> > >   you hours of tech support headaches, and inevitably win you over a
> > >   customer that, in the long run, is worth a lot more than the $35 you
> > >   spent  on the modem. We even offer to install it for free if they bring
> > >   the box in.  Let's remember that the goal is to KEEP the customer a
> > >   PAYING customer.  And nothing makes them more warm and fuzzy then
> > getting
> > >   something for free."
> > >
> > > This is interesting. Upgrading these customer's modems would have cost us
> > > $2065 in hardware and perhaps $400-500 in labor estimated to retain the
> > > $1000/month in revenue if this actually fixed the problem. I can see
> > > several problems though. You could get a considerable number of calls from
> > > unhappy customers like "my friend got a free modem now he gets 52K but I
> > > only get 42K or 28.8K. I want one too." The customer's computer needs to
> > > be sufficiently powered to run with a winmodem. How much time is spent
> > > explaining that only certain customers qualify and how exactly are those
> > > qualifications set? This also doesn't account for telco line issues. Many
> > > customers now can't even tell you what kind of modem they have or what
> > > processor they have, others may guess or argue that their's _should_
> > > qualify for the free upgrade. For the program to not piss off any other
> > > customers, it needs to be made available to everyone. Otherwise trouble
> > > seems inevitable.
> > >
> > > On the other hand, although it takes some capital (not much with eq
> > > leasing and zero install PRIs) and increases network complexity a little,
> > > it's not that big of a deal for a reasonably clued provider to add another
> > > NAS and move PRIs over to them in a separate hunt or just install a couple
> > > new PRIs and gradually grow the alternate modem pool. But really doesn't
> > > add much cost to the operation in the long run and the customers are
> > > retained as well. Also:
> > >
> > > 1) it's available to everyone,
> > > 2) it only takes a minute to help them change phone numbers
> > > 3) and in most cases, if this doesn't solve the problem, they're not
> > >    likely to be satisfied with anyone else and helps prove the problem
> > >    is theirs, motivating them to follow your recommedations.
> > >
> > > The main thing that tweaks me is having to take this action in the first
> > > place. Not to mention that we've got 7 or 8 hdsps from quad trades and arc
> > > upgrades and such that we are paying for but won't be using this year now,
> > > depending on the demand for the alternate pool. Cost of doing business.
> > >
> > > Time to get a MAX on eval and give it a whirl.
> > >
> > >
> > ============================================================================
> > > Jeffrey A. Lynch | JORSM Internet, Regional Internet Services
> > > email: [e-mail] | 7 Area Codes in Chicagoland and NW Indiana
> > > Voice: [phone] | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN
> > > Autoresponse: [e-mail] | Quality Service, Affordable Prices
> > > http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995
> > >
> > >
> > >
> > >
> > >
> > >
> > > -
> > >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> > >  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 "[e-mail]"
> > >  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 "[e-mail]"
> >  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 "[e-mail]"
> >  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 "[e-mail]"
>  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 "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) HiperARC redundancy
Date: 23 Aug 1999 09:28:34 -0400 (EDT)

Thus spake Brian Gordon
>Okay question about this....

>Any problems running load balancing and hiper arc redundancy?

Set them both up with the chassis awareness and dsa and dsa idle
rebalancing.

Then you can either define twice the number of IPs needed on each one
(so each has enough IP addresses in the pool to handle all the modems,
or "disable ip address_pool_round_robin" and set up the first arc with
pool 1 first, pool 2 second, and the second arc with pool 2 first and
pool 1 second.

Keep in mind that the dsa idle rebalancing isn't particularly
quick...like...it'll take a half hour or so to fail-over.

There may be other issues involved, but nothing comes to mind off the
top of my head.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Aaron Nabil <[e-mail]>
Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 23 Aug 1999 06:35:39 -0700 (PDT)

Paul Farber writes...
>Ok... so what are the proper configuration for CT-1's and PRI's?  These
>misterious "miconfigured lines" statement comes up all the time.  But
>other than B8ZS/ESF... what other items can be misconfigured?

The "misconfigured lines" are between the ILEC and CLEC, not between
the xLEC and you.

>Anybody *really* know?

Yes, but this is the wrong list to be discussing interoffice trunking.

>On Sat, 21 Aug 1999, Charles Sprickman wrote:
>
>> On Sat, 21 Aug 1999, Ed wrote:
>>
>> > So what do you say now Mr. Sprickman?
>>
>> The same thing, I guess.  Our CLEC has ISP customers using 3Com, Ascend,
>> Cisco, Livingston, and Bay gear.  They all have problems because large
>> numbers of trunks out to the ILEC are misconfigured.  It's a fairly common
>> problem in fast growing areas.
>>
>> Charles
>>


--
Aaron Nabil

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Tatai SV Krishnan <[e-mail]>
Subject: (usr-tc) Radius Attributes
Date: 22 Aug 1999 21:03:28 -0500 (CDT)


Authentication:
     0x9889    (39049) - SUPPORTS_TAGS - This is sent in the radius
authentication packet to inform the radius server that HiPerARC supports TAG
based tunnelling attributes.

Accounting:
     0x9856    (38998) - VTS_SESSION_KEY - This is implemented for
sessions VTS
     0x9858    (39000) - CALL_ARRIVED_TIME - call arrived time
     0x9859    (39001) - CALL_LOST_TIME - call lost time.
     0x986c    (39020) _ ACCT_REASON - accounting reason.





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


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Tatai SV Krishnan <[e-mail]>
Subject: (usr-tc) Radius Attributes
Date: 22 Aug 1999 21:03:28 -0500 (CDT)


Authentication:
     0x9889    (39049) - SUPPORTS_TAGS - This is sent in the radius
authentication packet to inform the radius server that HiPerARC supports TAG
based tunnelling attributes.

Accounting:
     0x9856    (38998) - VTS_SESSION_KEY - This is implemented for
sessions VTS
     0x9858    (39000) - CALL_ARRIVED_TIME - call arrived time
     0x9859    (39001) - CALL_LOST_TIME - call lost time.
     0x986c    (39020) _ ACCT_REASON - accounting reason.





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


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Steve Valiunas" <[e-mail]>
Subject: Re: (usr-tc) simple question
Date: 23 Aug 1999 09:27:20 -0500



Save UI to EEPROM instead of Save to NVRAM.




"Stainforth, Matthew" <[e-mail]> on 08/16/99 02:31:34 PM

Please respond to [e-mail]

Sent by:  "Stainforth, Matthew" <[e-mail]>


cc:    (Steve Valiunas/MW/US/3Com)





Ok, at the risk of sounding stupid, how do I change the NMC community names
from TCM and make them stick?  I have tried changing them in the Security,
Community Names box and telling the NMC to Save Chassis to NVRAM but they
always go back to the previous values for some reason.  I have always done
this with the CLI before installing the chassis but, in this case, I want to
avoid the 3 hour drive if possible.  I had a quick look on 3KB and the TCM
guide and nothing jumped out at me...

Thanks,

Matthew...

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 "[e-mail]"
 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 <[e-mail]>
Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 23 Aug 1999 10:26:49 -0400 (EDT)

My CLEC is just a reseller.. so it IS a ILEC issue.  Again, what does it
mean by misconfigured?  WHat are the "corrrect" settings?  If I call Bell,
and say "Hey, what are the line parameters for circuit ID's blal blah
blah" what should I expect?

Does anybody know?

Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax [phone]
[e-mail]

On Mon, 23 Aug 1999, Aaron Nabil wrote:

> Paul Farber writes...
> >Ok... so what are the proper configuration for CT-1's and PRI's?  These
> >misterious "miconfigured lines" statement comes up all the time.  But
> >other than B8ZS/ESF... what other items can be misconfigured?
>
> The "misconfigured lines" are between the ILEC and CLEC, not between
> the xLEC and you.
>
> >Anybody *really* know?
>
> Yes, but this is the wrong list to be discussing interoffice trunking.
>
> >On Sat, 21 Aug 1999, Charles Sprickman wrote:
> >
> >> On Sat, 21 Aug 1999, Ed wrote:
> >>
> >> > So what do you say now Mr. Sprickman?
> >>
> >> The same thing, I guess.  Our CLEC has ISP customers using 3Com, Ascend,
> >> Cisco, Livingston, and Bay gear.  They all have problems because large
> >> numbers of trunks out to the ILEC are misconfigured.  It's a fairly common
> >> problem in fast growing areas.
> >>
> >> Charles
> >>
>
>
> --
> Aaron Nabil
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: "Jim Curran" <[e-mail]>
Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 23 Aug 1999 09:49:57 -0500




Paul,

Even though Aaron pointed out that the "misconfigured lines" are not a user
issue, this is still a task that causes lots of people problems. In creating the
Chassis Starter application, we really tried to get to the heart of which
settings were absolutely required to get a line to work. We designed what we
determined to be the bare minimum (for U.S./Canada) into the app.

PRI
---
Switch type: variable (5E, DMS-100, NI-2)
Framing type: fixed at ESF
Line coding: fixed at B8ZS
Signaling type: fixed at message-oriented

Ch T1
-----
Signaling type: fixed at robbed-bit
Framing type: variable (ESF, SF [D4])
Line coding: variable (B8ZS, AMI)
Trunk type: variable (E&M II, loop-start, ground-start)*
Start signal: variable (wink, immediate, dial tone)
Acknowledgement wink: variable (enabled, disabled)
Addressing: variable (DNIS, ANI, DNIS-ANI, none)

*For trunk type E&M II, Start signal is never dial tone.
 For trunk type loop-start, Start signal is always dial tone.
 For trunk type ground-start, Start signal is always dial tone.
 For trunk type loop- or ground-start, Addressing is always none.

A demo is here:
http://totalservice.usr.com/cgi-bin/w3com/pws/totalservice/m6RIC2rPlIn8LQRn2zOMZwNVemtp6HgoMJwpvsXZ8JwoRWyy6WryFm9Kqy3QAxDJl8HYRY49GkxQU7-nrFiylqPLzsobCnd2sKct5jWEqhB26aqa6LWH

Jim Curran
3Com




Please respond to [e-mail]

Sent by:  Paul Farber <[e-mail]>


cc:    (Jim Curran/MW/US/3Com)




Ok... so what are the proper configuration for CT-1's and PRI's?  These
misterious "miconfigured lines" statement comes up all the time.  But
other than B8ZS/ESF... what other items can be misconfigured?

Anybody *really* know?

Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax [phone]
[e-mail]







-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Aaron Nabil <[e-mail]>
Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 23 Aug 1999 08:42:13 -0700 (PDT)

Paul Farber writes...
>My CLEC is just a reseller.. so it IS a ILEC issue.  Again, what does it
>mean by misconfigured?

Please try and pay attention to what is being said.

Nobody is talking about misconfigured line parameters you have
anything to do with.  It doesn't matter what your CLEC is.  The
problem being discussed is about interoffice trunks between two phone
companies, _not_ between you, and end user, and your phone company
(ILEC or CLEC or reseller or whatever).

>WHat are the "corrrect" settings?  If I call Bell,
>and say "Hey, what are the line parameters for circuit ID's blal blah
>blah" what should I expect?

You should expect them to answer with whatever is on the design (what
you ordered it as).  There are no more "correct" settings, other than
how you ordered it.  If you are ordering a new circuit, the "best if
available" would be ESF framing and B8ZS coding.

>On Mon, 23 Aug 1999, Aaron Nabil wrote:
>
>> Paul Farber writes...
>> >Ok... so what are the proper configuration for CT-1's and PRI's?  These
>> >misterious "miconfigured lines" statement comes up all the time.  But
>> >other than B8ZS/ESF... what other items can be misconfigured?
>>
>> The "misconfigured lines" are between the ILEC and CLEC, not between
>> the xLEC and you.
>>
>> >Anybody *really* know?
>>
>> Yes, but this is the wrong list to be discussing interoffice trunking.
>>
>> >On Sat, 21 Aug 1999, Charles Sprickman wrote:
>> >
>> >> On Sat, 21 Aug 1999, Ed wrote:
>> >>
>> >> > So what do you say now Mr. Sprickman?
>> >>
>> >> The same thing, I guess.  Our CLEC has ISP customers using 3Com, Ascend,
>> >> Cisco, Livingston, and Bay gear.  They all have problems because large
>> >> numbers of trunks out to the ILEC are misconfigured.  It's a fairly common
>> >> problem in fast growing areas.
>> >>
>> >> Charles
>> >>
>>
>>
>> --
>> Aaron Nabil
>>


--
Aaron Nabil

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Aaron Nabil <[e-mail]>
Subject: Re: (usr-tc) Radius Attributes
Date: 23 Aug 1999 08:44:47 -0700 (PDT)

Tatai SV Krishnan writes...
>Authentication:
>     0x9889    (39049) - SUPPORTS_TAGS - This is sent in the radius
>authentication packet to inform the radius server that HiPerARC supports TAG
>based tunnelling attributes.
>
>Accounting:
>     0x9856    (38998) - VTS_SESSION_KEY - This is implemented for
>sessions VTS
>     0x9858    (39000) - CALL_ARRIVED_TIME - call arrived time
>     0x9859    (39001) - CALL_LOST_TIME - call lost time.
>     0x986c    (39020) _ ACCT_REASON - accounting reason.

Thanks!

Where can I get a current dictionary that has all of these so I have
the enumerations as well?

--
Aaron Nabil

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: (usr-tc) 1.2.43 -> 1.2.37
Date: 23 Aug 1999 13:47:18 -0400 (EDT)

OK...upgraded a few DSP's to 1.2.37 from 1.2.43.  One of them didn't
bring the PRI back up after it booted on the new code.  :/  Futzed with
it for a while, on the phone with CLEC switch tech (pretty sharp guy),
but neither of us could find a problem with the line.  Downgraded back
to 1.2.43 and the line came back up.  :/

So...anyone know what changes were made in the transition from 1.2.43 to
1.2.37 that would affect this?  I looked in the release notes for 1.2.37
and didn't see anything relevant.

Symptoms...unavailable seconds steadily increasing, no errored second
increasing at all (errored seconds, severely errored seconds, etc.),
line status (dsx1LineStatus) was 2, which indicates yellow alarm, or far
end loss of frame.

Anyone have an idea what would be causing this?  Dealing with pretty
basic PRI here, ESF, B8ZS, custom5ESS.

Thanks
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Aaron Nabil <[e-mail]>
Subject: Re: (usr-tc) 1.2.43 -> 1.2.37
Date: 23 Aug 1999 11:36:10 -0700 (PDT)

Jeff Mcadams writes...
>OK...upgraded a few DSP's to 1.2.37 from 1.2.43.  One of them didn't
>bring the PRI back up after it booted on the new code.  :/  Futzed with
>it for a while, on the phone with CLEC switch tech (pretty sharp guy),
>but neither of us could find a problem with the line.  Downgraded back
>to 1.2.43 and the line came back up.  :/

Did you reload the NVRAM from default, or just upgrade the code and
hope all the data structures in the nvram were in the same place?  The
"works again after downgrade" would be consistent with not defaulting
the nvram.


--
Aaron Nabil

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) 1.2.43 -> 1.2.37
Date: 23 Aug 1999 14:41:36 -0400 (EDT)

Thus spake Aaron Nabil
>Jeff Mcadams writes...
>>OK...upgraded a few DSP's to 1.2.37 from 1.2.43.  One of them didn't
>>bring the PRI back up after it booted on the new code.  :/  Futzed with
>>it for a while, on the phone with CLEC switch tech (pretty sharp guy),
>>but neither of us could find a problem with the line.  Downgraded back
>>to 1.2.43 and the line came back up.  :/

>Did you reload the NVRAM from default, or just upgrade the code and
>hope all the data structures in the nvram were in the same place?  The
>"works again after downgrade" would be consistent with not defaulting
>the nvram.

I did go through my config routine for dsp's, which includes restoring
from defaults, yes.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Jamie Orzechowski" <[e-mail]>
Subject: Re: (usr-tc) 1.2.43 -> 1.2.37
Date: 23 Aug 1999 14:48:08 -0400

I had kind of the same problem ... I upgraded and did a restore to defaults
then brought the cards back up and they were in an endless reboot ... I took
them out and pur them into another chassis and they came up fine ...
reflashed them with the same new code ... put them back in the original
chassis and they were fine ...

----- Original Message -----
Sent: Monday, August 23, 1999 2:41 PM


> Thus spake Aaron Nabil
> >Jeff Mcadams writes...
> >>OK...upgraded a few DSP's to 1.2.37 from 1.2.43.  One of them didn't
> >>bring the PRI back up after it booted on the new code.  :/  Futzed with
> >>it for a while, on the phone with CLEC switch tech (pretty sharp guy),
> >>but neither of us could find a problem with the line.  Downgraded back
> >>to 1.2.43 and the line came back up.  :/
>
> >Did you reload the NVRAM from default, or just upgrade the code and
> >hope all the data structures in the nvram were in the same place?  The
> >"works again after downgrade" would be consistent with not defaulting
> >the nvram.
>
> I did go through my config routine for dsp's, which includes restoring
> from defaults, yes.
> --
> Jeff McAdams                            Email: [e-mail]
> Head Network Administrator              Voice: [phone]
> IgLou Internet Services                        [phone]
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: Blake Fithen <[e-mail]>
Subject: RE: (usr-tc) Since HiperArc "upgrade" Couriers can't connect
Date: 23 Aug 1999 14:24:51 -0500

PROBLEM SOLVED!!!!!

After 6 months of hearing Southwestern Bell say "It's on your end,
It's on your end, [ad infinitum]", and incessant nagging on my end
they FINALLY found trunking problems on THEIR END!!!

details? - let me know

blake

> -----Original Message-----
> From: Blake Fithen
> Sent: Wednesday, March 24, 1999 6:46 PM
> To: '[e-mail]'
> Subject: RE: (usr-tc) Since HiperArc "upgrade" Couriers can't connect
>
>
> P.S.  everything else seems to be going pretty good with this
> specific
> firmware revision. (ARC 4.1.59-6, DSP 1.2.43)
>
> blake
>
> > -----Original Message-----
> > From: Blake Fithen [mailto:[e-mail]]
> > Sent: Wednesday, March 24, 1999 6:40 PM
> > To: '[e-mail]'
> > Subject: RE: (usr-tc) Since HiperArc "upgrade" Couriers
> can't connect
> >
> >
> > We (me/TELCO) isolated and verified the problem down to
> > not enough TELCO infrastructure trunks between there and
> > here.  TELCO problem.
> >
> > blake
> >
> > > -----Original Message-----
> > > From: Mike Hamrich [mailto:[e-mail]]
> > > Sent: Sunday, March 21, 1999 10:13 PM
> > > To: [e-mail]
> > > Subject: Re: (usr-tc) Since HiperArc "upgrade" Couriers
> > can't connect
> > >
> > >
> > > Blake, before you did the upgrade how did you have the NMC
> > > set to answer
> > > ISDN calls, on the Quads or the Netserver?
> > > -----Original Message-----
> > > From: Blake Fithen <[e-mail]>
> > > To: '[e-mail]' <[e-mail]>
> > > Date: Thursday, March 18, 1999 9:11 PM
> > > Subject: RE: (usr-tc) Since HiperArc "upgrade" Couriers
> > can't connect
> > >
> > >
> > > >ARC 4.1.59-6
> > > >DSP 1.2.43
> > > >
> > > >The only thing we having problems with are ISDN calls.  Analog
> > > >current link transmit rates are anywhere from 14,400 to 53,300.
> > > >But i haven't seen a single ISDN call get established and pass
> > > >data. mon ppp, and mon radius show nothing - "li co"  will show
> > > >the modem being tied up but after about 10 seconds it drops.  I
> > > >had a few ISDN customers connected with 4.1.59 and 1.2.59 but
> > > >as soon as I upgraded the DSP to 1.2.43 things went downhill.
> > > >
> > > >[1 hour goes by]
> > > >
> > > >and at 7:30 my pager goes nuts saying that all our dedicated
> > > >ISDN customers are back up.  during this time i have been
> > > >gathering statistics from the incomplete ISDN calls and then
> > > >many dedicated customers with ISDN devices from many different
> > > >vendors begin working again without any intervention from me.
> > > >Ah! and everything came back up about the same time last night!
> > > >
> > > >WHAT THE HELL??!?!?!
> > > >
> > > >any similar experiences? TELCO sabotage?
> > > >
> > > >blake
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: Mike Hamrich [mailto:[e-mail]]
> > > >> Sent: Thursday, March 18, 1999 7:21 PM
> > > >> To: [e-mail]
> > > >> Subject: (usr-tc) Since HiperArc "upgrade" Couriers
> can't connect
> > > >>
> > > >>
> > > >> OK HiperArc with latest code 3/4/99
> > > >>
> > > >> Since the "upgrade" we are having tons of connection issues.
> > > >> Couriers can't connect
> > > >> Owners of Sporsters flashed with Feb '99 v.90 code
> connect slower
> > > >> OEM/Brown box Sportsters can't stay connected
> > > >>
> > > >> We also told owner of non X2 modem to go elsewere.
> > > >>
> > > >> We surveyed our users, 248 replied so far:
> > > >> 67% say slower speed, 22% are having problems saying
> > > >> connected, 4% can't
> > > >> connect at all, and ONLY 7%  report better connection.
> > > >>
> > > >> We have PRI lines, Set PPP offloading to no, Authenticate ANY
> > > >> Preferrd PAP
> > > >>
> > > >> Any other ideas to make this stuff work as well as the old
> > > stuff did?
> > > >>
> > > >> Thanks in advance for you help
> > > >>
> > > >> Mike Hamrich
> > > >> CIO, DrFast.Net, Inc.
> > > >> [phone]
> > > >>
> > > >>
> > > >> -
> > > >>  To unsubscribe to usr-tc, send an email to
> > > "[e-mail]"
> > > >>  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
> > "[e-mail]"
> > > > 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
> "[e-mail]"
> > >  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 "[e-mail]"
> >  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 "[e-mail]"
 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: <[e-mail]>
Subject: (usr-tc) VPNs and Total Control HUBS
Date: 23 Aug 1999 15:41:11 -0400 (EDT)


    I would like to hear from anyone doing VPNs with Total Control
hubs... We have 3 all running the latest codes and HiperArc

  Would like to know what steps we need (configuration) to get VPNs up and
what software/hardware a client might need to tie in.

  Any and all comments/suggestions welcome!

==============================================================================
Phillip Ferraro                WorldNet Access, Inc
[e-mail]    Onslow County's PREMIER InterNet Service
Voice [phone]            824 Gumbranch Square, Suite R3
FAX   [phone]             Jacksonville, Nc  28540-6269
==============================================================================



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: K Mitchell <[e-mail]>
Subject: (usr-tc) New DSPs
Date: 23 Aug 1999 16:11:45 -0400

Ok, finally my new DSP cards should be here by the end of the week, which
leads to a couple of questions;
1. What code do they ship with?
2. Is there a way to migrate over the trap settings, etc from the cards I
already have in the chassis?

Thanks,
Kirk


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


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Todd Keister" <[e-mail]>
Subject: Re: (usr-tc) New DSPs
Date: 23 Aug 1999 15:57:01 -0500



     Kirk:

     I am not sure exactly which code your DSPs will arrive with, but it will
probably not be current (they cards could have been in your resellers wharehouse
for several months).  In any event, when you get a new card it is always a good
idea to default the card  - "Restore both T1/E1 and Modems from Factory
Defaults" - then "Save both... to NVRAM" and then reboot.
     After you flash the card with the newest code (or current with the rest of
the chassis) you can load the SNMP traps from a template on an existing card,
save to NVRAM, reboot (or refresh from Template),  Save once more to NVRAM for
(and Save Chassis for good measure) and you should be good to go...

     Hope this helps.


               Todd ;-}






K Mitchell <[e-mail]> on 08/23/99 03:11:45 PM

Please respond to [e-mail]

Sent by:  K Mitchell <[e-mail]>


cc:    (Todd Keister/MW/US/3Com)




Ok, finally my new DSP cards should be here by the end of the week, which
leads to a couple of questions;
1. What code do they ship with?
2. Is there a way to migrate over the trap settings, etc from the cards I
already have in the chassis?

Thanks,
Kirk


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


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 "[e-mail]"
 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: Brian <[e-mail]>
Subject: (usr-tc) Telepath Modem Woes
Date: 23 Aug 1999 16:19:10 -0500 (CDT)


I have been getting reports from techs saying that Telepath modems (model
6000905) are having problems connecting to our USR TC chassis.  I believe
Gateway packages this modem with their pc's.

Has anyone else seen problems with this modem? fix?


Brian Feeny (BF304)     [e-mail]
318-222-2638 x 109    http://www.shreve.net/~signal
Network Administrator   ShreveNet Inc. (ASN 11881)



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Brian <[e-mail]>
Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 23 Aug 1999 16:24:26 -0500 (CDT)

>
> AOL, Earthlink and Mindspring ALL use Ascend in our area. Ascend has a
> distinct pre-tone... I know they are Ascends. These guys don't run their own
> POPs in most cases and whore out the business through third party POP
> vendors... that could be using anything.

I can't comment on most of this discussion, but I can say that 1 - 1.5
years ago AOL/Mindspring were mostly USR NASen........i don't know if that
has changed.

>
> So what do you say now Mr. Sprickman?
>
> Ed
>
> ----- Original Message -----
> From: Charles Sprickman <[e-mail]>
> To: <[e-mail]>
> Sent: Saturday, August 21, 1999 2:22 PM
> Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
>
>
> On Sat, 21 Aug 1999, Ed wrote:
>
> > People have
> > been telling us for months that they dialup AOsmell, Earthstink, or
> > Mindsling and connect at 53,333 and can't understand why they have such
> > problems with our system... well now we know... those guys use Ascend!
>
> As for AOL, I understood they were USR, but they actually just signed a
> big deal with Cisco.  The last article I saw about Mindspring in one of
> those trade rags showed their CTO standing in front of huge banks of USR
> stuff...  The only one I know is mostly Ascend is Earthlink.  RCN is an
> Ascend shop as well...
>
> Keep in mind most of those problems can also be attributed to your lines.
> Our CLEC is currently in the process of retesting all of their trunks out
> to the tandems and end-offices as they've found the ILEC is misconfiguring
> lots of them.  Symptoms are very similar, but the standout is if you see
> more errors in one direction; there's a 80-some percent chance there's a
> line coding mismatche somewhere.
>
> Charles
>
> > For now we will stick with 3com... however everyday that goes by it
> becomes
> > more difficult to justify...
> >
> >
> > Ed
> >
> > ----- Original Message -----
> > From: Jeff Lynch <[e-mail]>
> > To: <[e-mail]>
> > Sent: Saturday, August 21, 1999 10:26 AM
> > Subject: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
> >
> >
> > On Tue, 10 Aug 1999, Allen Marsalis wrote:
> >
> > > At 01:24 AM 8/10/99 -0400, Ed wrote:
> > > >3com not doing V.90 as well as Ascend's.....
> > > >
> > > >We have tested and found it to be true that Ascend's authenticate and
> > work
> > > >at V.90 speeds much more often than 3com. It even happens when using a
> > > >3com/USR modem. It takes certain a certain situation for this to happen
> > but
> > > >it does happen...
> > > >
> > > >Just wondered if others out there have noticed it or had their
> > competitors
> > > >using Ascend's have customers that say "Well I get 56K speeds on so and
> > so
> > > >Internet Service, why not yours?"
> > >
> > > We have been 100% USR/3COM for 3 years and we recently received a Max
> > > TNT for eval to address the above problem..  Both chassis will be
> > > at the same NOC.  2 new PRI's for the TNT should be up this week..
> > > I'll keep you posted as to the results and try to provide some
> statistical
> > > data..
> >
> > Sorry for the length here, but I think it's a good read, eventhough I did
> > write it myself :)
> >
> > We did some churn analysis for customers that are no longer active or no
> > longer customers.  We looked at at customers lost since March 1999 because
> > of:
> >
> > a) reported problems connecting, staying connected, or poor  performance
> > b) unexplained non-payers/dead-beats
> > c) customers cancelled but did not give a reason (and did not
> >    return our calls when we tried to followed up).
> >
> > We had 103 total cancellations for these reasons since March 1999.
> >
> > We had enough data to determine that 57% of these 103 had problems were
> > directly attributable to connection quality. Of these 59 (103*0.57)
> > customers lost:
> >
> >   50% of them had not established a connection in 1999 (many of
> >      them reported this trouble)
> >
> >   40% had a large number of <1 minute connections, and showed a pattern
> >      of having to redial when they did stay on longer than a few minutes
> >
> >   10% had connect speeds that varied more than a few "rungs" between
> >      2400-52000
> >
> >
> > Let's see...If we had an alternate modem pool with a different NAS type,
> > we might have saved these 59 customers. That's about $1000/month at an
> > average revenue of $17/customer/month. We are still likely to continue
> > loosing more if we don't take action.
> >
> > Alternatively Scot Desort <[e-mail]>, wrote:
> >
> >  "When all else
> >   fails, pull $35 out of petty cash and send the customer a Paradise
> >   Winmodem (LT chipset, PCI), for free. These things are GREAT, will save
> >   you hours of tech support headaches, and inevitably win you over a
> >   customer that, in the long run, is worth a lot more than the $35 you
> >   spent  on the modem. We even offer to install it for free if they bring
> >   the box in.  Let's remember that the goal is to KEEP the customer a
> >   PAYING customer.  And nothing makes them more warm and fuzzy then
> getting
> >   something for free."
> >
> > This is interesting. Upgrading these customer's modems would have cost us
> > $2065 in hardware and perhaps $400-500 in labor estimated to retain the
> > $1000/month in revenue if this actually fixed the problem. I can see
> > several problems though. You could get a considerable number of calls from
> > unhappy customers like "my friend got a free modem now he gets 52K but I
> > only get 42K or 28.8K. I want one too." The customer's computer needs to
> > be sufficiently powered to run with a winmodem. How much time is spent
> > explaining that only certain customers qualify and how exactly are those
> > qualifications set? This also doesn't account for telco line issues. Many
> > customers now can't even tell you what kind of modem they have or what
> > processor they have, others may guess or argue that their's _should_
> > qualify for the free upgrade. For the program to not piss off any other
> > customers, it needs to be made available to everyone. Otherwise trouble
> > seems inevitable.
> >
> > On the other hand, although it takes some capital (not much with eq
> > leasing and zero install PRIs) and increases network complexity a little,
> > it's not that big of a deal for a reasonably clued provider to add another
> > NAS and move PRIs over to them in a separate hunt or just install a couple
> > new PRIs and gradually grow the alternate modem pool. But really doesn't
> > add much cost to the operation in the long run and the customers are
> > retained as well. Also:
> >
> > 1) it's available to everyone,
> > 2) it only takes a minute to help them change phone numbers
> > 3) and in most cases, if this doesn't solve the problem, they're not
> >    likely to be satisfied with anyone else and helps prove the problem
> >    is theirs, motivating them to follow your recommedations.
> >
> > The main thing that tweaks me is having to take this action in the first
> > place. Not to mention that we've got 7 or 8 hdsps from quad trades and arc
> > upgrades and such that we are paying for but won't be using this year now,
> > depending on the demand for the alternate pool. Cost of doing business.
> >
> > Time to get a MAX on eval and give it a whirl.
> >
> >
> ============================================================================
> > Jeffrey A. Lynch | JORSM Internet, Regional Internet Services
> > email: [e-mail] | 7 Area Codes in Chicagoland and NW Indiana
> > Voice: [phone] | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN
> > Autoresponse: [e-mail] | Quality Service, Affordable Prices
> > http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995
> >
> >
> >
> >
> >
> >
> > -
> >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> >  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 "[e-mail]"
> >  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 "[e-mail]"
>  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 "[e-mail]"
>  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.
>

Brian Feeny (BF304)     [e-mail]
318-222-2638 x 109    http://www.shreve.net/~signal
Network Administrator   ShreveNet Inc. (ASN 11881)


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Brian <[e-mail]>
Subject: (usr-tc) Setting the Long Haul buildout
Date: 23 Aug 1999 16:28:31 -0500 (CDT)


What do you all use to determine what to set the Long Haul NIC buildout to
on your HDM's?  What would be the consequences for running an HDM in
"short haul" when it should be in long haul? (bad connections? missed
connections? etc).

Brian


Brian Feeny (BF304)     [e-mail]
318-222-2638 x 109    http://www.shreve.net/~signal
Network Administrator   ShreveNet Inc. (ASN 11881)


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Aaron Nabil <[e-mail]>
Subject: Re: (usr-tc) Setting the Long Haul buildout
Date: 23 Aug 1999 14:48:47 -0700 (PDT)

Brian writes...
>What do you all use to determine what to set the Long Haul NIC buildout to
>on your HDM's?

A T1 test set.

>What would be the consequences for running an HDM in "short haul" when
>it should be in long haul?

The power level the HDM sees will be lower than expected, and the
power level the T1 line sees will be higher than expected, unless it's
very, very far away.

>(bad connections? missed connections? etc).

T1 level does not relate to modem power level.   If the T1 levels are
so far out of range that you are getting errors, then all or any of the
above.  If you aren't getting errors, then it won't have any effect.


What determines if you select short haul or long haul is if you
are hooking up to a DSX-1 or T1 interface.  Almost any metallic
interface from a telco is going to be T1, anything from a M31 (or
sonet) mux (or directly from a switch) is going to be DSX-1.

For DSX-1 use short haul.
For T1 use long haul.


--
Aaron Nabil

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Scot Desort" <[e-mail]>
Subject: RE: (usr-tc) Setting the Long Haul buildout
Date: 23 Aug 1999 18:18:10 -0400

Aaron-

On that note, I have a question for you.

We currently have our TC's in a CLEC's central office, which is a remote
central office about 35 miles from the physical Lucent 5ESS.

Tomorrow we are moving our TC's to our operations center. Bell dropped us a
DDM2000 OC3, and we have clean 1.5 T-1's running between us the the _CLEC
central office_. From there, we're routed down to the switch into our PRI's.

CLEC has patched a test PRI through to our T-1's here, and I plugged in my
old Compaq equipment. Everything comes up fine, and the modems answer. So
far, so good. But, once I get everything moved here, should I be changing
the haul settings? The TC's have everything set to 'default' currently in
the co-lo. Would you suspect that I might need to change something once they
get here? I didn't have to do anything to the old Compaq clunker.

Thanks,

Scot
NJ Internet Access


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Aaron Nabil
> Sent: Monday, August 23, 1999 5:49 PM
> To: [e-mail]
> Subject: Re: (usr-tc) Setting the Long Haul buildout
>
>
> Brian writes...
> >What do you all use to determine what to set the Long Haul NIC
> buildout to
> >on your HDM's?
>
> A T1 test set.
>
> >What would be the consequences for running an HDM in "short haul" when
> >it should be in long haul?
>
> The power level the HDM sees will be lower than expected, and the
> power level the T1 line sees will be higher than expected, unless it's
> very, very far away.
>
> >(bad connections? missed connections? etc).
>
> T1 level does not relate to modem power level.   If the T1 levels are
> so far out of range that you are getting errors, then all or any of the
> above.  If you aren't getting errors, then it won't have any effect.
>
>
> What determines if you select short haul or long haul is if you
> are hooking up to a DSX-1 or T1 interface.  Almost any metallic
> interface from a telco is going to be T1, anything from a M31 (or
> sonet) mux (or directly from a switch) is going to be DSX-1.
>
> For DSX-1 use short haul.
> For T1 use long haul.
>
>
> --
> Aaron Nabil
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: Aaron Nabil <[e-mail]>
Subject: Re: (usr-tc) Setting the Long Haul buildout
Date: 23 Aug 1999 15:49:29 -0700 (PDT)

Scot Desort writes...
>Aaron-
>
>On that note, I have a question for you.
>
>We currently have our TC's in a CLEC's central office, which is a remote
>central office about 35 miles from the physical Lucent 5ESS.
>
>Tomorrow we are moving our TC's to our operations center. Bell dropped us a
>DDM2000 OC3, and we have clean 1.5 T-1's running between us the the _CLEC
>central office_. From there, we're routed down to the switch into our PRI's.

DS1/DS1PM packs on a DDM-2000 are DSX-1 only, therefore you use "short haul".


--
Aaron Nabil

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Blake Fithen <[e-mail]>
Subject: RE: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 23 Aug 1999 18:51:07 -0500

> -----Original Message-----
> From: Aaron Nabil [mailto:[e-mail]]
> Sent: Monday, August 23, 1999 8:36 AM
> To: [e-mail]
> Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well
> as Ascends
> Paul Farber writes...
> >Ok... so what are the proper configuration for CT-1's and
> PRI's?  These
> >misterious "miconfigured lines" statement comes up all the time.  But
> >other than B8ZS/ESF... what other items can be misconfigured?
>
> The "misconfigured lines" are between the ILEC and CLEC, not between
> the xLEC and you.
>
> >Anybody *really* know?
>
> Yes, but this is the wrong list to be discussing interoffice trunking.


Is there a right list?  Please let me know - I'd love to be on it!!!

thanks, blake

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: das <[e-mail]>
Subject: Re: (usr-tc) HiperARC redundancy
Date: 24 Aug 1999 09:29:18 +0900

Thanks again, Jeff.

das

Jeff Mcadams ([e-mail]) spake:

> Thus spake das
> >Thanks for the response, Jeff.
>
> >OK, considering this won't happen unless the first harc dies,
> >I assume it to be safe to use the same ip pools for both harcs.
> >Can you foresee any problems with that?
>
> Nope, as long as you're using it to provide redundancy, you should be
> fine with that.  If you were using it to do load balancing, things would
> get a bit tougher.  :)
> --
> Jeff McAdams                            Email: [e-mail]
> Head Network Administrator              Voice: [phone]
> IgLou Internet Services                        [phone]
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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.

--
____________________________________________
Alex Substanley       Global OnLine Japan
                Engineering Department
Das Man               TEL: [phone]
Systems Engineer      FAX: [phone]
  The Highest Quality Service, Bar None
____________________________________________

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Tavis Morse" <[e-mail]>
Subject: (usr-tc) v.90 and Other connection Problems
Date: 24 Aug 1999 02:45:17 +03d00

Hello!
This is my first post to the list after reading many of the recent comments in the archives about USR-TC vs. Ascend connect/throughput speed issues. We are a small ISP using two Hiper Chassis, each half populated with HiperDSP cards and all the latest code.
We have definately been dealing with the issue of customer's calling and complaining of slower-than-AOL connect speeds and v90 problems. While I feel validated in my belief that the DSP code is the issue, I need to know when and if this will be resolved by 3Com. Our president is very sensitive to customer's concerns and we are on the verge of ditching the TC's for MAX 6000's.
I dont want to have to do that - I really like this platform, but we have to make these people happy or our business goes bye-bye.
To be fair, at least 75% of our users are OK with their speed, but we know we are loosing business as people buy newer machines with cheap Rockwell/Lucent modems and suffer slower connections. This cannot continue.
Please respond if you have a timeframe for upgrades.


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: RE: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 24 Aug 1999 00:39:43 -0400 (EDT)

I got in a huge furball a while back on a list trying to pull this kind of
information out of "people who know".

Not wanting to start that again... but other than B8ZS/ESF.. what
parameters should be put on a CT/PRI?

Attentuation?
Gain?
Signal strength?
Number of purple monkeys in the NOC?
Acceptable SNR's?
Echo levels?


Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax [phone]
[e-mail]

On Mon, 23 Aug 1999, Blake Fithen wrote:

> > -----Original Message-----
> > From: Aaron Nabil [mailto:[e-mail]]
> > Sent: Monday, August 23, 1999 8:36 AM
> > To: [e-mail]
> > Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well
> > as Ascends
> > Paul Farber writes...
> > >Ok... so what are the proper configuration for CT-1's and
> > PRI's?  These
> > >misterious "miconfigured lines" statement comes up all the time.  But
> > >other than B8ZS/ESF... what other items can be misconfigured?
> >
> > The "misconfigured lines" are between the ILEC and CLEC, not between
> > the xLEC and you.
> >
> > >Anybody *really* know?
> >
> > Yes, but this is the wrong list to be discussing interoffice trunking.
>
>
> Is there a right list?  Please let me know - I'd love to be on it!!!
>
> thanks, blake
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) v.90 and Other connection Problems
Date: 24 Aug 1999 00:45:54 -0400 (EDT)

The *best* answer to date seems to be run two racks... and let the problem
customers move to the other rack as they are discovered.  I am not gonna
get any more DSP's... but will get an Ascend rack (48 ports) and see what
happens.... it can't hurt.

The 2.* DSP code did do a lot of new stuff.... but it seems that NFAS was
more important than connections and throughput.

FWIW.. I average a 10% call failure rate... probably higher because 3Com
equipment will not log an incoming call failure until it get so far into
the negotiation.... so there are probably a few more NOT getting recored
due to trap errors in the code and the way 3Com views what a failed
connection.

Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax [phone]
[e-mail]

On Tue, 24 Aug 1999, Tavis Morse wrote:

> Hello!
> This is my first post to the list after reading many of the recent comments in the archives about USR-TC vs. Ascend connect/throughput speed issues. We are a small ISP using two Hiper Chassis, each half populated with HiperDSP cards and all the latest code.
> We have definately been dealing with the issue of customer's calling and complaining of slower-than-AOL connect speeds and v90 problems. While I feel validated in my belief that the DSP code is the issue, I need to know when and if this will be resolved by 3Com. Our president is very sensitive to customer's concerns and we are on the verge of ditching the TC's for MAX 6000's.
> I dont want to have to do that - I really like this platform, but we have to make these people happy or our business goes bye-bye.
> To be fair, at least 75% of our users are OK with their speed, but we know we are loosing business as people buy newer machines with cheap Rockwell/Lucent modems and suffer slower connections. This cannot continue.
> Please respond if you have a timeframe for upgrades.
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) v.90 and Other connection Problems
Date: 24 Aug 1999 00:45:54 -0400 (EDT)

The *best* answer to date seems to be run two racks... and let the problem
customers move to the other rack as they are discovered.  I am not gonna
get any more DSP's... but will get an Ascend rack (48 ports) and see what
happens.... it can't hurt.

The 2.* DSP code did do a lot of new stuff.... but it seems that NFAS was
more important than connections and throughput.

FWIW.. I average a 10% call failure rate... probably higher because 3Com
equipment will not log an incoming call failure until it get so far into
the negotiation.... so there are probably a few more NOT getting recored
due to trap errors in the code and the way 3Com views what a failed
connection.

Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax [phone]
[e-mail]

On Tue, 24 Aug 1999, Tavis Morse wrote:

> Hello!
> This is my first post to the list after reading many of the recent comments in the archives about USR-TC vs. Ascend connect/throughput speed issues. We are a small ISP using two Hiper Chassis, each half populated with HiperDSP cards and all the latest code.
> We have definately been dealing with the issue of customer's calling and complaining of slower-than-AOL connect speeds and v90 problems. While I feel validated in my belief that the DSP code is the issue, I need to know when and if this will be resolved by 3Com. Our president is very sensitive to customer's concerns and we are on the verge of ditching the TC's for MAX 6000's.
> I dont want to have to do that - I really like this platform, but we have to make these people happy or our business goes bye-bye.
> To be fair, at least 75% of our users are OK with their speed, but we know we are loosing business as people buy newer machines with cheap Rockwell/Lucent modems and suffer slower connections. This cannot continue.
> Please respond if you have a timeframe for upgrades.
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: [e-mail] (Jeff Binkley)
Subject: (usr-tc) S/A Server
Date: 24 Aug 1999 07:49:00 -0500



We run 3Com's S/A server version 6.08 and have noticed an oddity which
was partially discussed here before.  We have some users who login with
[e-mail] instead of just userid.  S/A seems to accept this
just fine.  However, if you have login tracking enabled (MS Access
version of S/A), there is no entry in the database for
[e-mail], just userid.  Thus they get in but none of the
login tracking features will work since the accounting reacords can't
find a match in the database.  Is there a way to hack the script to
block the userid@mydomain logins ?  Or a way to strip the @mydomain.com
from the accounting records ?  What have others done ?


Jeff Binkley
ASA Network Computing

CMPQwk 1.42 9999

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Corneliu Rudeanu <[e-mail]>
Subject: Re: (usr-tc) S/A Server
Date: 24 Aug 1999 15:31:28 +0300 (EEST)

On Tue, 24 Aug 1999, Jeff Binkley wrote:

>
> We run 3Com's S/A server version 6.08 and have noticed an oddity which
> was partially discussed here before.  We have some users who login with
> [e-mail] instead of just userid.  S/A seems to accept this
> just fine.  However, if you have login tracking enabled (MS Access
> version of S/A), there is no entry in the database for
> [e-mail], just userid.  Thus they get in but none of the
> login tracking features will work since the accounting reacords can't
> find a match in the database.  Is there a way to hack the script to
> block the userid@mydomain logins ?  Or a way to strip the @mydomain.com
> from the accounting records ?  What have others done ?
>
>
> Jeff Binkley
> ASA Network Computing
>
> CMPQwk 1.42 9999
>

You could use a radius proxy which can strip the realm from the username.
Quite an easy task, isn't it?

There are many free Radius Proxy'es available and I guess they support
realm stripping. Yet, if you prefer a commercial one, I recommend
JamRadius (made by our company ;-). There are many other features and
realm striping is one of the basic ones...

Regards,
Corneliu Rudeanu

--
Corneliu Rudeanu
Head of Software Development Department
Dynamic Network Technologies Iasi, Romania
Phone: [phone]    FAX: [phone]
http://www.dntis.ro



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Mike Andrews <[e-mail]>
Subject: Re: (usr-tc) Telepath Modem Woes
Date: 24 Aug 1999 11:37:42 -0400 (EDT)

Telepaths used to be Sportsters in disguise, but now they're LT Winmodems
in disguise.  Hopefully Gateway hasn't downgraded all the way to Rockwell
HCF like Compaq and HP did...

See if it comes up as "Telepath LT" in the Modems control panel... if so,
the usual trick applies -- get them online at v.34 speeds and then send
them to http://808hi.com/56k/ltwin.htm for new drivers...


Mike Andrews (MA12) -=-=-  VP & Sysadmin, Digital Crescent, Frankfort KY
[e-mail]  -=--=-  [e-mail]  -=--=-  http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."

On Mon, 23 Aug 1999, Brian wrote:

> I have been getting reports from techs saying that Telepath modems (model
> 6000905) are having problems connecting to our USR TC chassis.  I believe
> Gateway packages this modem with their pc's.
>
> Has anyone else seen problems with this modem? fix?


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Tavis Morse <[e-mail]>
Subject: Re: (usr-tc) v.90 and Other connection Problems
Date: 24 Aug 1999 10:16:42 -0400

Thank you Mr. Farber for your advice, we will be trying to
set up another access platform for the users who have trouble with
the TC. Does 3Com's S/A support Ascend or vice-versa?
Here are some of the settings we use, if anyone sees a glaring mistake,
please let me know.
The HiPer DSP's are connected to PRI's coming from our own phone switch, a
DTI DXC 2k. They do not share B-channels. In the trunk configuration of the
TCM, we have 'message oriented' as the signal mode, dB0p0 as the transmit
line build out, and the primary switch type (what does this do?) as 5ESS.
The receiver gain is dB12, the cables from our switch to the DSP's are no
more than 15' long.
TIA,
Tavis




At 12:45 AM 8/24/99 -0400, you wrote:
>The *best* answer to date seems to be run two racks... and let the problem
>customers move to the other rack as they are discovered.  I am not gonna
>get any more DSP's... but will get an Ascend rack (48 ports) and see what
>happens.... it can't hurt.
>
>The 2.* DSP code did do a lot of new stuff.... but it seems that NFAS was
>more important than connections and throughput.
>
>FWIW.. I average a 10% call failure rate... probably higher because 3Com
>equipment will not log an incoming call failure until it get so far into
>the negotiation.... so there are probably a few more NOT getting recored
>due to trap errors in the code and the way 3Com views what a failed
>connection.
>
>Paul D. Farber II
>Farber Technology
>Ph. 570-628-5303
>Fax [phone]
>[e-mail]
>
>On Tue, 24 Aug 1999, Tavis Morse wrote:
>
>> Hello!
>> This is my first post to the list after reading many of the recent
comments in the archives about USR-TC vs. Ascend connect/throughput speed
issues. We are a small ISP using two Hiper Chassis, each half populated
with HiperDSP cards and all the latest code.
>> We have definately been dealing with the issue of customer's calling and
complaining of slower-than-AOL connect speeds and v90 problems. While I
feel validated in my belief that the DSP code is the issue, I need to know
when and if this will be resolved by 3Com. Our president is very sensitive
to customer's concerns and we are on the verge of ditching the TC's for MAX
6000's.
>> I dont want to have to do that - I really like this platform, but we
have to make these people happy or our business goes bye-bye.
>> To be fair, at least 75% of our users are OK with their speed, but we
know we are loosing business as people buy newer machines with cheap
Rockwell/Lucent modems and suffer slower connections. This cannot continue.
>> Please respond if you have a timeframe for upgrades.
>>
>>
>> -
>>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>>  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 "[e-mail]"
> 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 "[e-mail]"
 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: Pete Ashdown <[e-mail]>
Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 24 Aug 1999 11:45:33 -0600 (MDT)

Paul Farber said once upon a time:

>Not wanting to start that again... but other than B8ZS/ESF.. what
>parameters should be put on a CT/PRI?
>
>Attentuation?
>Gain?
>Signal strength?
>Number of purple monkeys in the NOC?
>Acceptable SNR's?
>Echo levels?

I use the defaults on all of these.  Of course, all of my PRIs are
delivered on fiber, so your mileage may vary.

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: David Ernst <[e-mail]>
Subject: (usr-tc) cistron radius rlogin "hint"
Date: 23 Aug 1999 08:22:04 -0500 (EST)

Hello.  I've got a slightly off-topic, "I-must-be-doing-something
stupid" type question.  We recently switched to cistron radius.  Our
previous radius (Merit) had a feature where it could automagically
determine whether someone was wanting a ppp session or a shell session
based on whether they actually logged in at the TC login prompt or not
(to get a PPP session you just started sending PAP stuff, otherwise
you got a shell on our default server).  This was very handy and a
surprisingly large number of our members used this feature.  We know
this because they now cannot get a shell account, and they're
complaining about it (rightfully so).

Reading the docs from cistron, it seems that the best way to do this
would be to have them log in as something like "username.shell" and
have the users/hints file set up to make that process a rlogin
account.  I tried this but to no avail, it still started a PPP
session.  Here was the "hint" I tried to use (don't laugh, ok?  We
never used hints with Merit and the cistron docs are not that
helpful).

DEFAULT    Suffix = ".shell", Strip-User-Name = Yes
    Hint = "Rlogin",
        Service-Type = Login-User,
        Login-Service = Rlogin,
        Login-IP-Host = thecorrect.host.net

I tried a variety of complementary stuff in the users file, but to no
avail.  Anyone know how to make this work?  Or have another proposed
way to let people dialin to a Unix shell?

Thanks in proverbial advance,
David

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Pete Ashdown <[e-mail]>
Subject: (usr-tc) List etiquette
Date: 24 Aug 1999 11:54:59 -0600 (MDT)

I'm seeing a lot of messages come in for approval that have one or two
paragraphs (or even less) of new content, then a ton of referred content.
The list management software will automatically bounce messages to me that
are over 10,000 lines.  If your reply consists of 20 lines, I will most
likely chuck the message rather than forward that mess on to everyone else.

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: David Ernst <[e-mail]>
Subject: (usr-tc) cistron radius rlogin "hint"
Date: 19 Aug 1999 15:29:03 -0500 (EST)

Hello.  I've got a slightly off-topic, "I-must-be-doing-something
stupid" type question.  We recently switched to cistron radius.  Our
previous radius (Merit) had a feature where it could automagically
determine whether someone was wanting a ppp session or a shell session
based on whether they actually logged in at the TC login prompt or not
(to get a PPP session you just started sending PAP stuff, otherwise
you got a shell on our default server).  This was very handy and a
surprisingly large number of our members used this feature.  We know
this because they now cannot get a shell account, and they're
complaining about it (rightfully so).

Reading the docs from cistron, it seems that the best way to do this
would be to have them log in as something like "username.shell" and
have the users/hints file set up to make that process a rlogin
account.  I tried this but to no avail, it still started a PPP
session.  Here was the "hint" I tried to use (don't laugh, ok?  We
never used hints with Merit and the cistron docs are not that
helpful).

DEFAULT    Suffix = ".shell", Strip-User-Name = Yes
    Hint = "Rlogin",
        Service-Type = Login-User,
        Login-Service = Rlogin,
        Login-IP-Host = thecorrect.host.net

I tried a variety of complementary stuff in the users file, but to no
avail.  Anyone know how to make this work?  Or have another proposed
way to let people dialin to a Unix shell?

Thanks in proverbial advance,
David

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Craig Thompson" <[e-mail]>
Subject: (usr-tc) HARC Chassis / DSPs for sale
Date: 18 Aug 1999 11:45:40 -0500

We are looking at selling the following piece of
equipment:

 1 Hiper ARC (128 meg) w/dual 10/100bt nic
 1 NMC Card with memory upgrade and ethernet nic
 2 Hiper DSP cards with nics
 1 70 amp power supply
 1 integrated fan tray

Price  $7000.00

Working fine.  Guaranteed against DOA.  Will allow
purchaser adequate time to test after arrival to
ensure equipment works.


Craig Thompson, Manager
WingNET Internet Services,
P.O. Box 3000 // Cleveland, TN 37320-3000
423-559-LINK (v)  423-559-5444 (f)
http://www.wingnet.net

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Kelly Peterson <[e-mail]>
Subject: (usr-tc) Help with assigning dedicated IP addresses across multiple
Date: 18 Aug 1999 08:45:16 -0600

<bigger>We want to be able to assign dedicated IP addresses to certain
clients.  We have a few HiperARCs running 4.1.59-6 firmware.  We have a
3Com CoreBuilder 3500 switch for out interior router.  We are using
RadiusNT version 2.5.124.  The problem is that our router does not seem
to be getting any RIPv2 updates from our HiperARCs when the client dials
in.  The client gets the dedicated IP address OK but cannot get past our
interior router.  An example client radius profile is shown below:


test    Password="test",

    User-Service-Type=Framed-User,

    Framed-Protocol=PPP,

    Framed-Address=206.75.84.2,

    Framed-Netmask=255.255.255.255,

    Framed-Routing=Broadcast,

    Idle-Timeout=3600,

    Framed-Compression=Van-Jacobsen-TCP-IP




The results of sh ip routing is shown below:


HiPer>> sh ip routing


IP ROUTER SETTINGS

IP Router Administrative Status:           ENABLED

IP Static Remote Routes:                   ENABLED

IP LAN Host Address:                       10.10.10.10

IP Autonomous System Number                1

IP Max Table Size:                         3880

IP Max Metric Entries:                     512

IP RIP                                     ENABLED

IP Number RIP Interfaces:                  1

IP Number RIP Neighbors:                   0

IP RIP Flags:                              METRICS

                                           SEND_REQUEST


Any help would be appreciated!


Thanks.


</bigger>

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: John Mies <[e-mail]>
Subject: (usr-tc) Rockwell / Conexant HCF Modem does not connect
Date: 16 Aug 1999 13:01:24 -0500

I have a client with a Compaq using a Rockwell / Conexant HCF PCI that
cannot connect. They have tried connecting to an Ascend, and it works. Is
this the flaky modem or is a 3Com issue?

John Mies

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Jamie Orzechowski" <[e-mail]>
Subject: (usr-tc) Radius Questions
Date: 24 Aug 1999 14:49:35 -0400

I am running ARC 4.1.59-6

I have a primary and secondary radius setup.

My Primary radisu server has never gone down yet I keep seeing people being
auenticated via my secondary server.

I have tried using the round_robin and the fall_through algorithms but both
give me the same problems ... Any ideas on why requests will still be sent
to my secondary even with the primary is online??



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Pete Ashdown <[e-mail]>
Subject: Re: (usr-tc) Rockwell / Conexant HCF Modem does not connect
Date: 24 Aug 1999 12:58:32 -0600 (MDT)

John Mies said once upon a time:
>
>I have a client with a Compaq using a Rockwell / Conexant HCF PCI that
>cannot connect. They have tried connecting to an Ascend, and it works. Is
>this the flaky modem or is a 3Com issue?

Big fat flakey modem.  I couldn't even get it to connect when I disasbled
the v.flex training.  I had to disable all 56K entirely to get it to work.
There is a good section on the HCF at http://808hi.com/56k.

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: [e-mail]
Subject: Re: (usr-tc) Radius Questions
Date: 24 Aug 1999 16:33:36 -0400



Try this setup:

Configure a primary accounting server & Secret
Configure a primary first backup (NOT SECONDARY) & secret.

"enable prioRITISE_FIRST_ACCOUNTING_SERVER_IN_A_GROUP"

With the above accepting will act like authentication with algorithm set to
"FALL-THROUGH".


Hope this helps,

F. N.



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Steve Coleman" <[e-mail]>
Subject: (usr-tc) OSPF?
Date: 24 Aug 1999 20:20:02 -0600

We just received our first TC chassis today.  It's my understanding that it
will support OSPF.  The unit shipped with HiperArc 4.1.11, which as far as I
can tell doesn't support OSPF.  The only upgrade available, 4.2.29, is
locked on USR's site with a message "this doesn't work".

This thing is useless to me without OSPF, we use OSPF for our Internal
routing protocol.  We have Livingston Portmasters, and Cisco's.

How do you get buy without OSPF?

Is there an interim release somewhere that will have OSPF support?

Another question:  Will these units automatically send the DNS servers to a
dialup PPP client, or does that need to be configured somewhere?

Thanks,

Steve Coleman
Computer Solutions


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) OSPF?
Date: 24 Aug 1999 22:22:33 -0400 (EDT)

Thus spake Steve Coleman
>We just received our first TC chassis today.  It's my understanding that it
>will support OSPF.  The unit shipped with HiperArc 4.1.11, which as far as I
>can tell doesn't support OSPF.  The only upgrade available, 4.2.29, is
>locked on USR's site with a message "this doesn't work".

4.2.29 is the first release that supports OSPF.

>This thing is useless to me without OSPF, we use OSPF for our Internal
>routing protocol.  We have Livingston Portmasters, and Cisco's.

>How do you get buy without OSPF?

RIPv2 and redistribute at the first hop into OSPF on a cisco.

>Another question:  Will these units automatically send the DNS servers to a
>dialup PPP client, or does that need to be configured somewhere?

Yes...they do that by default.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Steve Rivera <[e-mail]>
Subject: (usr-tc) WTB: USR 70A Power supplies
Date: 25 Aug 1999 12:48:06 -0400

Looking for 5- Power supplies.
USR 70A
Please forward available equipment to [e-mail]
....................................................
Steve Rivera - VP-WR Consultant Associates, Inc. (WRCA)
[e-mail]  v-732-833-2111 pgr-732-325-1092

WAN ACCESS SPECIALIST---http://www.wrca.net (CompleteLine Card)
Cisco, Ascend,USR,Adtran, Kentrox,Livingston, Microcom,Computone,Verilink
IBM,Motorola,UDS,Codex,ATT/Paradyne,Hayes,Racal Datacom,GDC,Telebit
MultiTech,Sync/Tylink,Wellfleet,BayNetworks(5399),Black Box,Micom & More










-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Steve Rivera <[e-mail]>
Subject: (usr-tc) WTB: MP16I
Date: 25 Aug 1999 13:37:43 -0400

Sorry for the double post...forgot this one.
I am looking to buy today.
I figure if anyone will have one it will be one of you guys or gals.

1- USR MP16I...buying today
....................................................
Steve Rivera - VP-WR Consultant Associates, Inc. (WRCA)
[e-mail]  v-732-833-2111 pgr-732-325-1092

WAN ACCESS SPECIALIST---http://www.wrca.net (CompleteLine Card)
Cisco, Ascend,USR,Adtran, Kentrox,Livingston, Microcom,Computone,Verilink
IBM,Motorola,UDS,Codex,ATT/Paradyne,Hayes,Racal Datacom,GDC,Telebit
MultiTech,Sync/Tylink,Wellfleet,BayNetworks(5399),Black Box,Micom & More










-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Matthew Opoka <[e-mail]>
Subject: (usr-tc) updated DSP from 1.2.37 to 2.0.81
Date: 25 Aug 1999 12:40:46 -0500 (CDT)

I flashed a dsp from 1.2.37 to 2.0.81 and now the damn thing doesn't work.
The LPBK/DALM stays green when a PRI is plugged in.
I flashed back to 1.2.37 and still the same thing.
Any ideas?



--
Matthew Opoka
Systems Admin
Mississippi Internet Services, Inc.
http://www.magnolia.net
Voice: 601.661.0081
Fax: [phone]


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Dave Martin <[e-mail]>
Subject: Re: (usr-tc) updated DSP from 1.2.37 to 2.0.81
Date: 25 Aug 1999 10:53:56 -0700

>I flashed a dsp from 1.2.37 to 2.0.81 and now the damn thing doesn't work.
>The LPBK/DALM stays green when a PRI is plugged in.
>I flashed back to 1.2.37 and still the same thing.
>Any ideas?
>
>--
>Matthew Opoka
>Systems Admin
>Mississippi Internet Services, Inc.
>http://www.magnolia.net
>Voice: 601.661.0081
>Fax: [phone]
>

I dunno why it didn't work when you flashed it back to 1.2.37, but the
green LPBK/D-ALM LED is your friend with 2.0.81.  It means you have a
working D channel on the span.  It's kinda nice with NFAS to get some
visible feedback of your D channel status...

Dave Martin                 Netcetera, Inc.            [e-mail]
               "Infinity Welcomes Careful Drivers"



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Tavis Morse <[e-mail]>
Subject: Re: (usr-tc) updated DSP from 1.2.37 to 2.0.81
Date: 25 Aug 1999 14:14:02 -0400

Mine did that too, but it still worked. I think
the green light is normal for the new code.
-Tavis Morse


At 12:40 PM 8/25/99 -0500, you wrote:
>I flashed a dsp from 1.2.37 to 2.0.81 and now the damn thing doesn't work.
>The LPBK/DALM stays green when a PRI is plugged in.
>I flashed back to 1.2.37 and still the same thing.
>Any ideas?
>
>
>
>--
>Matthew Opoka
>Systems Admin
>Mississippi Internet Services, Inc.
>http://www.magnolia.net
>Voice: 601.661.0081
>Fax: [phone]
>
>
>-
> To unsubscribe to usr-tc, send an email to "[e-mail]"
> 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 "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) updated DSP from 1.2.37 to 2.0.81
Date: 25 Aug 1999 14:34:06 -0400 (EDT)

Thus spake Tavis Morse
>Mine did that too, but it still worked. I think
>the green light is normal for the new code.

On the 2.0.x code, the lpbk led is also a d channel led...the green
light indicates that the d channel is up on that span.  (This is
significant since the 2.0.x code supports NFAS, so not all spans will
have d channels...this gives you a quick indication of which spans do
have d channels on them and whether they are primary or backup....backup
d channels will blink this light)

>At 12:40 PM 8/25/99 -0500, you wrote:
>>I flashed a dsp from 1.2.37 to 2.0.81 and now the damn thing doesn't work.
>>The LPBK/DALM stays green when a PRI is plugged in.
>>I flashed back to 1.2.37 and still the same thing.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Matthew Opoka <[e-mail]>
Subject: Re: (usr-tc) updated DSP from 1.2.37 to 2.0.81
Date: 25 Aug 1999 13:41:15 -0500 (CDT)

I'm going to watch it but the card wasn't answering. Got dead air.

--
Matthew Opoka
Systems Admin
Mississippi Internet Services, Inc.
http://www.magnolia.net
Voice: 601.661.0081
Fax: [phone]

On Wed, 25 Aug 1999, Jeff Mcadams wrote:

> Thus spake Tavis Morse
> >Mine did that too, but it still worked. I think
> >the green light is normal for the new code.
>
> On the 2.0.x code, the lpbk led is also a d channel led...the green
> light indicates that the d channel is up on that span.  (This is
> significant since the 2.0.x code supports NFAS, so not all spans will
> have d channels...this gives you a quick indication of which spans do
> have d channels on them and whether they are primary or backup....backup
> d channels will blink this light)
>
> >At 12:40 PM 8/25/99 -0500, you wrote:
> >>I flashed a dsp from 1.2.37 to 2.0.81 and now the damn thing doesn't work.
> >>The LPBK/DALM stays green when a PRI is plugged in.
> >>I flashed back to 1.2.37 and still the same thing.
> --
> Jeff McAdams                            Email: [e-mail]
> Head Network Administrator              Voice: [phone]
> IgLou Internet Services                        [phone]
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: gk <[e-mail]>
Subject: Re: (usr-tc) WTB: MP16I
Date: 25 Aug 1999 13:44:08 -0500 (CDT)

> 1- USR MP16I...buying today

I've got a spare one we bought in January but ended up not using...

care to make an offer?

--
: Greg Kemnitz - KB0OSO   : Skypoint Communications : WebSPAN             :
: PO Box 47804            : [phone]         : [phone]     :
: Plymouth, MN 55447-0804 : [e-mail]         : [e-mail]      :
: fax [phone]     : Internet connectivity   : Web page development:

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Steve Rivera <[e-mail]>
Subject: Re: (usr-tc) WTB: MP16I
Date: 25 Aug 1999 16:55:01 -0400

Thanks for the response. I understand you have a standing offer of $3000
for the
unit. Thats a great offer...Take it :)

Thanks for letting have a shot.

At 01:44 PM 08/25/1999 -0500, you wrote:
>> 1- USR MP16I...buying today
>
>I've got a spare one we bought in January but ended up not using...
>
>care to make an offer?
>
>--
>: Greg Kemnitz - KB0OSO   : Skypoint Communications : WebSPAN             :
>: PO Box 47804            : [phone]         : [phone]     :
>: Plymouth, MN 55447-0804 : [e-mail]         : [e-mail]      :
>: fax [phone]     : Internet connectivity   : Web page development:
>
>-
> To unsubscribe to usr-tc, send an email to "[e-mail]"
> 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 "[e-mail]"
 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: Steve Rivera <[e-mail]>
Subject: Re: (usr-tc) WTB: MP16I
Date: 25 Aug 1999 16:58:35 -0400

whats the staus here?

Thanks for the response. I understand you have a standing offer of $3000
for the
unit. Thats a great offer...Take it :)

Thanks for letting have a shot.

At 01:44 PM 08/25/1999 -0500, you wrote:
>> 1- USR MP16I...buying today
>
>I've got a spare one we bought in January but ended up not using...
>
>care to make an offer?
>
>--
>: Greg Kemnitz - KB0OSO   : Skypoint Communications : WebSPAN             :
>: PO Box 47804            : [phone]         : [phone]     :
>: Plymouth, MN 55447-0804 : [e-mail]         : [e-mail]      :
>: fax [phone]     : Internet connectivity   : Web page development:
>
>-
> To unsubscribe to usr-tc, send an email to "[e-mail]"
> 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 "[e-mail]"
 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: Robert von Bismarck <[e-mail]>
Subject: (usr-tc) HiPerDSP 2.0.81 and 2.0.19 differences ?
Date: 26 Aug 1999 14:41:41 +0200

I'm running DSP 1.2.43 on my chassis (30 HDSP's) and 4.1.59-6 on my ARC's.
This setup has been stable for several months now and the bugs are ironed
out.

I'm planning to upgrade to 2.x for the DSP and 4.2.x for the ARC.

I don't need any add-ins like NFAS, ANI/DNIS authentication, etc... I just
need the best possible V.90 and ISDN connections (don't tell me to go with
Lucent or Ascend, I think I'll bite you ;-)

I have E1 PRI's here, I was wondering if I should wait for 2.0.81 to come
out for E1 (only available for T1 now), should I stay with 1.2.43 or should
I take the 2.0.19 code.

I plan to get 4.2x code for the ARC's to replace RIPv2 with OSPF. This will
be done, whatever code I choose for the modems.

Anyone want to share problems/solutions during this kind of upgrade ?

I think I'll have to get 6.x code for the NMC first, right or wrong ?

Thanks for any pointers/hints/etc...

Robert

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) HiPerDSP 2.0.81 and 2.0.19 differences ?
Date: 26 Aug 1999 09:13:10 -0400

Thus spake Robert von Bismarck
> I'm running DSP 1.2.43 on my chassis (30 HDSP's) and 4.1.59-6 on my
> ARC's.  This setup has been stable for several months now and the bugs
> are ironed out.

> I'm planning to upgrade to 2.x for the DSP and 4.2.x for the ARC.
 4.2.x for the Arc is locked on totalservice right now, so unless you've
already pulled it down, you won't be able to get it.  There were
apparently some fairly significant problems with it, so I'd probably
stay away from it for the moment.  Hopefully, we'll get updated code
from 3Com soon (insert comments here about why I like Open Source
development ;) in the 4.2.x tree that supports OSPF that is a bit more
solid.  :)

I know at least Mike Andrews is running 4.2.29 anyway, I don't know what
sort of problems (if any) he's really having with it in production.

> I don't need any add-ins like NFAS, ANI/DNIS authentication, etc... I
> just need the best possible V.90 and ISDN connections (don't tell me
> to go with Lucent or Ascend, I think I'll bite you ;-)
 Of course, Lucent and Ascend are the same thing now.  :)  And while
they may give you better ISDN connections...I don't think I can put up
with the configuration of Ascend boxes...yuck.

> I have E1 PRI's here, I was wondering if I should wait for 2.0.81 to
> come out for E1 (only available for T1 now), should I stay with 1.2.43
> or should I take the 2.0.19 code.
 Honestly...if I were in your shoes, I'd probably stick with what you've
got currently...both for dsps and arcs.  The old adage, if it ain't
broke, don't fix it.  I'd say your chances of getting improved
connections with 2.0.19 code is iffy at best (considering they almost
immediately came out with a service release for it for t1 code), and its
likely to cause more problems.  :/

> I plan to get 4.2x code for the ARC's to replace RIPv2 with OSPF. This
> will be done, whatever code I choose for the modems.
 While I'm salivating waiting for the opportunity to banish RIP from my
network altogether...the time has not yet come to do that.  :)

> I think I'll have to get 6.x code for the NMC first, right or wrong ?
 I believe so...but having not made this transition myself...I couldn't
say for sure.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Brian Becker" <[e-mail]>
Subject: (usr-tc) B8ZS vs AMI
Date: 26 Aug 1999 08:45:46 -0500

I was wondering if anyone knew if there were differences in line quality,
connection speeds, etc. between B8ZS and AMI line coding. I've always used
AMI for my dialin's but was just informed by GTE rep that they felt B8ZS
gave better connection speeds.

Anyone have any input?

Brian Becker
Poplar Bluff Internet, Inc.


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Stainforth, Matthew" <[e-mail]>
Subject: RE: (usr-tc) B8ZS vs AMI
Date: 26 Aug 1999 11:12:07 -0300


I was told by a 3Com phone tech that PRIs MUST be ESF and B8ZS...but that
might just be verbal fluff.

On Thursday, August 26, 1999 10:46 AM, Brian Becker [SMTP:[e-mail]]
wrote:
> I was wondering if anyone knew if there were differences in line quality,
> connection speeds, etc. between B8ZS and AMI line coding. I've always used
> AMI for my dialin's but was just informed by GTE rep that they felt B8ZS
> gave better connection speeds.
>
> Anyone have any input?
>
> Brian Becker
> Poplar Bluff Internet, Inc.
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: "Brian Becker" <[e-mail]>
Subject: RE: (usr-tc) B8ZS vs AMI
Date: 26 Aug 1999 11:23:48 -0500

Our installs are all channelized T1's rather than PRI running from a
DMS10/100 on the TELCO side.

-----Original Message-----
[mailto:[e-mail]]On Behalf Of Stainforth, Matthew
Sent: Thursday, August 26, 1999 09:12 AM



I was told by a 3Com phone tech that PRIs MUST be ESF and B8ZS...but that
might just be verbal fluff.

On Thursday, August 26, 1999 10:46 AM, Brian Becker [SMTP:[e-mail]]
wrote:
> I was wondering if anyone knew if there were differences in line quality,
> connection speeds, etc. between B8ZS and AMI line coding. I've always used
> AMI for my dialin's but was just informed by GTE rep that they felt B8ZS
> gave better connection speeds.
>
> Anyone have any input?
>
> Brian Becker
> Poplar Bluff Internet, Inc.
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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 "[e-mail]"
 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: Nicolas St-Pierre <[e-mail]>
Subject: Re: (usr-tc) B8ZS vs AMI
Date: 26 Aug 1999 13:32:06 -0400



It is my understanding that AMI uses a lot more encapsulation space than
B8ZS and is usually used when the loops require better error
corrections. As far as connection speeds, since AMI uses more data for
encapsulation the total data bandwidth available is less than when B8ZS
is used which if I'm correct offers 1536Kbps of throughput on a PRI.


Nick

"Stainforth, Matthew" wrote:
>
> I was told by a 3Com phone tech that PRIs MUST be ESF and B8ZS...but that
> might just be verbal fluff.
>
> On Thursday, August 26, 1999 10:46 AM, Brian Becker [SMTP:[e-mail]]
> wrote:
> > I was wondering if anyone knew if there were differences in line quality,
> > connection speeds, etc. between B8ZS and AMI line coding. I've always used
> > AMI for my dialin's but was just informed by GTE rep that they felt B8ZS
> > gave better connection speeds.
> >
> > Anyone have any input?
> >
> > Brian Becker
> > Poplar Bluff Internet, Inc.
> >

--
Nicolas St-Pierre
Systems Engineer
Internet Access Solutions Ltd.
Tel [phone]
Fax [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Russ Miescke" <[e-mail]>
Subject: Re: (usr-tc) B8ZS vs AMI
Date: 26 Aug 1999 13:41:42 -0700

We have noticed that although the telco has our channelized Ts set to AMI,
we have less problems setting them to B8ZS on our TC racks.  We never
noticed it until we went to a T3 trunk.
Russ Miescke
Power Web Connect
----- Original Message -----
Sent: Thursday, August 26, 1999 9:23 AM


> Our installs are all channelized T1's rather than PRI running from a
> DMS10/100 on the TELCO side.
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Stainforth, Matthew
> Sent: Thursday, August 26, 1999 09:12 AM
> To: '[e-mail]'
> Subject: RE: (usr-tc) B8ZS vs AMI
>
>
>
> I was told by a 3Com phone tech that PRIs MUST be ESF and B8ZS...but that
> might just be verbal fluff.
>
> On Thursday, August 26, 1999 10:46 AM, Brian Becker [SMTP:[e-mail]]
> wrote:
> > I was wondering if anyone knew if there were differences in line
quality,
> > connection speeds, etc. between B8ZS and AMI line coding. I've always
used
> > AMI for my dialin's but was just informed by GTE rep that they felt B8ZS
> > gave better connection speeds.
> >
> > Anyone have any input?
> >
> > Brian Becker
> > Poplar Bluff Internet, Inc.
> >
> >
> > -
> >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> >  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 "[e-mail]"
>  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 "[e-mail]"
>  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 "[e-mail]"
 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: "Brian Becker" <[e-mail]>
Subject: RE: (usr-tc) B8ZS vs AMI
Date: 26 Aug 1999 14:08:25 -0500

So the telco is set to AMI and you are set to b8zs? How could that work...or
did I mis-understand you.

Thanks,
Brian

-----Original Message-----
[mailto:[e-mail]]On Behalf Of Russ Miescke
Sent: Thursday, August 26, 1999 03:42 PM


We have noticed that although the telco has our channelized Ts set to AMI,
we have less problems setting them to B8ZS on our TC racks.  We never
noticed it until we went to a T3 trunk.
Russ Miescke
Power Web Connect
----- Original Message -----
Sent: Thursday, August 26, 1999 9:23 AM


> Our installs are all channelized T1's rather than PRI running from a
> DMS10/100 on the TELCO side.
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Stainforth, Matthew
> Sent: Thursday, August 26, 1999 09:12 AM
> To: '[e-mail]'
> Subject: RE: (usr-tc) B8ZS vs AMI
>
>
>
> I was told by a 3Com phone tech that PRIs MUST be ESF and B8ZS...but that
> might just be verbal fluff.
>
> On Thursday, August 26, 1999 10:46 AM, Brian Becker [SMTP:[e-mail]]
> wrote:
> > I was wondering if anyone knew if there were differences in line
quality,
> > connection speeds, etc. between B8ZS and AMI line coding. I've always
used
> > AMI for my dialin's but was just informed by GTE rep that they felt B8ZS
> > gave better connection speeds.
> >
> > Anyone have any input?
> >
> > Brian Becker
> > Poplar Bluff Internet, Inc.
> >
> >
> > -
> >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> >  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 "[e-mail]"
>  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 "[e-mail]"
>  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 "[e-mail]"
 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 "[e-mail]"
 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: "Russ Miescke" <[e-mail]>
Subject: Re: (usr-tc) B8ZS vs AMI
Date: 26 Aug 1999 14:36:21 -0700

It works.  Not sure how.
Russ Miescke
----- Original Message -----
Sent: Thursday, August 26, 1999 12:08 PM


> So the telco is set to AMI and you are set to b8zs? How could that
work...or
> did I mis-understand you.
>
> Thanks,
> Brian
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Russ Miescke
> Sent: Thursday, August 26, 1999 03:42 PM
> To: [e-mail]
> Subject: Re: (usr-tc) B8ZS vs AMI
>
>
> We have noticed that although the telco has our channelized Ts set to AMI,
> we have less problems setting them to B8ZS on our TC racks.  We never
> noticed it until we went to a T3 trunk.
> Russ Miescke
> Power Web Connect
> ----- Original Message -----
> From: Brian Becker <[e-mail]>
> To: <[e-mail]>
> Sent: Thursday, August 26, 1999 9:23 AM
> Subject: RE: (usr-tc) B8ZS vs AMI
>
>
> > Our installs are all channelized T1's rather than PRI running from a
> > DMS10/100 on the TELCO side.
> >
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Stainforth, Matthew
> > Sent: Thursday, August 26, 1999 09:12 AM
> > To: '[e-mail]'
> > Subject: RE: (usr-tc) B8ZS vs AMI
> >
> >
> >
> > I was told by a 3Com phone tech that PRIs MUST be ESF and B8ZS...but
that
> > might just be verbal fluff.
> >
> > On Thursday, August 26, 1999 10:46 AM, Brian Becker
[SMTP:[e-mail]]
> > wrote:
> > > I was wondering if anyone knew if there were differences in line
> quality,
> > > connection speeds, etc. between B8ZS and AMI line coding. I've always
> used
> > > AMI for my dialin's but was just informed by GTE rep that they felt
B8ZS
> > > gave better connection speeds.
> > >
> > > Anyone have any input?
> > >
> > > Brian Becker
> > > Poplar Bluff Internet, Inc.
> > >
> > >
> > > -
> > >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> > >  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 "[e-mail]"
> >  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 "[e-mail]"
> >  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 "[e-mail]"
>  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 "[e-mail]"
>  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 "[e-mail]"
 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: "Brian Becker" <[e-mail]>
Subject: RE: (usr-tc) B8ZS vs AMI
Date: 26 Aug 1999 15:02:21 -0500

I'll try that on one of our boxes and see what that does. Can you further
explain what you meant by "we have less problems setting them to B8ZS on our
TC racks." Did it correct some users who weren't actually connecting? or
just increasing connect speeds?
Thanks,
Brian

-----Original Message-----
[mailto:[e-mail]]On Behalf Of Russ Miescke
Sent: Thursday, August 26, 1999 04:36 PM


It works.  Not sure how.
Russ Miescke
----- Original Message -----
Sent: Thursday, August 26, 1999 12:08 PM


> So the telco is set to AMI and you are set to b8zs? How could that
work...or
> did I mis-understand you.
>
> Thanks,
> Brian
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Russ Miescke
> Sent: Thursday, August 26, 1999 03:42 PM
> To: [e-mail]
> Subject: Re: (usr-tc) B8ZS vs AMI
>
>
> We have noticed that although the telco has our channelized Ts set to AMI,
> we have less problems setting them to B8ZS on our TC racks.  We never
> noticed it until we went to a T3 trunk.
> Russ Miescke
> Power Web Connect
> ----- Original Message -----
> From: Brian Becker <[e-mail]>
> To: <[e-mail]>
> Sent: Thursday, August 26, 1999 9:23 AM
> Subject: RE: (usr-tc) B8ZS vs AMI
>
>
> > Our installs are all channelized T1's rather than PRI running from a
> > DMS10/100 on the TELCO side.
> >
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Stainforth, Matthew
> > Sent: Thursday, August 26, 1999 09:12 AM
> > To: '[e-mail]'
> > Subject: RE: (usr-tc) B8ZS vs AMI
> >
> >
> >
> > I was told by a 3Com phone tech that PRIs MUST be ESF and B8ZS...but
that
> > might just be verbal fluff.
> >
> > On Thursday, August 26, 1999 10:46 AM, Brian Becker
[SMTP:[e-mail]]
> > wrote:
> > > I was wondering if anyone knew if there were differences in line
> quality,
> > > connection speeds, etc. between B8ZS and AMI line coding. I've always
> used
> > > AMI for my dialin's but was just informed by GTE rep that they felt
B8ZS
> > > gave better connection speeds.
> > >
> > > Anyone have any input?
> > >
> > > Brian Becker
> > > Poplar Bluff Internet, Inc.
> > >
> > >
> > > -
> > >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> > >  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 "[e-mail]"
> >  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 "[e-mail]"
> >  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 "[e-mail]"
>  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 "[e-mail]"
>  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 "[e-mail]"
 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 "[e-mail]"
 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: "Russ Miescke" <[e-mail]>
Subject: Re: (usr-tc) B8ZS vs AMI
Date: 26 Aug 1999 16:32:04 -0700

Ever since we put in our T3 & Mux, we had connection problems from all kinds
of users.  I posted a note to this list and several people told me of the
hazzards of running channelized T1s over a T3.  One person (I wish I
remembered who) suggested that the Mux was looking for a full 64k B channel
and was seeing 56k ami settings.  I Had one TC hub that I set to B8ZS and
immediately stopped having connection problems.  I set them all the same and
it worked fine.
Russ
----- Original Message -----
Sent: Thursday, August 26, 1999 1:02 PM


> I'll try that on one of our boxes and see what that does. Can you further
> explain what you meant by "we have less problems setting them to B8ZS on
our
> TC racks." Did it correct some users who weren't actually connecting? or
> just increasing connect speeds?
> Thanks,
> Brian
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Russ Miescke
> Sent: Thursday, August 26, 1999 04:36 PM
> To: [e-mail]
> Subject: Re: (usr-tc) B8ZS vs AMI
>
>
> It works.  Not sure how.
> Russ Miescke
> ----- Original Message -----
> From: Brian Becker <[e-mail]>
> To: <[e-mail]>
> Sent: Thursday, August 26, 1999 12:08 PM
> Subject: RE: (usr-tc) B8ZS vs AMI
>
>
> > So the telco is set to AMI and you are set to b8zs? How could that
> work...or
> > did I mis-understand you.
> >
> > Thanks,
> > Brian
> >
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Russ Miescke
> > Sent: Thursday, August 26, 1999 03:42 PM
> > To: [e-mail]
> > Subject: Re: (usr-tc) B8ZS vs AMI
> >
> >
> > We have noticed that although the telco has our channelized Ts set to
AMI,
> > we have less problems setting them to B8ZS on our TC racks.  We never
> > noticed it until we went to a T3 trunk.
> > Russ Miescke
> > Power Web Connect
> > ----- Original Message -----
> > From: Brian Becker <[e-mail]>
> > To: <[e-mail]>
> > Sent: Thursday, August 26, 1999 9:23 AM
> > Subject: RE: (usr-tc) B8ZS vs AMI
> >
> >
> > > Our installs are all channelized T1's rather than PRI running from a
> > > DMS10/100 on the TELCO side.
> > >
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]]On Behalf Of Stainforth,
Matthew
> > > Sent: Thursday, August 26, 1999 09:12 AM
> > > To: '[e-mail]'
> > > Subject: RE: (usr-tc) B8ZS vs AMI
> > >
> > >
> > >
> > > I was told by a 3Com phone tech that PRIs MUST be ESF and B8ZS...but
> that
> > > might just be verbal fluff.
> > >
> > > On Thursday, August 26, 1999 10:46 AM, Brian Becker
> [SMTP:[e-mail]]
> > > wrote:
> > > > I was wondering if anyone knew if there were differences in line
> > quality,
> > > > connection speeds, etc. between B8ZS and AMI line coding. I've
always
> > used
> > > > AMI for my dialin's but was just informed by GTE rep that they felt
> B8ZS
> > > > gave better connection speeds.
> > > >
> > > > Anyone have any input?
> > > >
> > > > Brian Becker
> > > > Poplar Bluff Internet, Inc.
> > > >
> > > >
> > > > -
> > > >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> > > >  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 "[e-mail]"
> > >  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 "[e-mail]"
> > >  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 "[e-mail]"
> >  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 "[e-mail]"
> >  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 "[e-mail]"
>  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 "[e-mail]"
>  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 "[e-mail]"
 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: Mike Andrews <[e-mail]>
Subject: Re: (usr-tc) HiPerDSP 2.0.81 and 2.0.19 differences ?
Date: 26 Aug 1999 17:23:34 -0400 (EDT)

On Thu, 26 Aug 1999, Jeff Mcadams wrote:

> Thus spake Robert von Bismarck
> > I'm running DSP 1.2.43 on my chassis (30 HDSP's) and 4.1.59-6 on my
> > ARC's.  This setup has been stable for several months now and the bugs
> > are ironed out.
>
> > I'm planning to upgrade to 2.x for the DSP and 4.2.x for the ARC.
>  4.2.x for the Arc is locked on totalservice right now, so unless you've
> already pulled it down, you won't be able to get it.  There were
> apparently some fairly significant problems with it, so I'd probably
> stay away from it for the moment.  Hopefully, we'll get updated code
> from 3Com soon (insert comments here about why I like Open Source
> development ;) in the 4.2.x tree that supports OSPF that is a bit more
> solid.  :)
>
> I know at least Mike Andrews is running 4.2.29 anyway, I don't know what
> sort of problems (if any) he's really having with it in production.

The route aggregation bug I mentioned earlier is biting us in the ass
occasionally.  That, and the bugs associated with the upgrade itself
(losing all authentication-related settings) were about the only problems
I've really had with it.  Check the archives for my earlier rants on
problems in 4.2.29.

4.1.59-6 worked well for just about everything except Mac FreePPP users.


>  Of course, Lucent and Ascend are the same thing now.  :)  And while
> they may give you better ISDN connections...I don't think I can put up
> with the configuration of Ascend boxes...yuck.

The word is the old Livingston gear is getting killed off in favor of the
Ascend.  PM4 is already dead.  PM3 will be dead soon.  PM2 may live on,
but that's not much of a help...

Ascend's user interface sucks, their SNMP implementation sucks, and I
haven't heard good things about their need for Radius VSA's for things
that should be standard.  (You think 3com is bad about that?  Not really.)

There's always Cisco...


> > I have E1 PRI's here, I was wondering if I should wait for 2.0.81 to
> > come out for E1 (only available for T1 now), should I stay with 1.2.43
> > or should I take the 2.0.19 code.
>  Honestly...if I were in your shoes, I'd probably stick with what you've
> got currently...both for dsps and arcs.  The old adage, if it ain't
> broke, don't fix it.  I'd say your chances of getting improved
> connections with 2.0.19 code is iffy at best (considering they almost
> immediately came out with a service release for it for t1 code), and its
> likely to cause more problems.  :/

2.0.81 and 1.2.37 seemed roughly the same, with 2.0.81 maybe being
slightly worse for the Rockwell HCF users.  But again, the problem is
much more Rockwell's than 3Com's.  LT Winmodem performance is about the
same... though we tend not to run into those very often anymore, and their
updated drivers actually work great once you get 'em.

Where was it I saw that Rockwell specifically made their modems hang up
after three speed shifts... it would certainly explain their disconnect
patterns...

With 4.2.29 + 2.0.81, I am having major Multilink PPP performance issues,
with both analog and ISDN multilink.  I don't know which card is to blame.

If you're not brave enough for 2.x DSP code, going from 1.2.43 to 1.2.37
seems safe.


> > I plan to get 4.2x code for the ARC's to replace RIPv2 with OSPF. This
> > will be done, whatever code I choose for the modems.
>  While I'm salivating waiting for the opportunity to banish RIP from my
> network altogether...the time has not yet come to do that.  :)

Aside from the aforementioned bugs, 4.2.29 did actually let us do that. :)
But I'd wait for the service release -- whenever that's coming -- to work
out some of that if you can...


> > I think I'll have to get 6.x code for the NMC first, right or wrong ?
>  I believe so...but having not made this transition myself...I couldn't
> say for sure.

Definitely upgrade your NMC code, even if you do nothing else.  It fixes a
LOT of really stupid off-by-one Radius accounting problems (these were
driving me absolutely nuts), some SNMP oddities, and a weird problem with
the console port not working with certain cables.


Mike Andrews (MA12) -=-=-  VP & Sysadmin, Digital Crescent, Frankfort KY
[e-mail]  -=--=-  [e-mail]  -=--=-  http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Mike Andrews <[e-mail]>
Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 26 Aug 1999 17:38:13 -0400 (EDT)

On Mon, 23 Aug 1999, Brian wrote:

> > AOL, Earthlink and Mindspring ALL use Ascend in our area. Ascend has a
> > distinct pre-tone... I know they are Ascends. These guys don't run their own
> > POPs in most cases and whore out the business through third party POP
> > vendors... that could be using anything.
>
> I can't comment on most of this discussion, but I can say that 1 - 1.5
> years ago AOL/Mindspring were mostly USR NASen........i don't know if that
> has changed.

Not in my area it hasn't.  AOL's dialups here in Frankfort are
Quads+Netservers, owned by Sprint.  Sprint's using Cisco in Lexington,
though, but AOL's main number there is ANSnet, which again is 3Com stuff.

At any rate, we don't often hear complaints of our connect speed vs AOL's. :)

Mindspring I'm not sure about.  They aren't a competitor for us.

For what it's worth though, just to throw a bit in here:

We had one guy once who had a bizarre v.34 vs v.90 problem. If he called
from his Frankfort home to our Frankfort number, he got v.34.  If he
called our Lawrenceburg number, which at the time was a POTS line that
call-forwarded to the same Frankfort number... he would get v.90.
Whether he was calling long distance, or had area calling, I'm not sure,
so I don't know if it was a padding issue... but it was odd that he had to
dial the "long way around" to get a faster speed than dialing direct, even
though the call ended up on the same physical PRI's and modems.  There is
no way you can blame *that* on 3Com. :)

PCM modems are so dependent on perfection at the phone company (which is
an oxymoron, really) that I don't have a big problem telling customers
that "no v.90 = telco problem".  (Unless they have a Rockwell HCF.)  And
we can get the telco to back us up, because most of their local employees
are customers of ours. :)


Mike Andrews (MA12) -=-=-  VP & Sysadmin, Digital Crescent, Frankfort KY
[e-mail]  -=--=-  [e-mail]  -=--=-  http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Steve McConnell <[e-mail]>
Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 26 Aug 1999 17:49:53 -0400

--On Thursday, August 26, 1999, 5:38 PM -0400 Mike Andrews
<[e-mail]> wrote:

>
> Mindspring I'm not sure about.  They aren't a competitor for us.

For what it is worth in the Raleigh-Durham-Triangle area Mindspring has
just a PILE of the Hiper chassis loaded to the gills with cards. It is my
impression this is a standard config for them, at least that is what the
install techs said. ( I expect to get  a nastygram from mspring now... ;)
)




Steve McConnell
EMJI
919-303-3217
888-258-8959


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: [e-mail] (Jeff Binkley)
Subject: (usr-tc) S/A SERVER
Date: 24 Aug 1999 07:49:00 -0500



We run 3Com's S/A server version 6.08 and have noticed an oddity which  have noticed an oddity which
was partially discussed here before.  We have some users who login with
[e-mail] instead of just userid.  S/A seems to accept this
just fine.  However, if you have login tracking enabled (MS Access
version of S/A), there is no entry in the database for
[e-mail], just userid.  Thus they get in but none of the
login tracking features will work since the accounting reacords can't
find a match in the database.  Is there a way to hack the script to
block the userid@mydomain logins ?  Or a way to strip the @mydomain.com
from the accounting records ?  What have others done ?


Jeff Binkley
ASA Networ

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
Date: 26 Aug 1999 19:39:12 -0400

Thus spake Mike Andrews
> We had one guy once who had a bizarre v.34 vs v.90 problem. If he called
> from his Frankfort home to our Frankfort number, he got v.34.  If he
> called our Lawrenceburg number, which at the time was a POTS line that
> call-forwarded to the same Frankfort number... he would get v.90.
> Whether he was calling long distance, or had area calling, I'm not sure,
> so I don't know if it was a padding issue... but it was odd that he had to
> dial the "long way around" to get a faster speed than dialing direct, even
> though the call ended up on the same physical PRI's and modems.  There is
> no way you can blame *that* on 3Com. :)

Heh...ain't that lovely.  :)  FWIW, this is almost assuredly an issue of
how the telco is routing the call.  I've spoken with several BellSouth
techs in Louisville (no, the real ones, not the monkeys that come out to
install stuff) and they explained some of how different calling patters
were routed.  Interestingly enough, at least here in Louisville, ISDN
data calls are routed the same way long distance calls are.  And area
calling really doesn't have anything to do with how the calls are
routed...they're still routed the same way, just billed differently.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: John Nelson <[e-mail]>
Subject: Re: (usr-tc) HiPerDSP 2.0.81 and 2.0.19 differences ?
Date: 26 Aug 1999 19:28:34 -0500

>Where was it I saw that Rockwell specifically made their modems hang up
>after three speed shifts... it would certainly explain their disconnect
>patterns...
    Rockwells retrain 3 times total, after that the connection will drop.
>=========================================================<
> -John Nelson                   |  email:                <
> --Technical Support            |       [e-mail]  <
> ---JORSM Internet              |                        <
> ----Toll Free # 1-877-JORSM95  |                        <
>=========================================================<
>=========================================================<
>                        JORSM Internet                   <
>          Regional Premium Internet Service Provider     <
>               Serving Chicagoland and NW Indiana        <
>                   927 Sheffield Ave Dyer, IN            <
>  Tech hours: M-F 9-9, Sat 10-2     http://www.jorsm.com <
>=========================================================<

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: das <[e-mail]>
Subject: (usr-tc) radius authentication problem with harc
Date: 27 Aug 1999 11:31:50 +0900

Hi,

I am experiencing some weird entries in my radius logs from a new hiperarc running 4.1.59.

I keep seeing this entry repeated time and time again:

accounting: client XXX sent accounting-request with invalid request authenticator

Does anyone have any idea what this pertains to?  We are running a hacked version of Livingston radius.

Thanks,

das

--
____________________________________________
Alex Substanley       Global OnLine Japan
                Engineering Department
Das Man               TEL: [phone]
Systems Engineer      FAX: [phone]
  The Highest Quality Service, Bar None
____________________________________________

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 Lynch <[e-mail]>
Subject: Re: (usr-tc) B8ZS vs AMI
Date: 26 Aug 1999 23:16:40 -0500 (CDT)

On Thu, 26 Aug 1999, Nicolas St-Pierre wrote:

>
>
> It is my understanding that AMI uses a lot more encapsulation space than
> B8ZS and is usually used when the loops require better error
> corrections. As far as connection speeds, since AMI uses more data for
> encapsulation the total data bandwidth available is less than when B8ZS
> is used which if I'm correct offers 1536Kbps of throughput on a PRI.

No. See my previous post on AMI vs B8ZS.

All DS1 transport carries 1536 kbits/second payload. 64k x 24 = 1536k
The 1.544 mbps actual clock rate comes from the insertion of a framing bit
every frame (24 timeslots x 8 bits/timeslot = 192 bits). Every DS1 gets
a 193rd bit for framing regardless of line coding.

Calculated another way It takes 125 microseconds to transmit a frame
(derived from the 8khz nyquist sampling frequency chosen for voice) so
192 bits/frame x 1/125microseconds/frame = 1536k bits/second.

Finally, since every ds1 actually transmits 193 bits per frame,
193 bits/frame x 1/125microseconds/frame = 1544k bits/second.

--jeff

============================================================================
Jeffrey A. Lynch        | JORSM Internet, Regional Internet Services
email: [e-mail]        | 7 Area Codes in Chicagoland and NW Indiana
Voice: [phone]        | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN
Autoresponse: [e-mail]    | Quality Service, Affordable Prices
http://www.jorsm.com        | Serving Gov, Biz, Indivds Since 1995



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 Lynch <[e-mail]>
Subject: Re: (usr-tc) B8ZS vs AMI
Date: 26 Aug 1999 23:26:01 -0500 (CDT)

On Thu, 26 Aug 1999, Russ Miescke wrote:

> Ever since we put in our T3 & Mux, we had connection problems from all kinds
> of users.  I posted a note to this list and several people told me of the
> hazzards of running channelized T1s over a T3.  One person (I wish I
> remembered who) suggested that the Mux was looking for a full 64k B channel
> and was seeing 56k ami settings.  I Had one TC hub that I set to B8ZS and
> immediately stopped having connection problems.  I set them all the same and
> it worked fine.

Heh, that's why it takes a while to provision circuits and the installer
spends an hour on average testing it before turn-over.  Most of them are
added/dropped on T3 or OCx over fiber somewhere between end points unless
they're on the same CO. Each channel/port has got to be provisioned
correctly. Most modern transport equipment defaults to B8ZS. Framing
usually defaults to ESF but framing is determined by the end points,
not the carrier.

--jeff

============================================================================
Jeffrey A. Lynch        | JORSM Internet, Regional Internet Services
email: [e-mail]        | 7 Area Codes in Chicagoland and NW Indiana
Voice: [phone]        | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN
Autoresponse: [e-mail]    | Quality Service, Affordable Prices
http://www.jorsm.com        | Serving Gov, Biz, Indivds Since 1995


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Marshall Morgan" <[e-mail]>
Subject: RE: (usr-tc) radius authentication problem with harc
Date: 27 Aug 1999 02:39:48 -0500

You do not have the radius secret enabled for accounting on your NAS.

set accounting primary_secret "mysecret"

Marshall Morgan

Internet Doorway, Inc (aka NETDOOR)
http://www.netdoor.com

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of das
> Sent: Thursday, August 26, 1999 9:32 PM
> To: [e-mail]
> Subject: (usr-tc) radius authentication problem with harc
>
>
> Hi,
>
> I am experiencing some weird entries in my radius logs from a new
> hiperarc running 4.1.59.
>
> I keep seeing this entry repeated time and time again:
>
> accounting: client XXX sent accounting-request with invalid request
> authenticator
>
> Does anyone have any idea what this pertains to?  We are running a
> hacked version of Livingston radius.
>
> Thanks,
>
> das
>
> --
> ____________________________________________
> Alex Substanley       Global OnLine Japan
>                 Engineering Department
> Das Man               TEL: [phone]
> Systems Engineer      FAX: [phone]
>   The Highest Quality Service, Bar None
> ____________________________________________
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: das <[e-mail]>
Subject: Re: (usr-tc) radius authentication problem with harc
Date: 27 Aug 1999 17:35:32 +0900

Hello Marshall,

Thanks for the response.

Yes, that is what I thought as well. But, resetting that did nothing.  I had the one harc
running 4.1.59 which had the problem.  I found that the harc had a secondary server set up
instead of a Primary First Backup Server.  Once I changed that, the problem for that harc
went away.  The other harc I am having a problem with is running code 4.1.7.  Do you think
that that might be the problem?  I have reset all of the accounting settings, but I noticed
that attribute_style is not an option on 4.1.7.

das

Marshall Morgan ([e-mail]) spake:

> You do not have the radius secret enabled for accounting on your NAS.
>
> set accounting primary_secret "mysecret"
>
> Marshall Morgan
>
> Internet Doorway, Inc (aka NETDOOR)
> http://www.netdoor.com
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of das
> > Sent: Thursday, August 26, 1999 9:32 PM
> > To: [e-mail]
> > Subject: (usr-tc) radius authentication problem with harc
> >
> >
> > Hi,
> >
> > I am experiencing some weird entries in my radius logs from a new
> > hiperarc running 4.1.59.
> >
> > I keep seeing this entry repeated time and time again:
> >
> > accounting: client XXX sent accounting-request with invalid request
> > authenticator
> >
> > Does anyone have any idea what this pertains to?  We are running a
> > hacked version of Livingston radius.
> >
> > Thanks,
> >
> > das
> >
> > --
> > ____________________________________________
> > Alex Substanley       Global OnLine Japan
> >                 Engineering Department
> > Das Man               TEL: [phone]
> > Systems Engineer      FAX: [phone]
> >   The Highest Quality Service, Bar None
> > ____________________________________________
> >
> > -
> >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> >  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 "[e-mail]"
>  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.

--
____________________________________________
Alex Substanley       Global OnLine Japan
                Engineering Department
Das Man               TEL: [phone]
Systems Engineer      FAX: [phone]
  The Highest Quality Service, Bar None
____________________________________________

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Frederick R. Doncillo" <[e-mail]>
Subject: Re: (usr-tc) B8ZS vs AMI
Date: 27 Aug 1999 17:24:32 +0800

how will we know what to use best between b8zs, ami or hdb3.  am now using hdb3
though.  thanks.

Jeff Lynch wrote:

> On Thu, 26 Aug 1999, Russ Miescke wrote:
>
> > Ever since we put in our T3 & Mux, we had connection problems from all kinds
> > of users.  I posted a note to this list and several people told me of the
> > hazzards of running channelized T1s over a T3.  One person (I wish I
> > remembered who) suggested that the Mux was looking for a full 64k B channel
> > and was seeing 56k ami settings.  I Had one TC hub that I set to B8ZS and
> > immediately stopped having connection problems.  I set them all the same and
> > it worked fine.
>
> Heh, that's why it takes a while to provision circuits and the installer
> spends an hour on average testing it before turn-over.  Most of them are
> added/dropped on T3 or OCx over fiber somewhere between end points unless
> they're on the same CO. Each channel/port has got to be provisioned
> correctly. Most modern transport equipment defaults to B8ZS. Framing
> usually defaults to ESF but framing is determined by the end points,
> not the carrier.
>
> --jeff
>
> ============================================================================
> Jeffrey A. Lynch                | JORSM Internet, Regional Internet Services
> email: [e-mail]           | 7 Area Codes in Chicagoland and NW Indiana
> Voice: [phone]            | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN
> Autoresponse: [e-mail]    | Quality Service, Affordable Prices
> http://www.jorsm.com            | Serving Gov, Biz, Indivds Since 1995
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: gk <[e-mail]>
Subject: Re: (usr-tc) WTB: MP16I
Date: 27 Aug 1999 06:44:59 -0500 (CDT)

>>I've got a spare one we bought in January but ended up not using...>
>>care to make an offer?>
>
>Thanks for the response. I understand you have a standing offer of $3000
>for the unit. Thats a great offer...Take it :)
>
>Thanks for letting have a shot.

BIG OOPS...

First -- I had *not* intended my reply to Steve to go to the list -- I'll
be checking more carefully in the future!!

Second -- Two discussion threads got merged, and his message regarding the
MP-16/i was confused with one regarding a Netserver-16 plus Imodem unit when
he placed a call to our office yesterday.  His offer on the MP-16/i was quite
acceptable (but of course would have been a bit low for an unused Netserver
16/I)

In any case, my apologies...


--
: Greg Kemnitz - KB0OSO   : Skypoint Communications : WebSPAN             :
: PO Box 47804            : [phone]         : [phone]     :
: Plymouth, MN 55447-0804 : [e-mail]         : [e-mail]      :
: fax [phone]     : Internet connectivity   : Web page development:

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: [e-mail] (Jeff Binkley)
Subject: Re: (usr-tc) B8ZS vs AMI
Date: 27 Aug 1999 09:08:00 -0500





u>On Thu, 26 Aug 1999, Nicolas St-Pierre wrote:



u>> It is my understanding that AMI uses a lot more encapsulation space
u>> than B8ZS and is usually used when the loops require better error
u>> corrections. As far as connection speeds, since AMI uses more data
u>> for encapsulation the total data bandwidth available is less than
u>> when B8ZS is used which if I'm correct offers 1536Kbps of throughput
u>> on a PRI.

u>No. See my previous post on AMI vs B8ZS.

u>All DS1 transport carries 1536 kbits/second payload. 64k x 24 = 1536k
u>The 1.544 mbps actual clock rate comes from the insertion of a framing
u>bit every frame (24 timeslots x 8 bits/timeslot = 192 bits). Every DS1
u>gets a 193rd bit for framing regardless of line coding.
u>
u>Calculated another way It takes 125 microseconds to transmit a frame
u>(derived from the 8khz nyquist sampling frequency chosen for voice) so
u>192 bits/frame x 1/125microseconds/frame = 1536k bits/second.

u>Finally, since every ds1 actually transmits 193 bits per frame,
u>193 bits/frame x 1/125microseconds/frame = 1544k bits/second.


Ok. Let's see if we can clear this up for everyone.

With T-1s there are a coupel of mutually exclusive features.  The first
is line coding (i.e. AMI vs B8ZS), the second is framing (SF vs ESF) and
the third is channelized, channelized with RBS and clear channel.  I'll
go through each one one at a time.


Line coding -

AMI and B8ZS are identical except under one very specific condition.
(Alternate Mark Inversion) AMI means that every other bit transmitted
down the wire is inverted.  (Binary 8 Zero Substitution) B8ZS is excatly
the same except that when the end device (i.e. DSP card) were to try and
send 8 consecutive zeroes, a substitution is performed with a special
B8ZS pattern.  This substituted pattern actually contains a bipolar
violation as far as AMI line coding is concerned (i.e. it send two
consecutives marks of the same polarity).  The whole reason for B8ZS was
to keep the signal strength strong enough during times of long sets of
zeros being sent.  This was especially helpful in days when distances
were limited on T-1s due to copper wire and repeater inefficiencies.
Due to the B8ZS substitution the easiest way to have telco troubleshoot
whether a line is really set for B8ZS or not is to have them send long
strings of zeros and see if the B8ZS code gets generated.  If any device
is set AMI, it will start coughing up BPV errors.  Likewise if the line
is supposed to be AMI and something is set B8ZS along the T-1, the next
downstream AMI device will start recording BPV errors.  Just backup on
device and you'll find the culprit.


Framing -

SF (superframe) and ESF (extended superframe) only determine how many
193 bit frames are generated before the framing bit pattern (i.e. how
you count the sequence of frames frame1, frame2, frame3 etc..) is
repeated.  The other main difference is that as the ANSI standard came
out which specified ESF, they allowed the recording of error information
with CSUs (i.e. ESF stats).  Also since ESF required less of the 8k of
data bits used for framing, so of this data could be used for other
things like remote retrieval of CSU stats and more.  But neither framing
nor line coding have any effect on the amount of data a T-1 can send.


Channelized, clear channel and RBS -

A channelized T-1 takes the 192 bit and places them into distinctive
timeslots and sequences for transmission.  The actual sequence of
transmission (i.e. which chanel gets sent first, next and so on) is
determined by the framing sequence type (I thought I said they were
mutually exclusive.  I did.  I'll explain next). such as D1, D2, D1D,
D3/D4 etc..   D1, D1D and D2 aren't used much any more.  For instance D2
was used to minize adjacent channel crosstalk back in the days when the
electronics weren't as stable as they are today.  Thus information on
one channel (say channel 2) wouldn't bleed over into channel 1 or 3 but
it could still bleed over into the channels that were sent before and
after it.  So how does framing affect channelization ?  Since some of
the D1, D1D, D2 schemes required the equipment to know which frame it
was on in the framing sequence the frame number was used to help build
the correct channelization for each frame.  Other than that, it didn't
much matter.  Once you got to D3/D4 framing, all of the channels are
sent sequentially (i.e. 1-24) so it doesn't really matter, except to
keep the end devices in sync (i.e. they both know what frame they are on
for the purposes of alarm detecion).  A clear channel T-1 is similar to
a channelized T-1 except that there aren't the 24 discrete 64kbs
timeslots but there is still 24 * 64kbs or 1.536mbs of data available.
Where things change is with RBS (robbed bit signalling) which is only
used on certain channlized T-1s (RBS can't be used on clear channel T-1s
because it is a channel level function).  RBS was designed to propogate
on hook/off hook information across a T-1 analog channel.  In otehr
words how could you tell someone picked up their telephone across a T-1
channel.  A mechanism called A/B bit signalling was devised to translate
on hook/off hook states into a certain sequence of A/B bit patterns.
But to send A/B bits from one end of a channel to another, the bits had
to come from somewhere but since on hook/off hooks don't occur at frame
speeds (i.e. 8000us), they didn't need to steal a bit out of every
channl for every frame.  So a scheme was devised (called RBS) which said
the least significant bit out of every 8 frames would be used.  Thus you
would get so  you would end up with 8000 * 7 bits (56kbs) of available
bandwidth for each channel.  So if you are using line side T-1s from
telco, which still use RBS, then your data limit is 56kbs.  Will V.90
calls go better over a 64kbs channel vs a 56kbs channel, only 3Com can
share their test data.  I would suspect the difference would be minimal
since the sampling of A/d is nonlinear on a T-1 channel.  Primary rate T-
1s are channelized but do not use RBS.  The reason is that the D-channel
which rides on channel 24 is specified to run at 64kbs.  And since the D-
channel carries the signalling information, the A/B bits aren't needed.

I hope this helps a little.

Jeff

CMPQwk 1.42 9999

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 Lynch <[e-mail]>
Subject: Re: (usr-tc) B8ZS vs AMI
Date: 27 Aug 1999 08:17:41 -0500 (CDT)

On Fri, 27 Aug 1999, Frederick R. Doncillo wrote:

> how will we know what to use best between b8zs, ami or hdb3.  am now using hdb3
> though.  thanks.

Sorry, I'm not familiar with HDB3, available in the US? Definately
choose B8ZS over AMI though.

--jeff

============================================================================
Jeffrey A. Lynch        | JORSM Internet, Regional Internet Services
email: [e-mail]        | 7 Area Codes in Chicagoland and NW Indiana
Voice: [phone]        | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN
Autoresponse: [e-mail]    | Quality Service, Affordable Prices
http://www.jorsm.com        | Serving Gov, Biz, Indivds Since 1995


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 Lynch <[e-mail]>
Subject: Re: (usr-tc) B8ZS vs AMI (Repost)
Date: 27 Aug 1999 08:21:24 -0500 (CDT)

Repost, sorry if you get doubles....

On Thu, 26 Aug 1999, Brian Becker wrote:

> I was wondering if anyone knew if there were differences in line quality,
> connection speeds, etc. between B8ZS and AMI line coding. I've always used
> AMI for my dialin's but was just informed by GTE rep that they felt B8ZS
> gave better connection speeds.
>
> Anyone have any input?
>
> Brian Becker
> Poplar Bluff Internet, Inc.

Ok, time to pull from some of early SDH training while I was
at Bell Labs...

AMI = Alternate Mark Inversion

Each time a "mark" bit (ie binary one) is transmitted, the line voltage
polarity is reversed. DS1 is essentially a "balanced" or "differential"
class transmission line with frequency shaping. This is done to maintain a
zero average (ie. 0VDC) voltage on the line. However, since the timing on
a loop timed circuit must be recovered from the data pattern, a loss of
sync can result in the event that a long period of zeros are transmitted
(ie, a flat line).

Additionally, if the receiver detects two "ones" of the same polarity
consecutively, it assumes it missed some data and flags this as a Bi-polar
violation and bumps up the bpv error counter.

A new line coding scheme was devised to provide clear channel capability
by utilizing bipolar violations, called B8ZS.

B8ZS = Bi-polar 8 Zero Suppression

If the CSU detects a binary zero (byte) is to be transmitted on any DS0
time slot, the transmitter inserts back-to-back bipolar violations on that
DS0 timeslot for that frame. This is extremely unlikely (but not
impossible) so when the receiver detects (when configured for B8ZS) two
bipolar violations in a single DS0 timeslot, it removes the ones from the
received signal and properly detects it as a DS0 zero-valued byte. This
keeps the receiver clock synchronized and allows clear channel
transmission.

So building on this, if you have AMI provisioned DS-1 transport and you
setup for B8ZS, you will transmit bpvs in place of channel zeros you send.
It will increase your bit error rate because you will transmit bpvs
everytime you have a zero-byte to send but in many cases, you could still
run ok and not realize it unless you watch the recieved signal error
counters. A modem-modem connection will rarely transmit an exact
zero-byte.

Hmm. I'm not sure what the significance would be on the receive side.
Let's see, if you purchase an AMI circuit, you are in essence, agreeing to
ensure that you do not transmit DS0 zero-valued bytes (ie 56K DS0 channel
restricted). Thus line quality issues resulting from violating this
restriction are your responsibility including loss of sync (slips)  by
loosing the ability to recover clock (not very common now with advanced
clocking circuitry built into modern CSUs). A clued telco could watch
their BPV counters in response to quality issues you report and shrug
their shoulders and tell you to adhere to the channel restrictions you
agreed to by not including clear channel capability with your order.

--jeff

============================================================================
Jeffrey A. Lynch        | JORSM Internet, Regional Internet Services
email: [e-mail]        | 7 Area Codes in Chicagoland and NW Indiana
Voice: [phone]        | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN
Autoresponse: [e-mail]    | Quality Service, Affordable Prices
http://www.jorsm.com        | Serving Gov, Biz, Indivds Since 1995



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 Lynch <[e-mail]>
Subject: RE: (usr-tc) B8ZS vs AMI (Repost)
Date: 27 Aug 1999 08:22:32 -0500 (CDT)

Another repost, I notices that a few of my follow ups didn't come
back this morning. Sorry if you get dups.

On Thu, 26 Aug 1999, Stainforth, Matthew wrote:

>
> I was told by a 3Com phone tech that PRIs MUST be ESF and B8ZS...but that
> might just be verbal fluff.

The probability of transmitting a zero-byte on the D-channel is an almost
certain probability. How many phone numbers (calling-station and
called-station) have a 0 in them? Too many to mention. Thus B8ZS is
essentially a requirement if you adhere strictly to protocol standards.
ESF is generally recommended because a CRC check is included which
helps flag potential data errors, particularly for the D-channel.

============================================================================
Jeffrey A. Lynch        | JORSM Internet, Regional Internet Services
email: [e-mail]        | 7 Area Codes in Chicagoland and NW Indiana
Voice: [phone]        | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN
Autoresponse: [e-mail]    | Quality Service, Affordable Prices
http://www.jorsm.com        | Serving Gov, Biz, Indivds Since 1995




-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 Lynch <[e-mail]>
Subject: Re: (usr-tc) B8ZS vs AMI (Repost)
Date: 27 Aug 1999 08:26:17 -0500 (CDT)

Problem with the list server last night? Another one that didn't
make it back. Sorry if you get dups.

On Thu, 26 Aug 1999, Russ Miescke wrote:

> We have noticed that although the telco has our channelized Ts set to AMI,
> we have less problems setting them to B8ZS on our TC racks.  We never
> noticed it until we went to a T3 trunk.

Hmmm, this could be because T3 uses a line coding of B3ZS. Your M13 should
properly handle the conversion whether you use AMI or B8ZS provided it's
properly provisioned end-to-end. Check the mux settings for each DS1
and at the telco.

--jeff

============================================================================
Jeffrey A. Lynch        | JORSM Internet, Regional Internet Services
email: [e-mail]        | 7 Area Codes in Chicagoland and NW Indiana
Voice: [phone]        | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN
Autoresponse: [e-mail]    | Quality Service, Affordable Prices
http://www.jorsm.com        | Serving Gov, Biz, Indivds Since 1995



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: (usr-tc) TRAPS
Date: 27 Aug 1999 10:20:33 -0400 (EDT)

Hello all

Anyone ever figure out why TCM will show connection failures but the ARC
not throw a trap for them?  I have at LEAST 700 call failures over 7 DSP's
over the past week, yet the trap log only shows about 50.

Is syslogging more reliable than SNMP traps?

Does ASCEND have the same problems?

I seem to average a 10% call failure.  Constant over the past 2 years,
using QUADS and now DSP's, all kinds of code upgrades etc.

I stopped my software contract in June.  Is the new 2.* code much better?
Or is it time to call my friendly ASCEND dealer and get a chassis from
them... most people seem to have good experiences with them.

Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax [phone]
[e-mail]


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) TRAPS
Date: 27 Aug 1999 10:23:59 -0400

Thus spake Paul Farber
> Anyone ever figure out why TCM will show connection failures but the
> ARC not throw a trap for them?

Uhm...because the Arc isn't responsible for modem handshaking, the modem
card is.  If you want to see call failure traps, you need to set up
logging (either radius, or snmp traps) from the NMC card and enable the
mdmTeConnAttemptFailure trap.  This will generate an event on the modem
card, which the NMC can then generate a trap or radius log from.
--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Phil Le Clercq <[e-mail]>
Subject: (usr-tc) DLL Invalid
Date: 27 Aug 1999 16:15:13 +0100

Hi all, just setting up some Arcs for the first time, the DSP answers the
call ok and starts negotiating..well it sounds ok.
PPP never quite gets to the arc..I get this..

                                                        Start       Start
IfName          User Name                   Type   DLL  Date        Time
slot:1/mod:2                                DIALIN INVALID 00-   -0000
00:00:00


Dll Invalid, It's probably something really basic I am missing, but at the
moment I'm stumped. Help much appreciated.
Thanks Phil

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Tatai SV Krishnan <[e-mail]>
Subject: Re: (usr-tc) DLL Invalid
Date: 26 Aug 1999 22:22:35 -0500 (CDT)

You will see the DLL invalid - until the PPP has started and finished
IPCP - Till that period of time the ARC does not know if the call is ppp
or shell etc, so it marks the call a Invalid


krish

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

On Fri, 27 Aug 1999, Phil Le Clercq wrote:

> Hi all, just setting up some Arcs for the first time, the DSP answers the
> call ok and starts negotiating..well it sounds ok.
> PPP never quite gets to the arc..I get this..
>
>                                                         Start       Start
> IfName          User Name                   Type   DLL  Date        Time
> slot:1/mod:2                                DIALIN INVALID 00-   -0000
> 00:00:00
>
>
> Dll Invalid, It's probably something really basic I am missing, but at the
> moment I'm stumped. Help much appreciated.
> Thanks Phil
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: Phil Le Clercq <[e-mail]>
Subject: RE: (usr-tc) DLL Invalid
Date: 27 Aug 1999 16:39:20 +0100

Cheers, but the call never completes. The only thing that comes up is this,
it never gets to the ppp stage.
The client gets the "You have been disconnected from the computer you
dialled....)
So which do I have setup incorrectly DSP or ARC, I presumed the ARC?
Thanks, Phil

-----Original Message-----
Sent: Friday, August 27, 1999 4:23 AM
Cc: TCH List (E-mail)


You will see the DLL invalid - until the PPP has started and finished
IPCP - Till that period of time the ARC does not know if the call is ppp
or shell etc, so it marks the call a Invalid


krish

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

On Fri, 27 Aug 1999, Phil Le Clercq wrote:

> Hi all, just setting up some Arcs for the first time, the DSP answers the
> call ok and starts negotiating..well it sounds ok.
> PPP never quite gets to the arc..I get this..
>
>                                                         Start       Start
> IfName          User Name                   Type   DLL  Date        Time
> slot:1/mod:2                                DIALIN INVALID 00-   -0000
> 00:00:00
>
>
> Dll Invalid, It's probably something really basic I am missing, but at the
> moment I'm stumped. Help much appreciated.
> Thanks Phil
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: Tatai SV Krishnan <[e-mail]>
Subject: RE: (usr-tc) DLL Invalid
Date: 26 Aug 1999 22:39:25 -0500 (CDT)

On Fri, 27 Aug 1999, Phil Le Clercq wrote:

> Cheers, but the call never completes. The only thing that comes up is this,
> it never gets to the ppp stage.
> The client gets the "You have been disconnected from the computer you
> dialled....)
> So which do I have setup incorrectly DSP or ARC, I presumed the ARC?

When a user dials to the chassis, the call is first answered by the DSP -
at that time the arc knows that a modem is trying to connect and it puts
the DLL in invalid state.

From your statement above it looks like that the modems never connect and
establish carrier.  If they did then you would see ppp data.  Now we need
to knwo the DSP setup and make sure that they are setup properlly - DNIS
digits/ Span level things etc, to start off and debug the dsp why the
call did not connect.

First would need to know what version of DSP code and would suggest to
open a ticket as well to have a tech look at the same.

regards

krish

> Thanks, Phil
>
> -----Original Message-----
> From: Tatai SV Krishnan [mailto:[e-mail]]
> Sent: Friday, August 27, 1999 4:23 AM
> To: Phil Le Clercq
> Cc: TCH List (E-mail)
> Subject: Re: (usr-tc) DLL Invalid
>
>
> You will see the DLL invalid - until the PPP has started and finished
> IPCP - Till that period of time the ARC does not know if the call is ppp
> or shell etc, so it marks the call a Invalid
>
>
> krish
>
> -----------------------------------------
>         \    T.S.V. Krishnan  \
>          \      Network System Engineer \ ( : - : )
>           \     3Com ............   \
>         ----------------------------------------------/
> [e-mail]
> ----------------------------/ http://interproc.ae.usr.com ----/
> -------------------------------------------------------------------------\
>     Any Sufficiently advanced bug is indistinguishable for a feature.
>                         - Rick Kulawiec
> -------------------------------------------------------------------------/
>
> On Fri, 27 Aug 1999, Phil Le Clercq wrote:
>
> > Hi all, just setting up some Arcs for the first time, the DSP answers the
> > call ok and starts negotiating..well it sounds ok.
> > PPP never quite gets to the arc..I get this..
> >
> >                                                         Start       Start
> > IfName          User Name                   Type   DLL  Date        Time
> > slot:1/mod:2                                DIALIN INVALID 00-   -0000
> > 00:00:00
> >
> >
> > Dll Invalid, It's probably something really basic I am missing, but at the
> > moment I'm stumped. Help much appreciated.
> > Thanks Phil
> >
> > -
> >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> >  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 "[e-mail]"
>  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 "[e-mail]"
 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: Brian <[e-mail]>
Subject: (usr-tc) Receiver Gain
Date: 27 Aug 1999 10:49:55 -0500 (CDT)


I have 3 CT1 spans in a POP, and 2 of the 3 work fine.  The one that does
not work shows a receiver gain of 0, the ones that work show a reciver
gain of like -14.7db.

Does this indicate that the telco signal coming from teh cpe is probably
incorrect?  Or is this something correctable on my end?  I am not sure if
the Receiver gains being different is the problem with the span, or it may
be something else telco related, but that is all that differs on a "dis
spnstats"

Brian


Brian Feeny (BF304)     [e-mail]
318-222-2638 x 109    http://www.shreve.net/~signal
Network Administrator   ShreveNet Inc. (ASN 11881)


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Mike Andrews <[e-mail]>
Subject: RE: (usr-tc) DLL Invalid
Date: 27 Aug 1999 11:52:09 -0400 (EDT)

On Fri, 27 Aug 1999, Phil Le Clercq wrote:

> Cheers, but the call never completes. The only thing that comes up is this,
> it never gets to the ppp stage.
> The client gets the "You have been disconnected from the computer you
> dialled....)
> So which do I have setup incorrectly DSP or ARC, I presumed the ARC?
> Thanks, Phil

DSP or the client modem, if the modem never finishes connecting.  Try
calling in with a dumb terminal program (like Hyperterminal) and see if
you can at least get that far.

If the modem does connect, then the ARC is probably at fault.  Check your
authentication settings, maybe?  Try the (undocumented) command "_auth
username passwd" to test a username/password combo from the command line
to see if your Radius setup is working.


Mike Andrews (MA12) -=-=-  VP & Sysadmin, Digital Crescent, Frankfort KY
[e-mail]  -=--=-  [e-mail]  -=--=-  http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Phil Le Clercq <[e-mail]>
Subject: RE: (usr-tc) DLL Invalid
Date: 27 Aug 1999 16:51:30 +0100

Cheers for that Krish, I'll spend some more time on the DSP and see how it
goes.
Thanks, Phil

-----Original Message-----
Sent: Friday, August 27, 1999 4:39 AM
Cc: TCH List (E-mail)


On Fri, 27 Aug 1999, Phil Le Clercq wrote:

> Cheers, but the call never completes. The only thing that comes up is
this,
> it never gets to the ppp stage.
> The client gets the "You have been disconnected from the computer you
> dialled....)
> So which do I have setup incorrectly DSP or ARC, I presumed the ARC?

When a user dials to the chassis, the call is first answered by the DSP -
at that time the arc knows that a modem is trying to connect and it puts
the DLL in invalid state.

From your statement above it looks like that the modems never connect and
establish carrier.  If they did then you would see ppp data.  Now we need
to knwo the DSP setup and make sure that they are setup properlly - DNIS
digits/ Span level things etc, to start off and debug the dsp why the
call did not connect.

First would need to know what version of DSP code and would suggest to
open a ticket as well to have a tech look at the same.

regards

krish

> Thanks, Phil
>
> -----Original Message-----
> From: Tatai SV Krishnan [mailto:[e-mail]]
> Sent: Friday, August 27, 1999 4:23 AM
> To: Phil Le Clercq
> Cc: TCH List (E-mail)
> Subject: Re: (usr-tc) DLL Invalid
>
>
> You will see the DLL invalid - until the PPP has started and finished
> IPCP - Till that period of time the ARC does not know if the call is ppp
> or shell etc, so it marks the call a Invalid
>
>
> krish
>
> -----------------------------------------
>         \    T.S.V. Krishnan  \
>          \      Network System Engineer \ ( : - : )
>           \     3Com ............   \
>         ----------------------------------------------/
> [e-mail]
> ----------------------------/ http://interproc.ae.usr.com ----/
> -------------------------------------------------------------------------\
>     Any Sufficiently advanced bug is indistinguishable for a feature.
>                         - Rick Kulawiec
> -------------------------------------------------------------------------/
>
> On Fri, 27 Aug 1999, Phil Le Clercq wrote:
>
> > Hi all, just setting up some Arcs for the first time, the DSP answers
the
> > call ok and starts negotiating..well it sounds ok.
> > PPP never quite gets to the arc..I get this..
> >
> >                                                         Start
Start
> > IfName          User Name                   Type   DLL  Date        Time
> > slot:1/mod:2                                DIALIN INVALID 00-   -0000
> > 00:00:00
> >
> >
> > Dll Invalid, It's probably something really basic I am missing, but at
the
> > moment I'm stumped. Help much appreciated.
> > Thanks Phil
> >
> > -
> >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> >  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 "[e-mail]"
>  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 "[e-mail]"
 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: das <[e-mail]>
Subject: Re: (usr-tc) DLL Invalid
Date: 28 Aug 1999 01:41:55 +0900

I would always get that when I would have the switch type set incorrectly
on the dsp card.

das

Phil Le Clercq ([e-mail]) spake:

> Cheers for that Krish, I'll spend some more time on the DSP and see how it
> goes.
> Thanks, Phil
>
> -----Original Message-----
> From: Tatai SV Krishnan [mailto:[e-mail]]
> Sent: Friday, August 27, 1999 4:39 AM
> To: Phil Le Clercq
> Cc: TCH List (E-mail)
> Subject: RE: (usr-tc) DLL Invalid
>
>
> On Fri, 27 Aug 1999, Phil Le Clercq wrote:
>
> > Cheers, but the call never completes. The only thing that comes up is
> this,
> > it never gets to the ppp stage.
> > The client gets the "You have been disconnected from the computer you
> > dialled....)
> > So which do I have setup incorrectly DSP or ARC, I presumed the ARC?
>
> When a user dials to the chassis, the call is first answered by the DSP -
> at that time the arc knows that a modem is trying to connect and it puts
> the DLL in invalid state.
>
> >From your statement above it looks like that the modems never connect and
> establish carrier.  If they did then you would see ppp data.  Now we need
> to knwo the DSP setup and make sure that they are setup properlly - DNIS
> digits/ Span level things etc, to start off and debug the dsp why the
> call did not connect.
>
> First would need to know what version of DSP code and would suggest to
> open a ticket as well to have a tech look at the same.
>
> regards
>
> krish
>
> > Thanks, Phil
> >
> > -----Original Message-----
> > From: Tatai SV Krishnan [mailto:[e-mail]]
> > Sent: Friday, August 27, 1999 4:23 AM
> > To: Phil Le Clercq
> > Cc: TCH List (E-mail)
> > Subject: Re: (usr-tc) DLL Invalid
> >
> >
> > You will see the DLL invalid - until the PPP has started and finished
> > IPCP - Till that period of time the ARC does not know if the call is ppp
> > or shell etc, so it marks the call a Invalid
> >
> >
> > krish
> >
> > -----------------------------------------
> >         \    T.S.V. Krishnan  \
> >          \      Network System Engineer \ ( : - : )
> >           \     3Com ............   \
> >         ----------------------------------------------/
> > [e-mail]
> > ----------------------------/ http://interproc.ae.usr.com ----/
> > -------------------------------------------------------------------------\
> >     Any Sufficiently advanced bug is indistinguishable for a feature.
> >                         - Rick Kulawiec
> > -------------------------------------------------------------------------/
> >
> > On Fri, 27 Aug 1999, Phil Le Clercq wrote:
> >
> > > Hi all, just setting up some Arcs for the first time, the DSP answers
> the
> > > call ok and starts negotiating..well it sounds ok.
> > > PPP never quite gets to the arc..I get this..
> > >
> > >                                                         Start
> Start
> > > IfName          User Name                   Type   DLL  Date        Time
> > > slot:1/mod:2                                DIALIN INVALID 00-   -0000
> > > 00:00:00
> > >
> > >
> > > Dll Invalid, It's probably something really basic I am missing, but at
> the
> > > moment I'm stumped. Help much appreciated.
> > > Thanks Phil
> > >
> > > -
> > >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> > >  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 "[e-mail]"
> >  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 "[e-mail]"
>  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.

--
____________________________________________
Alex Substanley       Global OnLine Japan
                Engineering Department
Das Man               TEL: [phone]
Systems Engineer      FAX: [phone]
  The Highest Quality Service, Bar None
____________________________________________

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Brian A. Buffington" <[e-mail]>
Subject: Re: (usr-tc) HiPerDSP 2.0.81 and 2.0.19 differences ?
Date: 27 Aug 1999 10:55:51 -0600

> >Where was it I saw that Rockwell specifically made their modems hang up
> >after three speed shifts... it would certainly explain their disconnect
> >patterns...
>     Rockwells retrain 3 times total, after that the connection will drop.

From the USR-TC mailing list... He's talking about the Rockwell HCF
modems that I hate so much and cause no end of grief for us.  This would
certainly explain why users with this type of modem seem to be in the
majority of complainants.  Apparently Lucent LT Winmodems with the
latest drivers from 808hi.com are fairly stable but only if they are
using those latest drivers.

--Brian

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) TRAPS
Date: 27 Aug 1999 16:43:22 -0400 (EDT)

Done.  Actually the DSP's need to be set, not the NMC (other then enable
traps and trap dest).  So yes, it is done.  I get some traps... only a
small percentage.  like 50 out of 700 or 800.

Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax [phone]
[e-mail]

On Fri, 27 Aug 1999, Jeff Mcadams wrote:

> Thus spake Paul Farber
> > Anyone ever figure out why TCM will show connection failures but the
> > ARC not throw a trap for them?
>
> Uhm...because the Arc isn't responsible for modem handshaking, the modem
> card is.  If you want to see call failure traps, you need to set up
> logging (either radius, or snmp traps) from the NMC card and enable the
> mdmTeConnAttemptFailure trap.  This will generate an event on the modem
> card, which the NMC can then generate a trap or radius log from.
> --
> Jeff McAdams                            Email: [e-mail]
> Head Network Administrator              Voice: [phone]
> IgLou Internet Services                        [phone]
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: "Richard Gamberg" <[e-mail]>
Subject: (usr-tc) V.90 delivering "as promised"
Date: 27 Aug 1999 11:12:35 -1000

I guess all you ISPs, along with the 30-40% of 56k modem owners I estimate
aren't getting 56k connects, will be happy to learn that a new Inverse study
says V.90 is now delivering as promised. They peg the no-56k number at 6.4%,
and imply that average '56k' throughput equivalent to a 38k connect (even
though the modem reports an average of 46k) is the V.90 promise.

http://808hi.com/56k/latest.htm
http://www.inversenet.com/news/pr/19990823.html

Some "real" numbers:
http://808hi.com/56k/ltsurvey.htm
http://808hi.com/56k/hcfsurvey.htm
http://808hi.com/56k/3comsurvey.htm
http://808hi.com/56k/what56.htm

Aloha,
Richard
56k=v.Unreliable - http://808hi.com/56k/


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Peter Olson <[e-mail]>
Subject: Re: (usr-tc) V.90 delivering "as promised"
Date: 27 Aug 1999 17:25:24 -0500

USR-TC list,
Without information about where they got their numbers, their methodologies or
location, I have to say their numbers are probably skewed in favor of V.90. In
my experience supporting only 600 roaming users on all 3COM equipment in the
Chicago area, we are seeing slightly slower average connections. Over half of
our users don't get v.90 connections at all. We are using ISDN-PRI / HiperDSP
1.2.59 code for now. Perhaps some of this could be improved when we make it to
the 2.0 code.

Average   36014 Kbps
Start date     9-Feb-99
end date  5-Aug-99
Median    33300 Kbps
Sample Size    12296 Connections
Mode      26400 Kbps
1200-33600     6366 Connections
33600-56K 5930 Connections
%v.34          51.77%
%v.90          48.23%

I am certain that some ISP's have much more information available, with less
brand specificity and numbers relative to the newest firmware.

Later,
--Peter



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Aaron Nabil <[e-mail]>
Subject: Re: (usr-tc) B8ZS vs AMI (Repost)
Date: 27 Aug 1999 23:03:25 -0700 (PDT)

Jeff Lynch writes...
>
>On Thu, 26 Aug 1999, Stainforth, Matthew wrote:
>
>>
>> I was told by a 3Com phone tech that PRIs MUST be ESF and B8ZS...but that
>> might just be verbal fluff.
>
>The probability of transmitting a zero-byte on the D-channel is an almost
>certain probability. How many phone numbers (calling-station and
>called-station) have a 0 in them? Too many to mention. Thus B8ZS is
>essentially a requirement if you adhere strictly to protocol standards.

I'm on vacation, and dialing (?) in via a CPDP network, so I don't have
access to my reference materials, but I'm almost certain that the D
channel is bit-inverted HDLC, which would make an entire 0 word a
total impossibility.


--
Aaron Nabil

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 Lynch <[e-mail]>
Subject: Re: (usr-tc) B8ZS vs AMI (Repost)
Date: 28 Aug 1999 09:09:08 -0500 (CDT)

On Fri, 27 Aug 1999, Aaron Nabil wrote:

> I'm on vacation, and dialing (?) in via a CPDP network, so I don't have
> access to my reference materials, but I'm almost certain that the D
> channel is bit-inverted HDLC, which would make an entire 0 word a
> total impossibility.

Hmm, I didn't remember bit inversion, but I'll take your word for it
because it makes sense to make zero-byte transmission impossible or at
least highly improbable. I suspect it's the latter since HDLC does bit
stuffing at 6 consecutive ones, so 0xff, 0xfe, or 0x8f stuffed and
inverted could trigger a zerobyte transmission. Of course it would have to
be aligned within a DS0 channel. This alone covers the highly improbable
case but I don't remember an illegal value restriction in the Q.931/I.451
spec to cover the impossible case. It's been too long since I examined it
and I don't really want to check, but if you do, it'd be kinda cool to
know in a geeky sort of way ;), but perhaps off list.

Regards,
--jeff

============================================================================
Jeffrey A. Lynch        | JORSM Internet, Regional Internet Services
email: [e-mail]        | 7 Area Codes in Chicagoland and NW Indiana
Voice: [phone]        | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN
Autoresponse: [e-mail]    | Quality Service, Affordable Prices
http://www.jorsm.com        | Serving Gov, Biz, Indivds Since 1995


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: K Mitchell <[e-mail]>
Subject: (usr-tc) Keep-alive traffic?
Date: 29 Aug 1999 21:35:45 -0400

Monitoring a connection that's been alive for about 10 hours, the only
thing I get is the following at about .5 second intervals. Keep-alive, or no?

Incoming PPP Data on interface: slot:1/mod:5
    21 45 00 00 3c 6b 90 00 00 20 01 90 76 cc ab 1f |!E  <k      v   |
    77 d0 8a e2 0d 08 00 24 e4 01 00 27 78 61 62 63 |w      $   'xabc|
    64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 |defghijklmnopqrs|
    74 75 76 77 61 62 63 64 65 66 67 68 69          |tuvwabcdefghi   |


Outgoing PPP Data on interface: slot:1/mod:5
    21 45 00 00 3c 35 6d 00 00 6e 01 78 99 d0 8a e2 |!E  <5m  n x    |
    0d cc ab 1f 77 00 00 2c e4 01 00 27 78 61 62 63 |    w  ,   'xabc|
    64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 |defghijklmnopqrs|
    74 75 76 77 61 62 63 64 65 66 67 68 69          |tuvwabcdefghi   |


Incoming PPP Data on interface: slot:1/mod:5
    21 45 00 00 3c 6c 90 00 00 20 01 8f 76 cc ab 1f |!E  <l      v   |
    77 d0 8a e2 0d 08 00 23 e4 01 00 28 78 61 62 63 |w      #   (xabc|
    64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 |defghijklmnopqrs|
    74 75 76 77 61 62 63 64 65 66 67 68 69          |tuvwabcdefghi   |


Outgoing PPP Data on interface: slot:1/mod:5
    21 45 00 00 3c 63 6d 00 00 6e 01 4a 99 d0 8a e2 |!E  <cm  n J    |
    0d cc ab 1f 77 00 00 2b e4 01 00 28 78 61 62 63 |    w  +   (xabc|
    64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 |defghijklmnopqrs|
    74 75 76 77 61 62 63 64 65 66 67 68 69          |tuvwabcdefghi   |


Incoming PPP Data on interface: slot:1/mod:5
    21 45 00 00 3c 6d 90 00 00 20 01 8e 76 cc ab 1f |!E  <m      v   |
    77 d0 8a e2 0d 08 00 22 e4 01 00 29 78 61 62 63 |w      "   )xabc|
    64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 |defghijklmnopqrs|
    74 75 76 77 61 62 63 64 65 66 67 68 69          |tuvwabcdefghi   |


Outgoing PPP Data on interface: slot:1/mod:5
    21 45 00 00 3c 91 6d 00 00 6e 01 1c 99 d0 8a e2 |!E  < m  n      |
    0d cc ab 1f 77 00 00 2a e4 01 00 29 78 61 62 63 |    w  *   )xabc|
    64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 |defghijklmnopqrs|
    74 75 76 77 61 62 63 64 65 66 67 68 69          |tuvwabcdefghi   |

Thanks,
Kirk


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


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Mike Andrews <[e-mail]>
Subject: Re: (usr-tc) Keep-alive traffic?
Date: 29 Aug 1999 22:39:08 -0400 (EDT)

It looks like they're pinging 208.138.226.13.

I'd call that a keepalive...


Mike Andrews (MA12) -=-=-  VP & Sysadmin, Digital Crescent, Frankfort KY
[e-mail]  -=--=-  [e-mail]  -=--=-  http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."

On Sun, 29 Aug 1999, K Mitchell wrote:

> Monitoring a connection that's been alive for about 10 hours, the only
> thing I get is the following at about .5 second intervals. Keep-alive, or no?
>
> Incoming PPP Data on interface: slot:1/mod:5
>     21 45 00 00 3c 6b 90 00 00 20 01 90 76 cc ab 1f |!E  <k      v   |
>     77 d0 8a e2 0d 08 00 24 e4 01 00 27 78 61 62 63 |w      $   'xabc|
>     64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 |defghijklmnopqrs|
>     74 75 76 77 61 62 63 64 65 66 67 68 69          |tuvwabcdefghi   |
>
>
> Outgoing PPP Data on interface: slot:1/mod:5
>     21 45 00 00 3c 35 6d 00 00 6e 01 78 99 d0 8a e2 |!E  <5m  n x    |
>     0d cc ab 1f 77 00 00 2c e4 01 00 27 78 61 62 63 |    w  ,   'xabc|
>     64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 |defghijklmnopqrs|
>     74 75 76 77 61 62 63 64 65 66 67 68 69          |tuvwabcdefghi   |
>
>
> Incoming PPP Data on interface: slot:1/mod:5
>     21 45 00 00 3c 6c 90 00 00 20 01 8f 76 cc ab 1f |!E  <l      v   |
>     77 d0 8a e2 0d 08 00 23 e4 01 00 28 78 61 62 63 |w      #   (xabc|
>     64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 |defghijklmnopqrs|
>     74 75 76 77 61 62 63 64 65 66 67 68 69          |tuvwabcdefghi   |
>
>
> Outgoing PPP Data on interface: slot:1/mod:5
>     21 45 00 00 3c 63 6d 00 00 6e 01 4a 99 d0 8a e2 |!E  <cm  n J    |
>     0d cc ab 1f 77 00 00 2b e4 01 00 28 78 61 62 63 |    w  +   (xabc|
>     64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 |defghijklmnopqrs|
>     74 75 76 77 61 62 63 64 65 66 67 68 69          |tuvwabcdefghi   |
>
>
> Incoming PPP Data on interface: slot:1/mod:5
>     21 45 00 00 3c 6d 90 00 00 20 01 8e 76 cc ab 1f |!E  <m      v   |
>     77 d0 8a e2 0d 08 00 22 e4 01 00 29 78 61 62 63 |w      "   )xabc|
>     64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 |defghijklmnopqrs|
>     74 75 76 77 61 62 63 64 65 66 67 68 69          |tuvwabcdefghi   |
>
>
> Outgoing PPP Data on interface: slot:1/mod:5
>     21 45 00 00 3c 91 6d 00 00 6e 01 1c 99 d0 8a e2 |!E  < m  n      |
>     0d cc ab 1f 77 00 00 2a e4 01 00 29 78 61 62 63 |    w  *   )xabc|
>     64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 |defghijklmnopqrs|
>     74 75 76 77 61 62 63 64 65 66 67 68 69          |tuvwabcdefghi   |
>


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: K Mitchell <[e-mail]>
Subject: Re: (usr-tc) Keep-alive traffic?
Date: 29 Aug 1999 23:15:47 -0400

At 10:39 PM 8/29/99 -0400, you wrote:
>It looks like they're pinging 208.138.226.13.
>
>I'd call that a keepalive...

That's what I figured. Is 76 cc ab 1f 208.138.226.13 or is 99 d0 8a e2 and,
are there any utilities that converts it fairly easily for the
binary-impaired?

Thanks,
Kirk

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


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: K Mitchell <[e-mail]>
Subject: Re: (usr-tc) Keep-alive traffic?
Date: 29 Aug 1999 23:36:54 -0400

At 11:15 PM 8/29/99 -0400, I wrote:
>At 10:39 PM 8/29/99 -0400, you wrote:
>>It looks like they're pinging 208.138.226.13.
>>
>>I'd call that a keepalive...
>
>That's what I figured. Is 76 cc ab 1f 208.138.226.13 or is 99 d0 8a e2 and,
>are there any utilities that converts it fairly easily for the
>binary-impaired?

I guess that should be cc ab lf 77  and  d0 8a e2 0d  :)

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


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Mike Andrews <[e-mail]>
Subject: Re: (usr-tc) Keep-alive traffic?
Date: 30 Aug 1999 01:49:32 -0400 (EDT)

On Sun, 29 Aug 1999, K Mitchell wrote:

> >That's what I figured. Is 76 cc ab 1f 208.138.226.13 or is 99 d0 8a e2 and,
> >are there any utilities that converts it fairly easily for the
> >binary-impaired?
>
> I guess that should be cc ab lf 77  and  d0 8a e2 0d  :)

Yeah.  It's just a raw IP packet with 0x21 glued on the front.  I just
used the chart inside the front cover "TCP/IP Illustrated, Volume 1"
(Stevens) to decode the packet by hand.  Src/dst addresses are near the
front of the packet.

hex-to-decimal conversions are just one line of perl or shell code.

I haven't written a utility because I just use tcpdump from another (Unix)
machine for this sort of thing -- and let it do all the decoding of IP.
(As long as you don't have a switch in the way.)  I guess a ppp decoder
ring sorta like the one Livingston had on their website for ComOS output
might be useful for those who are stuck without a sniffer.  (Which makes
no sense to me -- almost every Unix has one, and Microsoft has one for NT
somewhere...)


Mike Andrews (MA12) -=-=-  VP & Sysadmin, Digital Crescent, Frankfort KY
[e-mail]  -=--=-  [e-mail]  -=--=-  http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: (usr-tc) SNMP OID to reset card
Date: 30 Aug 1999 10:05:51 -0400 (EDT)

Hello all...

What OID can I send to reset a DSP?

Where can I get a good, up to date reference of the SNMP OID's for the
DSP's?

Is there a LINUX version of TCM yet?  I remember a list post to mail a guy
at 3Com... and luck yet?

Has anyone got TCM to run under X w/Wine?

Thanks.

Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax [phone]
[e-mail]


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Nicolas St-Pierre <[e-mail]>
Subject: Re: (usr-tc) TCM under X/Wine
Date: 30 Aug 1999 10:58:51 -0400

Paul Farber wrote:
>
> Has anyone got TCM to run under X w/Wine?
>
> Thanks.
>

I never was able to run it under Wine because of a SNMP API error.
However, it works great under Vmware, I do most of the TCM management
under Linux/X11 with Vmware.

Nick
--
Nicolas St-Pierre
Systems Engineer
Internet Access Solutions Ltd.
Tel [phone]
Fax [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Steve Valiunas" <[e-mail]>
Subject: Re: (usr-tc) radius authentication problem with harc
Date: 30 Aug 1999 10:09:30 -0500



Verify that the accounting secrets match between radius and the Harc- (there is
none by default on the Harc).

     STeve




das <[e-mail]> on 08/26/99 09:31:50 PM

Please respond to [e-mail]

Sent by:  das <[e-mail]>


cc:    (Steve Valiunas/MW/US/3Com)




Hi,

I am experiencing some weird entries in my radius logs from a new hiperarc
running 4.1.59.

I keep seeing this entry repeated time and time again:

accounting: client XXX sent accounting-request with invalid request
authenticator

Does anyone have any idea what this pertains to?  We are running a hacked
version of Livingston radius.

Thanks,

das

--
____________________________________________
Alex Substanley       Global OnLine Japan
                Engineering Department
Das Man               TEL: [phone]
Systems Engineer      FAX: [phone]
  The Highest Quality Service, Bar None
____________________________________________

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) TCM under X/Wine
Date: 30 Aug 1999 13:54:30 -0400 (EDT)

Do you have a link to Vmware???

I got the same SNMP error.  The np_msx32.exe (or whatever it was) will
run.. but there seems to be no DDE/OLE between the two apps.

Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax [phone]
[e-mail]

On Mon, 30 Aug 1999, Nicolas St-Pierre wrote:

> Paul Farber wrote:
> >
> > Has anyone got TCM to run under X w/Wine?
> >
> > Thanks.
> >
>
> I never was able to run it under Wine because of a SNMP API error.
> However, it works great under Vmware, I do most of the TCM management
> under Linux/X11 with Vmware.
>
> Nick
> --
> Nicolas St-Pierre
> Systems Engineer
> Internet Access Solutions Ltd.
> Tel [phone]
> Fax [phone]
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: Pete Ashdown <[e-mail]>
Subject: Re: (usr-tc) SNMP OID to reset card
Date: 30 Aug 1999 11:55:12 -0600 (MDT)

Paul Farber said once upon a time:

>Is there a LINUX version of TCM yet?  I remember a list post to mail a guy
>at 3Com... and luck yet?

I had a long discussion with the person in charge of development.  He
placed a survey on the list that polled interest in regards to a Linux
version.  He didn't get a strong response, and was put off by the fact that
people think TCM would be a better product if it was open source.  Based on
this, I don't think TCM Linux is a strong bet.  3com appears to be happy to
stick their head in the sand for a few more years based on an informal
poll.

What baffles me is that they insist on still making the HPUX version.  Do
they honestly believe that more ISPs/sysadmins are using HPUX than Linux?

>Has anyone got TCM to run under X w/Wine?

No, but I use it under Solaris and X.  The Solaris version is significantly
better than the Windoze version.  Its worth buying a cheap IPX for the sole
purpose of running TCM.

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Jamie Orzechowski" <[e-mail]>
Subject: (usr-tc) TCM Probs
Date: 30 Aug 1999 14:45:45 -0400

I got a very strange problem with TCM 6.0.23 for win ...

I use TCM without any problems ... when I updated my HARC to 4.1.29 and TCM
gives me an "Unable to initialze TL" error or something along those lines
.... I then downgraded my HARC to 4.1.59-6 and still get the same error ...
I uninstalled, remobed regkeys, extra .ini's sitting around and still
nothing ... I install TCM on another machine and it's fine ... any ideas??

----- Original Message -----
Sent: Monday, August 30, 1999 1:54 PM


> Do you have a link to Vmware???
>
> I got the same SNMP error.  The np_msx32.exe (or whatever it was) will
> run.. but there seems to be no DDE/OLE between the two apps.
>
> Paul D. Farber II
> Farber Technology
> Ph. 570-628-5303
> Fax [phone]
> [e-mail]
>
> On Mon, 30 Aug 1999, Nicolas St-Pierre wrote:
>
> > Paul Farber wrote:
> > >
> > > Has anyone got TCM to run under X w/Wine?
> > >
> > > Thanks.
> > >
> >
> > I never was able to run it under Wine because of a SNMP API error.
> > However, it works great under Vmware, I do most of the TCM management
> > under Linux/X11 with Vmware.
> >
> > Nick
> > --
> > Nicolas St-Pierre
> > Systems Engineer
> > Internet Access Solutions Ltd.
> > Tel [phone]
> > Fax [phone]
> >
> > -
> >  To unsubscribe to usr-tc, send an email to "[e-mail]"
> >  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 "[e-mail]"
>  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 "[e-mail]"
 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: "Russ Miescke" <[e-mail]>
Subject: (usr-tc) IP Spoofing
Date: 30 Aug 1999 14:02:32 -0700

How do I keep people from spoofing an IP address on the TC hub.
I know there is an option, but can't find it for the life of me.

Russ Miescke
Power Web Connect


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Stainforth, Matthew" <[e-mail]>
Subject: (usr-tc) DSPs, NFAS, 1 ARC
Date: 30 Aug 1999 16:31:54 -0300


I had an interesting thing happen today.  I amalgamated a bunch of our trunk
groups onto a single chassis with 9 DSPs and 1 ARC (130 AMP, HiPerNMC if
that matters).  The cards began filling up and when calls started hitting
the sixth card we started getting random busies, both fast and slow,
sometimes even dead air.  The first six cards are set up in 3 trunk groups,
each having 1 D channel per group.  So cards 1 and 2 share a D channel, 3
and 4, and so on.  The switch is set to round robin the calls so the groups
fill up more or less evenly.  The DSP in slot 6 would only fill to less than
half full and then start sending back a reorder.  Having tried everything I
know of, I finally moved the cards to a different chassis.  At that point
the trunk group started working again.  Here are the things I tried before
moving the cards:

soft busy/restore to service
hard busy/restore to service
reboot
restore T1/modems from NVRAM, save to NVRAM, reboot
restore T1/modems from default, reconfigure, save to NVRAM, reboot
replaced DSP NIC and NAC with brand new one from the shelf, flash, reconfig,
save to NVRAM, reboot
moved funky DSP from slot 6 to slot 12

Nothing would work except moving the cards to a different chassis.

Could this possibly be related to only having one ARC in the chassis?  I am
not running IPX or routing protocols at all.  All the DSPs are at software
version 2.0.81, ARC at 4.1.59-6.  The HiPerNMC is also running the latest
TCS 3.6 code.

Any ideas why this might be?

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Jack Singer" <[e-mail]>
Subject: (usr-tc) Need used TC Units
Date: 30 Aug 1999 15:56:18 -0400

Wanted to buy, used Total Control units, prefer X2 or V.90 upgraded.  I need
eight or more units, so if you have one or more, please email or call me
directly.

Internet Connections
6008 Hermitage Road
Richmond, VA  23228
[phone]
[e-mail]


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Steve Rivera <[e-mail]>
Subject: (usr-tc) WTB: Hyper DSP card
Date: 30 Aug 1999 16:13:00 -0400

I am looking to BUY a used Hyper DSP modem cards.
must include NAC and NIC.

Guaranteed working.
....................................................
Steve Rivera - VP-WR Consultant Associates, Inc. (WRCA)
[e-mail]  v-732-833-2111 pgr-732-325-1092

WAN ACCESS SPECIALIST---http://www.wrca.net (CompleteLine Card)
Cisco, Ascend,USR,Adtran, Kentrox,Livingston, Microcom,Computone,Verilink
IBM,Motorola,UDS,Codex,ATT/Paradyne,Hayes,Racal Datacom,GDC,Telebit
MultiTech,Sync/Tylink,Wellfleet,BayNetworks(5399),Black Box,Micom & More










-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Jamie Orzechowski" <[e-mail]>
Subject: (usr-tc) IPX Usage
Date: 30 Aug 1999 16:19:44 -0400

I am running ARC 4.1.59-6 and have a quick question

if I do a "show user default aLL_SETTINGS"

and I get the following

IPX Usage:                                 ENABLED
IPX Address:                               00000000
IPX Routing:                               RESPOND
IPX WAN Usage:                             DISABLED
IPX RIP Update:                            60 seconds
IPX RIP Age Multiplier:                    4
IPX SAP Update:                            60 seconds
IPX SAP Age Multiplier:                    4

how do I DISABLE IPX for the user "default" ... I can;t seem to find the
command ... also how do I disable IPX system wide ??


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Jamie Orzechowski" <[e-mail]>
Subject: Re: (usr-tc) IP Spoofing
Date: 30 Aug 1999 16:21:33 -0400

set nework user default spoofing enable/disable

----- Original Message -----
Sent: Monday, August 30, 1999 5:02 PM


> How do I keep people from spoofing an IP address on the TC hub.
> I know there is an option, but can't find it for the life of me.
>
> Russ Miescke
> Power Web Connect
>
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) SNMP OID to reset card
Date: 30 Aug 1999 16:26:11 -0400 (EDT)

If thety released the code I'm sure that someone would do it for free.

Running under WINE won't work.. thier SNMP app and tcm can't DDE (my
guess).

Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax [phone]
[e-mail]

On Mon, 30 Aug 1999, Pete Ashdown wrote:

> Paul Farber said once upon a time:
>
> >Is there a LINUX version of TCM yet?  I remember a list post to mail a guy
> >at 3Com... and luck yet?
>
> I had a long discussion with the person in charge of development.  He
> placed a survey on the list that polled interest in regards to a Linux
> version.  He didn't get a strong response, and was put off by the fact that
> people think TCM would be a better product if it was open source.  Based on
> this, I don't think TCM Linux is a strong bet.  3com appears to be happy to
> stick their head in the sand for a few more years based on an informal
> poll.
>
> What baffles me is that they insist on still making the HPUX version.  Do
> they honestly believe that more ISPs/sysadmins are using HPUX than Linux?
>
> >Has anyone got TCM to run under X w/Wine?
>
> No, but I use it under Solaris and X.  The Solaris version is significantly
> better than the Windoze version.  Its worth buying a cheap IPX for the sole
> purpose of running TCM.
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
 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: "Andrew:PC Global, Inc." <[e-mail]>
Subject: Re: (usr-tc) Need used TC Units
Date: 30 Aug 1999 14:55:48 -0700

Can you use v.34 token ring chassis?


Andrew Shlensky
****************************
PC Global, Inc.
[phone] office (NEW TEL NUMBER!)
[phone] fax
[phone] mobile
New!e-mail my mobile http://www.nextel.com/paging
URL:     http://www.pcglobal.net
E-MAIL: [e-mail]
ICQ:       21219089
Computer Service Parts SpEciaLiSts!
Leader in New/Used PCs,Laptops
Communication & Networking,Monitors
Printers, Hard Drives, Midrange/Mainframe.
Hard to Get Parts.  We buy and sell all
types of  GEAR-
****************************
----- Original Message -----
Sent: Monday, August 30, 1999 12:56 PM


Wanted to buy, used Total Control units, prefer X2 or V.90 upgraded.  I need
eight or more units, so if you have one or more, please email or call me
directly.

Internet Connections
6008 Hermitage Road
Richmond, VA  23228
[phone]
[e-mail]


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 "[e-mail]"
 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: Aaron Nabil <[e-mail]>
Subject: Re: (usr-tc) IP Spoofing
Date: 30 Aug 1999 15:07:38 -0700 (PDT)


I'm almost sure that's wrong.  I think it's something like...

set net user default ppp_source_ip_filter enable

although there might be a global switch you can flip.  The
radius attribute does not work.


Jamie Orzechowski writes...
>set nework user default spoofing enable/disable
>
>----- Original Message -----
>From: Russ Miescke <[e-mail]>
>To: <[e-mail]>
>Sent: Monday, August 30, 1999 5:02 PM
>Subject: (usr-tc) IP Spoofing
>
>
>> How do I keep people from spoofing an IP address on the TC hub.
>> I know there is an option, but can't find it for the life of me.
>>
>> Russ Miescke
>> Power Web Connect

--
Aaron Nabil

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Jack Singer" <[e-mail]>
Subject: Re: (usr-tc) Need used TC Units
Date: 30 Aug 1999 21:52:58 -0400

If it is cheap enough....

Jack

"Andrew:PC Global, Inc." wrote:

> Can you use v.34 token ring chassis?
>
> Andrew Shlensky
> ****************************
> PC Global, Inc.
> [phone] office (NEW TEL NUMBER!)
> [phone] fax
> [phone] mobile
> New!e-mail my mobile http://www.nextel.com/paging
> URL:     http://www.pcglobal.net
> E-MAIL: [e-mail]
> ICQ:       21219089
> Computer Service Parts SpEciaLiSts!
> Leader in New/Used PCs,Laptops
> Communication & Networking,Monitors
> Printers, Hard Drives, Midrange/Mainframe.
> Hard to Get Parts.  We buy and sell all
> types of  GEAR-
> ****************************
> ----- Original Message -----
> From: Jack Singer <[e-mail]>
> To: <[e-mail]>
> Sent: Monday, August 30, 1999 12:56 PM
> Subject: (usr-tc) Need used TC Units
>
> Wanted to buy, used Total Control units, prefer X2 or V.90 upgraded.  I need
> eight or more units, so if you have one or more, please email or call me
> directly.
>
> Internet Connections
> 6008 Hermitage Road
> Richmond, VA  23228
> [phone]
> [e-mail]
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
>  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 "[e-mail]"
 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: Phil Le Clercq <[e-mail]>
Subject: (usr-tc) Mr. PC Global and his Spam
Date: 31 Aug 1999 09:20:52 +0100

Has anyone else on the TCH list received the below spam from pcglobal? The
only way my email address would have been nabbed would be from this TCH
list. I am formally asking pcglobal to refrain from using these mailing
techniques, this was not the reason for which I joined this list and believe
it to be bang out of order. Please don't do it again.
Phil Le Clercq

"Dear Subscriber,
You have been asked to be added to our Huge Inventory list. This list will
be updated to alert you as we receive in the quantites of computer hardware
we notified you of.

We just received in the following- We wish to move the lots of equipment as
specified in the category:
Please submit your offer. Our decision to sell will be made by 3:00 Tuesday
Aug, 30 1999
As always, all items are in stock, in OUR inventory. No middlemen, brokers
involved.

All items FOB Phoenix, AZ

PRINTERS:
(2) Lexmark Optra R+ W/Duplexer.......more crap

........(15) HP Vectra VL90
(20) ATT Globalyst 520
(30) assorted 486 notebooks color/mono

PC Global, Inc
[phone] Tel
[phone] Fax

Customer relations
Inventory logistics"

-----Original Message-----
Sent: Tuesday, August 31, 1999 2:53 AM


If it is cheap enough....

Jack

"Andrew:PC Global, Inc." wrote:

> Can you use v.34 token ring chassis?
>
> Andrew Shlensky
> ****************************
> PC Global, Inc.
> [phone] office (NEW TEL NUMBER!)
> [phone] fax
> [phone] mobile
> New!e-mail my mobile http://www.nextel.com/paging
> URL:     http://www.pcglobal.net
> E-MAIL: [e-mail]
> ICQ:       21219089
> Computer Service Parts SpEciaLiSts!
> Leader in New/Used PCs,Laptops
> Communication & Networking,Monitors
> Printers, Hard Drives, Midrange/Mainframe.
> Hard to Get Parts.  We buy and sell all
> types of  GEAR-
> ****************************
> ----- Original Message -----
> From: Jack Singer <[e-mail]>
> To: <[e-mail]>
> Sent: Monday, August 30, 1999 12:56 PM
> Subject: (usr-tc) Need used TC Units
>
> Wanted to buy, used Total Control units, prefer X2 or V.90 upgraded.  I
need
> eight or more units, so if you have one or more, please email or call me
> directly.
>
> Internet Connections
> 6008 Hermitage Road
> Richmond, VA  23228
> [phone]
> [e-mail]
>
> -
>  To unsubscribe to usr-tc, send an email to "[e-mail]"
>  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 "[e-mail]"
>  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 "[e-mail]"
 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 "[e-mail]"
 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: D Mayer <[e-mail]>
Subject: (usr-tc) Equivalent of "set reported" for HiPer ARC?
Date: 31 Aug 1999 10:00:54 -0400

Is there an equivalent of the old "set reported" NETServer command for
the HiPer ARCs?  This would be the address that the ARC reports as the
remote address in PPP negotiation.

Thanks,
Peter D. Mayer
NetWalk System Administrator
[e-mail]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Kevin Benton <[e-mail]>
Subject: Re: (usr-tc) Mr. PC Global and his Spam
Date: 31 Aug 1999 10:01:29 -0400 (EDT)

On Tue, 31 Aug 1999, Phil Le Clercq wrote:

> Has anyone else on the TCH list received the below spam from pcglobal? The
> only way my email address would have been nabbed would be from this TCH
> list. I am formally asking pcglobal to refrain from using these mailing
> techniques, this was not the reason for which I joined this list and believe
> it to be bang out of order. Please don't do it again.
> Phil Le Clercq

hahaha...  Good one...  And you thought I would bite on a silly little
spam like that.  The best way to get rid of spam is to ignore it.  If
nobody bites, the spam will be ineffective and not worth the effort.

Kevin

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


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 <[e-mail]>
Subject: Re: (usr-tc) Equivalent of "set reported" for HiPer ARC?
Date: 31 Aug 1999 10:08:31 -0400

Thus spake D Mayer
>Is there an equivalent of the old "set reported" NETServer command for
>the HiPer ARCs?  This would be the address that the ARC reports as the
>remote address in PPP negotiation.

set ip unnumbered_link local_address 204.255.239.10

--
Jeff McAdams                            Email: [e-mail]
Head Network Administrator              Voice: [phone]
IgLou Internet Services                        [phone]

-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Andrew:PC Global, Inc." <[e-mail]>
Subject: (usr-tc) Appology Mr. PC Global and his Spam
Date: 31 Aug 1999 08:06:56 -0700

List Members,
An appology to anyone who received my equipment list, it was not intentional
it was directed at a customer base but somehow, the email program I used
managed to send the mail to everyone in my deleted folder which was some of
you. I understand that you dont want to see equipment posted here. Really I
do.

I can assure you this was accidental and won't happen again. Promise. :-)

Have a good day.

Andrew Shlensky
PC Global, Inc
****************************
----- Original Message -----
Sent: Tuesday, August 31, 1999 7:01 AM


On Tue, 31 Aug 1999, Phil Le Clercq wrote:

> Has anyone else on the TCH list received the below spam from pcglobal? The
> only way my email address would have been nabbed would be from this TCH
> list. I am formally asking pcglobal to refrain from using these mailing
> techniques, this was not the reason for which I joined this list and
believe
> it to be bang out of order. Please don't do it again.
> Phil Le Clercq

hahaha...  Good one...  And you thought I would bite on a silly little
spam like that.  The best way to get rid of spam is to ignore it.  If
nobody bites, the spam will be ineffective and not worth the effort.

Kevin

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


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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 "[e-mail]"
 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: "Mike Wronski" <[e-mail]>
Subject: (usr-tc) RE:  IP Spoofing
Date: 31 Aug 1999 10:51:34 -0500

It is wrong.. the command is
"SET NET USER DEFAULT PPP_SOURCE_IP_FILTER_ENABLED"

-M


|-----Original Message-----
|From: [e-mail]
|[mailto:[e-mail]]On Behalf Of Aaron Nabil
|Sent: Monday, August 30, 1999 5:08 PM
|To: [e-mail]
|Subject: Re: (usr-tc) IP Spoofing
|
|
|
|I'm almost sure that's wrong.  I think it's something like...
|
|set net user default ppp_source_ip_filter enable
|
|although there might be a global switch you can flip.  The
|radius attribute does not work.
|
|
|Jamie Orzechowski writes...
|>set nework user default spoofing enable/disable
|>
|>----- Original Message -----
|>From: Russ Miescke <[e-mail]>
|>To: <[e-mail]>
|>Sent: Monday, August 30, 1999 5:02 PM
|>Subject: (usr-tc) IP Spoofing
|>
|>
|>> How do I keep people from spoofing an IP address on the TC hub.
|>> I know there is an option, but can't find it for the life of me.
|>>
|>> Russ Miescke
|>> Power Web Connect
|
|--
|Aaron Nabil
|
|-
| To unsubscribe to usr-tc, send an email to "[e-mail]"
| 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 "[e-mail]"
 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: Tavis Morse <[e-mail]>
Subject: (usr-tc) TC and Cistron
Date: 31 Aug 1999 13:13:28 -0400

Hello,
I'm trying to set up cistron radius to work with the HiperArc,
does anyone have this working? If so, I'm wondering what typical clients
and users file entries might look like.
I have been trying to get it working unsuccessfully for 2 days.,
so far I can't even get the radius.log to show any activity at all with the
-y flag. TCPdump shows 'datametrics' packets coming in.
TIA
Tavis Morse
Norfolk County Internet


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Steve Rivera <[e-mail]>
Subject: (usr-tc) USR Hyper Cards/Bundles & Digital Modem Wont answer ?
Date: 31 Aug 1999 13:40:19 -0400

Hello Guys, I know some of you have stated that you are not interested in
these products emails.
So since that is the case I have a tech support questions for those who
care to reply.
For those who are happy to see great deals on USR hardware I have something
in here for you too.

Part #1 Technical Assistance Needed
Have a chassis running 6 quad modem cards. 3 are analog/digital, the other
3 are just digital.
I have flashed the double sided modem cards to 6.0.6 and the single sided
cards to 6.1.6
The problem....
The an/dig cards are having no problem answering the incoming call.
However the plain digital modems wont pick up the line.
Has anyone seen problems like this? Does the code have anything to do with it?
Any suggestions would be greatly appreciated.

Part #2 Great Deals!

Prices are posted but I can work with those of you from this list.
Be sure to email or call me stating you are from USR Mailing List.

New Condition/Open Box

Spares
69-001914-00 Rev:A Hyper DSP NAC $4000/set or BO
69-001826-00 Rev:B Hyper DSP NIC

69-001574-01 Rev:7 Netserver Pri NAC $2000/set or BO
69-001003-00 Rev:3 Netserver PRI NIC

69-00790-00 Quad Digital Modems

Hyper Bundles: 2 available $45,000each or BO
New Condition/Open Box
Front-
2- PSU 130 1.009.916-01
Slot 1 - Empty
Slot 2 - Hyper DSP Card 69-001914-00 R:A
Slot 3 - Hyper DSP Card 69-001914-00 R:A
Slot 4 - Hyper DSP Card 69-001914-00 R:A
Slot 5 - Hyper DSP Card 69-001914-00 R:A
Slot 6 - Netserver PRI Card 69-001574-01 R:C w/ 35-0001-01 R:E
Slot 7 - Hyper DSP Card 69-001914-00 R:A
Slot 8 - Hyper DSP Card 69-001914-00 R:A
Slot 9 - Hyper DSP Card 69-001914-00 R:A
Slot 10 - Hyper DSP Card 69-001914-00 R:A
Slot 11 - Hyper DSP Card 69-001914-00 R:A
Slot 12 - Hyper DSP Card 69-001914-00 R:A
Slot 13 - Hyper DSP Card 69-001914-00 R:A
Slot 14 - Hyper DSP Card 69-001914-00 R:A
Slot 15 - Hyper DSP Card 69-001914-00 R:A
Slot 16 - Netserver Card 69-001574-01 R:C
Slot 17 - Network Managment Card 69-002469-00 R:6

Back-
2- DC/PSI 130A 1.009.915-01
Slot 1 - Empty
Slot 2 - Hyper DSP T1/E1 NIC 69-001826-00 R:B
Slot 3 - Hyper DSP T1/E1 NIC 69-001826-00 R:B
Slot 4 - Hyper DSP T1/E1 NIC 69-001826-00 R:B
Slot 5 - Hyper DSP T1/E1 NIC 69-001826-00 R:B
Slot 6 - High Speed WAN NIC 69-00100-000 R:F
Slot 7 - Hyper DSP T1/E1 NIC 69-001826-00 R:B
Slot 8 - Hyper DSP T1/E1 NIC 69-001826-00 R:B
Slot 9 - Hyper DSP T1/E1 NIC 69-001826-00 R:B
Slot 10 - Hyper DSP T1/E1 NIC 69-001826-00 R:B
Slot 11 - Hyper DSP T1/E1 NIC 69-001826-00 R:B
Slot 12 - Hyper DSP T1/E1 NIC 69-001826-00 R:B
Slot 13 -Hyper DSP T1/E1 NIC 69-001826-00 R:B
Slot 14 - Hyper DSP T1/E1 NIC 69-001826-00 R:B
Slot 15 -Hyper DSP T1/E1 NIC 69-001826-00 R:B
Slot 16 - High Speed WAN NIC 69-00100-000 R:F
Slot 17 - Ethernet NIC 69-000211-00 R:3

Classic TC Bundles: Qty 10,  Asking $8000 each or BO
New/Open Box Condition, all docs, original box

TC chassis w/ Dual 130A DC power
2x Dual PRI w/ nics
12x Quad Digital Modem
1x Netserver PRI w/ nic
1x NMC w/ nic
....................................................
Steve Rivera - VP-WR Consultant Associates, Inc. (WRCA)
[e-mail]  v-732-833-2111 pgr-732-325-1092

WAN ACCESS SPECIALIST---http://www.wrca.net (CompleteLine Card)
Cisco, Ascend,USR,Adtran, Kentrox,Livingston, Microcom,Computone,Verilink
IBM,Motorola,UDS,Codex,ATT/Paradyne,Hayes,Racal Datacom,GDC,Telebit
MultiTech,Sync/Tylink,Wellfleet,BayNetworks(5399),Black Box,Micom & More










-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: Igor Brezac <[e-mail]>
Subject: (usr-tc) 3com dictionary file
Date: 31 Aug 1999 19:34:05 -0400 (EDT)


Hello,

Recently we switched to Livingston Radius 2.1 for user authentication.  All
our NASs are TCH boxen.  We'd like to use the vendor specific attributes
that are used by 3com/usr.  We do not have dictionary file with USR
attributes.  Do you know if USR VSAs can be used with Livingston Radius? If
so, can some email me USR dictionary file?

Your help will be greatly appreciated.

-Igor



-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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: "Tavis Morse" <[e-mail]>
Subject: Re: (usr-tc) 3com dictionary file
Date: 01 Sep 1999 00:44:54 +03d00

Igor,
I dont know if it helps, but there is a USR dictionary file that comes with the cistron radius server. You can get it at: http://www.miquels.cistron.nl/radius/
Tavis Morse
NCI


-
 To unsubscribe to usr-tc, send an email to "[e-mail]"
 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.