August 1999

Subject: Re: (usr-tc) ATTENTION SHOPPERS - Last day for 3COM Quad Trade-up promotion, special!!
From: Ed <ed@taylors.com>
Date: 1999-07-30 20:29:26

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: usr-tc@lists.xmission.com=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) (403) 571-5000 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 "majordomo@xmission.com" = with "unsubscribe usr-tc" in the body of the 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:greg@dynavar.com" title=3Dgreg@dynavar.com>Greg = Genge</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20 href=3D"mailto:usr-tc@lists.xmission.com"=20 title=3Dusr-tc@lists.xmission.com>usr-tc@lists.xmission.com</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) (403) 571-5000 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 "majordomo@xmission.com" 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--

Subject: Re: (usr-tc) Not True - Dynavar Quad trade in deal.
From: Ed <ed@taylors.com>
Date: 1999-07-30 20:36:45

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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) (403) 571-5000 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 "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Question.
From: Paul M. Oster <devious@minot.com>
Date: 1999-08-01 11:27:47

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 <devious@minot.com> http://www.minot.com/ Magic Internet Services (701) 838-1265 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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Question.
From: John Schmerold <john@katy.com>
Date: 1999-08-01 21:05:18

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 <devious@minot.com> http://www.minot.com/ > Magic Internet Services (701) 838-1265 > 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 "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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

Subject: (usr-tc) are power supplies swapable.
From: eric@dol.net
Date: 1999-08-02 12:36:14

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 : 302-762-0375 Fax: 302-762-3462 Failure is NOT an option...

Subject: (usr-tc) HiperARC: Very bogus route accepted from dialup user even though
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-08-02 13:12:23

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

Subject: Re: (usr-tc) are power supplies swapable.
From: eric@dol.net
Date: 1999-08-02 13:16:11

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 eric@dol.net >>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: jeffm@iglou.com >Head Network Administrator Voice: (502) 966-3848 >IgLou Internet Services (800) 436-4456 > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 : 302-762-0375 Fax: 302-762-3462 Failure is NOT an option...

Subject: RE: (usr-tc) are power supplies swapable.
From: Marshall Morgan <marshall@netdoor.com>
Date: 1999-08-02 13:43:06

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: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of eric@dol.net > Sent: Monday, August 02, 1999 1:36 PM > To: usr-tc@lists.xmission.com > 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

Subject: (usr-tc) Filters on net0 question - Not filtering?
From: Suncoast Networking ISP TC List Mailbox <tclist@mail.flausa.net>
Date: 1999-08-02 13:44:39

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

Subject: RE: (usr-tc) HiperARC: Very bogus route accepted from dialup user even though supposedly not accepting routes from dialup users....
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-08-02 13:52:11

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Scott Trautman |Sent: Monday, August 02, 1999 1:12 PM |To: usr-tc@lists.xmission.com |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

Subject: Re: (usr-tc) HiperARC: Very bogus route accepted from dialup user even though
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-02 14:59:22

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) are power supplies swapable.
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-02 15:00:39

Thus spake eric@dol.net >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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) HiperARC: Very bogus route accepted from dialup user
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-08-02 15:28:08

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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) hyper arc v4.2.29 on hold
From: Rick <rallan@monmouth.com>
Date: 1999-08-02 21:43:04

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 / rick@monmouth.com | Connect to a Backbone not a Wishbone Head of Network Engineering | Monmouth Internet Corporation 732-842-5366=====extension 102 | http://www.monmouth.com -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Subject: Re: (usr-tc) hyper arc v4.2.29 on hold
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-08-03 04:11:28

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

Subject: Re: (usr-tc) hyper arc v4.2.29 on hold
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-08-03 08:19:17

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

Subject: Re: (usr-tc) hyper arc v4.2.29 on hold
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-08-03 09:27:14

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 "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the 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. 519-985-8410 >fax. 519-258-3009 > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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

Subject: Re: (usr-tc) cost of DSP
From: K Mitchell <mitch@keyconn.net>
Date: 1999-08-03 09:33:47

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 mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: Re: (usr-tc) hyper arc v4.2.29 on hold
From: Mike Andrews <mandrews@termfrost.org>
Date: 1999-08-03 09:57:49

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 mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com "If you're not part of the solution.... you're part of the precipitate."

Subject: (usr-tc) cost of DSP
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 1999-08-03 10:00:07

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

Subject: Re: (usr-tc) cost of DSP
From: Brian Elfert <brian@citilink.com>
Date: 1999-08-03 10:33:17

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

Subject: Re: (usr-tc) cost of DSP
From: Hostmaster Soho Solutions - Javier Szyszlican <root@host.net.ar>
Date: 1999-08-03 10:39:16

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 mitch@keyconn.net >Keystone Connect Unlock Your World >Altoona, PA 814-941-5000 http://www.keyconn.net > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Error Opening Device Configuration File?
From: vanhalen@coredcs.com
Date: 1999-08-03 10:55:04

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

Subject: Re: (usr-tc) hyper arc v4.2.29 on hold
From: Clayton Zekelman <clayton@mnsi.net>
Date: 1999-08-03 11:46:24

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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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. 519-985-8410 fax. 519-258-3009

Subject: Re: (usr-tc) Error Opening Device Configuration File?
From: Steve Valiunas <steve_valiunas@mw.3com.com>
Date: 1999-08-03 12:10:54

You didn't upgrade TCM, and the old TCM doesn't know about the new NMC. steve vanhalen@coredcs.com on 08/03/99 10:55:04 AM Please respond to usr-tc@lists.xmission.com Sent by: vanhalen@coredcs.com 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 "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) cost of DSP
From: K Mitchell <mitch@keyconn.net>
Date: 1999-08-03 12:25:49

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 mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: Re: (usr-tc) cost of DSP
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-08-03 13:02:02

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 570-628-5545 farber@admin.f-tech.net 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 mitch@keyconn.net > Keystone Connect Unlock Your World > Altoona, PA 814-941-5000 http://www.keyconn.net > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) cost of DSP
From: Greg Genge <greg@dynavar.com>
Date: 1999-08-03 14:46:17

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 570-628-5545 >farber@admin.f-tech.net > >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 mitch@keyconn.net >> Keystone Connect Unlock Your World >> Altoona, PA 814-941-5000 http://www.keyconn.net >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) (403) 571-5000 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.

Subject: (usr-tc) Pipeline vs 3Com
From: Ken Kirchner <kenk@shreve.net>
Date: 1999-08-03 16:18:15

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:kenk@shreve.net Asst SysAdmin .o. Voice (318) 222-2638 Ext 108 ShreveNet, Inc. .o. Fax (318) 213-6612

Subject: RE: (usr-tc) Pipeline vs 3Com
From: Jason Cropper <jason@clearsail.net>
Date: 1999-08-03 16:46:05

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:owner-usr-tc@lists.xmission.com]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:kenk@shreve.net Asst SysAdmin .o. Voice (318) 222-2638 Ext 108 ShreveNet, Inc. .o. Fax (318) 213-6612 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) hyper arc v4.2.29 on hold
From: Mike Andrews <mandrews@termfrost.org>
Date: 1999-08-03 19:57:16

> 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 mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com "If you're not part of the solution.... you're part of the precipitate."

Subject: Re: (usr-tc) hyper arc v4.2.29 on hold
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-03 21:00:44

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) HiperDSP interface down
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-08-03 21:11:14

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: 81-3-5334-1700 > Systems Engineer FAX: 81-3-5334-1701 > The Highest Quality Service, Bar None > ____________________________________________ > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) hyper arc v4.2.29 on hold
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-08-03 21:20:45

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 ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ 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: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) TC SS7 gateway?
From: Allen Marsalis <am@shreve.net>
Date: 1999-08-03 21:44:03

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

Subject: Re: (usr-tc) hyper arc v4.2.29 on hold
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-08-04 05:17:15

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

Subject: (usr-tc) HiperDSP interface down
From: das <das@gol.com>
Date: 1999-08-04 09:29:48

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: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1701 The Highest Quality Service, Bar None ____________________________________________

Subject: Re: (usr-tc) cost of DSP
From: Brett Murphy <me@murf.net>
Date: 1999-08-04 09:36:45

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: +61 3 9486-8844 fax: +61 3 9486-6822 email: me@murf.net 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 mitch@keyconn.net >Keystone Connect Unlock Your World >Altoona, PA 814-941-5000 http://www.keyconn.net > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) hyper arc v4.2.29 on hold
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-08-04 10:36:48

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

Subject: Re: (usr-tc) HiperDSP interface down
From: das <das@gol.com>
Date: 1999-08-04 11:51:20

Thanks, Krish. This one is running 4.1.7 (looks like I've missed this one) das Tatai SV Krishnan (tkrishna@bubba.ae.usr.com) 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: 81-3-5334-1700 > > Systems Engineer FAX: 81-3-5334-1701 > > The Highest Quality Service, Bar None > > ____________________________________________ > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 The Highest Quality Service, Bar None ____________________________________________

Subject: (usr-tc) Switch type
From: Terry Kennedy <terry@olypen.com>
Date: 1999-08-04 12:38:36

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

Subject: Re: (usr-tc) hyper arc v4.2.29 on hold
From: Mike Andrews <mandrews@termfrost.org>
Date: 1999-08-04 12:42:25

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 mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com "If you're not part of the solution.... you're part of the precipitate."

Subject: (usr-tc) Now for my next problem, HiperDSP upgrade
From: vanhalen@coredcs.com
Date: 1999-08-04 14:13:41

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

Subject: RE: (usr-tc) Switch type
From: Terry Kennedy <terry@olypen.com>
Date: 1999-08-04 15:23:33

Thanks for the help. -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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. 519-985-8410 fax. 519-258-3009 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Switch type
From: Clayton Zekelman <clayton@mnsi.net>
Date: 1999-08-04 16:25:51

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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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. 519-985-8410 fax. 519-258-3009

Subject: (usr-tc) 3Com Modem tradeup
From: Richard Lorbieski <richard@alpha1.net>
Date: 1999-08-04 17:16:50

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 - richard@alpha1.net Chief Technical Officer - Senior System Administrator Alpha1 Internet http://www.alpha1.net 409.731.8236 - 877.4.alpha1 (877.425.7421)

Subject: RE: (usr-tc) 3Com Modem tradeup
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-08-04 17:23:26

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Richard Lorbieski |Sent: Wednesday, August 04, 1999 5:17 PM |To: usr-tc@lists.xmission.com |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

Subject: (usr-tc) Looked but can't find this
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-04 17:34:07

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) 3Com Modem tradeup
From: Stephen Amadei <amadei@dandy.net>
Date: 1999-08-04 17:36:59

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

Subject: Re: (usr-tc) 3Com Modem tradeup
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-04 18:57:29

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) Bulk config file text decoder program - 3COM???
From: Mr Bill <l3expert@yahoo.com>
Date: 1999-08-04 21:59:16

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

Subject: Re: (usr-tc) Looked but can't find this
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-08-05 09:00:17

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: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) v.42 selective reject on dsp
From: Brian Hitchcock <brianh@kcweb.net>
Date: 1999-08-05 09:02:59

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 > > minicrmn@nbnet.nb.ca > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Is there a command to completely turn of Chap Authentication on the
From: Ralph Helfenberger <r.helfenberger@comlight.ch>
Date: 1999-08-05 09:38:40

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 r.helfenberger@comlight.ch Comlight AG Tel +41 31 740 40 40 Tennisweg 21 Fax +41 31 740 40 90 3178 Boesingen Switzerland www.comlight.ch ==========================================================================

Subject: (usr-tc) v.42 selective reject on dsp
From: Mini Computer Room T-5 <minicrmn@nbnet.nb.ca>
Date: 1999-08-05 10:53:14

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 minicrmn@nbnet.nb.ca

Subject: (usr-tc) ISDN Call control option
From: pferraro@wna-linknet.com
Date: 1999-08-05 11:41:46

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 pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ==============================================================================

Subject: Re: (usr-tc) Looked but can't find this
From: Ed <ed@taylors.com>
Date: 1999-08-05 11:54:22

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 ed@1st.net FIRST Inc. ----- Original Message ----- Cc: <usr-tc@lists.xmission.com> 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: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) CustoFlex ISDN
From: K Mitchell <mitch@keyconn.net>
Date: 1999-08-05 13:13:20

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 mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: Re: (usr-tc) Locating a bad port on DSP
From: Dan Hollis <goemon@sasami.anime.net>
Date: 1999-08-05 13:46:33

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

Subject: (usr-tc) Hiper DSP code 2.0.19
From: Cheryl Johnson <netadmin@seidata.com>
Date: 1999-08-05 13:55:41

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--

Subject: Re: (usr-tc) Locating a bad port on DSP
From: Pete Ashdown <pashdown@xmission.com>
Date: 1999-08-05 14:42:00

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.

Subject: RE: (usr-tc) Locating a bad port on DSP
From: Randy Cosby <dcosby@infowest.com>
Date: 1999-08-05 14:46:09

Wouldn't it be nice if your admin shared that program :) Randy InfoWest > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ken Kirchner > Sent: Thursday, August 05, 1999 2:26 PM > To: usr-tc@lists.xmission.com > 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:kenk@shreve.net (___) > (__) Asst SysAdmin .o. Voice (318) 222-2638 Ext 108 (__) > (_) ShreveNet, Inc. .o. Fax (318) 213-6612 (_) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Question.
From: Pete Ashdown <pashdown@xmission.com>
Date: 1999-08-05 14:56:10

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.

Subject: Re: (usr-tc) Locating a bad port on DSP
From: Pete Ashdown <pashdown@xmission.com>
Date: 1999-08-05 14:58:46

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.

Subject: Re: (usr-tc) Locating a bad port on DSP
From: Pete Ashdown <pashdown@xmission.com>
Date: 1999-08-05 15:00:35

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.

Subject: Re: (usr-tc) Locating a bad port on DSP
From: Brice Ligget <ligget@twoalpha.net>
Date: 1999-08-05 15:11:49

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 ligget@twoalpha.net http://www.twoalpha.net/~bligget DoD#2159 User Error: Replace user and press any key to continue.

Subject: (usr-tc) Locating a bad port on DSP
From: Jim Johnson <jim@perigee.net>
Date: 1999-08-05 15:20:54

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

Subject: Re: (usr-tc) Locating a bad port on DSP
From: Ken Kirchner <kenk@shreve.net>
Date: 1999-08-05 15:26:01

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:kenk@shreve.net (___) (__) Asst SysAdmin .o. Voice (318) 222-2638 Ext 108 (__) (_) ShreveNet, Inc. .o. Fax (318) 213-6612 (_)

Subject: Re: (usr-tc) Locating a bad port on DSP
From: Jim Johnson <jim@perigee.net>
Date: 1999-08-05 15:48:02

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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Locating a bad port on DSP
From: Ken Kirchner <kenk@shreve.net>
Date: 1999-08-05 16:06:12

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:kenk@shreve.net (___) (__) Asst SysAdmin .o. Voice (318) 222-2638 Ext 108 (__) (_) ShreveNet, Inc. .o. Fax (318) 213-6612 (_)

Subject: Re: (usr-tc) Locating a bad port on DSP
From: Jim Johnson <jim@perigee.net>
Date: 1999-08-05 16:43:36

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:kenk@shreve.net (___) > (__) Asst SysAdmin .o. Voice (318) 222-2638 Ext 108 (__) > (_) ShreveNet, Inc. .o. Fax (318) 213-6612 (_) > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Locating a bad port on DSP
From: Joe Priestley <pries@fgi.net>
Date: 1999-08-05 16:45:55

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:kenk@shreve.net (___) > (__) Asst SysAdmin .o. Voice (318) 222-2638 Ext 108 (__) > (_) ShreveNet, Inc. .o. Fax (318) 213-6612 (_) > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) Radius suggestions?
From: Mike Moore <moore@jcevans.com>
Date: 1999-08-05 16:49:39

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

Subject: Re: (usr-tc) Radius suggestions?
From: Brian Hitchcock <brianh@kcweb.net>
Date: 1999-08-05 17:08:34

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:moore@jcevans.com] >> Sent: Thursday, August 05, 1999 6:50 PM >> To: usr-tc@xmission.com >> 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 "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) 2.0.81 dsp code
From: Scott Boggs <sboggs@unitedbank.net>
Date: 1999-08-05 17:21:20

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

Subject: Re: (usr-tc) 2.0.81 dsp code
From: pferraro@wna-linknet.com
Date: 1999-08-05 17:27:09

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 pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Radius suggestions?
From: Richard Lorbieski <richard@alpha1.net>
Date: 1999-08-05 17:39:15

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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 - richard@alpha1.net Chief Technical Officer - Senior System Administrator Alpha1 Internet http://www.alpha1.net 409.731.8236 - 877.4.alpha1 (877.425.7421)

Subject: Re: (usr-tc) Radius suggestions?
From: Dan Hollis <goemon@sasami.anime.net>
Date: 1999-08-05 17:49:17

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

Subject: Re: (usr-tc) Locating a bad port on DSP
From: Jim Johnson <jim@perigee.net>
Date: 1999-08-05 18:21:42

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:kenk@shreve.net (___) > > (__) Asst SysAdmin .o. Voice (318) 222-2638 Ext 108 (__) > > (_) ShreveNet, Inc. .o. Fax (318) 213-6612 (_) > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) Radius suggestions?
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 1999-08-05 18:41:41

I like Steel Belted from Funk Software for proxying to an NT SAM. > -----Original Message----- > From: Mike Moore [SMTP:moore@jcevans.com] > Sent: Thursday, August 05, 1999 6:50 PM > To: usr-tc@xmission.com > 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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Locating a bad port on DSP
From: Ken Kirchner <kenk@shreve.net>
Date: 1999-08-05 19:42:23

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:kenk@shreve.net (___) (__) Asst SysAdmin .o. Voice (318) 222-2638 Ext 108 (__) (_) ShreveNet, Inc. .o. Fax (318) 213-6612 (_)

Subject: Re: (usr-tc) Radius suggestions?
From: Thomas C Kinnen <tkinnen@livingston.com>
Date: 1999-08-05 20:44:28

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 - <tkinnen@ra.lucent.com> <tkinnen@sobhrach.com> [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"

Subject: Re: (usr-tc) Radius suggestions?
From: K Mitchell <mitch@keyconn.net>
Date: 1999-08-05 20:44:33

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 mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: Re: (usr-tc) Radius suggestions?
From: K Mitchell <mitch@keyconn.net>
Date: 1999-08-05 20:53:49

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 mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: RE: (usr-tc) CustoFlex ISDN
From: Scot Desort <scot@njaccess.net>
Date: 1999-08-05 22:20:16

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:owner-usr-tc@lists.xmission.com]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 mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: RE: (usr-tc) CustoFlex ISDN
From: K Mitchell <mitch@keyconn.net>
Date: 1999-08-05 22:48:20

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 mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: Re: (usr-tc) Locating a bad port on DSP
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-08-05 23:31:29

> > 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 mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com "If you're not part of the solution.... you're part of the precipitate."

Subject: Re: (usr-tc) Locating a bad port on DSP
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-08-05 23:45:59

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.

Subject: Re: (usr-tc) Radius suggestions?
From: Richard Lorbieski <richard@alpha1.net>
Date: 1999-08-05 23:46:54

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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) High Pitch Tone
From: Jamie Orzechowski <mhz@ripnet.com>
Date: 1999-08-06 06:27:26

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) ...

Subject: Re: (usr-tc) High Pitch Tone
From: Jim Johnson <jim@perigee.net>
Date: 1999-08-06 08:23:56

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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Locating a bad port on DSP
From: Brett Murphy <me@murf.net>
Date: 1999-08-06 10:36:23

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

Subject: (usr-tc) bad port locator
From: Pete Ashdown <pashdown@xmission.com>
Date: 1999-08-06 10:56:03

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 pashdown@xmission.com # 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}"

Subject: RE: (usr-tc) NMC booting failure after power down
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 1999-08-06 11:46:13

On Friday, August 06, 1999 11:04 AM, Kalev Nurklik [SMTP:kalev@mail.lbi.ee] 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.

Subject: Re: (usr-tc) bad port locator
From: Jim Johnson <jim@perigee.net>
Date: 1999-08-06 14:17:49

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 pashdown@xmission.com > > # 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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) 2.0.81 dsp code
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-08-06 15:14:38

<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

Subject: (usr-tc) NMC booting failure after power down
From: Kalev Nurklik <kalev@mail.lbi.ee>
Date: 1999-08-06 17:03:51

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: +372 6 308 909 Fax: +372 6 308 901 E-mail: k.nurklik@online.ee http://www.online.ee

Subject: (usr-tc) Gateways and routing...
From: Stephen Amadei <amadei@dandy.net>
Date: 1999-08-06 17:08:18

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

Subject: Re: (usr-tc) bad port locator
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-08-06 17:35:02

I probably will as soon as I dig up the appropriate OID's... Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- 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 pashdown@xmission.com > > > > # 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 "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Gateways and routing...
From: Charles Sprickman <spork@inch.com>
Date: 1999-08-06 18:30:41

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 (212)243-5200 | | spork@inch.com access@inch.com | = =----------------= 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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Gateways and routing...
From: Stephen Amadei <amadei@dandy.net>
Date: 1999-08-06 18:42:03

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

Subject: Re: (usr-tc) Gateways and routing...
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-08-06 19:41:09

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

Subject: RE: (usr-tc) Gateways and routing...
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 1999-08-06 21:21:23

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:amadei@dandy.net] > Sent: Friday, August 06, 1999 7:42 PM > To: usr-tc@lists.xmission.com > 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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) High Pitch Tone
From: Jim Johnson <jim@perigee.net>
Date: 1999-08-07 09:53:24

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

Subject: (usr-tc) Script for pulling USER times
From: pferraro@wna-linknet.com
Date: 1999-08-07 10:12:54

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 pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ==============================================================================

Subject: (usr-tc) WebRamp 310i
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1999-08-07 12:39:00

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

Subject: Re: (usr-tc) Script for pulling USER times
From: Allen Marsalis <am@shreve.net>
Date: 1999-08-07 12:43:18

At 10:12 AM 8/7/99 -0400, pferraro@wna-linknet.com 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 >pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service >Voice (910) 346-0835 824 Gumbranch Square, Suite R3 >FAX (910) 455-1933 Jacksonville, Nc 28540-6269 >============================================================================== > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) High Pitch Tone
From: Brett Murphy <me@murf.net>
Date: 1999-08-07 13:33:29

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

Subject: Re: (usr-tc) WebRamp 310i
From: Jamie Orzechowski <mhz@ripnet.com>
Date: 1999-08-07 14:48:06

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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >

Subject: Re: (usr-tc) Looked but can't find this
From: Bob Purdon (Lists) <lists@aussie.nu>
Date: 1999-08-07 17:28:02

> > 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. +61 (3) 6234 7444

Subject: RE: (usr-tc) Gateways and routing...
From: Suncoast Networking ISP TC List Mailbox <tclist@mail.flausa.net>
Date: 1999-08-07 17:51:28

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:amadei@dandy.net] >> Sent: Friday, August 06, 1999 7:42 PM >> To: usr-tc@lists.xmission.com >> 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 >>

Subject: Re: (usr-tc) Gateways and routing...
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-07 18:17:40

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Filtering Specific username
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-09 07:56:48

Thus spake bert.f@pacific.net.ph >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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) Utilization
From: Steve Johnson <linuxnut@sonic.net>
Date: 1999-08-09 09:28:42

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 (707)522-1001 (33.6kbps) (707)522-1000 (Voice) e-mail linuxnut at sonic.net http://www.sonic.net ---------------------------------------------------------------------------- "Knowing others is wisdom, knowing your self is Enlightenment." -- Lao-Tzu

Subject: FW: (usr-tc) HiperARC: Very bogus route accepted from dialup user
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-08-09 09:30:34

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

Subject: (usr-tc) Odd route showing up in netserver
From: Paul Oster <devious@minot.com>
Date: 1999-08-09 09:54:23

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:701-852-4374 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:admin@minot.com REV:19990809T145423Z END:VCARD ------=_NextPart_000_000F_01BEE24D.28E4E040--

Subject: Re: (usr-tc) Utilization
From: Brice Ligget <ligget@twoalpha.net>
Date: 1999-08-09 10:48:04

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 ligget@twoalpha.net 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

Subject: Re: (usr-tc) Utilization
From: Steve McConnell <stevem@emji.net>
Date: 1999-08-09 12:45:14

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 <linuxnut@sonic.net> 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 > (707)522-1001 (33.6kbps) (707)522-1000 (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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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

Subject: Re: (usr-tc) Utilization
From: Allen Marsalis <am@shreve.net>
Date: 1999-08-09 12:57:02

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 > (707)522-1001 (33.6kbps) (707)522-1000 (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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Utilization
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-08-09 14:21:44

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 mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- 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 > (707)522-1001 (33.6kbps) (707)522-1000 (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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) ARC's Ethernet Port2
From: brian@semo.net
Date: 1999-08-09 15:45:55

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

Subject: FW: (usr-tc) HiperARC: Very bogus route accepted from dialup user
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-08-09 15:55:29

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: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Scott Trautman |Sent: Monday, August 09, 1999 3:55 PM |To: 'usr-tc@lists.xmission.com' |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: 'usr-tc@lists.xmission.com' |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 "majordomo@xmission.com" |> with "unsubscribe usr-tc" in the body of the message. |> For information on digests or retrieving files and old messages send |> "help" to the same address. Do not use quotes in your message. |> | |- | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" | with "unsubscribe usr-tc" in the body of the message. | For information on digests or retrieving files and old messages send | "help" to the same address. Do not use quotes in your message. | |- | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" | with "unsubscribe usr-tc" in the body of the message. | For information on digests or retrieving files and old messages send | "help" to the same address. Do not use quotes in your message. |

Subject: Re: (usr-tc) ARC's Ethernet Port2
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-09 16:58:31

Thus spake brian@semo.net >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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: FW: (usr-tc) HiperARC: Very bogus route accepted from dialup user
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-09 17:13:46

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) HiperARC: Very bogus route accepted from dialup user even though supposedly not accepting routes from dialup users.
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-09 18:36:41

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Packet Bus Clock setting on Netserver?
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-09 21:48:31

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Script for pulling USER times
From: peter@gol.com
Date: 1999-08-09 23:13:51

pferraro@wna-linknet.com (pferraro@wna-linknet.com) 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.

Subject: (usr-tc) 3com not doing V.90 as well as Ascends
From: Ed <ed@taylors.com>
Date: 1999-08-10 01:24:13

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

Subject: (usr-tc) Filtering Specific username
From: bert.f@pacific.net.ph
Date: 1999-08-10 02:06:56

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

Subject: Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Greg Coffey <gcoffey@vcn.com>
Date: 1999-08-10 07:30:24

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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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

Subject: Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Greg Coffey <gcoffey@vcn.com>
Date: 1999-08-10 07:39:37

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

Subject: Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Jim Johnson <jim@perigee.net>
Date: 1999-08-10 08:18:27

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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Webramp 310i
From: Frank Basso <frank@okwhatever.com>
Date: 1999-08-10 08:29:46

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

Subject: Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-08-10 09:47:49

Post some logs please. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net 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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Webramp 310i
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-08-10 10:25:58

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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) HARC 4.2.29
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 1999-08-10 10:35:55

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?

Subject: (usr-tc) Packet Bus Clock setting on Netserver?
From: Brett Murphy <me@murf.net>
Date: 1999-08-10 10:42:39

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: +61 3 9486-8844 fax: +61 3 9486-6822 email: me@murf.net 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.

Subject: Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Allen Marsalis <am@shreve.net>
Date: 1999-08-10 11:09:23

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

Subject: (usr-tc) Webramp 310i
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1999-08-10 11:13:00

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

Subject: Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Ed <ed@taylors.com>
Date: 1999-08-10 11:45:13

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

Subject: (usr-tc) Dual E1 NIC Problem
From: Brett Murphy <me@murf.net>
Date: 1999-08-10 15:08:34

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: +61 3 9486-8844 fax: +61 3 9486-6822 email: me@murf.net 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.

Subject: (usr-tc) Prime on Dual T1 card & HiperARC
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-08-10 15:49:14

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

Subject: RE: (usr-tc) Prime on Dual T1 card & HiperARC
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-08-10 16:32:55

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Prime on Dual T1 card & HiperARC
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-10 16:56:28

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) 3com not doing V.90 as well as Ascends
From: Scot Desort <scot@njaccess.net>
Date: 1999-08-10 18:36:25

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: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ed > Sent: Tuesday, August 10, 1999 1:24 AM > To: usr-tc@lists.xmission.com > 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

Subject: Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Ed <ed@taylors.com>
Date: 1999-08-10 22:49:30

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: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ed > Sent: Tuesday, August 10, 1999 1:24 AM > To: usr-tc@lists.xmission.com > 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 "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) 3com not doing V.90 as well as Ascends
From: Scot Desort <scot@njaccess.net>
Date: 1999-08-10 23:43:53

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:owner-usr-tc@lists.xmission.com]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

Subject: (usr-tc) WTB - USR Total Control NETServer 8 Power Supply
From: Len Pikulski <lenp@nothinbut.net>
Date: 1999-08-11 01:57:53

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 lenp@nothinbut.net (856) 222-1514 http://www.nothinbut.net

Subject: Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Ed <ed@taylors.com>
Date: 1999-08-11 03:25:05

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:owner-usr-tc@lists.xmission.com]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 "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) Routing (?) problems
From: Sam Lowe <slowe@universalcom.net>
Date: 1999-08-11 07:34:14

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. slowe@universalcom.net

Subject: Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-11 08:00:03

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-11 08:00:03

Subject: Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Jeff Lynch <jeff@mercury.jorsm.com>
Date: 1999-08-11 09:42:37

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: jeff@jorsm.com | 7 Area Codes in Chicagoland and NW Indiana Voice: (219)322-2180 | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN Autoresponse: info@jorsm.com | Quality Service, Affordable Prices http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995

Subject: RE: (usr-tc) 2.0.81 dsp code
From: Ken Kirchner <kenk@shreve.net>
Date: 1999-08-11 09:56:08

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:kenk@shreve.net (___) (__) Asst SysAdmin .o. Voice (318) 222-2638 Ext 108 (__) (_) ShreveNet, Inc. .o. Fax (318) 213-6612 (_)

Subject: Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Ed <ed@taylors.com>
Date: 1999-08-11 10:06:18

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-11 10:19:44

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Ed <ed@taylors.com>
Date: 1999-08-11 10:44:33

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) 2.0.81 dsp code
From: Scott Boggs <sboggs@unitedbank.net>
Date: 1999-08-11 10:46:34

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:nabil@spiritone.com] > Sent: Friday, August 06, 1999 6:15 PM > To: usr-tc@lists.xmission.com > 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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-11 10:54:57

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) bad port locator
From: Eric Billeter <ebilleter@cableone.net>
Date: 1999-08-11 11:56:53

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. eric.billeter@cableone.net 602-364-6462 -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]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:mandrews@bit0.com] > Sent: Friday, August 06, 1999 4:35 PM > To: usr-tc@lists.xmission.com > 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 > mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- > 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 pashdown@xmission.com > > > > > > # 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 > "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old > messages send > > > "help" to the same address. Do not use quotes in your message. > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old > messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) E1 File Needed
From: Marty Elliott <marty@2assetrecovery.com>
Date: 1999-08-11 12:11:19

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 marty@2assetrecovery.com www.2assetrecovery.com ====================

Subject: (usr-tc) RE: (USR-TC) WEBRAMP 310I
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1999-08-11 12:32:00

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

Subject: RE: (usr-tc) bad port locator
From: Blake Fithen <fithen@networksplus.com>
Date: 1999-08-11 13:47:10

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:mandrews@bit0.com] > Sent: Friday, August 06, 1999 4:35 PM > To: usr-tc@lists.xmission.com > 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 > mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- > 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 pashdown@xmission.com > > > > > > # 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 > "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old > messages send > > > "help" to the same address. Do not use quotes in your message. > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old > messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) bad port locator
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-11 14:55:48

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) bad port locator
From: Jamie Orzechowski <mhz@ripnet.com>
Date: 1999-08-11 15:07:02

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:mandrews@bit0.com] > > Sent: Friday, August 06, 1999 4:35 PM > > To: usr-tc@lists.xmission.com > > 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 > > mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- > > 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 pashdown@xmission.com > > > > > > > > # 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 > > "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old > > messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old > > messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >

Subject: RE: (usr-tc) bad port locator
From: Blake Fithen <fithen@networksplus.com>
Date: 1999-08-11 15:39:44

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:jeffm@iglou.com] > Sent: Wednesday, August 11, 1999 1:56 PM > To: usr-tc@lists.xmission.com > 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: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) bad port locator
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 1999-08-11 15:54:35

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:jeffm@iglou.com] 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: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Locating a bad port on DSP
From: Brian <signal@shreve.net>
Date: 1999-08-11 16:51:39

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:kenk@shreve.net (___) > > (__) Asst SysAdmin .o. Voice (318) 222-2638 Ext 108 (__) > > (_) ShreveNet, Inc. .o. Fax (318) 213-6612 (_) > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: RE: (usr-tc) Locating a bad port on DSP
From: Brian <signal@shreve.net>
Date: 1999-08-11 16:54:56

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> # <signal@shreve.net> $|=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: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ken Kirchner > > Sent: Thursday, August 05, 1999 2:26 PM > > To: usr-tc@lists.xmission.com > > 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:kenk@shreve.net (___) > > (__) Asst SysAdmin .o. Voice (318) 222-2638 Ext 108 (__) > > (_) ShreveNet, Inc. .o. Fax (318) 213-6612 (_) > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: Re: (usr-tc) Locating a bad port on DSP
From: Brian <signal@shreve.net>
Date: 1999-08-11 16:56:07

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:kenk@shreve.net (___) > (__) Asst SysAdmin .o. Voice (318) 222-2638 Ext 108 (__) > (_) ShreveNet, Inc. .o. Fax (318) 213-6612 (_) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: RE: (usr-tc) bad port locator
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-08-11 17:37:53

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 mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- 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:jeffm@iglou.com] > 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: jeffm@iglou.com > > Head Network Administrator Voice: (502) 966-3848 > > IgLou Internet Services (800) 436-4456 > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Andres Kroonmaa <andre@mail.lbi.ee>
Date: 1999-08-11 18:12:43

On 11 Aug 99, at 8:00, Jeff Mcadams <usr-tc@lists.xmission.com> 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: andre@online.ee Senior Network Engineer Organization: MicroLink Online Tel: 6308 909 Tallinn, Sakala 19 Pho: +372 6308 909 Estonia, EE0001 http://www.online.ee Fax: +372 6308 901 ----------------------------------------------------------------------

Subject: RE: (usr-tc) 3com not doing V.90 as well as Ascends
From: Bob Purdon (Lists) <lists@aussie.nu>
Date: 1999-08-11 21:47:15

> 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. +61 (3) 6234 7444

Subject: Re: (usr-tc) bad port locator
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-08-11 22:48:07

> >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.

Subject: Re: (usr-tc) bad port locator
From: Brian <signal@shreve.net>
Date: 1999-08-12 08:01:45

On Thu, 12 Aug 1999, Brett Murphy wrote: > > -----Original Message----- > From: Mike Andrews <mandrews@bit0.com> > To: 'usr-tc@lists.xmission.com' <usr-tc@lists.xmission.com> > 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) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: Re: (usr-tc) bad port locator
From: Brett Murphy <me@murf.net>
Date: 1999-08-12 10:39:13

>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:mandrews@bit0.com] >> Sent: Friday, August 06, 1999 4:35 PM >> To: usr-tc@lists.xmission.com >> 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 >> mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- >> 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 pashdown@xmission.com >> > > >> > > # 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 >> "majordomo@xmission.com" >> > > with "unsubscribe usr-tc" in the body of the message. >> > > For information on digests or retrieving files and old >> messages send >> > > "help" to the same address. Do not use quotes in your message. >> > >> > - >> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> > with "unsubscribe usr-tc" in the body of the message. >> > For information on digests or retrieving files and old >> messages send >> > "help" to the same address. Do not use quotes in your message. >> > >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) bad port locator
From: Brett Murphy <me@murf.net>
Date: 1999-08-12 10:49:02

-----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 >mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- 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:jeffm@iglou.com] >> 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: jeffm@iglou.com >> > Head Network Administrator Voice: (502) 966-3848 >> > IgLou Internet Services (800) 436-4456 >> > >> > - >> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> > with "unsubscribe usr-tc" in the body of the message. >> > For information on digests or retrieving files and old messages send >> > "help" to the same address. Do not use quotes in your message. >> >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Using both Ethernet interfaces on HiPer ARC
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-12 11:40:42

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) Changing dial up.
From: Brice Ligget <ligget@twoalpha.net>
Date: 1999-08-12 12:41:10

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

Subject: Re: (usr-tc) Changing dial up.
From: Brice Ligget <ligget@twoalpha.net>
Date: 1999-08-12 13:51:22

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: jeffm@iglou.com >Head Network Administrator Voice: (502) 966-3848 >IgLou Internet Services (800) 436-4456 -- Brice Ligget Billings MT ligget@twoalpha.net http://www.twoalpha.net/~bligget DoD#2159 I will not aim for the head.

Subject: Re: (usr-tc) Changing dial up.
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-12 14:57:24

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) Changing dial up.
From: Hofmann <jay@iglou.com>
Date: 1999-08-12 15:02:07

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: jayh@iglou.com Technical Support Team Leader Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) Idle time
From: David Swearingin <david@carolnet.com>
Date: 1999-08-12 15:51:14

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 (david@carolnet.com) CARROLLTON INTERNET SERVICE (www.carolnet.com) First Financial Group, Inc. 11 N. Folger, Carrollton, MO 64633 660-542-3002 Fax 660-542-3003

Subject: (usr-tc) Using both Ethernet interfaces on HiPer ARC
From: Ralph Helfenberger <r.helfenberger@comlight.ch>
Date: 1999-08-12 17:34:54

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 r.helfenberger@comlight.ch Comlight AG Tel +41 31 740 40 40 Tennisweg 21 Fax +41 31 740 40 90 3178 Boesingen Switzerland www.comlight.ch ==========================================================================

Subject: (usr-tc) Okay, the Prime is in, up and good....a couple more questions...a
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-08-12 17:39:11

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 scott@gdinet.com Madison WI 53718 http://www.gdinet.com

Subject: (usr-tc) OT: Filters
From: Hostmaster Soho Solutions - Javier Szyszlican <root@host.net.ar>
Date: 1999-08-12 17:43:45

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

Subject: Re: (usr-tc) Okay, the Prime is in, up and good....a couple more questions...a
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-12 21:06:46

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Routing (?) problems
From: Sam Lowe <slowe@universalcom.net>
Date: 1999-08-13 07:04:27

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. slowe@universalcom.net

Subject: Re: (usr-tc) HiperARC security hole
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-08-13 07:10:17

Could you send me the source? krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ 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 <jchapman@1ST.NET> > To: <BUGTRAQ@SECURITYFOCUS.COM> > 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 > > jchapman@1st.net www.1st.net > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) HiperARC security hole
From: Jamie Orzechowski <mhz@ripnet.com>
Date: 1999-08-13 19:06:16

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 > jchapman@1st.net www.1st.net

Subject: (usr-tc) HiperARC - Dangerous HiperBomb
From: Ed Taylor <ed@taylors.com>
Date: 1999-08-13 19:50:05

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: usr-tc@lists.xmission.com >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 > jchapman@1st.net www.1st.net - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) HiperARC security hole
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-13 21:35:56

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
From: Jamie Orzechowski <mhz@ripnet.com>
Date: 1999-08-13 21:57:21

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" <mhz@ripnet.com> > Reply-To: usr-tc@lists.xmission.com > 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 <jchapman@1ST.NET> > To: <BUGTRAQ@SECURITYFOCUS.COM> > 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 > > jchapman@1st.net www.1st.net > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >

Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-13 22:02:27

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
From: Rick <rallan@monmouth.com>
Date: 1999-08-13 23:06:59

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" <mhz@ripnet.com> > Reply-To: usr-tc@lists.xmission.com > 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 <jchapman@1ST.NET> > To: <BUGTRAQ@SECURITYFOCUS.COM> > 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 > > jchapman@1st.net www.1st.net > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 / rick@monmouth.com | Connect to a Backbone not a Wishbone Head of Network Engineering | Monmouth Internet Corporation 732-842-5366=====extension 102 | http://www.monmouth.com -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
From: Rick <rallan@monmouth.com>
Date: 1999-08-13 23:15:52

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" <mhz@ripnet.com> > > Reply-To: usr-tc@lists.xmission.com > > 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 <jchapman@1ST.NET> > > To: <BUGTRAQ@SECURITYFOCUS.COM> > > 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 > > > jchapman@1st.net www.1st.net > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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 / rick@monmouth.com | 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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 / rick@monmouth.com | Connect to a Backbone not a Wishbone Head of Network Engineering | Monmouth Internet Corporation 732-842-5366=====extension 102 | http://www.monmouth.com -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Subject: RE: (usr-tc) HiperARC - Dangerous HiperBomb
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-08-14 00:39:36

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 ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ 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: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Rick > > Sent: Friday, August 13, 1999 10:07 PM > > To: usr-tc@lists.xmission.com > > 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" <mhz@ripnet.com> > > > Reply-To: usr-tc@lists.xmission.com > > > 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 <jchapman@1ST.NET> > > > To: <BUGTRAQ@SECURITYFOCUS.COM> > > > 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 > > > > jchapman@1st.net www.1st.net > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the 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 / rick@monmouth.com | 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 "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Need X2 keys for NMC
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-08-14 00:41:06

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 ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ 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 lenp@nothinbut.net (856) 222-1514 > http://www.nothinbut.net > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) disabling telnet
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-08-14 00:42:49

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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) HiperARC - Dangerous HiperBomb
From: Marshall Morgan <marshall@netdoor.com>
Date: 1999-08-14 01:09:46

But your own customers can still reboot them via dialup to that NAS. Marshall Morgan Internet Doorway, Inc. (aka NETDOOR) > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Rick > Sent: Friday, August 13, 1999 10:07 PM > To: usr-tc@lists.xmission.com > 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" <mhz@ripnet.com> > > Reply-To: usr-tc@lists.xmission.com > > 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 <jchapman@1ST.NET> > > To: <BUGTRAQ@SECURITYFOCUS.COM> > > 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 > > > jchapman@1st.net www.1st.net > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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 / rick@monmouth.com | 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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >

Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
From: Ed <ed@taylors.com>
Date: 1999-08-14 02:38:35

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: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Rick > Sent: Friday, August 13, 1999 10:07 PM > To: usr-tc@lists.xmission.com > 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" <mhz@ripnet.com> > > Reply-To: usr-tc@lists.xmission.com > > 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 <jchapman@1ST.NET> > > To: <BUGTRAQ@SECURITYFOCUS.COM> > > 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 > > > jchapman@1st.net www.1st.net > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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 / rick@monmouth.com | 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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) Need X2 keys for NMC
From: Len Pikulski <lenp@nothinbut.net>
Date: 1999-08-14 03:07:26

Any resources would be greatly appreciated. Thanks <*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*> Len Pikulski lenp@nothinbut.net (856) 222-1514 http://www.nothinbut.net

Subject: (usr-tc) disabling telnet
From: Jamie Orzechowski <mhz@ripnet.com>
Date: 1999-08-14 08:00:45

what is the command to disable telnet on an arc anyways??

Subject: Re: (usr-tc) disabling telnet
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-14 08:20:12

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
From: pferraro@wna-linknet.com
Date: 1999-08-14 09:21:42

Is there a way to deny access to the port, but allow only certain IPS to telnet to it? ============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 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" <mhz@ripnet.com> > Reply-To: usr-tc@lists.xmission.com > 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 <jchapman@1ST.NET> > To: <BUGTRAQ@SECURITYFOCUS.COM> > 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 > > jchapman@1st.net www.1st.net > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-14 09:52:21

Thus spake pferraro@wna-linknet.com > 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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-14 10:28:40

Thus spake Peter >Jeff Mcadams <jeffm@iglou.com> wrote >> Thus spake pferraro@wna-linknet.com >> > 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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-14 14:00:22

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
From: Brian M. Gordon <administrator@westelcom.com>
Date: 1999-08-14 18:26:47

How would I add a range of ips? ----- Original Message ----- Cc: <usr-tc@lists.xmission.com> 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 ............ \ > ----------------------------------------------/ > tkrishna@bubba.ae.usr.com > ----------------------------/ 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: owner-usr-tc@lists.xmission.com > > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Rick > > > Sent: Friday, August 13, 1999 10:07 PM > > > To: usr-tc@lists.xmission.com > > > 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" <mhz@ripnet.com> > > > > Reply-To: usr-tc@lists.xmission.com > > > > 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 <jchapman@1ST.NET> > > > > To: <BUGTRAQ@SECURITYFOCUS.COM> > > > > 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 > > > > > jchapman@1st.net www.1st.net > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the 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 / rick@monmouth.com | 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 "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
From: Jamie Orzechowski <mhz@ripnet.com>
Date: 1999-08-14 21:28:17

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: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >

Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-08-14 21:35:31

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 <tkrishna@bubba.ae.usr.com> > To: Marshall Morgan <marshall@netdoor.com> > Cc: <usr-tc@lists.xmission.com> > 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 ............ \ > > ----------------------------------------------/ > > tkrishna@bubba.ae.usr.com > > ----------------------------/ 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: owner-usr-tc@lists.xmission.com > > > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Rick > > > > Sent: Friday, August 13, 1999 10:07 PM > > > > To: usr-tc@lists.xmission.com > > > > 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" <mhz@ripnet.com> > > > > > Reply-To: usr-tc@lists.xmission.com > > > > > 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 <jchapman@1ST.NET> > > > > > To: <BUGTRAQ@SECURITYFOCUS.COM> > > > > > 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 > > > > > > jchapman@1st.net www.1st.net > > > > > > > > > > - > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > For information on digests or retrieving files and old messages > send > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > - > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > > with "unsubscribe usr-tc" in the body of the 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 / rick@monmouth.com | 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 "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-08-14 21:40:23

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 ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ 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 <jeffm@iglou.com> > To: <usr-tc@lists.xmission.com> > 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: jeffm@iglou.com > > Head Network Administrator Voice: (502) 966-3848 > > IgLou Internet Services (800) 436-4456 > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
From: Brian M. Gordon <administrator@westelcom.com>
Date: 1999-08-14 22:15:05

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 <jeffm@iglou.com> > To: <usr-tc@lists.xmission.com> > 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: jeffm@iglou.com > > Head Network Administrator Voice: (502) 966-3848 > > IgLou Internet Services (800) 436-4456 > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
From: Peter <peter@gol.com>
Date: 1999-08-14 23:09:06

Jeff Mcadams <jeffm@iglou.com> wrote > Thus spake pferraro@wna-linknet.com > > 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.

Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-14 23:22:39

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Link dead after 8 Days
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-08-15 10:25:32

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 mitch@keyconn.net > Keystone Connect Unlock Your World > Altoona, PA 814-941-5000 http://www.keyconn.net > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Link dead after 8 Days
From: Dale Hege <fhege@sover.net>
Date: 1999-08-15 11:10:00

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

Subject: (usr-tc) Security and Accounting Server vs. SAM questions
From: Howard Reeves <hreeves@altamontks.com>
Date: 1999-08-15 11:45:09

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 hreeves@altamontks.com

Subject: Re: (usr-tc) stalling
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-08-15 19:25:56

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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Link dead after 8 Days
From: Sam Lowe <slowe@universalcom.net>
Date: 1999-08-15 20:11:54

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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Link dead after 8 Days
From: K Mitchell <mitch@keyconn.net>
Date: 1999-08-15 22:18:51

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 mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: Re: (usr-tc) Link dead after 8 Days
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-08-15 23:29:43

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 <tkrishna@bubba.ae.usr.com> > To: K Mitchell <mitch@keyconn.net> > Cc: <usr-tc@lists.xmission.com> > Sent: Sunday, August 15, 1999 10:25 AM > Subject: Re: (usr-tc) Link dead after 8 Days > > > > >

Subject: Re: (usr-tc) Link dead after 8 Days
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-08-16 01:40:58

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:kenk@shreve.net (___) > (__) Asst SysAdmin .o. Voice (318) 222-2638 Ext 108 (__) > (_) ShreveNet, Inc. .o. Fax (318) 213-6612 (_) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) stalling
From: Jamie Orzechowski <mhz@ripnet.com>
Date: 1999-08-16 07:01:09

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

Subject: Re: (usr-tc) Link dead after 8 Days
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-08-16 10:23:09

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 > csparks@cqc.com > > > ----- Original Message ----- > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > To: Sam Lowe <slowe@universalcom.net> > Cc: <usr-tc@lists.xmission.com> > 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 <tkrishna@bubba.ae.usr.com> > > > To: K Mitchell <mitch@keyconn.net> > > > Cc: <usr-tc@lists.xmission.com> > > > 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 "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) HiperARC - Dangerous HiperBomb
From: Kevin Benton <s1kevin@tims.net>
Date: 1999-08-16 10:23:25

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

Subject: Re: (usr-tc) Link dead after 8 Days
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-08-16 10:27:18

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:kenk@shreve.net (___) > (__) Asst SysAdmin .o. Voice (318) 222-2638 Ext 108 (__) > (_) ShreveNet, Inc. .o. Fax (318) 213-6612 (_) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) HiperARC - Dangerous HiperBomb
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-16 10:30:32

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Link dead after 8 Days
From: Sam Lowe <slowe@universalcom.net>
Date: 1999-08-16 11:33:00

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: <usr-tc@lists.xmission.com> Sent: Sunday, August 15, 1999 10:25 AM >

Subject: Re: (usr-tc) stalling
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-08-16 11:59:11

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

Subject: Re: (usr-tc) Link dead after 8 Days
From: Ken Kirchner <kenk@shreve.net>
Date: 1999-08-16 12:31:22

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:kenk@shreve.net (___) (__) Asst SysAdmin .o. Voice (318) 222-2638 Ext 108 (__) (_) ShreveNet, Inc. .o. Fax (318) 213-6612 (_)

Subject: (usr-tc) Rockwell / Conexant HCF Modem does not connect
From: John Mies <jmies@advancenet.net>
Date: 1999-08-16 13:01:24

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

Subject: RE: (usr-tc) simple question
From: Eric Billeter <ebilleter@cableone.net>
Date: 1999-08-16 13:02:36

Make your changes Highlight NMC Actions Save UI to EEPROM Eric Billeter Internet Engineer Cable One, Inc. eric.billeter@cableone.net 602-364-6462 -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]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 "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) Perhaps another simple question - HiperARC
From: Marty Elliott <marty@2assetrecovery.com>
Date: 1999-08-16 13:52:31

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:mandrews@bit0.com] >Sent: Monday, August 16, 1999 3:10 PM >To: usr-tc@lists.xmission.com >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 >mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- 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 "majordomo@xmission.com" >> > with "unsubscribe usr-tc" in the body of the message. >> > For information on digests or retrieving files and old messages send >> > "help" to the same address. Do not use quotes in your message. >> > >> >> > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) Perhaps another simple question - HiperARC initial configuration/
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-08-16 14:58:47

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

Subject: RE: (usr-tc) Perhaps another simple question - HiperARC initial c
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-08-16 15:39:19

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 mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- 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 "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Perhaps another simple question - HiperARC initial
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-08-16 16:06:47

Turn on dip switch 6, especially if you made your own serial cable... Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- 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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Perhaps another simple question - HiperARC initial
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-08-16 16:10:03

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 mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- 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 "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > >

Subject: Re: (usr-tc) Link dead after 8 Days
From: Clint R. Sparks <csparks@cqc.com>
Date: 1999-08-16 16:23:00

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 csparks@cqc.com ----- Original Message ----- Cc: <usr-tc@lists.xmission.com> 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 <tkrishna@bubba.ae.usr.com> > > To: K Mitchell <mitch@keyconn.net> > > Cc: <usr-tc@lists.xmission.com> > > 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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) simple question
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 1999-08-16 16:31:34

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...

Subject: RE: (usr-tc) Link dead after 8 Days
From: Blake Fithen <fithen@networksplus.com>
Date: 1999-08-16 16:57:33

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:csparks@cqc.com] > Sent: Monday, August 16, 1999 4:23 PM > To: usr-tc@lists.xmission.com > 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 > csparks@cqc.com > > > ----- Original Message ----- > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > To: Sam Lowe <slowe@universalcom.net> > Cc: <usr-tc@lists.xmission.com> > 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 <tkrishna@bubba.ae.usr.com> > > > To: K Mitchell <mitch@keyconn.net> > > > Cc: <usr-tc@lists.xmission.com> > > > 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 "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old > messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Link dead after 8 Days
From: Ken Kirchner <kenk@shreve.net>
Date: 1999-08-16 17:00:55

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:kenk@shreve.net (___) (__) Asst SysAdmin .o. Voice (318) 222-2638 Ext 108 (__) (_) ShreveNet, Inc. .o. Fax (318) 213-6612 (_)

Subject: RE: (usr-tc) Link dead after 8 Days
From: Ken Kirchner <kenk@shreve.net>
Date: 1999-08-16 17:03:44

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:kenk@shreve.net (___) (__) Asst SysAdmin .o. Voice (318) 222-2638 Ext 108 (__) (_) ShreveNet, Inc. .o. Fax (318) 213-6612 (_)

Subject: (usr-tc) 2 ARC's - one chassis
From: Jamie Orzechowski <mhz@ripnet.com>
Date: 1999-08-16 17:06:59

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.

Subject: (usr-tc) Telnet exploit round 2...
From: Stephen Amadei <amadei@dandy.net>
Date: 1999-08-17 00:03:33

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

Subject: Re: (usr-tc) Link dead after 8 Days
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-08-17 00:45:28

I am using a netgear RT328 to dial into a Courier I modem and experience the same problem. I think the Netgear gear has a problem with not keeping NAT mappings or some such thing. I message to netgear tech got me a "reload the flash".. not to helpful. It's not your DSP's... its the Netgear. I have a 3Com OfficeConnect also that dials into the DSP's..... will run fine for days then the B's wont come up. Reboot the OfficeConnect (or simple DROP the B's manually and your back in business). Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net 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.

Subject: Re: (usr-tc) radiusd and CHAP authentication
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-08-17 09:03:23

On Tue, 17 Aug 1999 pferraro@wna-linknet.com 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 > pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service > Voice (910) 346-0835 824 Gumbranch Square, Suite R3 > FAX (910) 455-1933 Jacksonville, Nc 28540-6269 > ============================================================================== > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) 2 ARC's - one chassis
From: Brian <signal@shreve.net>
Date: 1999-08-17 09:06:01

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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: Re: (usr-tc) 2 ARC's - one chassis
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-08-17 09:47:32

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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) Telnet exploit round 2...
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-08-17 10:41:50

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: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stephen Amadei |Sent: Monday, August 16, 1999 11:04 PM |To: usr-tc@lists.xmission.com |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. |

Subject: Re: (usr-tc) 2 ARC's - one chassis
From: florin_neamtu@3com.com
Date: 1999-08-17 11:13:02

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" <mhz@ripnet.com> on 08/16/99 05:06:59 PM Please respond to usr-tc@lists.xmission.com Sent by: "Jamie Orzechowski" <mhz@ripnet.com> 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 "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Telnet exploit round 2...
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1999-08-17 12:23:41

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 "majordomo@xmission.com" | with "unsubscribe usr-tc" in the body of the 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

Subject: (usr-tc) Mulitcasting (mbone)
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-08-17 13:00:43

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

Subject: RE: (usr-tc) 2 ARC's - one chassis
From: Boggs, Scott <sboggs@unitedbank.net>
Date: 1999-08-17 13:28:43

I did it last May. I got these tips from chip@wirefire.com 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:mhz@ripnet.com] > Sent: Monday, August 16, 1999 5:07 PM > To: usr-tc@lists.xmission.com > 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. > >

Subject: RE: (usr-tc) Perhaps another simple question - HiperARC initial c
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-08-17 13:39:23

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:mandrews@bit0.com] >Sent: Monday, August 16, 1999 3:10 PM >To: usr-tc@lists.xmission.com >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 >mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- 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 "majordomo@xmission.com" >> > with "unsubscribe usr-tc" in the body of the message. >> > For information on digests or retrieving files and old messages send >> > "help" to the same address. Do not use quotes in your message. >> > >> >> > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) 2 ARC's - one chassis
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-08-17 14:46:36

Florin_Neamtu@3com.com 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

Subject: (usr-tc) NMC event logging
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-17 14:50:32

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) Bad Modem monitoring
From: Eric Billeter <ebilleter@cableone.net>
Date: 1999-08-17 16:31:06

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. eric.billeter@cableone.net 602-364-6462

Subject: Re: (usr-tc) 2 ARC's - one chassis
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-17 18:19:04

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) Bad Modem monitoring
From: Eric Billeter <ebilleter@cableone.net>
Date: 1999-08-17 18:20:39

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. eric.billeter@cableone.net 602-364-6462 -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]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. > > eric.billeter@cableone.net > 602-364-6462 > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the 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--

Subject: (usr-tc) radiusd and CHAP authentication
From: pferraro@wna-linknet.com
Date: 1999-08-17 18:29:06

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 pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ==============================================================================

Subject: Re: (usr-tc) 2 ARC's - one chassis
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-08-17 18:59:47

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

Subject: RE: (usr-tc) Telnet exploit round 2...
From: Stephen Amadei <amadei@dandy.net>
Date: 1999-08-17 19:40:30

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

Subject: Re: (usr-tc) Bad Modem monitoring
From: Jamie Orzechowski <mhz@ripnet.com>
Date: 1999-08-17 20:08:55

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. > > eric.billeter@cableone.net > 602-364-6462 > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >

Subject: Re: (usr-tc) 1 ARC - 14 DSPS
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-08-17 20:29:43

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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Bad Modem monitoring
From: Jamie Orzechowski <mhz@ripnet.com>
Date: 1999-08-17 21:32:45

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. > > eric.billeter@cableone.net > 602-364-6462 > > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jamie Orzechowski > Sent: Tuesday, August 17, 1999 5:09 PM > To: usr-tc@lists.xmission.com > 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 <ebilleter@cableone.net> > To: <usr-tc@lists.xmission.com> > 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. > > > > eric.billeter@cableone.net > > 602-364-6462 > > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) 2 ARC's - one chassis
From: Jamie Orzechowski <mhz@ripnet.com>
Date: 1999-08-17 22:18:36

I would just like to know if one ARC can even handle 14 DSP's or should I use 2 ARCS?

Subject: (usr-tc) 1 ARC - 14 DSPS
From: Jamie Orzechowski <mhz@ripnet.com>
Date: 1999-08-18 06:16:23

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?

Subject: Re: (usr-tc) 1 ARC - 14 DSPS
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-18 07:31:19

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) ARC flash going bad
From: Michael DeMan <michael@prf.org>
Date: 1999-08-18 08:28:00

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

Subject: Re: (usr-tc) 2 ARC's - one chassis
From: Jim Johnson <jim@perigee.net>
Date: 1999-08-18 08:29:38

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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) Help with assigning dedicated IP addresses across multiple
From: Kelly Peterson <netadmin@compusmart.ab.ca>
Date: 1999-08-18 08:45:16

<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>

Subject: Re: (usr-tc) RE: ARC flash going bad
From: Michael DeMan <michael@prf.org>
Date: 1999-08-18 09:32:01

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.

Subject: (usr-tc) Internic
From: Jim Johnson <jim@perigee.net>
Date: 1999-08-18 09:32:06

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

Subject: RE: (usr-tc) Internic
From: Hofmann <jay@iglou.com>
Date: 1999-08-18 09:40:09

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: jayh@iglou.com Technical Support Team Leader Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) NFAS on DSPs
From: pferraro@wna-linknet.com
Date: 1999-08-18 09:40:51

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 pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Internic
From: Jim Johnson <jim@perigee.net>
Date: 1999-08-18 09:45:22

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: jayh@iglou.com > Technical Support Team Leader Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) 1 ARC - 14 DSP's
From: John Verreault <verreaul@aei.ca>
Date: 1999-08-18 09:56:06

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: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan > Sent: Tuesday, August 17, 1999 10:48 AM > To: Jamie Orzechowski > Cc: usr-tc@lists.xmission.com > 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 "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) NFAS on DSPs
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 1999-08-18 09:58:10

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...

Subject: RE: (usr-tc) 1 ARC - 14 DSPS
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-08-18 10:16:54

|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

Subject: RE: (usr-tc) Bad Modem monitoring
From: Eric Billeter <ebilleter@cableone.net>
Date: 1999-08-18 10:17:08

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. eric.billeter@cableone.net 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--

Subject: (usr-tc) DNIS not working on PRI
From: Marshall Morgan <marshall@netdoor.com>
Date: 1999-08-18 10:24:37

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

Subject: (usr-tc) DSP Signal Levels
From: Kevin Benton <s1kevin@tims.net>
Date: 1999-08-18 10:34:56

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: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

Subject: (usr-tc) RE: ARC flash going bad
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-08-18 10:36:32

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Michael DeMan |Sent: Wednesday, August 18, 1999 10:28 AM |To: usr-tc@lists.xmission.com |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

Subject: Re: (usr-tc) 2 ARC's - one chassis
From: Jamie Orzechowski <mhz@ripnet.com>
Date: 1999-08-18 11:26:05

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

Subject: Re: (usr-tc) 1 ARC - 14 DSPS
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-18 11:26:46

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) 1 ARC - 14 DSPS
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-08-18 11:30:15

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 mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com "If you're not part of the solution.... you're part of the precipitate."

Subject: (usr-tc) HARC Chassis / DSPs for sale
From: Craig Thompson <manager@wingnet.net>
Date: 1999-08-18 11:45:40

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

Subject: (usr-tc) Interface load SNMP data on Netservers?
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-08-18 11:48:07

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

Subject: Re: (usr-tc) Bad Modem monitoring
From: Brett Murphy <me@murf.net>
Date: 1999-08-18 12:16:03

-----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 <ebilleter@cableone.net> >To: <usr-tc@lists.xmission.com> >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. >> >> eric.billeter@cableone.net >> 602-364-6462 >> >> -----Original Message----- >> From: owner-usr-tc@lists.xmission.com >> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jamie Orzechowski >> Sent: Tuesday, August 17, 1999 5:09 PM >> To: usr-tc@lists.xmission.com >> 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 <ebilleter@cableone.net> >> To: <usr-tc@lists.xmission.com> >> 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. >> > >> > eric.billeter@cableone.net >> > 602-364-6462 >> > >> > >> > >> > >> > - >> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> > with "unsubscribe usr-tc" in the body of the message. >> > For information on digests or retrieving files and old messages send >> > "help" to the same address. Do not use quotes in your message. >> > >> > >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) TRAP disconnect reasons
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-08-18 12:26:26

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 570-628-5545 farber@admin.f-tech.net

Subject: Re: (usr-tc) TRAP disconnect reasons
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-18 12:32:32

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) TRAP disconnect reasons
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-08-18 12:53:42

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 570-628-5545 farber@admin.f-tech.net 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: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) RE: ARC flash going bad
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-08-18 12:55:33

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: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Michael DeMan |Sent: Wednesday, August 18, 1999 11:32 AM |To: usr-tc@lists.xmission.com |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" <mike@coredump.ae.usr.com> |>To: <usr-tc@lists.xmission.com> |>Subject: (usr-tc) RE: ARC flash going bad |>Date: Wed, Aug 18, 1999, 8:36 AM |> | |> |> |>|-----Original Message----- |>|From: owner-usr-tc@lists.xmission.com |>|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Michael DeMan |>|Sent: Wednesday, August 18, 1999 10:28 AM |>|To: usr-tc@lists.xmission.com |>|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 "majordomo@xmission.com" |> with "unsubscribe usr-tc" in the body of the message. |> For information on digests or retrieving files and old messages send |> "help" to the same address. Do not use quotes in your message. |> | |- | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" | with "unsubscribe usr-tc" in the body of the message. | For information on digests or retrieving files and old messages send | "help" to the same address. Do not use quotes in your message. |

Subject: Re: (usr-tc) Interface load SNMP data on Netservers?
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-18 13:07:37

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) TRAP disconnect reasons
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-18 13:18:35

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) DSP Signal Levels
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-08-18 14:02:42

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

Subject: (usr-tc) Acct-Terminate-Cause
From: mingkai <mingkai@pacific.net.sg>
Date: 1999-08-18 14:12:54

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

Subject: Re: (usr-tc) 2 ARC's - one chassis
From: Jason Kelton <cascade@keltec.com.au>
Date: 1999-08-18 14:39:59

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.

Subject: (usr-tc) PPP login failed
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1999-08-18 14:40:58

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

Subject: RE: (usr-tc) Internic
From: Robert von Bismarck <rvb@petrel.ch>
Date: 1999-08-18 17:02:56

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:jim@perigee.net] Sent: mercredi, 18. ao=FBt 1999 15:45 To: usr-tc@lists.xmission.com 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: jayh@iglou.com > Technical Support Team Leader Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 >=20 > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) Another dead ISDN link
From: K Mitchell <mitch@keyconn.net>
Date: 1999-08-18 17:10:22

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 mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: Re: (usr-tc) Another dead ISDN link
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-18 17:18:16

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Another dead ISDN link
From: K Mitchell <mitch@keyconn.net>
Date: 1999-08-18 17:43:23

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 mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: Re: (usr-tc) RE: ARC flash going bad
From: Bryan Wann <bwann@cwis.net>
Date: 1999-08-18 18:24:17

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 bwann@cwis.net CWIS Internet Services http://www.cwis.net

Subject: Re: (usr-tc) RE: ARC flash going bad
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-18 20:59:37

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) RE: ARC flash going bad
From: Ronald Kushner <ron@glis.net>
Date: 1999-08-18 23:09:17

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

Subject: Re: (usr-tc) 2 ARC's - one chassis
From: Jim Johnson <jim@perigee.net>
Date: 1999-08-19 08:33:57

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 <jim@perigee.net> > To: <usr-tc@lists.xmission.com> > 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 "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) Bad Modem monitoring
From: Eric Billeter <ebilleter@cableone.net>
Date: 1999-08-19 09:57:38

The SNMP_session and some others are included with MRTG. That's where I got them from Eric Billeter Internet Engineer Cable One, Inc. eric.billeter@cableone.net 602-364-6462 -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]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: +61 3 9486-8844 fax: +61 3 9486-6822 email: me@murf.net 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. > >eric.billeter@cableone.net >602-364-6462 > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Bad Modem monitoring
From: Brett Murphy <me@murf.net>
Date: 1999-08-19 10:34:05

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: +61 3 9486-8844 fax: +61 3 9486-6822 email: me@murf.net 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. > >eric.billeter@cableone.net >602-364-6462 >

Subject: (usr-tc) ISDN callback
From: Pete Ashdown <pashdown@xmission.com>
Date: 1999-08-19 12:02:12

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.

Subject: (usr-tc) Idle-Timeout & Session-Timeout
From: Jim Johnson <jim@perigee.net>
Date: 1999-08-19 12:09:57

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

Subject: (usr-tc) cistron radius rlogin "hint"
From: David Ernst <drernst@bloomington.in.us>
Date: 1999-08-19 15:29:03

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

Subject: Re: (usr-tc) 2 ARC's - one chassis
From: Jason Kelton <cascade@keltec.com.au>
Date: 1999-08-19 16:01:07

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

Subject: (usr-tc) Idle time
From: vito@aracnet.net
Date: 1999-08-19 17:27:07

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

Subject: Re: (usr-tc) Idle time
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-19 17:31:38

Thus spake vito@aracnet.net >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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Link dead after 8 Days
From: Ken Kirchner <kenk@shreve.net>
Date: 1999-08-19 17:32:29

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:kenk@shreve.net (___) (__) Asst SysAdmin .o. Voice (318) 222-2638 Ext 108 (__) (_) ShreveNet, Inc. .o. Fax (318) 213-6612 (_)

Subject: Re: (usr-tc) Idle time
From: Jim Johnson <jim@perigee.net>
Date: 1999-08-19 17:34:15

Yea. But why can't I get the ARC to do it from radius? Jim Jeff Mcadams wrote: > > Thus spake vito@aracnet.net > >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: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Idle time
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-19 17:37:39

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Out Calling
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-08-19 20:03:54

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. > slowe@universalcom.net > >

Subject: (usr-tc) Out Calling
From: Sam Lowe <slowe@universalcom.net>
Date: 1999-08-20 06:43:38

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. slowe@universalcom.net ------=_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:slowe@universalcom.net">slowe@universalcom.net</A><BR></FO= NT></DIV></BODY></HTML> ------=_NextPart_000_0080_01BEEAD7.552FB250--

Subject: Re: (usr-tc) Another dead ISDN link
From: K Mitchell <mitch@keyconn.net>
Date: 1999-08-20 07:16:56

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 mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: Re: (usr-tc) Another dead ISDN link
From: Sam Lowe <slowe@universalcom.net>
Date: 1999-08-20 07:18:06

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. slowe@universalcom.net ----- 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 mitch@keyconn.net > Keystone Connect Unlock Your World > Altoona, PA 814-941-5000 http://www.keyconn.net > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Idle time
From: Jim Johnson <jim@perigee.net>
Date: 1999-08-20 08:13:41

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: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) Modem errors.
From: Brice Ligget <ligget@twoalpha.net>
Date: 1999-08-20 08:28:00

<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>

Subject: Re: (usr-tc) Idle time
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-20 08:49:05

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Idle time
From: Jim Johnson <jim@perigee.net>
Date: 1999-08-20 09:14:31

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: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) Idle time
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-08-20 09:30:42

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: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jim Johnson |Sent: Friday, August 20, 1999 8:15 AM |To: usr-tc@lists.xmission.com |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: jeffm@iglou.com |> Head Network Administrator Voice: (502) 966-3848 |> IgLou Internet Services (800) 436-4456 |> |> - |> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" |> with "unsubscribe usr-tc" in the body of the message. |> For information on digests or retrieving files and old messages send |> "help" to the same address. Do not use quotes in your message. | |- | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" | with "unsubscribe usr-tc" in the body of the message. | For information on digests or retrieving files and old messages send | "help" to the same address. Do not use quotes in your message. |

Subject: Re: (usr-tc) Link dead after 8 Days
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-08-20 09:41:27

Nothing can be done. The DSP's have problems. I can't expect a customer to allow me to tinker with the the setup and run up their ISDN bill so I can "see if I can get it to work". THese are not leased lines, so I just explained that line drops are to be expected. Some people have them others don't. I have one business customer up for weeks using a BOCA 33.6 calling into another BOCA 33.6. But the OfficeConnect will not reliably call into the TC chassis. One vendor has it right (BOCA) the other one (3Com) dosen't. They are still much happier now then with thier other ISP..... they value the serivce more than the internet conncetion. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net 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:kenk@shreve.net (___) > (__) Asst SysAdmin .o. Voice (318) 222-2638 Ext 108 (__) > (_) ShreveNet, Inc. .o. Fax (318) 213-6612 (_) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Modem Failure monitor
From: Eric Billeter <ebilleter@cableone.net>
Date: 1999-08-20 09:58:03

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. eric.billeter@cableone.net 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--

Subject: Re: (usr-tc) Idle time
From: Jim Johnson <jim@perigee.net>
Date: 1999-08-20 10:04:44

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: jeffm@iglou.com > > Head Network Administrator Voice: (502) 966-3848 > > IgLou Internet Services (800) 436-4456 > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Another dead ISDN link
From: K Mitchell <mitch@keyconn.net>
Date: 1999-08-20 10:48:29

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 mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: Re: (usr-tc) Idle time
From: Jim Johnson <jim@perigee.net>
Date: 1999-08-20 11:31:04

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: owner-usr-tc@lists.xmission.com > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jim Johnson > |Sent: Friday, August 20, 1999 8:15 AM > |To: usr-tc@lists.xmission.com > |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: jeffm@iglou.com > |> Head Network Administrator Voice: (502) 966-3848 > |> IgLou Internet Services (800) 436-4456 > |> > |> - > |> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > |> with "unsubscribe usr-tc" in the body of the message. > |> For information on digests or retrieving files and old messages send > |> "help" to the same address. Do not use quotes in your message. > | > |- > | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > | with "unsubscribe usr-tc" in the body of the message. > | For information on digests or retrieving files and old messages send > | "help" to the same address. Do not use quotes in your message. > | > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Idle time
From: Jason Cropper <jason@clearsail.net>
Date: 1999-08-20 15:01:06

Sessesion-Timeout is specified in seconds. _jason Scot Desort wrote: > > Is 'SESSION-TIMEOUT' also in seconds, or is it in minutes? > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jim Johnson > > Sent: Friday, August 20, 1999 10:05 AM > > To: usr-tc@lists.xmission.com > > 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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Idle time
From: David Swearingin <david@carolnet.com>
Date: 1999-08-20 15:06:23

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: owner-usr-tc@lists.xmission.com >> > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jim Johnson >> > Sent: Friday, August 20, 1999 10:05 AM >> > To: usr-tc@lists.xmission.com >> > 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 "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 (david@carolnet.com) CARROLLTON INTERNET SERVICE (www.carolnet.com) First Financial Group, Inc. 11 N. Folger, Carrollton, MO 64633 660-542-3002 Fax 660-542-3003

Subject: RE: (usr-tc) Idle time
From: Scot Desort <scot@njaccess.net>
Date: 1999-08-20 15:51:41

Is 'SESSION-TIMEOUT' also in seconds, or is it in minutes? > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jim Johnson > Sent: Friday, August 20, 1999 10:05 AM > To: usr-tc@lists.xmission.com > 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

Subject: Re: (usr-tc) allowing one user to auth on one channel...
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-08-20 21:37:52

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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Jeff Lynch <jeff@mercury.jorsm.com>
Date: 1999-08-21 09:26:11

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 <scot@njaccess.net>, 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: jeff@jorsm.com | 7 Area Codes in Chicagoland and NW Indiana Voice: (219)322-2180 | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN Autoresponse: info@jorsm.com | Quality Service, Affordable Prices http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995

Subject: (usr-tc) allowing one user to auth on one channel...
From: Rick <rickyz@mindspring.com>
Date: 1999-08-21 10:24:32

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

Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Jeff Lynch <jeff@mercury.jorsm.com>
Date: 1999-08-21 10:37:23

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: jeff@jorsm.com | 7 Area Codes in Chicagoland and NW Indiana Voice: (219)322-2180 | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN Autoresponse: info@jorsm.com | Quality Service, Affordable Prices http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995

Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Ed <ed@taylors.com>
Date: 1999-08-21 11:05:16

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 <scot@njaccess.net>, 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: jeff@jorsm.com | 7 Area Codes in Chicagoland and NW Indiana Voice: (219)322-2180 | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN Autoresponse: info@jorsm.com | Quality Service, Affordable Prices http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Jim Johnson <jim@perigee.net>
Date: 1999-08-21 11:10:17

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 <jeff@mercury.jorsm.com> > To: <usr-tc@lists.xmission.com> > 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 <scot@njaccess.net>, 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: jeff@jorsm.com | 7 Area Codes in Chicagoland and NW Indiana > Voice: (219)322-2180 | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN > Autoresponse: info@jorsm.com | Quality Service, Affordable Prices > http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Ed <ed@taylors.com>
Date: 1999-08-21 11:52:01

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 <jeff@mercury.jorsm.com> > To: <usr-tc@lists.xmission.com> > 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 <scot@njaccess.net>, 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: jeff@jorsm.com | 7 Area Codes in Chicagoland and NW Indiana > Voice: (219)322-2180 | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN > Autoresponse: info@jorsm.com | Quality Service, Affordable Prices > http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Ed <ed@taylors.com>
Date: 1999-08-21 11:59:57

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: jeff@jorsm.com | 7 Area Codes in Chicagoland and NW Indiana Voice: (219)322-2180 | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN Autoresponse: info@jorsm.com | Quality Service, Affordable Prices http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) Need help with Netserver 8i
From: Greg Coffey <gcoffey@vcn.com>
Date: 1999-08-21 13:48:42

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 <gcoffey@vcn.com> 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

Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Charles Sprickman <spork@inch.com>
Date: 1999-08-21 14:22:59

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 <jeff@mercury.jorsm.com> > To: <usr-tc@lists.xmission.com> > 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 <scot@njaccess.net>, 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: jeff@jorsm.com | 7 Area Codes in Chicagoland and NW Indiana > Voice: (219)322-2180 | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN > Autoresponse: info@jorsm.com | Quality Service, Affordable Prices > http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995 > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Ed <ed@taylors.com>
Date: 1999-08-21 14:44:30

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 <jeff@mercury.jorsm.com> > To: <usr-tc@lists.xmission.com> > 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 <scot@njaccess.net>, 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: jeff@jorsm.com | 7 Area Codes in Chicagoland and NW Indiana > Voice: (219)322-2180 | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN > Autoresponse: info@jorsm.com | Quality Service, Affordable Prices > http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995 > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) allowing one user to auth on one channel...
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-08-21 20:17:27

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:tkrishna@bubba.ae.usr.com] > Sent: Friday, August 20, 1999 10:38 PM > To: Rick > Cc: usr-tc@lists.xmission.com > 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 "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Charles Sprickman <spork@inch.com>
Date: 1999-08-21 22:26:22

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 <spork@inch.com> > To: <usr-tc@lists.xmission.com> > 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 <jeff@mercury.jorsm.com> > > To: <usr-tc@lists.xmission.com> > > 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 <scot@njaccess.net>, 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: jeff@jorsm.com | 7 Area Codes in Chicagoland and NW Indiana > > Voice: (219)322-2180 | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN > > Autoresponse: info@jorsm.com | Quality Service, Affordable Prices > > http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995 > > > > > > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) allowing one user to auth on one channel...
From: Rick <rickyz@mindspring.com>
Date: 1999-08-21 23:32:15

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

Subject: (usr-tc) looking for info on CFM file format from File MIB
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-08-22 04:16:52

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

Subject: (usr-tc) anyone tell me what these attributes are?
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-08-22 06:17:38

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

Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-22 09:11:09

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Scot Desort <scot@njaccess.net>
Date: 1999-08-22 11:20:38

Well done, Jeff. -Scot Desort NJ Internet Access -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Ed <ed@taylors.com>
Date: 1999-08-22 13:49:09

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) anyone tell me what these attributes are?
From: Nicolas St-Pierre <nstpierre@iasl.com>
Date: 1999-08-22 18:49:34

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 (905) 469-4953 Fax (905) 469-4954

Subject: (usr-tc) Radius Attributes
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-08-22 21:03:28

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 ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec

Subject: (usr-tc) Radius Attributes
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-08-22 21:03:28

Subject: Re: (usr-tc) HiperARC redundancy
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-23 00:44:12

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-08-23 06:35:39

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

Subject: (usr-tc) Radius questions
From: Jamie Orzechowski <mhz@ripnet.com>
Date: 1999-08-23 08:04:49

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???

Subject: Re: (usr-tc) HiperARC redundancy
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-23 08:04:56

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Radius questions
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-23 08:16:26

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) cistron radius rlogin "hint"
From: David Ernst <drernst@bloomington.in.us>
Date: 1999-08-23 08:22:04

Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-08-23 08:42:13

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

Subject: Re: (usr-tc) Radius Attributes
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-08-23 08:44:47

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

Subject: Re: (usr-tc) HiperARC redundancy
From: Brian Gordon <administrator@westelcom.com>
Date: 1999-08-23 09:14:01

Okay question about this.... Any problems running load balancing and hiper arc redundancy? Brian Gordon brian@westelcom.com ----- 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: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-08-23 09:20:20

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 570-628-5545 farber@admin.f-tech.net 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 <spork@inch.com> > > To: <usr-tc@lists.xmission.com> > > 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 <jeff@mercury.jorsm.com> > > > To: <usr-tc@lists.xmission.com> > > > 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 <scot@njaccess.net>, 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: jeff@jorsm.com | 7 Area Codes in Chicagoland and NW Indiana > > > Voice: (219)322-2180 | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN > > > Autoresponse: info@jorsm.com | Quality Service, Affordable Prices > > > http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995 > > > > > > > > > > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) simple question
From: Steve Valiunas <steve_valiunas@mw.3com.com>
Date: 1999-08-23 09:27:20

Save UI to EEPROM instead of Save to NVRAM. "Stainforth, Matthew" <MatthewS@staff.brunnet.net> on 08/16/99 02:31:34 PM Please respond to usr-tc@lists.xmission.com Sent by: "Stainforth, Matthew" <MatthewS@staff.brunnet.net> 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 "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) HiperARC redundancy
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-23 09:28:34

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Jim Curran <jim_curran@mw.3com.com>
Date: 1999-08-23 09:49:57

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

Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-08-23 10:26:49

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 570-628-5545 farber@admin.f-tech.net 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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) 1.2.43 -> 1.2.37
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-08-23 11:36:10

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

Subject: (usr-tc) HiperARC redundancy
From: das <das@gol.com>
Date: 1999-08-23 12:19:19

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: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 The Highest Quality Service, Bar None ____________________________________________

Subject: (usr-tc) 1.2.43 -> 1.2.37
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-23 13:47:18

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) Since HiperArc "upgrade" Couriers can't connect
From: Blake Fithen <fithen@networksplus.com>
Date: 1999-08-23 14:24:51

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: 'usr-tc@lists.xmission.com' > 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:fithen@NetworksPlus.com] > > Sent: Wednesday, March 24, 1999 6:40 PM > > To: 'usr-tc@lists.xmission.com' > > 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:mikeh@drfast.net] > > > Sent: Sunday, March 21, 1999 10:13 PM > > > To: usr-tc@lists.xmission.com > > > 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 <fithen@NetworksPlus.com> > > > To: 'usr-tc@lists.xmission.com' <usr-tc@lists.xmission.com> > > > 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:mhamrich@drfast.net] > > > >> Sent: Thursday, March 18, 1999 7:21 PM > > > >> To: usr-tc@lists.xmission.com > > > >> 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. > > > >> (216) 797-1040 > > > >> > > > >> > > > >> - > > > >> To unsubscribe to usr-tc, send an email to > > > "majordomo@xmission.com" > > > >> with "unsubscribe usr-tc" in the body of the message. > > > >> For information on digests or retrieving files and old > > > messages send > > > >> "help" to the same address. Do not use quotes in > your message. > > > >> > > > > > > > >- > > > > To unsubscribe to usr-tc, send an email to > > "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old > > messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > - > > > To unsubscribe to usr-tc, send an email to > "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old > > messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old > messages send > > "help" to the same address. Do not use quotes in your message. > > >

Subject: Re: (usr-tc) HiperARC redundancy
From: das <das@gol.com>
Date: 1999-08-23 14:39:01

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 (jeffm@iglou.com) 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: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 The Highest Quality Service, Bar None ____________________________________________

Subject: Re: (usr-tc) 1.2.43 -> 1.2.37
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-23 14:41:36

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) 1.2.43 -> 1.2.37
From: Jamie Orzechowski <mhz@ripnet.com>
Date: 1999-08-23 14:48:08

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: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >

Subject: Re: (usr-tc) Setting the Long Haul buildout
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-08-23 14:48:47

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

Subject: (usr-tc) VPNs and Total Control HUBS
From: pferraro@wna-linknet.com
Date: 1999-08-23 15:41:11

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 pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ==============================================================================

Subject: Re: (usr-tc) Setting the Long Haul buildout
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-08-23 15:49:29

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

Subject: Re: (usr-tc) New DSPs
From: Todd Keister <todd_keister@mw.3com.com>
Date: 1999-08-23 15:57:01

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 <mitch@keyconn.net> on 08/23/99 03:11:45 PM Please respond to usr-tc@lists.xmission.com Sent by: K Mitchell <mitch@keyconn.net> 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 mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) New DSPs
From: K Mitchell <mitch@keyconn.net>
Date: 1999-08-23 16:11:45

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 mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: (usr-tc) Telepath Modem Woes
From: Brian <signal@shreve.net>
Date: 1999-08-23 16:19:10

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) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Brian <signal@shreve.net>
Date: 1999-08-23 16:24:26

> > 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 <spork@inch.com> > To: <usr-tc@lists.xmission.com> > 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 <jeff@mercury.jorsm.com> > > To: <usr-tc@lists.xmission.com> > > 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 <scot@njaccess.net>, 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: jeff@jorsm.com | 7 Area Codes in Chicagoland and NW Indiana > > Voice: (219)322-2180 | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN > > Autoresponse: info@jorsm.com | Quality Service, Affordable Prices > > http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995 > > > > > > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: (usr-tc) Setting the Long Haul buildout
From: Brian <signal@shreve.net>
Date: 1999-08-23 16:28:31

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) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: RE: (usr-tc) Setting the Long Haul buildout
From: Scot Desort <scot@njaccess.net>
Date: 1999-08-23 18:18:10

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: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil > Sent: Monday, August 23, 1999 5:49 PM > To: usr-tc@lists.xmission.com > 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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Blake Fithen <fithen@networksplus.com>
Date: 1999-08-23 18:51:07

> -----Original Message----- > From: Aaron Nabil [mailto:nabil@spiritone.com] > Sent: Monday, August 23, 1999 8:36 AM > To: usr-tc@lists.xmission.com > 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

Subject: RE: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-08-24 00:39:43

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 570-628-5545 farber@admin.f-tech.net On Mon, 23 Aug 1999, Blake Fithen wrote: > > -----Original Message----- > > From: Aaron Nabil [mailto:nabil@spiritone.com] > > Sent: Monday, August 23, 1999 8:36 AM > > To: usr-tc@lists.xmission.com > > 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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) v.90 and Other connection Problems
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-08-24 00:45:54

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 570-628-5545 farber@admin.f-tech.net 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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) v.90 and Other connection Problems
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-08-24 00:45:54

Subject: (usr-tc) v.90 and Other connection Problems
From: Tavis Morse <tavism@norfolk-county.com>
Date: 1999-08-24 02:45:17

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.

Subject: (usr-tc) S/A Server
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1999-08-24 07:49:00

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 userid@mydomain.com 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 userid@mydomain.com, 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

Subject: (usr-tc) S/A SERVER
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1999-08-24 07:49:00

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 userid@mydomain.com 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 userid@mydomain.com, 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

Subject: Re: (usr-tc) HiperARC redundancy
From: das <das@gol.com>
Date: 1999-08-24 09:29:18

Thanks again, Jeff. das Jeff Mcadams (jeffm@iglou.com) 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: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 The Highest Quality Service, Bar None ____________________________________________

Subject: Re: (usr-tc) v.90 and Other connection Problems
From: Tavis Morse <tavism@ncounty.net>
Date: 1999-08-24 10:16:42

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 570-628-5545 >farber@admin.f-tech.net > >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 "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >

Subject: Re: (usr-tc) Telepath Modem Woes
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-08-24 11:37:42

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 mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- 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?

Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Pete Ashdown <pashdown@xmission.com>
Date: 1999-08-24 11:45:33

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.

Subject: (usr-tc) List etiquette
From: Pete Ashdown <pashdown@xmission.com>
Date: 1999-08-24 11:54:59

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.

Subject: Re: (usr-tc) Rockwell / Conexant HCF Modem does not connect
From: Pete Ashdown <pashdown@xmission.com>
Date: 1999-08-24 12:58:32

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.

Subject: (usr-tc) Radius Questions
From: Jamie Orzechowski <mhz@ripnet.com>
Date: 1999-08-24 14:49:35

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??

Subject: Re: (usr-tc) S/A Server
From: Corneliu Rudeanu <rudy@dntis.ro>
Date: 1999-08-24 15:31:28

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 > userid@mydomain.com 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 > userid@mydomain.com, 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: +40-32-252938 FAX: +40-32-252933 http://www.dntis.ro

Subject: Re: (usr-tc) Radius Questions
From: florin_neamtu@3com.com
Date: 1999-08-24 16:33:36

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.

Subject: (usr-tc) OSPF?
From: Steve Coleman <scoleman2@csolutions.net>
Date: 1999-08-24 20:20:02

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

Subject: Re: (usr-tc) OSPF?
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-24 22:22:33

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) updated DSP from 1.2.37 to 2.0.81
From: Dave Martin <dpm@netcetera.com>
Date: 1999-08-25 10:53:56

>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: 601.634.1952 > 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. dpm@netcetera.com "Infinity Welcomes Careful Drivers"

Subject: (usr-tc) updated DSP from 1.2.37 to 2.0.81
From: Matthew Opoka <phantom@pemberton.magnolia.net>
Date: 1999-08-25 12:40:46

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: 601.634.1952

Subject: (usr-tc) WTB: USR 70A Power supplies
From: Steve Rivera <sales@wrca.net>
Date: 1999-08-25 12:48:06

Looking for 5- Power supplies. USR 70A Please forward available equipment to sales@wrca.net .................................................... Steve Rivera - VP-WR Consultant Associates, Inc. (WRCA) sales@wrca.net 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

Subject: (usr-tc) WTB: MP16I
From: Steve Rivera <sales@wrca.net>
Date: 1999-08-25 13:37:43

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) sales@wrca.net 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

Subject: Re: (usr-tc) updated DSP from 1.2.37 to 2.0.81
From: Matthew Opoka <phantom@pemberton.magnolia.net>
Date: 1999-08-25 13:41:15

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: 601.634.1952 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: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) WTB: MP16I
From: gk <gk@skypoint.com>
Date: 1999-08-25 13:44:08

> 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 : +1 612 417 0227 : +1 612 417 0207 : : Plymouth, MN 55447-0804 : gk@skypoint.com : gk@webspan.com : : fax +1 612 449 0488 : Internet connectivity : Web page development:

Subject: Re: (usr-tc) updated DSP from 1.2.37 to 2.0.81
From: Tavis Morse <tavism@ncounty.net>
Date: 1999-08-25 14:14:02

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

Subject: Re: (usr-tc) updated DSP from 1.2.37 to 2.0.81
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-25 14:34:06

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) WTB: MP16I
From: Steve Rivera <sales@wrca.net>
Date: 1999-08-25 16:55:01

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 : +1 612 417 0227 : +1 612 417 0207 : >: Plymouth, MN 55447-0804 : gk@skypoint.com : gk@webspan.com : >: fax +1 612 449 0488 : Internet connectivity : Web page development: > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) WTB: MP16I
From: Steve Rivera <sales@wrca.net>
Date: 1999-08-25 16:58:35

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 : +1 612 417 0227 : +1 612 417 0207 : >: Plymouth, MN 55447-0804 : gk@skypoint.com : gk@webspan.com : >: fax +1 612 449 0488 : Internet connectivity : Web page development: > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) B8ZS vs AMI
From: Brian Becker <brian@semo.net>
Date: 1999-08-26 08:45:46

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.

Subject: Re: (usr-tc) HiPerDSP 2.0.81 and 2.0.19 differences ?
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-26 09:13:10

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) B8ZS vs AMI
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 1999-08-26 11:12:07

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:brian@semo.net] 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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) B8ZS vs AMI
From: Brian Becker <brian@semo.net>
Date: 1999-08-26 11:23:48

Our installs are all channelized T1's rather than PRI running from a DMS10/100 on the TELCO side. -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]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:brian@semo.net] 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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) B8ZS vs AMI
From: Nicolas St-Pierre <nstpierre@iasl.com>
Date: 1999-08-26 13:32:06

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:brian@semo.net] > 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 (905) 469-4953 Fax (905) 469-4954

Subject: Re: (usr-tc) B8ZS vs AMI
From: Russ Miescke <russm@powerweb.net>
Date: 1999-08-26 13:41:42

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: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stainforth, Matthew > Sent: Thursday, August 26, 1999 09:12 AM > To: 'usr-tc@lists.xmission.com' > 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:brian@semo.net] > 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 "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) B8ZS vs AMI
From: Brian Becker <brian@semo.net>
Date: 1999-08-26 14:08:25

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:owner-usr-tc@lists.xmission.com]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: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stainforth, Matthew > Sent: Thursday, August 26, 1999 09:12 AM > To: 'usr-tc@lists.xmission.com' > 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:brian@semo.net] > 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 "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) B8ZS vs AMI
From: Russ Miescke <russm@powerweb.net>
Date: 1999-08-26 14:36:21

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: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Russ Miescke > Sent: Thursday, August 26, 1999 03:42 PM > To: usr-tc@lists.xmission.com > 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 <brian@semo.net> > To: <usr-tc@lists.xmission.com> > 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: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stainforth, Matthew > > Sent: Thursday, August 26, 1999 09:12 AM > > To: 'usr-tc@lists.xmission.com' > > 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:brian@semo.net] > > 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 "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) HiPerDSP 2.0.81 and 2.0.19 differences ?
From: Robert von Bismarck <rvb@petrel.ch>
Date: 1999-08-26 14:41:41

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

Subject: RE: (usr-tc) B8ZS vs AMI
From: Brian Becker <brian@semo.net>
Date: 1999-08-26 15:02:21

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:owner-usr-tc@lists.xmission.com]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: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Russ Miescke > Sent: Thursday, August 26, 1999 03:42 PM > To: usr-tc@lists.xmission.com > 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 <brian@semo.net> > To: <usr-tc@lists.xmission.com> > 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: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stainforth, Matthew > > Sent: Thursday, August 26, 1999 09:12 AM > > To: 'usr-tc@lists.xmission.com' > > 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:brian@semo.net] > > 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 "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) B8ZS vs AMI
From: Russ Miescke <russm@powerweb.net>
Date: 1999-08-26 16:32:04

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: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Russ Miescke > Sent: Thursday, August 26, 1999 04:36 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) B8ZS vs AMI > > > It works. Not sure how. > Russ Miescke > ----- Original Message ----- > From: Brian Becker <brian@semo.net> > To: <usr-tc@lists.xmission.com> > 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: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Russ Miescke > > Sent: Thursday, August 26, 1999 03:42 PM > > To: usr-tc@lists.xmission.com > > 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 <brian@semo.net> > > To: <usr-tc@lists.xmission.com> > > 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: owner-usr-tc@lists.xmission.com > > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stainforth, Matthew > > > Sent: Thursday, August 26, 1999 09:12 AM > > > To: 'usr-tc@lists.xmission.com' > > > 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:brian@semo.net] > > > 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 "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) HiPerDSP 2.0.81 and 2.0.19 differences ?
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-08-26 17:23:34

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 mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com "If you're not part of the solution.... you're part of the precipitate."

Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-08-26 17:38:13

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 mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com "If you're not part of the solution.... you're part of the precipitate."

Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Steve McConnell <stevem@emji.net>
Date: 1999-08-26 17:49:53

--On Thursday, August 26, 1999, 5:38 PM -0400 Mike Andrews <mandrews@bit0.com> 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

Subject: Re: (usr-tc) HiPerDSP 2.0.81 and 2.0.19 differences ?
From: John Nelson <johnn@jorsm.com>
Date: 1999-08-26 19:28:34

>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 | johnn@jorsm.com < > ---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 < >=========================================================<

Subject: Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-26 19:39:12

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) DLL Invalid
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-08-26 22:22:35

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 ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ 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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) DLL Invalid
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-08-26 22:39:25

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:tkrishna@bubba.ae.usr.com] > 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 ............ \ > ----------------------------------------------/ > tkrishna@bubba.ae.usr.com > ----------------------------/ 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 "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) B8ZS vs AMI
From: Jeff Lynch <jeff@mercury.jorsm.com>
Date: 1999-08-26 23:16:40

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: jeff@jorsm.com | 7 Area Codes in Chicagoland and NW Indiana Voice: (219)322-2180 | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN Autoresponse: info@jorsm.com | Quality Service, Affordable Prices http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995

Subject: Re: (usr-tc) B8ZS vs AMI
From: Jeff Lynch <jeff@mercury.jorsm.com>
Date: 1999-08-26 23:26:01

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: jeff@jorsm.com | 7 Area Codes in Chicagoland and NW Indiana Voice: (219)322-2180 | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN Autoresponse: info@jorsm.com | Quality Service, Affordable Prices http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995

Subject: RE: (usr-tc) radius authentication problem with harc
From: Marshall Morgan <marshall@netdoor.com>
Date: 1999-08-27 02:39:48

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: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of das > Sent: Thursday, August 26, 1999 9:32 PM > To: usr-tc@lists.xmission.com > 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: 81-3-5334-1700 > Systems Engineer FAX: 81-3-5334-1711 > The Highest Quality Service, Bar None > ____________________________________________ > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >

Subject: Re: (usr-tc) WTB: MP16I
From: gk <gk@skypoint.com>
Date: 1999-08-27 06:44:59

>>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 : +1 612 417 0227 : +1 612 417 0207 : : Plymouth, MN 55447-0804 : gk@skypoint.com : gk@webspan.com : : fax +1 612 449 0488 : Internet connectivity : Web page development:

Subject: Re: (usr-tc) B8ZS vs AMI
From: Jeff Lynch <jeff@mercury.jorsm.com>
Date: 1999-08-27 08:17:41

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: jeff@jorsm.com | 7 Area Codes in Chicagoland and NW Indiana Voice: (219)322-2180 | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN Autoresponse: info@jorsm.com | Quality Service, Affordable Prices http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995

Subject: Re: (usr-tc) B8ZS vs AMI (Repost)
From: Jeff Lynch <jeff@mercury.jorsm.com>
Date: 1999-08-27 08:21:24

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: jeff@jorsm.com | 7 Area Codes in Chicagoland and NW Indiana Voice: (219)322-2180 | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN Autoresponse: info@jorsm.com | Quality Service, Affordable Prices http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995

Subject: RE: (usr-tc) B8ZS vs AMI (Repost)
From: Jeff Lynch <jeff@mercury.jorsm.com>
Date: 1999-08-27 08:22:32

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: jeff@jorsm.com | 7 Area Codes in Chicagoland and NW Indiana Voice: (219)322-2180 | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN Autoresponse: info@jorsm.com | Quality Service, Affordable Prices http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995

Subject: Re: (usr-tc) B8ZS vs AMI (Repost)
From: Jeff Lynch <jeff@mercury.jorsm.com>
Date: 1999-08-27 08:26:17

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: jeff@jorsm.com | 7 Area Codes in Chicagoland and NW Indiana Voice: (219)322-2180 | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN Autoresponse: info@jorsm.com | Quality Service, Affordable Prices http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995

Subject: Re: (usr-tc) B8ZS vs AMI
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1999-08-27 09:08:00

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

Subject: (usr-tc) TRAPS
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-08-27 10:20:33

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 570-628-5545 farber@admin.f-tech.net

Subject: Re: (usr-tc) TRAPS
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-27 10:23:59

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) Receiver Gain
From: Brian <signal@shreve.net>
Date: 1999-08-27 10:49:55

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) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: Re: (usr-tc) HiPerDSP 2.0.81 and 2.0.19 differences ?
From: Brian A. Buffington <draconis@bridgernet.com>
Date: 1999-08-27 10:55:51

> >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

Subject: (usr-tc) V.90 delivering "as promised"
From: Richard Gamberg <bbhi@shaka.com>
Date: 1999-08-27 11:12:35

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/

Subject: (usr-tc) radius authentication problem with harc
From: das <das@gol.com>
Date: 1999-08-27 11:31:50

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: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 The Highest Quality Service, Bar None ____________________________________________

Subject: RE: (usr-tc) DLL Invalid
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-08-27 11:52:09

Subject: (usr-tc) DLL Invalid
From: Phil Le Clercq <phil.le.clercq@cinergy.net>
Date: 1999-08-27 16:15:13

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

Subject: RE: (usr-tc) DLL Invalid
From: Phil Le Clercq <phil.le.clercq@cinergy.net>
Date: 1999-08-27 16:39:20

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 ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ 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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) TRAPS
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-08-27 16:43:22

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 570-628-5545 farber@admin.f-tech.net 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: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) DLL Invalid
From: Phil Le Clercq <phil.le.clercq@cinergy.net>
Date: 1999-08-27 16:51:30

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:tkrishna@bubba.ae.usr.com] > 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 ............ \ > ----------------------------------------------/ > tkrishna@bubba.ae.usr.com > ----------------------------/ 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 "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) B8ZS vs AMI
From: Frederick R. Doncillo <fred@skyinet.net>
Date: 1999-08-27 17:24:32

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: jeff@jorsm.com | 7 Area Codes in Chicagoland and NW Indiana > Voice: (219)322-2180 | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN > Autoresponse: info@jorsm.com | Quality Service, Affordable Prices > http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) V.90 delivering "as promised"
From: Peter Olson <peter.olson@chi.frb.org>
Date: 1999-08-27 17:25:24

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

Subject: Re: (usr-tc) radius authentication problem with harc
From: das <das@gol.com>
Date: 1999-08-27 17:35:32

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 (marshall@netdoor.com) 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: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of das > > Sent: Thursday, August 26, 1999 9:32 PM > > To: usr-tc@lists.xmission.com > > 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: 81-3-5334-1700 > > Systems Engineer FAX: 81-3-5334-1711 > > The Highest Quality Service, Bar None > > ____________________________________________ > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 The Highest Quality Service, Bar None ____________________________________________

Subject: Re: (usr-tc) B8ZS vs AMI (Repost)
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-08-27 23:03:25

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

Subject: Re: (usr-tc) DLL Invalid
From: das <das@gol.com>
Date: 1999-08-28 01:41:55

I would always get that when I would have the switch type set incorrectly on the dsp card. das Phil Le Clercq (phil.le.clercq@cinergy.net) 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:tkrishna@bubba.ae.usr.com] > 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:tkrishna@bubba.ae.usr.com] > > 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 ............ \ > > ----------------------------------------------/ > > tkrishna@bubba.ae.usr.com > > ----------------------------/ 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 "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 The Highest Quality Service, Bar None ____________________________________________

Subject: Re: (usr-tc) B8ZS vs AMI (Repost)
From: Jeff Lynch <jeff@mercury.jorsm.com>
Date: 1999-08-28 09:09:08

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: jeff@jorsm.com | 7 Area Codes in Chicagoland and NW Indiana Voice: (219)322-2180 | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN Autoresponse: info@jorsm.com | Quality Service, Affordable Prices http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995

Subject: (usr-tc) Keep-alive traffic?
From: K Mitchell <mitch@keyconn.net>
Date: 1999-08-29 21:35:45

Subject: Re: (usr-tc) Keep-alive traffic?
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-08-29 22:39:08

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 mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- 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 | >

Subject: Re: (usr-tc) Keep-alive traffic?
From: K Mitchell <mitch@keyconn.net>
Date: 1999-08-29 23:15:47

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 mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: Re: (usr-tc) Keep-alive traffic?
From: K Mitchell <mitch@keyconn.net>
Date: 1999-08-29 23:36:54

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 mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: Re: (usr-tc) Keep-alive traffic?
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-08-30 01:49:32

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 mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com "If you're not part of the solution.... you're part of the precipitate."

Subject: (usr-tc) SNMP OID to reset card
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-08-30 10:05:51

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 570-628-5545 farber@admin.f-tech.net

Subject: Re: (usr-tc) radius authentication problem with harc
From: Steve Valiunas <steve_valiunas@mw.3com.com>
Date: 1999-08-30 10:09:30

Verify that the accounting secrets match between radius and the Harc- (there is none by default on the Harc). STeve das <das@gol.com> on 08/26/99 09:31:50 PM Please respond to usr-tc@lists.xmission.com Sent by: das <das@gol.com> 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: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 The Highest Quality Service, Bar None ____________________________________________ - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) TCM under X/Wine
From: Nicolas St-Pierre <nstpierre@iasl.com>
Date: 1999-08-30 10:58:51

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 (905) 469-4953 Fax (905) 469-4954

Subject: Re: (usr-tc) SNMP OID to reset card
From: Pete Ashdown <pashdown@xmission.com>
Date: 1999-08-30 11:55:12

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.

Subject: Re: (usr-tc) TCM under X/Wine
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-08-30 13:54:30

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 570-628-5545 farber@admin.f-tech.net 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 (905) 469-4953 > Fax (905) 469-4954 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) IP Spoofing
From: Russ Miescke <russm@powerweb.net>
Date: 1999-08-30 14:02:32

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

Subject: (usr-tc) TCM Probs
From: Jamie Orzechowski <mhz@ripnet.com>
Date: 1999-08-30 14:45:45

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 570-628-5545 > farber@admin.f-tech.net > > 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 (905) 469-4953 > > Fax (905) 469-4954 > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >

Subject: Re: (usr-tc) Need used TC Units
From: Andrew:PC Global, Inc. <andrew@pcglobal.net>
Date: 1999-08-30 14:55:48

Can you use v.34 token ring chassis? Andrew Shlensky **************************** PC Global, Inc. (602) 438-6200 office (NEW TEL NUMBER!) (602) 438-1119 fax (305) 216-8638 mobile New!e-mail my mobile http://www.nextel.com/paging URL: http://www.pcglobal.net E-MAIL: andrew@pcglobal.net 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 (800) 664-5270 jsinger@i-c.net - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) IP Spoofing
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-08-30 15:07:38

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 <russm@powerweb.net> >To: <usr-tc@lists.xmission.com> >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

Subject: (usr-tc) Need used TC Units
From: Jack Singer <jsinger@aaacars.com>
Date: 1999-08-30 15:56:18

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 (800) 664-5270 jsinger@i-c.net

Subject: (usr-tc) WTB: Hyper DSP card
From: Steve Rivera <sales@wrca.net>
Date: 1999-08-30 16:13:00

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) sales@wrca.net 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

Subject: (usr-tc) IPX Usage
From: Jamie Orzechowski <mhz@ripnet.com>
Date: 1999-08-30 16:19:44

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 ??

Subject: Re: (usr-tc) IP Spoofing
From: Jamie Orzechowski <mhz@ripnet.com>
Date: 1999-08-30 16:21:33

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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >

Subject: Re: (usr-tc) SNMP OID to reset card
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-08-30 16:26:11

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 570-628-5545 farber@admin.f-tech.net 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 "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) DSPs, NFAS, 1 ARC
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 1999-08-30 16:31:54

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?

Subject: Re: (usr-tc) Need used TC Units
From: Jack Singer <jsinger@aaacars.com>
Date: 1999-08-30 21:52:58

If it is cheap enough.... Jack "Andrew:PC Global, Inc." wrote: > Can you use v.34 token ring chassis? > > Andrew Shlensky > **************************** > PC Global, Inc. > (602) 438-6200 office (NEW TEL NUMBER!) > (602) 438-1119 fax > (305) 216-8638 mobile > New!e-mail my mobile http://www.nextel.com/paging > URL: http://www.pcglobal.net > E-MAIL: andrew@pcglobal.net > 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 <jsinger@aaacars.com> > To: <usr-tc@lists.xmission.com> > 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 > (800) 664-5270 > jsinger@i-c.net > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) Appology Mr. PC Global and his Spam
From: Andrew:PC Global, Inc. <andrew@pcglobal.net>
Date: 1999-08-31 08:06:56

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: s1kevin@tims.net 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 "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) Mr. PC Global and his Spam
From: Phil Le Clercq <phil.le.clercq@cinergy.net>
Date: 1999-08-31 09:20:52

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 (602) 438-6200 Tel (602) 438-1119 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. > (602) 438-6200 office (NEW TEL NUMBER!) > (602) 438-1119 fax > (305) 216-8638 mobile > New!e-mail my mobile http://www.nextel.com/paging > URL: http://www.pcglobal.net > E-MAIL: andrew@pcglobal.net > 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 <jsinger@aaacars.com> > To: <usr-tc@lists.xmission.com> > 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 > (800) 664-5270 > jsinger@i-c.net > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) Equivalent of "set reported" for HiPer ARC?
From: D Mayer <dmayer@netwalk.com>
Date: 1999-08-31 10:00:54

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 dmayer@netwalk.com

Subject: Re: (usr-tc) Mr. PC Global and his Spam
From: Kevin Benton <s1kevin@tims.net>
Date: 1999-08-31 10:01:29

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: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

Subject: Re: (usr-tc) Equivalent of "set reported" for HiPer ARC?
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-08-31 10:08:31

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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) RE: IP Spoofing
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-08-31 10:51:34

Subject: (usr-tc) TC and Cistron
From: Tavis Morse <tavism@ncounty.net>
Date: 1999-08-31 13:13:28

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

Subject: (usr-tc) USR Hyper Cards/Bundles & Digital Modem Wont answer ?
From: Steve Rivera <sales@wrca.net>
Date: 1999-08-31 13:40:19

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) sales@wrca.net 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

Messages