September 1998

An "OE" in DMS speak is physical port your equipment is connected to. Its the way the switch identifies an individual line port, exclusive of the phone number assigned to it. Not sure what he's trying to tell you from that though. At 02:59 PM 9/17/98 -0400, you wrote: > >We're having immense trouble with our telco, BellSouth (known hereafter >as The BEAST). One representative of The BEAST, who works at the CO locally, >told us that all of our lines are `OEs' (Pronounced Oh-Ees), and that we might >have better results with trunks. > >What's the difference? > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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. 875 Ouellette Avenue Windsor, Ontario N9A 4J6 tel. 519-985-8410 fax. 519-258-3009

I have a TC hub here and some v.34 analog cards and some analog nics. I decided to put it together and try it. It all works EXCEPT I cannot get a dialtone on ANY of the modems. I can type AT and get OK, etc... I have tried different phone cords, etc... made sure the line was live. I looked in the manual and it shows that the analog NIC's should have daughtercards. NONE of the NICs I have, have those daughtercards even tho they are all labeled as ANALOG. Is this my problem? ~~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ Jake Messinger ph:713-772-6690 Lucent Dealer AMS, Inc. fx:713-774-3498 Medical Billing 8300 Bissonnet #400 jake@ams.com , ICQ# 4403734 Internet Services Houston, Texas 77074 www.ams.com/~jake and Hardware ~~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~

The high power constellation is defaulting the output power in x2 mode to -6db (as opposed to the default of -12db). Note, -6 is "louder" than -12. The advantage to enabling it is many people will get faster download speeds (that will vary site to site) as -6db uses more PCM codewords and is able to generate a constellation with more data points. The disadvantage is the increase of power will cause louder echo and may (probably will) decrease the backchannel (upload direction) speed. There is also a risk of distortion at the higher levels. In V.90 the setting is more "fine tunable", you can increase it in 1db increments. Though this varies depending on how the PTT's loss plan is implemented, the number I have found to most desirable is -9db (good compromise number). This generally gives the best balance between forward channel speed and backchannel degradation. There are several countries where -6 is almost always the best. UK, France, South Africa, Argentina, Chile come to mind. We have found these country's PTTs tend to apply an echo loss plan that is heavy and all on the analog side of the codec. The V.90 client can automatically overcome any digital loss (as it can be measured during training), but analog loss cannot be distinguished from loop loss, so it must be manually cranked up. Note, in the US and Canada this is not adjustable. Both the US and Canadian authorities limit transmit power to -12. So only those with E1 code can make these adjustments. Unfortunately, I have not done any thorough investigations on the Estonian network. You will need to experiment a bit. If you crank it up and customers complain of connection problems or backchannel degradation, you will want to drop it back to -12. If many of your customers are getting good speeds in the upper 40s and 50's, my suggestion is to leave it alone (as they say, "if it ain't broke, don't fix it"). If the majority of your customers are getting lower 40's/upper 30s, it is worth a try. Hope that helps! "Andres Kroonmaa" <andre@ml.ee> on 09/01/98 02:56:52 AM Please respond to usr-tc@lists.xmission.com cc: (John Powell/MW/US/3Com) What is x2 high-power constellation for hdm? It is disabled by default. Is there any point in enabling it? ---------------------------------------------------------------------- Andres Kroonmaa mail: andre@online.ee Network Manager Organization: MicroLink Online Tel: 6308 909 Tallinn, Sakala 19 Pho: +372 6308 909 Estonia, EE0001 http://www.online.ee Fax: +372 6308 901 ---------------------------------------------------------------------- - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

What is x2 high-power constellation for hdm? It is disabled by default. Is there any point in enabling it? ---------------------------------------------------------------------- Andres Kroonmaa mail: andre@online.ee Network Manager Organization: MicroLink Online Tel: 6308 909 Tallinn, Sakala 19 Pho: +372 6308 909 Estonia, EE0001 http://www.online.ee Fax: +372 6308 901 ----------------------------------------------------------------------

Is this NT box using DUN, and if so are they specifying a static IP ? if so NT will assume a /24 netmask and the Netserver will dump the connection. If they Are a static IP then have them set their connection to dynamically assigned, and the correct mask will be passed to them. If they are dynamic, NT DOES cache the last address it was assigned and may have issues, occasionally. My 2 cents. -Frank -----Original Message----- >Is there anything special to be set in the Netserver to allow Windows NT to >connect and pass data? I upgraded to 3.7.24 early this morning and now I >have a customer who cannot pass data. I suspect it's a routing issue, but I >cannot figure it out. > >Thanks, >Wayne Barber (barberw@tidewater.net) >IS Supervisor >Coastal Telco Services > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Is there anything special to be set in the Netserver to allow Windows NT to connect and pass data? I upgraded to 3.7.24 early this morning and now I have a customer who cannot pass data. I suspect it's a routing issue, but I cannot figure it out. Thanks, Wayne Barber (barberw@tidewater.net) IS Supervisor Coastal Telco Services

> -----Original Message----- > From: Wayne Barber <barberw@tidewater.net> > To: usr-tc <usr-tc@lists.xmission.com> > Date: Tuesday, September 01, 1998 1:07 PM > Subject: (usr-tc) WinNT and Netserver 3.7.24 > > > >Is there anything special to be set in the Netserver to allow Windows NT to > >connect and pass data? I upgraded to 3.7.24 early this morning and now I > >have a customer who cannot pass data. I suspect it's a routing issue, but I > >cannot figure it out. > > Make sure that you have vj-compression tuned on at both ends. The user should have vj enabled on his radius/user profile and the ip header compression on NT side should be enabled. The problem is due to the fact that the NT Server has vj enabled and the NETServer does not have the same enabled for the user. krish > >Thanks, > >Wayne Barber (barberw@tidewater.net) > >IS Supervisor > >Coastal Telco Services > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and 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. >

Trying to hook a Modem Pool 16 to a Portmaster 2 Does anyone know the pin outs and or other issues. Also the pins for a sportster 33.6 Faxmodem to a portmaster2. Thank you, Tim Patterson @harborside

Here are the pinouts of the MP8/16 RJ45 RS232 port : 1 > Ring Indicate or DSR (depending on S58 register) 2 > DCD 3 > DTR 4 > Signal Ground 5 > RX 6 > TX 7 > CTS 8 > RTS Tim Patterson <tim@harborside.com> on 09/01/98 10:42:28 PM Please respond to usr-tc@lists.xmission.com cc: (John Powell/MW/US/3Com) Trying to hook a Modem Pool 16 to a Portmaster 2 Does anyone know the pin outs and or other issues. Also the pins for a sportster 33.6 Faxmodem to a portmaster2. Thank you, Tim Patterson @harborside - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

On Tuesday, September 01, 1998 3:44 PM, Tatai SV Krishnan [SMTP:tkrishna@bubba.ae.usr.com] wrote: > > Make sure that you have vj-compression tuned on at both ends. The user > should have vj enabled on his radius/user profile and the ip header > compression on NT side should be enabled. The problem is due to the fact > that the NT Server has vj enabled and the NETServer does not have the > same enabled for the user. NT SP3 helps also. Marshall Morgan Internet Doorway, Inc (aka NETDOOR) http://www.netdoor.com 601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838

Thanks to John, I resolved connecting a MP8/16 to a Livingston Portmaster-2. For the archive: The pin outs are: MP8/16 Portmaster ======================= 1 RI-DSR 6 2 DCD 8 3 DTR 20 4 SG 7 5 RD 3 6 TD 2 7 CTS 4 8 RTS 5 Thank you, Tim Patterson @harborside On Tue, 1 Sep 1998, John Powell wrote: > > Here are the pinouts of the MP8/16 RJ45 RS232 port : > > 1 > Ring Indicate or DSR (depending on S58 register) > 2 > DCD > 3 > DTR > 4 > Signal Ground > 5 > RX > 6 > TX > 7 > CTS > 8 > RTS > > > > > > Tim Patterson <tim@harborside.com> on 09/01/98 10:42:28 PM > > Please respond to usr-tc@lists.xmission.com > > To: usr-tc <usr-tc@lists.xmission.com> > cc: (John Powell/MW/US/3Com) > Subject: (usr-tc) Modem Pool Pin Outs. > > > > > Trying to hook a Modem Pool 16 to a Portmaster 2 > Does anyone know the pin outs and or other > issues. > > Also the pins for a sportster 33.6 Faxmodem to > a portmaster2. > > Thank you, > > Tim Patterson > @harborside > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and 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. >

On Wed, 2 Sep 1998, Angela A. Burford wrote: > Hi, > > I am about to enable rip in my usr chassis (some have HiPerCards, some > have NetServer Cards) and i'd like to know how often are the routing table > refreshed and sent out? RIP broadcasts its routing tables every 30 seconds. > I am enabling rip so that users that use static ip can dial > into any of our chassis, but i want to make sure that if a user that uses > a static ip disconnects from a terminal server and reconnects to another > right away will not experiment problems as a consequence of the routing > table have not been refreshed quick enough and is still routing his ip > to where he was connected for first time. Hope that makes sense... What you want makes sense. It is a good thing. [tm] Unfortunately, you cannot do it with RIP due to the 30 second propagation delay. Further, if you have a large rip network, it may take more time for the routes to propogate all the way to your core. I don't know of a way to do what you want to do without using another IGP, such as OSPF. Unfortunately, the Netservers don't do OSPF and I don't believe the HiperArcs do either. (as of yet) > Angela Good luck, Todd --- Todd Nagengast /_\\//_\ Network Hero v. 907.562.4638 tsgd@alaska.net \ //\\ / Internet Alaska, Inc. f. 907.562.1677 My name is CCIEMontoya. You smurfed my router. Prepare to DIE! 1024/DB3041FD BE 60 73 FE 61 C5 A4 F3 C8 13 3C 93 C8 63 1F 5C

Hi, I am about to enable rip in my usr chassis (some have HiPerCards, some have NetServer Cards) and i'd like to know how often are the routing table refreshed and sent out? I am enabling rip so that users that use static ip can dial into any of our chassis, but i want to make sure that if a user that uses a static ip disconnects from a terminal server and reconnects to another right away will not experiment problems as a consequence of the routing table have not been refreshed quick enough and is still routing his ip to where he was connected for first time. Hope that makes sense... Thanks Angela

This is a multi-part message in MIME format. ------=_NextPart_000_006C_01BDD66B.DC946780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I have an unusual situation. I have a HiperARC/DSP box being used for both regular dial-up customers, and as an upstream for a cable modem (3com) network as well. My radius server recognizes the type of user by the realm: no realm=dialup, @icable.com=cable. I would like to somehow have all the traffic for the icable.com realm go out over the second ethernet port to a separate 100BaseT network (eth:2) from my dial-up users (eth:1). This would allow me to set up a separate proxy server, dhcp server, etc. Is this possible, and if so, how? My Radius server is Radiator, so I'm very flexible there. Thanks, Randy Cosby <dcosby@infowest.com> Vice President InfoWest Global Internet Services, Inc. (435)674-0165 http://www.infowest.com ------=_NextPart_000_006C_01BDD66B.DC946780 Content-Type: application/octet-stream; name="Randy Cosby.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Randy Cosby.vcf" BEGIN:VCARD VERSION:2.1 N:Cosby;Randy FN:Randy Cosby ORG:InfoWest Global Internet Services, Inc. TITLE:Vice President NOTE;ENCODING=3DQUOTED-PRINTABLE:What do I do? =3D0D=3D0A=3D0D=3D0AVice = President, InfoWest =3D0D=3D0AAreas of responsib=3D ility include: Research, Development, communications services = http://www.inf=3D owest.com=3D0D=3D0A=3D0D=3D0AWeb Site = Manager=3D0D=3D0Ahttp://www.devshed.com=3D0D=3D0Ahttp:=3D //www.32bit.com=3D0D=3D0A=3D0D=3D0AUtah's first Internet-over-cable: = iCable=3D0D=3D0Ahtt=3D p://www.icable.net=3D0D=3D0A=3D0D=3D0AWhat can I do for you? TEL;WORK;VOICE:(435) 674-0165 TEL;WORK;FAX:(435) 674-9734 ADR;WORK:;;1845 West Sunset Boulevard;St. George;UT;84770;United States = of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:1845 West Sunset = Boulevard=3D0D=3D0ASt. George, UT 84770=3D0D=3D0AUnited States of A=3D merica URL: URL:http://www.infowest.com EMAIL;PREF;INTERNET:dcosby@infowest.com REV:19980630T225731Z END:VCARD ------=_NextPart_000_006C_01BDD66B.DC946780--

Thus spake Todd Nagengast >On Wed, 2 Sep 1998, Angela A. Burford wrote: >> I am enabling rip so that users that use static ip can dial >> into any of our chassis, but i want to make sure that if a user that uses >> a static ip disconnects from a terminal server and reconnects to another >> right away will not experiment problems as a consequence of the routing >> table have not been refreshed quick enough and is still routing his ip >> to where he was connected for first time. Hope that makes sense... >What you want makes sense. It is a good thing. [tm] >Unfortunately, you cannot do it with RIP due to the >30 second propagation delay. Not entirely true...if she uses RIP version 2, it does incremental updates...though there are still hold down timers and such associated with switching from one chassis to another (which will amount to anywhere from 2 to 4 minutes if I remember correctly), but just a new connection would be broadcast out in an incremental update immediately if its using RIPv2. >I don't know of a way to do what you want to do without >using another IGP, such as OSPF. Unfortunately, the Netservers >don't do OSPF and I don't believe the HiperArcs do either. (as >of yet) Use a Cisco router (even a little 2501 will handle this with no problem) to redistribute the RIPv2 learned from the netservers (need 11.1 IOS on the cisco to support ripv2) into OSPF...best way I've found to do it and it works pretty well here. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

There are some good examples of how to accomplish this at www.shreve.net/tcs On Wed, 2 Sep 1998, Jeff Mcadams wrote: > Thus spake Todd Nagengast > >On Wed, 2 Sep 1998, Angela A. Burford wrote: > >> I am enabling rip so that users that use static ip can dial > >> into any of our chassis, but i want to make sure that if a user that uses > >> a static ip disconnects from a terminal server and reconnects to another > >> right away will not experiment problems as a consequence of the routing > >> table have not been refreshed quick enough and is still routing his ip > >> to where he was connected for first time. Hope that makes sense... > > >What you want makes sense. It is a good thing. [tm] > >Unfortunately, you cannot do it with RIP due to the > >30 second propagation delay. > > Not entirely true...if she uses RIP version 2, it does incremental > updates...though there are still hold down timers and such associated > with switching from one chassis to another (which will amount to > anywhere from 2 to 4 minutes if I remember correctly), but just a new > connection would be broadcast out in an incremental update immediately > if its using RIPv2. > > >I don't know of a way to do what you want to do without > >using another IGP, such as OSPF. Unfortunately, the Netservers > >don't do OSPF and I don't believe the HiperArcs do either. (as > >of yet) > > Use a Cisco router (even a little 2501 will handle this with no problem) > to redistribute the RIPv2 learned from the netservers (need 11.1 IOS on > the cisco to support ripv2) into OSPF...best way I've found to do it and > it works pretty well here. > -- > 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. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

We are considering the HiPer Arc upgrade to replace our netserver cards. To make this a bit more cost effective, would we be able to change our older 45amp chassis to also use the HiPer DSP cards to give us a higher modem chassis? Would we also be able to have more than 2 HiPer DSP's in the older 45amp chassis? Thanks ********************************************************* Jason Watkins jwatkins@iland.net I-Land Internet Services http://www.iland.net Support & Network Operations Center *********************************************************

Hi all, is there anyway to set an idle time out for ISDN calls? I'm using Dual E1 PRI's, with Netservers terminating the calls (code 2.5.4 and 3.5.34 respectively). I can only find reference to timeout on S ports not I ports. Thanks in advance for any help. Phil Cinergy Communications.

On 2 Sep 98, at 1:04, Marshall Morgan wrote: "barberw@tidewater.net" <barberw@tidewater.net> Date sent: Wed, 2 Sep 1998 01:04:59 -0500 Organization: Internet Doorway, Inc. Send reply to: usr-tc@lists.xmission.com > On Tuesday, September 01, 1998 3:44 PM, Tatai SV Krishnan > [SMTP:tkrishna@bubba.ae.usr.com] wrote: > > > > Make sure that you have vj-compression tuned on at both ends. The user > > should have vj enabled on his radius/user profile and the ip header > > compression on NT side should be enabled. The problem is due to the > > fact that the NT Server has vj enabled and the NETServer does not have > > the same enabled for the user. > > NT SP3 helps also. > > Marshall Morgan > > Internet Doorway, Inc (aka NETDOOR) > http://www.netdoor.com > > 601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > We find that in most cases the user needs to have software compression (not VJ Compression) turned off in DUN. Once it is turned off everything works. This is with Netserver 3.7.24. **************************************************************** * Fred Williams email fwilliams@gtnet.gov.uk * * CCTA voice 01603 704706 * * Rosebery Court GTN 3040 4706 * * St Andrews Business Park fax 01603 704817 * * NORWICH GTN fax 3040 4817 * * NR7 0HS UK * ****************************************************************

We recently upgraded to version 3.7.73 (an ER release) of the Netserver card. We needed a working version of 8 bit telnet, so we could not use the current recommended release. After the upgrade, things seems to be working nicely with one exception. Customer's that dial in using NT can't connect. Window 95, 3.1, Mac's etc are all fine. It seems to be just NT 4.0. >From our side, the customer is authenticated and shows up as "established" when doing a "sh all" on the Netserver. We are unable to "ping" them though. Any suggestions would be appreciated! --

On Wed, 2 Sep 1998, Jason W wrote: > We are considering the HiPer Arc upgrade to replace > our netserver cards. To make this a bit more cost effective, > would we be able to change our older 45amp chassis to > also use the HiPer DSP cards to give us a higher modem > chassis? Would we also be able to have more than 2 HiPer > DSP's in the older 45amp chassis? > The high-density chassis, the ones with the integrated fan tray can hold a full complement of HDM's and ARC's. The low-density chassis, the ones without or with a seperate fan tray, can only hold up to 96ports I beleive. Brian > Thanks > > ********************************************************* > Jason Watkins jwatkins@iland.net > I-Land Internet Services http://www.iland.net > Support & Network Operations Center > ********************************************************* > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Brian was heard to say: >The low-density chassis, the ones without or with a seperate fan tray, can >only hold up to 96ports I beleive. According to my numbers, you could theoretically put 7 hiperDSP's, one hiperARC, and one NMC in a 45A chassis. That would be 44.8 amps, so you really would need to have both power supplies in it and a really good air flow. And I'm sure you would eventually fry the power supplies. --Ricky

Thus spake Ricky Beam >Brian was heard to say: >>The low-density chassis, the ones without or with a seperate fan tray, can >>only hold up to 96ports I beleive. >According to my numbers, you could theoretically put 7 hiperDSP's, one >hiperARC, and one NMC in a 45A chassis. That would be 44.8 amps, so you >really would need to have both power supplies in it and a really good >air flow. And I'm sure you would eventually fry the power supplies. Not sure its an issue of power supply though...I think its backplane bandwidth that's more of a concern. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Check the compression, if the client has it enabled - then enable the same on the NETServer/radius for the user krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Wed, 2 Sep 1998, G. Douglas Davidson wrote: > We recently upgraded to version 3.7.73 (an ER release) of the Netserver card. > We needed a working version of 8 bit telnet, so we could not use the current > recommended release. > > After the upgrade, things seems to be working nicely with one exception. > Customer's that dial in using NT can't connect. Window 95, 3.1, Mac's etc are > all fine. It seems to be just NT 4.0. > > >From our side, the customer is authenticated and shows up as "established" when > doing a "sh all" on the Netserver. We are unable to "ping" them though. > > Any suggestions would be appreciated! > > -- > ----- > G Douglas Davidson | CityNet, Inc. > douglas@city-net.com | Pittsburgh, PA > voice: 412.481.5406 | fax: 412.431.1315 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Wed, 2 Sep 1998, Ricky Beam wrote: > Brian was heard to say: > >The low-density chassis, the ones without or with a seperate fan tray, can > >only hold up to 96ports I beleive. > > According to my numbers, you could theoretically put 7 hiperDSP's, one > hiperARC, and one NMC in a 45A chassis. That would be 44.8 amps, so you > really would need to have both power supplies in it and a really good > air flow. And I'm sure you would eventually fry the power supplies. Is power the only issue though? I thought the actual size of the packet bus what different on the two chassis. Brian > > --Ricky > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Thanks for the answers so far, but none of it has worked. We look in the netserver when the user dials in and it doesn't show MS or STAC compression, but we still cannot ping. I did notice that the netserver is passing DNS info. Could this be causing the problem? Wayne Barber > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Fred Williams > Sent: Wednesday, September 02, 1998 1:40 PM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) WinNT and Netserver 3.7.24 > <snip> > > We find that in most cases the user needs to have software > compression (not VJ Compression) turned off in DUN. Once it is > turned off everything works. This is with Netserver 3.7.24. > > > > **************************************************************** > * Fred Williams email fwilliams@gtnet.gov.uk * > * CCTA voice 01603 704706 * > * Rosebery Court GTN 3040 4706 * > * St Andrews Business Park fax 01603 704817 * > * NORWICH GTN fax 3040 4817 * > * NR7 0HS UK * > ****************************************************************

On 2 Sep 98, at 18:36, G. Douglas Davidson wrote: Date sent: Wed, 2 Sep 1998 18:36:48 -0400 Send reply to: usr-tc@lists.xmission.com > We recently upgraded to version 3.7.73 (an ER release) of the Netserver > card. > We needed a working version of 8 bit telnet, so we could not use the > current > recommended release. > > After the upgrade, things seems to be working nicely with one exception. > Customer's that dial in using NT can't connect. Window 95, 3.1, Mac's > etc are > all fine. It seems to be just NT 4.0. > > >From our side, the customer is authenticated and shows up as > >"established" when > doing a "sh all" on the Netserver. We are unable to "ping" them though. > > Any suggestions would be appreciated! > > -- > ----- > G Douglas Davidson | CityNet, Inc. > douglas@city-net.com | Pittsburgh, PA > voice: 412.481.5406 | fax: 412.431.1315 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Try setting software compression (not VJ Compression) off in DUN. This is a known problem with Netserver 3.7.24 so it may have been carried forward to 3.7.73. **************************************************************** * Fred Williams email fwilliams@gtnet.gov.uk * * CCTA voice 01603 704706 * * Rosebery Court GTN 3040 4706 * * St Andrews Business Park fax 01603 704817 * * NORWICH GTN fax 3040 4817 * * NR7 0HS UK * ****************************************************************

Does any one know which SNMP object could be used to get the active session time ( online time of active modem ) ? BTW, I'm having some complains of users that their connections logs show long online times, and they say that's wrong. I have already configured the Idle Timeout at the interface, and I would like to monitor it closer. - Marcelo

Andres Kroonmaa said once upon a time: > > > "show cpu util" is supposed to show cpu utilisation, right? > It is always 0%, so you'd think it is no implemented yet. > > But, I've seen it to be 1%, at a time that command prompt > was very unresponsiv, that is most probably cpu at 100% > > Now comes next logical assumtion that 3com have "forgotten" > to use x100 multiplier to derive percent from ratio. I wouldn't put it past them. I've never seen anything other than 0%.

Did you set the iterface setting to nic instead of t1? > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jake Messinger > Sent: Saturday, August 29, 1998 4:50 PM > To: usr-tc@xmission.com > Subject: (usr-tc) Cannot get dialtone on ANY of the analog modems > > > I have a TC hub here and some v.34 analog cards and some analog nics. I > decided to put it together and try it. > > It all works EXCEPT I cannot get a dialtone on ANY of the modems. I can > type AT and get OK, etc... I have tried different phone cords, etc... made > sure the line was live. > > I looked in the manual and it shows that the analog NIC's should have > daughtercards. NONE of the NICs I have, have those daughtercards even tho > they are all labeled as ANALOG. Is this my problem? > > ~~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~ > *-,._.,-*~ > Jake Messinger ph:713-772-6690 > Lucent Dealer > AMS, Inc. fx:713-774-3498 Medical Billing > 8300 Bissonnet #400 jake@ams.com , ICQ# 4403734 Internet Services > Houston, Texas 77074 www.ams.com/~jake and Hardware > ~~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~ > *-,._.,-*~ > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

a while back someone posted a message saying they had quad modems for a total control enterprise hub for sale. they were the quad analog/digital modem cards. they were selling them for $1,000.00 each. does anyone have any more left? we're looking to upgrade on of our smaller sites where there are no digital lines avalible, so it's not worth upgrading yet. just email me with a price. c-ya! :-)

Has this list been down? I sent 3 emails to it last week that are only JUST NOW showing up. ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ Jake Messinger ph:713-772-6690 Lucent Dealer AMS, Inc. fx:713-774-3498 Medical Billing 8300 Bissonnet #400 jake@ams.com , ICQ# 4403734 Internet Services Houston, Texas 77074 www.ams.com/~jake and Hardware ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~

Is there going to be a V90 upgrade for the Hiper DSP that works with the Netserver? Any info? Thanks John x2@gti.net

This is a multi-part message in MIME format. ------=_NextPart_000_001C_01BDD76E.600A3CE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We are currently using the RADIUS server in IIS4.0 under winNT. The = part I like about it is that it uses the NT user database. I don't = really like any of the rest of it. I would like to hear what other = people are using for authentication and some strengths and weakness of = the packages available. Thanks in advance, Ryan Hilliard TwoAlpha P.O. Box 369 Laurel, MT 59044 (406)628-1500 (406)628-1400 FAX ------=_NextPart_000_001C_01BDD76E.600A3CE0 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> <META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT color=3D#000000 size=3D2>We are currently using the RADIUS = server in=20 IIS4.0 under winNT.&nbsp; The part I like about it is that it uses the = NT user=20 database.&nbsp; I don't really like any of the rest of it.&nbsp; I would = like to=20 hear what other people are using for authentication and some strengths = and=20 weakness of the packages available.</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV> <DIV><FONT size=3D2>Thanks in advance,</FONT></DIV> <DIV><FONT size=3D2></FONT>&nbsp;</DIV> <DIV><FONT color=3D#000000 size=3D2>Ryan Hilliard<BR>TwoAlpha<BR>P.O. = Box=20 369<BR>Laurel, MT 59044<BR>(406)628-1500<BR>(406)628-1400=20 FAX</FONT></DIV></BODY></HTML> ------=_NextPart_000_001C_01BDD76E.600A3CE0--

here's the problem ... we have a netserver 16+ v.34 that we purchased a while ago (about six months). anyway, ever since we bought the thing it works fine except some of our customers get kicked out right after negotiation. they try again and they might get in on the very next try, or have to try up to eight times, but they get in eventually. some people get in just fine, almost all of the time. we downgraded the netserver code to 3.3 and the modems to the latest version of code before they came out with v4 of the netserver code. the strange thing is, we have another site running some netserver 8 v.34 boxes (not +'s) that are running the same exact code as the netserver in question, and no one has a problem with that. after countless hours on the phone with 3com/usr, their techs just left me hanging. they can't figure it out at all. they said that all of my settings were correct. and every time they try to dial in, they get in on the first try. so my questions are ... 1. has anyone else had this problem? 2. is there anyway to monitor the actual phone lines coming into the modems to see if it's not the phone companies lines? 3. i've heard some problems with Win95 version A and some particular modems (such as a USR 33.6 and some "no names" also), is there any form of a patch for Win95 that fixes this? i've already tried the DUN upgrade, with no luck. 4. is there anyway network traffic can be causing the people to be kicked off? 5. are there any differences between the netserver +'s and the non-+'s except the code their running that might cause this? thanks for any help anyone can give me. c-ya! :-)

This didn't work. I can check the netserver and see that he got a link with compression but still no data is passed. I tried turning it off and no luck. I created a user in the netserver and tried that with both compression on and off, still no luck. The customer is bringing in the machine so we can try some stuff. I've never worked with NT before, so wish me luck. Wayne Barber > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan > Sent: Thursday, September 03, 1998 9:50 AM > To: G. Douglas Davidson > Cc: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) NT can't connect after 3.7.73 upgrade > > > Check the compression, if the client has it enabled - then enable the > same on the NETServer/radius for the user > > krish >

On Fri, 4 Sep 1998, Richard Bosire wrote: > Hi .s > > Is there a way I can have radius accting details be written to two > machines at the same time ?.. If you are using HiperARC's then yes, you can specify a primary and secondary server, and then specify under accounting configuration that you want to send to BOTH. Brian > > TIA > > > bosire > > -- > > \\|// - ? > (o o) > +==================================oOOo=(_)=oOOo========+ > | Richard Bosire rbosire@africaonline.co.ke | > | AfricaOnline Ltd | > | union towers, 2nd floor | > | tel: 254-2-243775 | > | .oooO | > | http://www.africaonline.co.ke ( ) Oooo. | > +===================================\ (==( )==========+ > \_) ) / > (_/ > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

I take it back. Krish was right, as usual. Once the customer found the proper compression to check, he turned on VJ and was in like Flynn (so to speak). The problem was that the "user" was not going to the dialup networking folder to check the settings. He was only doing it from the desktop, where the setups are limited. Have NT customers go to Start-Accessories-Dialup Networking and look for VJ compression after that. I'm sorry I cannot be any more specific, but I still haven't seen an NT setup. Wayne Barber > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Wayne Barber > Sent: Friday, September 04, 1998 8:10 AM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) NT can't connect after 3.7.73 upgrade > > > This didn't work. I can check the netserver and see that he got a > link with > compression but still no data is passed. I tried turning it off > and no luck. > I created a user in the netserver and tried that with both compression on > and off, still no luck. > > The customer is bringing in the machine so we can try some stuff. > I've never > worked with NT before, so wish me luck. > > Wayne Barber > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan > > Sent: Thursday, September 03, 1998 9:50 AM > > To: G. Douglas Davidson > > Cc: usr-tc@lists.xmission.com > > Subject: Re: (usr-tc) NT can't connect after 3.7.73 upgrade > > > > > > Check the compression, if the client has it enabled - then enable the > > same on the NETServer/radius for the user > > > > 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. >

Hi .s Is there a way I can have radius accting details be written to two machines at the same time ?.. TIA bosire -- \\|// - ? (o o) +==================================oOOo=(_)=oOOo========+ | Richard Bosire rbosire@africaonline.co.ke | | AfricaOnline Ltd | | union towers, 2nd floor | | tel: 254-2-243775 | | .oooO | | http://www.africaonline.co.ke ( ) Oooo. | +===================================\ (==( )==========+ \_) ) / (_/

On Sep 4, 8:09am, Wayne Barber wrote: > Subject: RE: (usr-tc) NT can't connect after 3.7.73 upgrade > This didn't work. I can check the netserver and see that he got a link with > compression but still no data is passed. I tried turning it off and no luck. > I created a user in the netserver and tried that with both compression on > and off, still no luck. > > The customer is bringing in the machine so we can try some stuff. I've never > worked with NT before, so wish me luck. > > Wayne Barber > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan > > Sent: Thursday, September 03, 1998 9:50 AM > > To: G. Douglas Davidson > > Cc: usr-tc@lists.xmission.com > > Subject: Re: (usr-tc) NT can't connect after 3.7.73 upgrade > > > > > > Check the compression, if the client has it enabled - then enable the > > same on the NETServer/radius for the user > > > > krish > > I turned off the compression on the NT box and still no luck. We are having these customers dial into an old PM2 now, but that is hardly a long term solution. This is really weird. --

Jake, Yes, you can. Use the AT%Dn command. I cut out the appropriate info from the quad modem reference manual for you. ********************* Line Source. Command: %Dn Use I6 to display current line source (see Chapter 3,nquiries). Standard Analog setting is for analog phone lines through a Quad Analog/Digital NIC. T1/DS0 setting is for a T1 DS0 through a chassis T1 card. T1/PRI is for an ISDN line through a chassis PRI card. %D0 Standard Analog (POTS) %D1 T1/DS0 %D2 T1/PRI (ISDN) ***************************************** Mike Stankavich, CTO NorFab/ISP, Inc 921 SW Washington, #404 Portland, OR 97205 mike@ethergate.com http://www.ethergate.com -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jake Messinger Sent: Friday, September 04, 1998 12:48 PM On Fri, 4 Sep 1998, Eric Young wrote: > Jake, > > Open your chassis in TCM and then make sure after having selected the I dont have a total control network manager board. See im new to TC's. Can I do it via the serial port on each modem? ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ Jake Messinger ph:713-772-6690 Lucent Dealer AMS, Inc. fx:713-774-3498 Medical Billing 8300 Bissonnet #400 jake@ams.com , ICQ# 4403734 Internet Services Houston, Texas 77074 www.ams.com/~jake and Hardware ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

we have 1 older chassis left that doesn't have any double up cards in it yet. we have a few hiper dsp cards hanging around so i thought i would double it up. all of the double-uping we did in the past was with the kit from usr with the hiper dsp and the memory all in one package. where can i get the memory upgrades for the nmc and the netserver? and what should it cost? solunet wasn't sure what i wanted and then the price seems a little high, about $400 for both. matthew

On Fri, 4 Sep 1998, Eric Young wrote: > Jake, > > Open your chassis in TCM and then make sure after having selected the I dont have a total control network manager board. See im new to TC's. Can I do it via the serial port on each modem? ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ Jake Messinger ph:713-772-6690 Lucent Dealer AMS, Inc. fx:713-774-3498 Medical Billing 8300 Bissonnet #400 jake@ams.com , ICQ# 4403734 Internet Services Houston, Texas 77074 www.ams.com/~jake and Hardware ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~

Jake, Now you've got me. I went through that about a year ago & I can't remember all the details. I switched over to using TCM pretty shortly after that. I can make you a good deal on an NMC if you want :) The only thing I can think of is that perhaps you have a digital-only modem. Does it say analog/digital on the front of the card? Mike -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jake Messinger Sent: Friday, September 04, 1998 2:00 PM On Fri, 4 Sep 1998, Jake Messinger wrote: > On Fri, 4 Sep 1998, Mike Stankavich wrote: > > > Yes, you can. Use the AT%Dn command. I cut out the appropriate info from the > > quad modem reference manual for you. Okay that didnt work, I set it for AT%d0 and did at&w and hard reset it but it didnt do anything. I KNOW the line is good, I took it off a working modem. Here is ATI6, I dont see any line setting on it tho: USRobotics Analog Quad HST Dual Standard V.34+ Fax Link Diagnostics... Chars sent 0 Chars Received 0 Chars lost 0 Octets sent 0 Octets Received 0 Blocks sent 0 Blocks Received 0 Blocks resent 0 Retrains Requested 0 Retrains Granted 0 Line Reversals 0 Blers 0 Link Timeouts 0 Link Naks 0 Data Compression NONE Equalization Long Fallback Disabled Last Call 00:00:00 Disconnect Reason is No Dialtone I tried changing at%d to 0 and then I did an at%d? and it always comes up as 001. Why cant I change it? ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ Jake Messinger ph:713-772-6690 Lucent Dealer AMS, Inc. fx:713-774-3498 Medical Billing 8300 Bissonnet #400 jake@ams.com , ICQ# 4403734 Internet Services Houston, Texas 77074 www.ams.com/~jake and Hardware ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Jake, Open your chassis in TCM and then make sure after having selected the modem(s) in question that your line interface source is set to 'NIC' under the 'Configure' ->Programmed Settings ->Line Interface Options' parameter group. Sincerely, eric young a.k.a. the hub doctor technical support solunet, inc. http://www.solunet.com <http://www.solunet.com> v888.449.5766 - direct support v800.795.2814 v407.676.7947 f407.676.0809 eric@solunet.com <mailto:eric@solunet.com> We don't make networking equipment, we make it WORK! -----Original Message----- From: Jake Messinger [SMTP:jake@ams.com] Sent: Saturday, August 29, 1998 7:50 PM To: usr-tc@xmission.com Subject: (usr-tc) Cannot get dialtone on ANY of the analog modems I have a TC hub here and some v.34 analog cards and some analog nics. I decided to put it together and try it. It all works EXCEPT I cannot get a dialtone on ANY of the modems. I can type AT and get OK, etc... I have tried different phone cords, etc... made sure the line was live. I looked in the manual and it shows that the analog NIC's should have daughtercards. NONE of the NICs I have, have those daughtercards even tho they are all labeled as ANALOG. Is this my problem? ~~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ Jake Messinger ph:713-772-6690 Lucent Dealer AMS, Inc. fx:713-774-3498 Medical Billing 8300 Bissonnet #400 jake@ams.com , ICQ# 4403734 Internet Services Houston, Texas 77074 www.ams.com/~jake and Hardware ~~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

On Fri, 4 Sep 1998, Mike Stankavich wrote: > Yes, you can. Use the AT%Dn command. I cut out the appropriate info from the > quad modem reference manual for you. Well F**K it was THAT easy, huh!?!? Okay thanx guys!!!!! BTW, I dont have the manuals? I searched thru the PDF version and didnt find this, but I was looking in the INSTALL guide. ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ Jake Messinger ph:713-772-6690 Lucent Dealer AMS, Inc. fx:713-774-3498 Medical Billing 8300 Bissonnet #400 jake@ams.com , ICQ# 4403734 Internet Services Houston, Texas 77074 www.ams.com/~jake and Hardware ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~

Sorry Jake, I'm out of ideas. Anybody else? Mike -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jake Messinger Sent: Friday, September 04, 1998 3:29 PM On Fri, 4 Sep 1998, Mike Stankavich wrote: > Jake, > > Now you've got me. I went through that about a year ago & I can't remember > all the details. I switched over to using TCM pretty shortly after that. I > can make you a good deal on an NMC if you want :) The only thing I can think > of is that perhaps you have a digital-only modem. Does it say analog/digital > on the front of the card? modem says ANALOG, nic says ANALOG. ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ Jake Messinger, VP. ph:713-772-6690 Lucent Dealer AMS, Inc. fx:713-774-3498 Medical Billing 8300 Bissonnet #400 jake@ams.com , ICQ# 4403734 Internet Services Houston, Texas 77074 www.ams.com/~jake and Hardware Adjunct Professor University of Houston, CBA jake@uh.edu ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

On Fri, 4 Sep 1998, Jake Messinger wrote: > On Fri, 4 Sep 1998, Mike Stankavich wrote: > > > Yes, you can. Use the AT%Dn command. I cut out the appropriate info from the > > quad modem reference manual for you. Okay that didnt work, I set it for AT%d0 and did at&w and hard reset it but it didnt do anything. I KNOW the line is good, I took it off a working modem. Here is ATI6, I dont see any line setting on it tho: USRobotics Analog Quad HST Dual Standard V.34+ Fax Link Diagnostics... Chars sent 0 Chars Received 0 Chars lost 0 Octets sent 0 Octets Received 0 Blocks sent 0 Blocks Received 0 Blocks resent 0 Retrains Requested 0 Retrains Granted 0 Line Reversals 0 Blers 0 Link Timeouts 0 Link Naks 0 Data Compression NONE Equalization Long Fallback Disabled Last Call 00:00:00 Disconnect Reason is No Dialtone I tried changing at%d to 0 and then I did an at%d? and it always comes up as 001. Why cant I change it? ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ Jake Messinger ph:713-772-6690 Lucent Dealer AMS, Inc. fx:713-774-3498 Medical Billing 8300 Bissonnet #400 jake@ams.com , ICQ# 4403734 Internet Services Houston, Texas 77074 www.ams.com/~jake and Hardware ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~

On Fri, 4 Sep 1998, Mike Stankavich wrote: > Jake, > > Now you've got me. I went through that about a year ago & I can't remember > all the details. I switched over to using TCM pretty shortly after that. I > can make you a good deal on an NMC if you want :) The only thing I can think > of is that perhaps you have a digital-only modem. Does it say analog/digital > on the front of the card? modem says ANALOG, nic says ANALOG. ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ Jake Messinger, VP. ph:713-772-6690 Lucent Dealer AMS, Inc. fx:713-774-3498 Medical Billing 8300 Bissonnet #400 jake@ams.com , ICQ# 4403734 Internet Services Houston, Texas 77074 www.ams.com/~jake and Hardware Adjunct Professor University of Houston, CBA jake@uh.edu ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~

> all of the double-uping we did in the past was with the kit from usr with > the hiper dsp and the memory all in one package. > > where can i get the memory upgrades for the nmc and the netserver? and > what should it cost? > > solunet wasn't sure what i wanted and then the price seems a little high, > about $400 for both. Unfortunatly, you can't get the 8MB flash SIMM from a different source - it is propriatary USR/3COM. The good news is that it shouldn't cost *that* much. The USR part number is 002453-0 and should go for around $225 for the 16MB SIMM and 8MB flash SIMM together. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Executive Vice President - Exec-PC, Inc. |

thanks. that might help. i didn't know there was a part number for both together but speaking of which, other than having already ordered one and knowing the number, how would one figure out usr part numbers? sales reps ask me for usr part numbers for odd things like this and i always hope that they had a better source for such numbers. matthew Curt Shambeau wrote: > > > all of the double-uping we did in the past was with the kit from usr with > > the hiper dsp and the memory all in one package. > > > > where can i get the memory upgrades for the nmc and the netserver? and > > what should it cost? > > > > solunet wasn't sure what i wanted and then the price seems a little high, > > about $400 for both. > > Unfortunatly, you can't get the 8MB flash SIMM from a different source - > it is propriatary USR/3COM. > > The good news is that it shouldn't cost *that* much. The USR part > number is 002453-0 and should go for around $225 for the 16MB SIMM and 8MB > flash SIMM together. > > -------------------------------------------------------------------------- > | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | > | Executive Vice President - Exec-PC, 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.

Apparently the ARC is not listening to the RADIUS "Filter-Id" as documented. I set two filters on the ARC, "mail.in" and "mail.out". The ARC documentation states that if you send "Filter-Id = name" then "name.in" and "name.out" will be applied to the connection. This did not happen. I then tried the same filters as "mail.in.fil" and "mail.out.fil", thinking that maybe there was a typo in the documentation. It still didn't work. I know RADIUS is passing this properly because my Netservers react in the correct fashion. Has anyone managed to get this to work? I'm not interested in passing the entire filter via RADIUS, my Merit RADIUS is overworked as it is.

I just answered my own question by browsing the archives. Mike Wronski wrote back in June: First: make sure you are not using 4.0.19. If so get 4.0.29 from totalservice. >This works, but what most people miss is turning on filters. This is done >by >"set interface slot:x/:mod:[1-Y] filter_access on" >Then disable and re-enable the interfaces. > >Also remember the in vs out conventions. In and out is always in reference >to the >interface and not the dial client. > > USER INTERFACE > DATA --> = input filter > <--- DATA = output filter

Have you tried to have the customer install the RAS/Routing upgrade? maybe that will help... Leon

On 1 Sep 98, at 10:12, John Powell <usr-tc@lists.xmission.com> wrote: > The high power constellation is defaulting the output power in x2 mode to > -6db (as opposed to the default of -12db). Note, -6 is "louder" than -12. > > Unfortunately, I have not done any thorough investigations on the Estonian > network. You will need to experiment a bit. If you crank it up and > customers complain of connection problems or backchannel degradation, you > will want to drop it back to -12. If many of your customers are getting > good speeds in the upper 40s and 50's, my suggestion is to leave it alone > (as they say, "if it ain't broke, don't fix it"). If the majority of your > customers are getting lower 40's/upper 30s, it is worth a try. Thanks alot, John! It was a good insight, and I hope you will stay with us. ---------------------------------------------------------------------- Andres Kroonmaa mail: andre@online.ee Network Manager Organization: MicroLink Online Tel: 6308 909 Tallinn, Sakala 19 Pho: +372 6308 909 Estonia, EE0001 http://www.online.ee Fax: +372 6308 901 ----------------------------------------------------------------------

: Is the archive of this list at : : http://www.datasys.net/usr-tc/ : : The links from the index pages found there are all broken. Whoops. This problem is temporary. The primary archive for the list is at ftp://ftp.xmission.com/pub/lists/usr-tc/ At best, usr-tc.datasys.net is a cooked mirror.

Has anyone experienced any problems between Hiper chassis and NetGear RT-328 ISDN routers??.. We have had multiple netgear units at multiple locations and we are experienced dropped connections and/or stuck routes, right in the middle of a download.. any issues between these two?.. thanks. Allen

Hello, Can I setup 1 or 2 quad analog/digital modem cards in my Total control chassis to accept pots calls ?, If so then do I have to have a terminal server connect to the RS232 connectors, OR will the Total Control handle the answering and data flow to the modems through the packet buss ? So far I have not been able to get the modem to answer thanks

Once upon a time Mike Andrews shaped the electrons to say... >good reason they don't finish moving the Pilgrim (ARC) code to the >NETserver hardware that I missed seeing? Yeah - if they fix the NetServer TC it is harder for them to strong-arm you into PAYING to upgrade to the HiPer ARC TC. The longer the NetServer goes unfixed, the more people they can convince to shell out more cash to buy new HW to 'fix' the problems. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

Looks like there is a new NETserver release out. Once again, "Quake improvements" are listed in the release notes. Anyone tried this yet and know if there's any real progress yet? I can't get the code myself since we still haven't bought a service contract... Mike Andrews (MA12) icq 6602506 -------------- mandrews@dcr.net Senior Systems/Network Administrator --- mandrews@termfrost.org Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "If Barbie is so popular, why do you have to buy her friends?..."

nope ... I was running beta 3.8.0 before this and now quake is alot slower with 3.8.1 ... I keep getting 3 or 4 second pauses for no reason ... 3Com is NOT going to fix this prob ... the can but they won't ... so i'll go get my new equipment from Livingston .. PM4's are VERY nice ... -----Original Message----- >Looks like there is a new NETserver release out. Once again, "Quake >improvements" are listed in the release notes. Anyone tried this yet and >know if there's any real progress yet? I can't get the code myself since >we still haven't bought a service contract... > > >Mike Andrews (MA12) icq 6602506 -------------- mandrews@dcr.net >Senior Systems/Network Administrator --- mandrews@termfrost.org >Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ >"If Barbie is so popular, why do you have to buy her friends?..." > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Jamie Orzechowski was heard to say: >nope ... I was running beta 3.8.0 before this and now quake is alot slower >with 3.8.1 ... I keep getting 3 or 4 second pauses for no reason ... That and the fact that 3Com is not paying any attention to the beta tester (at all?) -- 3.8.1 has some serious problems that I pointed out were still broken from 3.8.0 to 3.8.1 with in a few days of 3.8.1 being posted for testing. They have, of course, not touched the 3.8.1 code or even lifted a finger to fix what they broke. (Yes, 3.7 works, 3.8 broke it.) --Ricky

hmm .. what is broken in 3.8.1? mabey they are just screwing us over so we are forced to upgrade to HARC's ? -----Original Message----- >Jamie Orzechowski was heard to say: >>nope ... I was running beta 3.8.0 before this and now quake is alot slower >>with 3.8.1 ... I keep getting 3 or 4 second pauses for no reason ... > >That and the fact that 3Com is not paying any attention to the beta tester >(at all?) -- 3.8.1 has some serious problems that I pointed out were still >broken from 3.8.0 to 3.8.1 with in a few days of 3.8.1 being posted for >testing. They have, of course, not touched the 3.8.1 code or even lifted >a finger to fix what they broke. (Yes, 3.7 works, 3.8 broke it.) > >--Ricky > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Yipe... almost sorry I asked. I haven't been reading the list too closely lately -- was there ever a good reason they don't finish moving the Pilgrim (ARC) code to the NETserver hardware that I missed seeing? Mike Andrews (MA12) icq 6602506 -------------- mandrews@dcr.net Senior Systems/Network Administrator --- mandrews@termfrost.org Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "If Barbie is so popular, why do you have to buy her friends?..." On Mon, 7 Sep 1998, Ricky Beam wrote: > Jamie Orzechowski was heard to say: > >nope ... I was running beta 3.8.0 before this and now quake is alot slower > >with 3.8.1 ... I keep getting 3 or 4 second pauses for no reason ... > > That and the fact that 3Com is not paying any attention to the beta tester > (at all?) -- 3.8.1 has some serious problems that I pointed out were still > broken from 3.8.0 to 3.8.1 with in a few days of 3.8.1 being posted for > testing. They have, of course, not touched the 3.8.1 code or even lifted > a finger to fix what they broke. (Yes, 3.7 works, 3.8 broke it.) > > --Ricky

First, You need to verify that the Modem Line interface source is set to nic. Select the modems you want to change. go to configure, select program setting, then select Line Interface Options, next select Line Interface Source , Need to verify it is set to nic. Perform a set, and the modem (s) should start answering calls. Hope this helps. Mark Ross <mark@apu.ccis.com> on 09/07/98 06:00:26 PM Please respond to usr-tc@lists.xmission.com cc: (Eugene Carpenter/US/3Com) Hello, Can I setup 1 or 2 quad analog/digital modem cards in my Total control chassis to accept pots calls ?, If so then do I have to have a terminal server connect to the RS232 connectors, OR will the Total Control handle the answering and data flow to the modems through the packet buss ? So far I have not been able to get the modem to answer thanks - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Welcome to the wonderful world of 3Com NON-TECH SUPPORT, a place where all your worst nightmares will come to life. Technically, I think 3Com is giving you the shaft. You have a contract. A contract is a contract. Point out the fine print to your 3Com Rep. As for applicable laws, maybe something like an ex-post facto clause. But I believe that only applies to US government. Save yourself a migraine, get a PM3 or PM4. They are so sweet to setup (initialize about 2 mins, configure 1 min, reboot 1 min, walk away with confidence), and Lucent/Livingston FREE tech support is awesome, way better than 3Com's PAY-UP-THE-NOSE SUPPORT. Of course, if you absolutely have to have 24/7 support, they haver very reasonable service contracts. But IMHO, you can usually do with just the FREE support. Jose -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of matthew Sent: Monday, September 07, 1998 5:02 PM well the quake issue was never really an issue for us. we have always had really good luck with our total control stuff, but something happened recently that has me pissed. we had a service contract we bought a while ago that we never activated. we went to activate it and were told that 3com has a new policy that you must have service contracts for ALL of your total control equipment or they won't let you get or even activate an already purchased service contract for just 1 or a few pieces of equipment. i really hate to be told i must purchase service contracts for everything i have from one manufacturer. we never really looked at the pm3 equipment but i'm feeling like i should really look at the pm4 stuff. is it just me or does this border on abuse? is there any law that would protect us from them passing mandates like this??? matthew Jamie Orzechowski wrote: > > nope ... I was running beta 3.8.0 before this and now quake is alot slower > with 3.8.1 ... I keep getting 3 or 4 second pauses for no reason ... > > 3Com is NOT going to fix this prob ... the can but they won't ... so i'll go > get my new equipment from Livingston .. PM4's are VERY nice ... > > -----Original Message----- > From: Mike Andrews <mandrews@termfrost.org> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Monday, September 07, 1998 6:24 PM > Subject: (usr-tc) NETserver 3.8.1 > > >Looks like there is a new NETserver release out. Once again, "Quake > >improvements" are listed in the release notes. Anyone tried this yet and > >know if there's any real progress yet? I can't get the code myself since > >we still haven't bought a service contract... > > > > > >Mike Andrews (MA12) icq 6602506 -------------- mandrews@dcr.net > >Senior Systems/Network Administrator --- mandrews@termfrost.org > >Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ > >"If Barbie is so popular, why do you have to buy her friends?..." - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

IF THERE ARE ANY 3COM personnel not afraid to read this list, I hope you realize I am probably one of many ISPs you lost mucho bucks from. Of course, I'm only a small ISP over here. But according to my growth trend, you just lost out on half a million in sales over the next year... Jose

Is the archive of this list at http://www.datasys.net/usr-tc/ The links from the index pages found there are all broken. Thanks for any info. fbsd

well the quake issue was never really an issue for us. we have always had really good luck with our total control stuff, but something happened recently that has me pissed. we had a service contract we bought a while ago that we never activated. we went to activate it and were told that 3com has a new policy that you must have service contracts for ALL of your total control equipment or they won't let you get or even activate an already purchased service contract for just 1 or a few pieces of equipment. i really hate to be told i must purchase service contracts for everything i have from one manufacturer. we never really looked at the pm3 equipment but i'm feeling like i should really look at the pm4 stuff. is it just me or does this border on abuse? is there any law that would protect us from them passing mandates like this??? matthew Jamie Orzechowski wrote: > > nope ... I was running beta 3.8.0 before this and now quake is alot slower > with 3.8.1 ... I keep getting 3 or 4 second pauses for no reason ... > > 3Com is NOT going to fix this prob ... the can but they won't ... so i'll go > get my new equipment from Livingston .. PM4's are VERY nice ... > > -----Original Message----- > From: Mike Andrews <mandrews@termfrost.org> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Monday, September 07, 1998 6:24 PM > Subject: (usr-tc) NETserver 3.8.1 > > >Looks like there is a new NETserver release out. Once again, "Quake > >improvements" are listed in the release notes. Anyone tried this yet and > >know if there's any real progress yet? I can't get the code myself since > >we still haven't bought a service contract... > > > > > >Mike Andrews (MA12) icq 6602506 -------------- mandrews@dcr.net > >Senior Systems/Network Administrator --- mandrews@termfrost.org > >Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ > >"If Barbie is so popular, why do you have to buy her friends?..."

USR USED to be great ... but since 3Com .. THEY SUCK! ... I get some chick called "Lei" on tech support that I cannot even understand ... she does not believe one word I say ... so I say .. fine ... run your tests ... she tried to explain to me that I have my box configured wrong ... after 45 mins on the phone ... she goes oh .. your right =) .. happens over and over ... one out of 10 calls I actually get a USR tech that knows his/her stuff ... they have yet to fix any of my problems ... I'll be glad to see when people starting buying elsewhere ... USR might have been on top at one time .. but I can find many other providers that will give me what I need now and not give me excuses and broken code ... listen up 3COM! ... why should wespend $400,000 with your company when we do not get the support we deserve ... -----Original Message----- >well the quake issue was never really an issue for us. we have always >had really good luck with our total control stuff, but something >happened recently that has me pissed. > > we had a service contract we bought a while ago that we never >activated. we went to activate it and were told that 3com has a new >policy that you must have service contracts for ALL of your total >control equipment or they won't let you get or even activate an already >purchased service contract for just 1 or a few pieces of equipment. > > i really hate to be told i must purchase service contracts for >everything i have from one manufacturer. > > we never really looked at the pm3 equipment but i'm feeling like i >should really look at the pm4 stuff. is it just me or does this border >on abuse? > > is there any law that would protect us from them passing mandates like >this??? > > matthew > >Jamie Orzechowski wrote: >> >> nope ... I was running beta 3.8.0 before this and now quake is alot slower >> with 3.8.1 ... I keep getting 3 or 4 second pauses for no reason ... >> >> 3Com is NOT going to fix this prob ... the can but they won't ... so i'll go >> get my new equipment from Livingston .. PM4's are VERY nice ... >> >> -----Original Message----- >> From: Mike Andrews <mandrews@termfrost.org> >> To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >> Date: Monday, September 07, 1998 6:24 PM >> Subject: (usr-tc) NETserver 3.8.1 >> >> >Looks like there is a new NETserver release out. Once again, "Quake >> >improvements" are listed in the release notes. Anyone tried this yet and >> >know if there's any real progress yet? I can't get the code myself since >> >we still haven't bought a service contract... >> > >> > >> >Mike Andrews (MA12) icq 6602506 -------------- mandrews@dcr.net >> >Senior Systems/Network Administrator --- mandrews@termfrost.org >> >Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ >> >"If Barbie is so popular, why do you have to buy her friends?..." > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Same here. -----Original Message----- >IF THERE ARE ANY 3COM personnel not afraid to read this list, I hope you >realize I am probably one of many ISPs you lost mucho bucks from. > >Of course, I'm only a small ISP over here. But according to my growth >trend, you just lost out on half a million in sales over the next year... > > >Jose > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

<RANT> All I want is what I paid for when I bought my TC boxes. Code that works!!! If they couldn't deliver that when they sold me the boxes, they sure as hell better get me code that works without having shell out $$,$$$.$$ a year for a stinking service contract. I'm not looking for advanced replacement of parts, 24-hour tech support, or any of those nice extras I'd expect to pay for via a service contract. I just want a stinking hub that works with my customers modems and performs the tasks it was designed for without major problems. My contract with them ran out 2 months ago and I will never again pay for the type of support I received from them. Nor will I ever buy another TC hub or any other 3-Com equipment until they have support that makes sense. E.g., if you make buggy code and I buy it, I want it fixed... But for now, I'll vote with my wallet. </RANT> Jamie Orzechowski wrote: > > same here! > > -----Original Message----- > From: Jose de Leon <jadiel@thevision.net> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Monday, September 07, 1998 10:27 PM > Subject: (usr-tc) 3Com: You Lose! > > >IF THERE ARE ANY 3COM personnel not afraid to read this list, I hope you > >realize I am probably one of many ISPs you lost mucho bucks from. > > > >Of course, I'm only a small ISP over here. But according to my growth > >trend, you just lost out on half a million in sales over the next year... > > > > > >Jose > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and 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. -- ======================================================= =========== Andrew Aken - President ========= ====== GlobalEyes Communications, Inc. ====== =Southern Illinois' Fastest Connection to the Internet= ========== http://www.GlobalEyes.net ======== =======================================================

same here! -----Original Message----- >IF THERE ARE ANY 3COM personnel not afraid to read this list, I hope you >realize I am probably one of many ISPs you lost mucho bucks from. > >Of course, I'm only a small ISP over here. But according to my growth >trend, you just lost out on half a million in sales over the next year... > > >Jose > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

: Technically, I think 3Com is giving you the shaft. You have a : contract. A contract is a contract. Point out the fine print to your : 3Com Rep. We have a hard time getting a 3Com rep to return phone calls. It's pitiful -- it's a major hassle for them to bother to sell us a maintenance contract.

Jamie Orzechowski was heard to say: >USR USED to be great ... but since 3Com .. THEY SUCK! ... I get some chick >called "Lei" on tech support that I cannot even understand ... she does not >believe one word I say ... so I say .. fine ... run your tests ... she tried >to explain to me that I have my box configured wrong ... after 45 mins on >the phone ... she goes oh .. your right =) .. happens over and over ... one >out of 10 calls I actually get a USR tech that knows his/her stuff ... they >have yet to fix any of my problems ... I'll be glad to see when people >starting buying elsewhere ... USR might have been on top at one time .. but >I can find many other providers that will give me what I need now and not >give me excuses and broken code ... listen up 3COM! ... why should wespend >$400,000 with your company when we do not get the support we deserve ... About the only thing worth anything is their RADIUS server -- slower, but very configurable. And I'm not entirely sure 3Com/USR wrote it. In their defense, I think management is more of the problem than the people writing the code -- they only do what they are ordered to do. --Ricky

MegaZone was heard to say: >Yeah - if they fix the NetServer TC it is harder for them to strong-arm >you into PAYING to upgrade to the HiPer ARC TC. The longer the NetServer >goes unfixed, the more people they can convince to shell out more cash >to buy new HW to 'fix' the problems. FWIW, the ARC is a better product. I don't think you are still using a 386 as your desktop machine? Granted, a 603e is a bit much for a rack full of quads. From a price-port density (i.e. rack space) point-of-view, the hiper stuff is one of the best solutions (and all them lights translates to a good bit of "wow" for customer walk throughs -- i.e. $$$) --Ricky

Jose de Leon was heard to say: >IF THERE ARE ANY 3COM personnel not afraid to read this list, I hope you >realize I am probably one of many ISPs you lost mucho bucks from. > >Of course, I'm only a small ISP over here. But according to my growth >trend, you just lost out on half a million in sales over the next year... .5Mil$ doesn't get their attention anymore... How much hardware does AOL, Sprint, or Mindspring have? --Ricky

well that is actually the only reason we really need the service contract, we want to be able to keep getting updates to code and after our last contact ran out the only thing we lost access to on their website was the radius/security code. now if someone wanted to download it and send me the nt version of security/accounting... matthew Ricky Beam wrote: > > Jamie Orzechowski was heard to say: > >USR USED to be great ... but since 3Com .. THEY SUCK! ... I get some chick > >called "Lei" on tech support that I cannot even understand ... she does not > >believe one word I say ... so I say .. fine ... run your tests ... she tried > >to explain to me that I have my box configured wrong ... after 45 mins on > >the phone ... she goes oh .. your right =) .. happens over and over ... one > >out of 10 calls I actually get a USR tech that knows his/her stuff ... they > >have yet to fix any of my problems ... I'll be glad to see when people > >starting buying elsewhere ... USR might have been on top at one time .. but > >I can find many other providers that will give me what I need now and not > >give me excuses and broken code ... listen up 3COM! ... why should wespend > >$400,000 with your company when we do not get the support we deserve ... > > About the only thing worth anything is their RADIUS server -- slower, but > very configurable. And I'm not entirely sure 3Com/USR wrote it. In their > defense, I think management is more of the problem than the people writing > the code -- they only do what they are ordered to do. > > --Ricky > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Once upon a time Ricky Beam shaped the electrons to say... >About the only thing worth anything is their RADIUS server -- slower, but >very configurable. And I'm not entirely sure 3Com/USR wrote it. In their I believe it is modified from Merit RADIUS source. BTW, have you looked at some of the free server's like Cistron RADIUS? I hate to say it, but I think it is better than any of the base RADIUS servers from vendors like Ascend, 3Com, even Lucent. Very configurable, build in simultaneous use control WITH SNMP backup, they just put out an alpha with VSA support, etc. All free, done by online developers coordinated by mailing list. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

Once upon a time Ricky Beam shaped the electrons to say... >sort of short coming. Most of them don't support SecureID authentication >which was the entire reason USR products ever came in the building. And, Ah, yeah, that usually requires contact with SecurID and I don't think any of the free servers do it. Lucent RABU's free server does, but it is only available to Lucent HW users. >I'd love to test out other hardware, but our parent compnay (Carolina Power >and Light) would shit kittens if a Lucent product came in the door. They Got any NetServers? They run an OS licensed from Lucent RABU (was Livingston). Tell them that, maybe they'll help replace them. ;-) Seriously though - that's just silly. The NAS products have next to nil to do with the phone switches. I still like 3Com hubs and NICs even if I like to poke fun at their NAS. >PS: Ever looked at CiscoSecure? Not of late, and I understand they've been polishing it up. I need to check it out again. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

I know that some 3com techs read this message list and the following message is NOT a flame towards them. In fact I get BETTER support from this list than the 24/7 contract that we got suckered into. This message is directed toward 3com management. <sarcasm> I insist that AOL, Sprint, and Mindspring continue to purchase 3Com products! Moreover, any ISP who serves the 409 and (soon) 281,713,512,210 area code PLEASE buy 3com Total Control products! Ignore all of the complaints on this mailing list. Have an open mind and an open wallet. 3com is your ticket! The chassis name says it all - "Total Control", meaning it will TOTALLY CONTROL YOU! Since buying our 3com Hiper ARC/Hiper DSP chassis, life has never been the same! </sarcasm> Since May, we have an intermittent problem with our 3com Hiper DSP chassis. It will "ring - no answer". It happens on any slot or modem and we have to reset the slot to get the bad modem to finally answer. 3com claimed it was our PRI provider (GTE). And GTE blamed 3com. Finally, GTE was able to PROVE to 3com that in fact the call was routing to our chassis. I have emailed 3com our syslog file plus other screen shots, yet... Last night it happened 3 times: Sep 7 21:09:32 bry409 At 21:07:33, Facility "GWC Modem Driver", Level "CRITICAL ":: GWCMDMDRV FSM illegal event interface slot:4/mod:4, state Disconnecting, eve nt CallArrivedReq Sep 7 21:30:14 bry409 At 21:28:15, Facility "GWC Modem Driver", Level "CRITICAL ":: GWCMDMDRV FSM illegal event interface slot:4/mod:6, state Disconnecting, eve nt CallArrivedReq Sep 7 21:39:37 bry409 At 21:37:38, Facility "GWC Modem Driver", Level "CRITICAL ":: GWCMDMDRV FSM illegal event interface slot:1/mod:2, state Disconnecting, eve nt CallArrivedReq The only way to fix this problem is to reset the entire PRI slot. Last night we booted off nearly 35 users - THIS IS UNACCEPTABLE! We cannot simply reset the affected modem - it won't respond to any modem commands. We have done EVERYTHING 3com has suggested (upgrade software, re-flash, and change card slots), but now 3com insist that we login via serial connection, however, this is at a REMOTE location. I thought these *&^(*&^ things can be managed via remote! Anyway I got instructions on what debug commands they needed as to determine the problem, yet those commands were WRONG (syntax errors). Nevertheless, I'm tired of ping-ponging with 3com. I'm getting tired of calling and getting "a luck of the draw" tech and have to explain this problem for 15-20 mins! Will we vote with our wallet? YOU BET YOUR ASS! By December 1, we plan to expand into Houston - and ITS NOT A SMALL MARKET 3COM! I guarantee that there will be not ONE 3com chassis, hub, switch, or NIC in our racks! I plan to send 3com and Source Technology (the place we bought this POS) a copy of invoices of purchases we made from Cisco or Lucent (we are leaning toward Lucent). In fact I may have them framed. We started out with USR (analog) modems and had good luck with them. We then moved up to their Courier-I modem pool and modems. Again, we had very few problems. Yet, this Total Control Chassis (the Hiper ARC/DSP) have been a nightmare from the start. We cannot afford to lose anymore subscribers because 3COm is unable/unwilling to solve our problem. I also have a complaint about 3Com's software policy. I can't believe that you charge for upgrades or require a service contract! Is 3Com trying to recoup the cost from buying the right to rename Candlestick Park to 3Com Park? We recently bought a used Livingston (Lucent) PM-25 from a reseller in Houston. The dealer already upgraded the OS for us, yet we can get future upgrades on Lucent's web site. Moreover, we were able to download the PM Config utility for the amazing price of $0.00. Needless to say I'm quite impressed with Livingston/Lucent. Oh, I forgot to mention they are sending us an eval PM3 unit! Last thing about Livingston, they didn't care how/what/where we got our PM product. We didn't need to go through channels to get updated software. Their only concern seems to be that it works - PERIOD! We consider our Hiper DSP chassis a $23,000 expensive lesson - maybe a token boat anchor, paper weight or door stop. Richard Lorbieski Senior System Admin Alpha1 "Former 3com customer" Internet richard@alpha1.net Ricky Beam wrote: > > Jose de Leon was heard to say: > >IF THERE ARE ANY 3COM personnel not afraid to read this list, I hope you > >realize I am probably one of many ISPs you lost mucho bucks from. > > > >Of course, I'm only a small ISP over here. But according to my growth > >trend, you just lost out on half a million in sales over the next year... > > .5Mil$ doesn't get their attention anymore... How much hardware does AOL, > Sprint, or Mindspring have? >

MegaZone was heard to say: >Once upon a time Ricky Beam shaped the electrons to say... >>About the only thing worth anything is their RADIUS server -- slower, but >>very configurable. And I'm not entirely sure 3Com/USR wrote it. In their > >I believe it is modified from Merit RADIUS source. That's like saying Netscape is a modified version of Mosaic. I've got both Merit and 3Com/USR RADIUS sources and they are *very* different. That does not rule out the possiblity that USR bought the Merit source and used it's core packet processing engine, but the end product can be matched to Merit. >BTW, have you looked at some of the free server's like Cistron RADIUS? Yes, I've looked about every free thing I can get and they all have some sort of short coming. Most of them don't support SecureID authentication which was the entire reason USR products ever came in the building. And, IMO, that's the only reason "we" (I had nothing to do with the decision) replaced all of our modem hardware (MicroCom HDMS/Fast Chassis + Netblazers) with USR (now 3Com) TC hardware. It's taken 18 months to complete the process and we still have old "junk" out in the network. As much as I like the flashiness of the TC hardware (all them lights) and will hate the 2 year process of removing the 3Com "junk" from the network, as this point, the instant Cisco make an offer, I'd be very likely to take it. I'd love to test out other hardware, but our parent compnay (Carolina Power and Light) would shit kittens if a Lucent product came in the door. They already hate the Definity phone switch we have (leased before the merger.) They have this thing with Nortel and 3Com (network products) -- I don't understand it. About the only thing I'd trust from 3Com is the RADIUS server so long as I have the source code -- it's hard to hard to abandon something I'm maintaining myself... --Ricky PS: Ever looked at CiscoSecure?

MegaZone was heard to say: >Once upon a time Ricky Beam shaped the electrons to say... >>I'd love to test out other hardware, but our parent compnay (Carolina Power >>and Light) would shit kittens if a Lucent product came in the door. They > >Got any NetServers? They run an OS licensed from Lucent RABU (was Livingston). >Tell them that, maybe they'll help replace them. ;-) You misunderstand... Lucent will give us a PM3/4. The instant it comes in the door, I don't have a job -- get it. >Seriously though - that's just silly. The NAS products have next to nil to >do with the phone switches. I still like 3Com hubs and NICs even if I like >to poke fun at their NAS. Tell me about it... yet more idiot spooge from mangers that have no idea what they are selling their soul for. They seem to be of the mind "what's good for Telco is good ISP." They have a hard lesson moving at high speed towards they head. (They just love making decisions without talking to the people running the ISP side of things. They may know how to move dialtone but they have zero clue as to moving IP.) --Ricky

On Mon, 7 Sep 1998, Mark Ross wrote: > Hello, > Can I setup 1 or 2 quad analog/digital modem cards in my Total control > chassis to accept pots calls ?, If so then do I have to have a terminal > server connect to the RS232 connectors, OR will the Total Control handle > the answering and data flow to the modems through the packet buss ? > > So far I have not been able to get the modem to answer > Yes you can - depending upon the type of the gateway card you have. Say you have a netserver, then you can disable those two or one port ( S port ) on the netserver and connect it to the terminal server. You should then set the modems to rs232 ( via tcm or just disable them from the netserver ) and then set the line to analog ( at%d0 ) krish > thanks > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Tue, 8 Sep 1998, Bob Purdon wrote: > Now we have to deal with resellers. Doesn't come close to the service we > had before dealing direct. I know 3COM's *big* customers have reps of > their own, but I guess we don't spend enough. Don't be so confident in that. Our firm is a 3com ASP, full blown support contracts, yada yada, and I've still had a really difficult time dealing with their infrastructure. If I were 3com management, I'd be very concerned about a technical support system which has received such widespread, negative reviews from almost all comers. It also speaks ill of the future when resellers, who move millions of dollars of product every year, still have a hard time getting code updates or technical support, due to an inability to integrate heteregenous (sp?) support systems. Anyone at 3Com awake out here?

Thus spake Bob Purdon >dp2-tc was, about 3 weeks ago, on the IP address pA05.dev is now on. The >DNS has been updated, name servers HUP'd, and NETserver rebooted in the >interim. >Everything else on the network sees this IP address correctly, except this >particular NETserver. Somehow, this NETserver is picking up old DNS data. >In one case, it's showing a hostname that doesn't exist in our DNS any >longer (grep "hostname" *). >Any ideas anyone? Netservers have thier own DNS caching mechanism that you can specify the timeout on...uhm...don't remember the command off the top of my head, but think its defaults to 30 seconds, so unless you've changed it, it *shouldn't* be still holding onto this data for that reason. The command (just went and found it) is: set dnscache <DD:HH:MM> Might want to check out what your value is set to and see if it got set really high for some reason. I *wish* that if they were going to do their own DNS caching that they'd do away with the dnscache command and just cache based on DNS TTL's...that's why they're *there* for goodness sakes. That's a pet peeve of mine...people putting DNS cache's in software and doing their own timeouts instead of using normal DNS timeout info which is readily available. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Lets start a TC boat anchor art project. I've got one to contribute. I've got space in front of my building, a little glue, some well placed bird crap, creative arrangement, we could make a nice artistic statement. -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Richard Lorbieski Sent: Tuesday, September 08, 1998 1:52 AM [snip snip] We consider our Hiper DSP chassis a $23,000 expensive lesson - maybe a token boat anchor, paper weight or door stop. Richard Lorbieski Senior System Admin Alpha1 "Former 3com customer" Internet richard@alpha1.net Ricky Beam wrote: > > Jose de Leon was heard to say: > >IF THERE ARE ANY 3COM personnel not afraid to read this list, I hope you > >realize I am probably one of many ISPs you lost mucho bucks from. > > > >Of course, I'm only a small ISP over here. But according to my growth > >trend, you just lost out on half a million in sales over the next year... > > .5Mil$ doesn't get their attention anymore... How much hardware does AOL, > Sprint, or Mindspring have? > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

On Mon, 7 Sep 1998 Eugene_Carpenter@3com.com wrote: > You need to verify that the Modem Line interface source is set to nic. How do I check this via the serial port? > > Select the modems you want to change. > go to configure, select program setting, Using what program? Can it be used thru the serial port of the nic because that is the ONLY way I have to communicate with the modems. ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ Jake Messinger, VP. ph:713-772-6690 Lucent Dealer AMS, Inc. fx:713-774-3498 Medical Billing 8300 Bissonnet #400 jake@ams.com , ICQ# 4403734 Internet Services Houston, Texas 77074 www.ams.com/~jake and Hardware Adjunct Professor University of Houston, CBA jake@uh.edu ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~

What made it even worse is they doubled the price on top of that from the previous maintance contract fees. Jeff U>well the quake issue was never really an issue for us. we have always U>had really good luck with our total control stuff, but something U>happened recently that has me pissed. U> we had a service contract we bought a while ago that we never U>activated. we went to activate it and were told that 3com has a new U>policy that you must have service contracts for ALL of your total U>control equipment or they won't let you get or even activate an U>already purchased service contract for just 1 or a few pieces of U>equipment. U> i really hate to be told i must purchase service contracts for U>everything i have from one manufacturer. U> we never really looked at the pm3 equipment but i'm feeling like i U>should really look at the pm4 stuff. is it just me or does this border U>on abuse? U> is there any law that would protect us from them passing mandates U>like this??? U> matthew U>Jamie Orzechowski wrote: U>> nope ... I was running beta 3.8.0 before this and now quake is alot U>> slower with 3.8.1 ... I keep getting 3 or 4 second pauses for no U>> reason ... U>> 3Com is NOT going to fix this prob ... the can but they won't ... so U>> i'll go get my new equipment from Livingston .. PM4's are VERY nice U>> ... U>> -----Original Message----- U>> From: Mike Andrews <mandrews@termfrost.org> U>> To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> U>> Date: Monday, September 07, 1998 6:24 PM U>> Subject: (usr-tc) NETserver 3.8.1 U>> >Looks like there is a new NETserver release out. Once again, U>> >"Quake improvements" are listed in the release notes. Anyone tried U>> >this yet and know if there's any real progress yet? I can't get U>> >the code myself since we still haven't bought a service contract... CMPQwk 1.42 9999

It is a problem with 3Com management and the fact that they are losers. How do I know that? Winners never give up. Actually, maybe not the management since they just tell people what to do. It is probably 3Com leadership. 3Com has no vision right now. 3Com gave up on the TC because they have a very difficult time solving the problem. -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Vito Sent: Tuesday, September 08, 1998 9:24 AM So then why is there so much UDP packet loss ie. Major PING time. If anyone know's how to fix UDP packet problem please let me know? Is a problem of the server's or USR modem racks? At 08:02 PM 9/7/98 , you wrote: >well the quake issue was never really an issue for us. we have always >had really good luck with our total control stuff, but something >happened recently that has me pissed. > > we had a service contract we bought a while ago that we never >activated. we went to activate it and were told that 3com has a new >policy that you must have service contracts for ALL of your total >control equipment or they won't let you get or even activate an already >purchased service contract for just 1 or a few pieces of equipment. > > i really hate to be told i must purchase service contracts for >everything i have from one manufacturer. > > we never really looked at the pm3 equipment but i'm feeling like i >should really look at the pm4 stuff. is it just me or does this border >on abuse? > > is there any law that would protect us from them passing mandates like >this??? > > matthew > >Jamie Orzechowski wrote: >> >> nope ... I was running beta 3.8.0 before this and now quake is alot slower >> with 3.8.1 ... I keep getting 3 or 4 second pauses for no reason ... >> >> 3Com is NOT going to fix this prob ... the can but they won't ... so i'll go >> get my new equipment from Livingston .. PM4's are VERY nice ... >> >> -----Original Message----- >> From: Mike Andrews <mandrews@termfrost.org> >> To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >> Date: Monday, September 07, 1998 6:24 PM >> Subject: (usr-tc) NETserver 3.8.1 >> >> >Looks like there is a new NETserver release out. Once again, "Quake >> >improvements" are listed in the release notes. Anyone tried this yet and >> >know if there's any real progress yet? I can't get the code myself since >> >we still haven't bought a service contract... >> > >> > >> >Mike Andrews (MA12) icq 6602506 -------------- mandrews@dcr.net >> >Senior Systems/Network Administrator --- mandrews@termfrost.org >> >Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ >> >"If Barbie is so popular, why do you have to buy her friends?..." > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 Vito - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

NETserver 3.7.24. S38 smith dp2-tc.southcom. Netwrk In ESTABLISHED 14 dp2-tc should read pA05.dev, and up until yesterday, that's what it *did* say. dp2-tc was, about 3 weeks ago, on the IP address pA05.dev is now on. The DNS has been updated, name servers HUP'd, and NETserver rebooted in the interim. Everything else on the network sees this IP address correctly, except this particular NETserver. Somehow, this NETserver is picking up old DNS data. In one case, it's showing a hostname that doesn't exist in our DNS any longer (grep "hostname" *). Any ideas anyone? Regards, Bob Purdon, Technical Manager, Southern Internet Services.

What must I do to put a Dual-E1 and Quads on a chassis with HARC and DSPs. I could not see a option to set a slot as Dual-E1, on ARC commands. The only options was: EMPTY, HDM_24, HDM_30, QUAD_I_MODEM, QUAD_MODEM - Marcelo

> USR USED to be great ... but since 3Com .. THEY SUCK! ... I get some > chick called "Lei" on tech support that I cannot even understand ... > she does not believe one word I say ... :-) I had one in Singapore tell me to take photos of our NETserver card so that they could get the serial number, despite the fact that I'd have to take 4 NETserver's out of service to do it and drive nearly 1000km. All this because they needed a 12 digit serial number, rather than the 8 digit one TCM shows. Even the local guys couldn't believe this one... Regards, Bob Purdon, Technical Manager, Southern Internet Services.

On the Total Control Hub, can you use the traffic shape implementation as i= n the Cisco Routers to limit the bandwidth=2E

So then why is there so much UDP packet loss ie. Major PING time. If anyone know's how to fix UDP packet problem please let me know? Is a problem of the server's or USR modem racks? At 08:02 PM 9/7/98 , you wrote: >well the quake issue was never really an issue for us. we have always >had really good luck with our total control stuff, but something >happened recently that has me pissed. > > we had a service contract we bought a while ago that we never >activated. we went to activate it and were told that 3com has a new >policy that you must have service contracts for ALL of your total >control equipment or they won't let you get or even activate an already >purchased service contract for just 1 or a few pieces of equipment. > > i really hate to be told i must purchase service contracts for >everything i have from one manufacturer. > > we never really looked at the pm3 equipment but i'm feeling like i >should really look at the pm4 stuff. is it just me or does this border >on abuse? > > is there any law that would protect us from them passing mandates like >this??? > > matthew > >Jamie Orzechowski wrote: >> >> nope ... I was running beta 3.8.0 before this and now quake is alot slower >> with 3.8.1 ... I keep getting 3 or 4 second pauses for no reason ... >> >> 3Com is NOT going to fix this prob ... the can but they won't ... so i'll go >> get my new equipment from Livingston .. PM4's are VERY nice ... >> >> -----Original Message----- >> From: Mike Andrews <mandrews@termfrost.org> >> To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >> Date: Monday, September 07, 1998 6:24 PM >> Subject: (usr-tc) NETserver 3.8.1 >> >> >Looks like there is a new NETserver release out. Once again, "Quake >> >improvements" are listed in the release notes. Anyone tried this yet and >> >know if there's any real progress yet? I can't get the code myself since >> >we still haven't bought a service contract... >> > >> > >> >Mike Andrews (MA12) icq 6602506 -------------- mandrews@dcr.net >> >Senior Systems/Network Administrator --- mandrews@termfrost.org >> >Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ >> >"If Barbie is so popular, why do you have to buy her friends?..." > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 Vito

Thus spake jcusmano@westcon.com >On the Total Control Hub, can you use the traffic shape implementation as i= >n the >Cisco Routers to limit the bandwidth=2E Right! haha...they can't even get their systems to where they can reliably pass data back and forth *without* trying to affect the flows at all...I'd be scared to let them try to shape the traffic flows at all... -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

I'm having the same problem with PRI's. I've got the dual PRI card, 12 quads & an ARC card & I can't get the modems to take calls - it always gives me a fast busy. I've got 14 DSPs in a box with 2 ARCs that work fine (excepting the usual complaints), but I can't get my last 2 going on the quads. Any thoughts? Mike Stankavich NorFab/ISP, Inc. Portland OR mike@ethergate.com -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Marcelo Souza Sent: Tuesday, September 08, 1998 6:25 AM What must I do to put a Dual-E1 and Quads on a chassis with HARC and DSPs. I could not see a option to set a slot as Dual-E1, on ARC commands. The only options was: EMPTY, HDM_24, HDM_30, QUAD_I_MODEM, QUAD_MODEM - Marcelo - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

If you do not know the answer, please do not reply=2E =20= ____________________Reply Separator____________________ Author: jeffm@iglou=2Ecom Thus spake jcusmano@westcon=2Ecom >On the Total Control Hub, can you use the traffic shape implementation as i=3D >n the >Cisco Routers to limit the bandwidth=3D2E Right! haha=2E=2E=2Ethey can't even get their systems to where they can reliably pass data back and forth *without* trying to affect the flows at all=2E=2E=2EI'd be scared to let them try to shape the traffic flows at all=2E=2E=2E -- Jeff McAdams Email: jeffm@iglou=2Ecom Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission=2Ecom" with "unsubscribe usr-tc" in the body of the message=2E For information on digests or retrieving files and old messages send "help" to the same address=2E Do not use quotes in your message=2E

Thus spake jcusmano@westcon.com >If you do not know the answer, please do not reply Well...it was a reply, in a fashion...guess I'll have to make it simpler... No, you can't do this, and I think it would be a collosally bad idea for 3Com to try it since they can't seem to get their software working with just the features they currently "support." -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Telnet to the Netserver and issue a "show table hosts" If the information is wrong here, correct it. If it is empty, add the address for the first IP address in your pool. (IE Assigned address, not reported address) Even if you delete entries here, it has been our experience it will "remember" the last host name that lived in this table when all the host names have been deleted. It can lead to some strange show all's. Steve Kinkaid > >NETserver 3.7.24. > >S38 smith dp2-tc.southcom. Netwrk In ESTABLISHED 14 > >dp2-tc should read pA05.dev, and up until yesterday, that's what it *did* >say. > >dp2-tc was, about 3 weeks ago, on the IP address pA05.dev is now on. The >DNS has been updated, name servers HUP'd, and NETserver rebooted in the >interim. > >Everything else on the network sees this IP address correctly, except this >particular NETserver. Somehow, this NETserver is picking up old DNS data. >In one case, it's showing a hostname that doesn't exist in our DNS any >longer (grep "hostname" *). > >Any ideas anyone? > >Regards, > >Bob Purdon, >Technical Manager, >Southern Internet Services. > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >

On Mon, 7 Sep 1998, Ricky Beam wrote: > Jamie Orzechowski was heard to say: > >nope ... I was running beta 3.8.0 before this and now quake is alot slower > >with 3.8.1 ... I keep getting 3 or 4 second pauses for no reason ... > > That and the fact that 3Com is not paying any attention to the beta tester > (at all?) -- 3.8.1 has some serious problems that I pointed out were still > broken from 3.8.0 to 3.8.1 with in a few days of 3.8.1 being posted for > testing. They have, of course, not touched the 3.8.1 code or even lifted > a finger to fix what they broke. (Yes, 3.7 works, 3.8 broke it.) What are the issues in 3.8.1? I'd like to know before I install this, even on my test setup. Brian

You might want to look at Midnight Networks Avalanche/Web product http://www.midnight.com/AvalancheWeb/ Or, maybe Digital Technology, Inc.'s Chisel: http://www.dti-test.com See ya, Jaime At 04:33 PM 9/8/98 -0400, Jamie Orzechowski wrote: >Hi Everyone ... Being an ISP list I thought someone might have an idea where >to get something like this ... I need a program that will do something like >500 http requests and stored the TIME and K/SEC it took to get each one ... >for statistics ... something to compare speed between different ISP's ... >anyone have a clue what I could use for this ?? > >Jamie Orzechowski Jaime Sainez mailto:jsainez@livingston.com Product Marketing Engineer Tel: 925 737-2301 PortMaster Products Fax: 925 737-2110 Lucent Technologies RABU Pgr: 800 607-4937

just called and bitched at 3com about this and the tech guy didn't know what UDP was =) -----Original Message----- >So then why is there so much UDP packet loss ie. Major PING time. If anyone >know's how to fix UDP packet problem please let me know? >Is a problem of the server's or USR modem racks? > > > > >At 08:02 PM 9/7/98 , you wrote: >>well the quake issue was never really an issue for us. we have always >>had really good luck with our total control stuff, but something >>happened recently that has me pissed. >> >> we had a service contract we bought a while ago that we never >>activated. we went to activate it and were told that 3com has a new >>policy that you must have service contracts for ALL of your total >>control equipment or they won't let you get or even activate an already >>purchased service contract for just 1 or a few pieces of equipment. >> >> i really hate to be told i must purchase service contracts for >>everything i have from one manufacturer. >> >> we never really looked at the pm3 equipment but i'm feeling like i >>should really look at the pm4 stuff. is it just me or does this border >>on abuse? >> >> is there any law that would protect us from them passing mandates like >>this??? >> >> matthew >> >>Jamie Orzechowski wrote: >>> >>> nope ... I was running beta 3.8.0 before this and now quake is alot slower >>> with 3.8.1 ... I keep getting 3 or 4 second pauses for no reason ... >>> >>> 3Com is NOT going to fix this prob ... the can but they won't ... so >i'll go >>> get my new equipment from Livingston .. PM4's are VERY nice ... >>> >>> -----Original Message----- >>> From: Mike Andrews <mandrews@termfrost.org> >>> To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >>> Date: Monday, September 07, 1998 6:24 PM >>> Subject: (usr-tc) NETserver 3.8.1 >>> >>> >Looks like there is a new NETserver release out. Once again, "Quake >>> >improvements" are listed in the release notes. Anyone tried this yet and >>> >know if there's any real progress yet? I can't get the code myself since >>> >we still haven't bought a service contract... >>> > >>> > >>> >Mike Andrews (MA12) icq 6602506 -------------- mandrews@dcr.net >>> >Senior Systems/Network Administrator --- mandrews@termfrost.org >>> >Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ >>> >"If Barbie is so popular, why do you have to buy her friends?..." >> >>- >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the 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 > >Vito > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Thus spake Jamie Orzechowski >just called and bitched at 3com about this and the tech guy didn't know what >UDP was =) Why am I not surprised? Did you get it escalated? -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

I would love to get the EMail addresses of 3com dept. heads or management etc ... anyone? -----Original Message----- >Thus spake jcusmano@westcon.com >>On the Total Control Hub, can you use the traffic shape implementation as i= >>n the >>Cisco Routers to limit the bandwidth=2E > >Right! haha...they can't even get their systems to where they can >reliably pass data back and forth *without* trying to affect the flows >at all...I'd be scared to let them try to shape the traffic flows at >all... >-- >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. >

Ricky Beam <jfbeam@Interpath.net> writes: > .5Mil$ doesn't get their attention anymore... How much hardware does AOL, > Sprint, or Mindspring have? A lot. :-) -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

no ... I just called 10 times in a row to see what I would get for answers ... they ranged from I don't know what the problem is ... to NETServer code 3.8.1 will be the last code release for NETServer and the currentt problems will not be fixed ... and a sales pitch to get a HiPER Arc when I mentioned PM4's ... =) -----Original Message----- >Thus spake Jamie Orzechowski >>just called and bitched at 3com about this and the tech guy didn't know what >>UDP was =) > >Why am I not surprised? > >Did you get it escalated? >-- >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. >

for about three years now, we've been using 3com/usr equipment (tc hubs, tc netservers, etc). but lately i've been having nothing but trouble ... nothing major, just enough to piss off customers. things like unknown hangup problems, users not getting connected the first couple of tries ... etc., etc., etc. and don't think i haven't tried to fix these problems. i've tried, 3com's tried, people on this mailing list have tried, all without sucess. it's just one flaky problem after another. anyway ... my question is, does anyone out there know of any better equipment? if not better, how about equaly as good, but without the headaces. also, does anyone know of any equipment/software that might let us test the analog phone lines that we are using with our usr/3com equipment? we have no clue wether the phone company is at fault, but usr/3com won't even talk to us about that possability. thanks for any help anyone can give. c-ya! :-)

Hi Everyone ... Being an ISP list I thought someone might have an idea where to get something like this ... I need a program that will do something like 500 http requests and stored the TIME and K/SEC it took to get each one ... for statistics ... something to compare speed between different ISP's ... anyone have a clue what I could use for this ?? Jamie Orzechowski RipNET Internet System Administrator Tel.: (613)342-3946 ext 293 Tel.: (800)267-4434 ext 293 Fax.: (613)342-8672 Page.: (613)341-0883 EMail.: mailto:mhz@recorder.ca Web.: http://www.moonchilli.com "One World, One Web, One Program" - Microsoft Promotional Ad "Ein Reich, Ein Volk, Ein Fuhrer" - Adolf Hitler

I am interested ... I would love to see a LARGE group of ISP's getting involved and finally get somethign donw about this ... I'll be happy with Free HiPER ARC's ... even 2 free HiPER ARC for my 5 chassis will be fine ... -----Original Message----- >I believe there is a law, the same one that stops printer manufactures from >voiding warranty if you use recharged toner. I will ask my partner, a lawyer >about it. > >BTW if we can not get v.90 to work right in our 2059 chassis we are thinking >about a class action suit, anybody interested in turning boat anchors to >cash? Seriously the v.90 is BS but our unit runs X2 great! Off of PRI's > >Mike Hamrich >CIO >DrFast.Net, Inc. >-----Original Message----- >From: Vito <vito@aracnet.net> >To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >Date: Tuesday, September 08, 1998 8:57 AM >Subject: Re: (usr-tc) NETserver 3.8.1 > > >>So then why is there so much UDP packet loss ie. Major PING time. If anyone >>know's how to fix UDP packet problem please let me know? >>Is a problem of the server's or USR modem racks? >> >> >> >> >>At 08:02 PM 9/7/98 , you wrote: >>>well the quake issue was never really an issue for us. we have always >>>had really good luck with our total control stuff, but something >>>happened recently that has me pissed. >>> >>> we had a service contract we bought a while ago that we never >>>activated. we went to activate it and were told that 3com has a new >>>policy that you must have service contracts for ALL of your total >>>control equipment or they won't let you get or even activate an already >>>purchased service contract for just 1 or a few pieces of equipment. >>> >>> i really hate to be told i must purchase service contracts for >>>everything i have from one manufacturer. >>> >>> we never really looked at the pm3 equipment but i'm feeling like i >>>should really look at the pm4 stuff. is it just me or does this border >>>on abuse? >>> >>> is there any law that would protect us from them passing mandates like >>>this??? >>> >>> matthew >>> >>>Jamie Orzechowski wrote: >>>> >>>> nope ... I was running beta 3.8.0 before this and now quake is alot >slower >>>> with 3.8.1 ... I keep getting 3 or 4 second pauses for no reason ... >>>> >>>> 3Com is NOT going to fix this prob ... the can but they won't ... so >>i'll go >>>> get my new equipment from Livingston .. PM4's are VERY nice ... >>>> >>>> -----Original Message----- >>>> From: Mike Andrews <mandrews@termfrost.org> >>>> To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >>>> Date: Monday, September 07, 1998 6:24 PM >>>> Subject: (usr-tc) NETserver 3.8.1 >>>> >>>> >Looks like there is a new NETserver release out. Once again, "Quake >>>> >improvements" are listed in the release notes. Anyone tried this yet >and >>>> >know if there's any real progress yet? I can't get the code myself >since >>>> >we still haven't bought a service contract... >>>> > >>>> > >>>> >Mike Andrews (MA12) icq 6602506 -------------- mandrews@dcr.net >>>> >Senior Systems/Network Administrator --- mandrews@termfrost.org >>>> >Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ >>>> >"If Barbie is so popular, why do you have to buy her friends?..." >>> >>>- >>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >>> with "unsubscribe usr-tc" in the body of the 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 >> >>Vito >> >>- >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and 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. >

I believe there is a law, the same one that stops printer manufactures from voiding warranty if you use recharged toner. I will ask my partner, a lawyer about it. BTW if we can not get v.90 to work right in our 2059 chassis we are thinking about a class action suit, anybody interested in turning boat anchors to cash? Seriously the v.90 is BS but our unit runs X2 great! Off of PRI's Mike Hamrich CIO DrFast.Net, Inc. -----Original Message----- >So then why is there so much UDP packet loss ie. Major PING time. If anyone >know's how to fix UDP packet problem please let me know? >Is a problem of the server's or USR modem racks? > > > > >At 08:02 PM 9/7/98 , you wrote: >>well the quake issue was never really an issue for us. we have always >>had really good luck with our total control stuff, but something >>happened recently that has me pissed. >> >> we had a service contract we bought a while ago that we never >>activated. we went to activate it and were told that 3com has a new >>policy that you must have service contracts for ALL of your total >>control equipment or they won't let you get or even activate an already >>purchased service contract for just 1 or a few pieces of equipment. >> >> i really hate to be told i must purchase service contracts for >>everything i have from one manufacturer. >> >> we never really looked at the pm3 equipment but i'm feeling like i >>should really look at the pm4 stuff. is it just me or does this border >>on abuse? >> >> is there any law that would protect us from them passing mandates like >>this??? >> >> matthew >> >>Jamie Orzechowski wrote: >>> >>> nope ... I was running beta 3.8.0 before this and now quake is alot slower >>> with 3.8.1 ... I keep getting 3 or 4 second pauses for no reason ... >>> >>> 3Com is NOT going to fix this prob ... the can but they won't ... so >i'll go >>> get my new equipment from Livingston .. PM4's are VERY nice ... >>> >>> -----Original Message----- >>> From: Mike Andrews <mandrews@termfrost.org> >>> To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >>> Date: Monday, September 07, 1998 6:24 PM >>> Subject: (usr-tc) NETserver 3.8.1 >>> >>> >Looks like there is a new NETserver release out. Once again, "Quake >>> >improvements" are listed in the release notes. Anyone tried this yet and >>> >know if there's any real progress yet? I can't get the code myself since >>> >we still haven't bought a service contract... >>> > >>> > >>> >Mike Andrews (MA12) icq 6602506 -------------- mandrews@dcr.net >>> >Senior Systems/Network Administrator --- mandrews@termfrost.org >>> >Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ >>> >"If Barbie is so popular, why do you have to buy her friends?..." >> >>- >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the 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 > >Vito > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Yes ! set modem_group all prompt "/r" -Frank -----Original Message----- >can i change the next message ? > >Welcome to 3com Total Control HiperARC (TM) >Networks That Go The Distance (TM) >Login: > >...in a login session: > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Also do not forget set modem_group all message "Your Text Here" the prompt is the actual "login" prompt text -----Original Message----- >Yes ! > >set modem_group all prompt "/r" > >-Frank >-----Original Message----- >From: Abraham Aldaco <aaldaco@campus.her.itesm.mx> >To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >Date: Tuesday, September 08, 1998 5:02 PM >Subject: (usr-tc) welcome message > > >>can i change the next message ? >> >>Welcome to 3com Total Control HiperARC (TM) >>Networks That Go The Distance (TM) >>Login: >> >>...in a login session: >> >> >> >>- >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and 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. >

can i change the next message ? Welcome to 3com Total Control HiperARC (TM) Networks That Go The Distance (TM) Login: ...in a login session:

> We have a hard time getting a 3Com rep to return phone calls. It's > pitiful -- it's a major hassle for them to bother to sell us a > maintenance contract. At least you *have one*. We had a USR rep, who was great. We dealt with local USR technical support, which was great. Now we have to deal with resellers. Doesn't come close to the service we had before dealing direct. I know 3COM's *big* customers have reps of their own, but I guess we don't spend enough. Regards, Bob Purdon, Technical Manager, Southern Internet Services.

thanks for the pointer, I had done this, I even entered the at command ats0=1 for the modem, I also checked the jumpers on the modem, dip sw 5 I think it was, But no luck, I have seen the docs for the quad modem NIC card, and they refer to the unit with a "daughter card" being for analog use only, That is the style that I have. I have no idea why they would have a "analog/digital" style of NIC, as having the NIC in place would be for analog POTS lines. PS my modems are analog/digital thanks again On Mon, 7 Sep 1998 Eugene_Carpenter@3com.com wrote: > First, > You need to verify that the Modem Line interface source is set to nic. > > Select the modems you want to change. > go to configure, select program setting, > then select Line Interface Options, > next select Line Interface Source , > Need to verify it is set to nic. > Perform a set, and the modem (s) should start answering calls. > > Hope this helps. > > > > > Mark Ross <mark@apu.ccis.com> on 09/07/98 06:00:26 PM > > Please respond to usr-tc@lists.xmission.com > > To: usr-tc@lists.xmission.com > cc: (Eugene Carpenter/US/3Com) > Subject: (usr-tc) how can I do this > > > > > Hello, > Can I setup 1 or 2 quad analog/digital modem cards in my Total control > chassis to accept pots calls ?, If so then do I have to have a terminal > server connect to the RS232 connectors, OR will the Total Control handle > the answering and data flow to the modems through the packet buss ? > > So far I have not been able to get the modem to answer > > thanks > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and 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. >

Bob Purdon <bobp@southcom.com.au> writes: > In the case of a customer on a POTS line with a dedicated modem it's easy > - poll the NETserver or NMC for the inOctets and outOctets values for > their dedicated port. > > In the case of a customer coming in on a PRI line, it's more difficult as > the customer may be on a different modem/port every call. True, but it doesn't have to be much harder. You can still receive traps from modems as they process calls - if you poll those modems at call completion (and perhaps at start for basic data), you'll have the data you need at a modem level. The startup accounting information and/or authentication packets (or just NETServer syslogs) can let you know what port (and thus what modem) a user is on, so you just combine the two sets of data. > But, I need to check the ifLastChange object also to see if the counters > have wrapped, or the port has been reset (call dropped and brought back > up). Trouble is, the ifLastChange object shows the time since the > NETserver was booted, not the time since the last port status change. I'd have to re-check, but that sounds about right, but I think you may be misinterpreting the object. That is, ifLastChange holds the value of sysUpTime (timeticks since the NETServer was booted) as of the last interface state change. It's not a delta showing accumulated time since that state change, but the system clock at the point the state changed. Or in other words, if the NETServer has been up for 24 hours, and you have an interface that has been in the "up" state for an hour, the ifLastChange value is going to be 23 hours. Of course, that's not going to serve to detect any rollover of counters, since the rolling of a counter is not a state change of the interface. I don't think MIB-II provides any good support for this - you kind of just need to figure it out - normally by periodic polling during the lifetime of a session. Even if the ifLastChange object worked the way you wanted (delta from last change) that would be a last change in port state (e.g., "up", "down") and wouldn't be updated when a counter wrapped, so you'd still have to figure that out some other way. > What I have also noticed is that the behaviour differs from that of a > Cisco. A Cisco (at least a 1003), when the port resets will keep the > inOctets and outOctets values and continue incrementing them on the next > call. Which is right? The USR approach (reset on each call), or the > Cisco approach (keep incrementing across calls)? Good question - I think it depends on when an interface is instantiated. Depending on what you are looking at for the Cisco, if it's one of it's permanent interfaces, then it's always around, regardless of whether or not a user is online. However, for the TC, the "ptp" interface is created dynamically when a user comes online. Thus, by definition, the interface is "new" for that user, and the counters have to start from the beginning. Although one could I suppose consider the MIB slightly ambiguous in this regard - it just documents those objects as total data transferred, but doesn't specify if its from interface creation, or last state change. I'd probably have to go with from creation for my own interpretation, which I think matches both Cisco/3Com behavior (assuming it was a permanent interface on the Cisco). In terms of your data queries though, given the duration of calls and the possibility of overrun/wrap, I don't think you'll be able to get away with periodic polling of a session such that you can detect a wrap. It doesn't have to be frequent though - assuming a symmetric x2 connection without RBS (64kbps) and ignoring error control overhead and assuming a really good 4:1 compression ratio (so about 32000cps), you'd still need about 1.5 days to wrap a 32-bit counter. So for modem sessions, even a 24 hour polling period should be fine. Of course, given that it's a pretty small expense (or if you have ISDN customers or someone transferring a continuous file with nothing but the letter "A" (:-)), you could just do hourly polls or something. This would be true even in the case of querying the modem directly via the NMC (which is how we do things here at ANS) if you were concerned with wrap-around, since even the modem is returning a value as a 32-bit integer. In fact, in that case you'd probably have to verify if the value is treated as signed (as defined in the MIB) or unsigned - in MIB-II it should just be unsigned due to the Counter definition. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

I previously wrote: > Even if the ifLastChange object worked the way you wanted (delta from > last change) that would be a last change in port state (e.g., "up", > "down") and wouldn't be updated when a counter wrapped, so you'd still > have to figure that out some other way. BTW, it's relatively easy to compute the "delta" you may be looking for - just query ifLastChange and sysUpTime in the same PDU, and then calculate sysUpTime-ifLastChange and you'll have the duration that the interface has been in the latest state. Technically, a value <= that duration, since in theory ifLastChange might be zero if the SNMP agent re-initialized since the last state change, but I don't think that'll ever happen with the NETServer, since even if SNMP is disabled/re-enabled, the system uptime isn't re-initialized. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

: I need to be able to account for traffic delivered by modem to particular : customers. I'm intending to do this with SNMP and an SQL backend. : [...] : : Radius accounting is not an option as the customers must be billed monthly : and calls can (and do) span months. Disconnecting customers at the end of : the month is also not an option. You could depend on the long term; e.g., in August, you're billed for calls that terminate in July. Without some manual intervention, you'd lose a few calls at the begining, but in the long term (if your billing will be in the long term) it'd be nearly equal. My metered users are billed for time on calls that terminate in the given month.

> : Radius accounting is not an option as the customers must be billed monthly > : and calls can (and do) span months. Disconnecting customers at the end of > : the month is also not an option. depending on your radius server and how the logs are done, you could just insert an end record and a start record for each active user at the time you run the end/start function. -- [ Jim Mercer Reptilian Research jim@reptiles.org +1 416 410-5633 ] [ The telephone, for those of you who have forgotten, was a commonly used ] [ communications technology in the days before electronic mail. ] [ They're still easy to find in most large cities. -- Nathaniel Borenstein ]

: Except we have calls anything up to 3 months long It doesn't sound like random dropped connections are one of your problems! :-)

Does the Netserver own the modems you are trying to use the pots lines on ?? If you connect to the console of the Netserver perform a : sho all, your modems should show Active, Ready, and Present. Hope this helps Mark Ross <mark@apu.ccis.com> on 09/08/98 09:45:23 PM Please respond to usr-tc@lists.xmission.com cc: (Eugene Carpenter/US/3Com) thanks for the pointer, I had done this, I even entered the at command ats0=1 for the modem, I also checked the jumpers on the modem, dip sw 5 I think it was, But no luck, I have seen the docs for the quad modem NIC card, and they refer to the unit with a "daughter card" being for analog use only, That is the style that I have. I have no idea why they would have a "analog/digital" style of NIC, as having the NIC in place would be for analog POTS lines. PS my modems are analog/digital thanks again On Mon, 7 Sep 1998 Eugene_Carpenter@3com.com wrote: > First, > You need to verify that the Modem Line interface source is set to nic. > > Select the modems you want to change. > go to configure, select program setting, > then select Line Interface Options, > next select Line Interface Source , > Need to verify it is set to nic. > Perform a set, and the modem (s) should start answering calls. > > Hope this helps. > > > > > Mark Ross <mark@apu.ccis.com> on 09/07/98 06:00:26 PM > > Please respond to usr-tc@lists.xmission.com > > To: usr-tc@lists.xmission.com > cc: (Eugene Carpenter/US/3Com) > Subject: (usr-tc) how can I do this > > > > > Hello, > Can I setup 1 or 2 quad analog/digital modem cards in my Total control > chassis to accept pots calls ?, If so then do I have to have a terminal > server connect to the RS232 connectors, OR will the Total Control handle > the answering and data flow to the modems through the packet buss ? > > So far I have not been able to get the modem to answer > > thanks > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and 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.

I have a new chassis (HiperARC and 3 HiPerDSP's) that I installed about a week ago. Since that time we have been receiving complaints up the *$#% about frequent disconnects. I have checked the obvious, errors on the T1's (we're using Channelized T1) and there are none showing. I have also checked for off the wall disconnect reasons. Most of the reasons that I am showing in TCM is v42DisconnectCmd, or recvdGatewayDiscCmd, which support said wasn't an issue. Originally when I started hearing of the errors I attributed it to the 1.2.5 code on the DSP's so I downgraded to 1.0.8 thinking that would solve the problem, but it hasn't. Support suggested that I do a PPP mon on a user as they are dialing in so I am doing that right now and logging it, but if someone knows where else I should/could check I would appreciate it. HARC card is running the latest code. The weird thing is that I can call into the chassis via a modem from our POT's lines that are still in place at the pop, acheive a good clean x2 connection (44k) and stay connected for hours, however this connection is not a PPP connection. I have no way to test a PPP connection other than LD, which if it were phone line problems probably wouldn't show up. I have a feeling that it is a telco issue, since our CT1's are one of the first that they have installed and configured (It's a small rural telco that serves about 10k customers in the mountains) but I don't know where or how to point it to them since I am not seeing errors on the lines. Any ideas/help would be appreciated. -Eric

> Netservers have thier own DNS caching mechanism that you can specify > the timeout on...uhm...don't remember the command off the top of my > head, but think its defaults to 30 seconds, so unless you've changed > it, it *shouldn't* be still holding onto this data for that reason. Been there, checked that. Currently set, as per the default, for 30 minutes. The data changed around 3 weeks ago. I've tried from external hosts and they resolve both ways just fine - it's just this NETserver. I've got no idea where it's getting it's data from - certainly not the DNS server it's being pointed at. As I mentioned previously, the NETserver has been rebooted (twice actually) since the DNS data changed. Another site, where exactly the same work was done, is fine. Confused... Regards, Bob Purdon, Technical Manager, Southern Internet Services.

> Can I setup 1 or 2 quad analog/digital modem cards in my Total control > chassis to accept pots calls ?, If so then do I have to have a > terminal server connect to the RS232 connectors, OR will the Total > Control handle the answering and data flow to the modems through the > packet buss ? Yes, we're doing there here in a couple of POP's. We set the line interface to NIC on the analogue cards in question and plugged POTS lines into them. The rest are set for PRI. The NETserver handles calls, simultaneously, for both line types (as you'd expect). Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Mark R. Lindsey was heard to say: >: Except we have calls anything up to 3 months long > >It doesn't sound like random dropped connections are one of your problems! >:-) We don't have a "random drop" problem... we drop people on purpose :-) --Ricky

A couple things that might help narrow down the problem: - Take a look at other modem stats on calls that are having trouble. Items like gain recalc's, line block errors, protocol timeouts and stuff might point to the problem if it is telco oriented. - If possible, have the customer let you know what their modem is delivering as a termination reason. As long as their modem was not reset by the PPP stack, that info should be available via hyperterminal after the call. On a USR modem it is at the bottom of the ATI6 screen. Other modems vary, but on recent Rockwells it is probably in the AT&V1 screen, and on Lucent's the ATI11 screen. - Are the users noting performance problems just prior to disconnect For your info: v42DisconnectCmd is the client decided to terminate the link for some reason (such as terminating the session) recvdGatewayDiscCmd is the HARC dropped the call (often a timeout of some variety, or an exit from a nonPPP - terminal/telnet session, but there could be many other legit reasons) Both are common reasons and considered "clean". They may, but probably won't, point to the source of the problem unless you find a trend. JP Eric C Forcey <eric@psnw.com> on 09/09/98 01:13:08 AM Please respond to usr-tc@lists.xmission.com cc: (John Powell/MW/US/3Com) I have a new chassis (HiperARC and 3 HiPerDSP's) that I installed about a week ago. Since that time we have been receiving complaints up the *$#% about frequent disconnects. I have checked the obvious, errors on the T1's (we're using Channelized T1) and there are none showing. I have also checked for off the wall disconnect reasons. Most of the reasons that I am showing in TCM is v42DisconnectCmd, or recvdGatewayDiscCmd, which support said wasn't an issue. Originally when I started hearing of the errors I attributed it to the 1.2.5 code on the DSP's so I downgraded to 1.0.8 thinking that would solve the problem, but it hasn't. Support suggested that I do a PPP mon on a user as they are dialing in so I am doing that right now and logging it, but if someone knows where else I should/could check I would appreciate it. HARC card is running the latest code. The weird thing is that I can call into the chassis via a modem from our POT's lines that are still in place at the pop, acheive a good clean x2 connection (44k) and stay connected for hours, however this connection is not a PPP connection. I have no way to test a PPP connection other than LD, which if it were phone line problems probably wouldn't show up. I have a feeling that it is a telco issue, since our CT1's are one of the first that they have installed and configured (It's a small rural telco that serves about 10k customers in the mountains) but I don't know where or how to point it to them since I am not seeing errors on the lines. Any ideas/help would be appreciated. -Eric - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Thus spake Bob Purdon >> The startup accounting information and/or authentication packets (or >> just NETServer syslogs) can let you know what port (and thus what >> modem) a user is on, so you just combine the two sets of data. >I was hoping to get away with something simpler, using just SNMP. I'd >like to be able to give my monitor a NETserver name, community and >customer IP address and have it do the rest. Another complication is the >possibility of the call being on one of many NETservers... Hmmm... Well, we do what David said with all of our calls...and its turned out to be *extremely* useful for other things as well. We basically have a perl script that loops basically doing a tail -f on the radius accounting file and parses it for information about who logs on and off ports. When someone logs on, it creates two files in directorys that we have (we call it userstatus)...the filenames are in two seperate subdirectories...one uses the IP number that is given (whether statically assigned or dynamically assigned) as the filename, the other uses the port that the user is on (<ip address of netserver>:<port on netserver>). In the files is most of the information from the radius accounting start records (userid, ip number, netserver they're on, port they're on, what city they're in, time the call started, what number they called (so we can distinguish 800 calls from regular dial-ins), and what number they called from/callerid information). This has turned out to be *very* valuable troubleshooting information on its own, but the *real* value has come from being able to write scripts that look in this directory, and can grep for a userid in there really quickly and find the IP number the person is on, find the netserver and port their on and quickly send an SNMP request for certain information. We've used it to create a web page that a user can check their own modem statistics (live connect speed, modulation type, etc.), queried live from the modems via SNMP. Basically, the page grabs the IP address that the HTTP request is coming from, looks it up in this directory (don't even have to do the grep in this case), and fires off an SNMP request to the NMC to get the info directly from the modem. The only thing we have to manually maintain is a table mapping IP addresses of netservers to IP addresses of NMC's (which is trivial). -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Sir, once you upgrade your NetServer to 3.8.1 you may use HiPer DSP 1.2.5 for v.90 connections. As to your other argument; We will not be discontinuing support for the NetServer cards for some time. The rumors you heard pertained more to the dis-continuation of sales on the product. Kevin Benton <s1kevin@tims.net> on 09/09/98 09:04:57 AM Please respond to usr-tc@lists.xmission.com cc: (Brian McIntire/MW/US/3Com) On Sat, 11 Jul 1998, Tatai SV Krishnan wrote: > Date: Sat, 11 Jul 1998 09:34:36 -0500 (CDT) > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > Reply-To: usr-tc@lists.xmission.com > To: Jeff Mcadams <jeffm@iglou.com> > Cc: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Netservers becoming unsupported?! > > On Sat, 11 Jul 1998, Jeff Mcadams wrote: > > > Thus spake Jamie Orzechowski > > >BTW: I was talking with a USR Level 2 support guy and he sais NETServers > > >will become unsupported this christmas ... but they will have an AMAZING > > >deal on HiPER ARC's because they are going to force the end users to upgrade > > >... so I guess that's a good thing ... =) > > > > Say WHAT?! You *are* kidding us, right? I hope? If USR/3Com pulls > > support for the Netservers by Christmas, I for one will start screaming > > bloody murder and cozy up really nice with my local Cisco rep. That is > > unless they make some *phenomenal* improvements to the HiPer equipment > > from what I've seen. At this point, the HiPer stuff just isn't up to > > snuff for what we use it for, our setup *requires* some of the protocol > > support that the netservers have that the HiPer doesn't at this point > > (yeah, yeah, its in beta, I know) and I have serious doubts that the > > support for these protocols (MPIP in specific) will be ready for prime > > time and still leave us enough time to get all of our equipment switched > > over...This isn't even considering the cost of upgrading (even with an > > AMAZING deal, it will still cost us money, how much you want to bet?) > > > > I am not sure about this - Yes the HiPer arc in beta does support > everything that the NETServer does and much more. Why don't you give it > a try. > > regards > > krish > > > Someone please tell me that this is a miscommunication somewhere along > > the way. Well, I take it that because it there was no comment about it being a miscommunication that the statement was true. Krish, I happen to agree with Jamie and I *HAVE* 16 Chassis's on the field many with NSC's, ARC's and DSP's and quite frankly, I sure as heck hope that 3Com doesn't make a terrible business decision to stop supporting the NSC's. 3Com has known *KNOWN* about our need/desire to have V.90 code for how long now? Still no code that will work with the NSC's and after many months, we are just now getting code that's supposed to work with V.90. We just bought these NSC Chassis's at the beginning of the year and already their parts are going to the circular file? Give me a break... I will be opening communication with Ascend and Cisco very shortly if I don't see some dramatic improvements here. Until today, we're nearly 100% 3Com for digital dial-up equipment. I wonder how much longer that will continue. With our current purchase rate, that would mean the loss of approximately one chassis sale a month and climbing. I think our sales rep might like to know the attitude 3Com is coming across with because of the potential loss of customers. What would we like to see? We'd like to see the netservers continue to be supported for at least three more years since our warranty support won't run out for most of that time, and if 3Com really wants us to switch to HARC's so bad because they don't want to support them any longer, 3Com ought to be offering *FREE* upgrades to the HARC's. We'd also like to see 3Com fix those well known long-term bugs like memory leaks in TCM which we've been griping about for how long now? Automatically rebooting a machine just to keep a program from crashing is not an acceptable long-term solution. Program uptime should be measured in weeks/months not minutes/hours. Someone else was saying something about crappy (OS) servers. Crappy servers come from programs which misbehave. I'm quite certain the 3Com has its own QC procedures for software. One of the procedures I use with programs I've written is to watch the size of the program to see if it increases over time. I know how big it should be and when I find that I've got a program which grows without bounds, I fix the problem. Seems to me that 3Com ought to be using this type of procedure more for its own programs (such as the RADIUS server). Lastly, please reinstate the level 1 and level 2 support definitions or at least do something to bring your new tech's up to speed a little better. When I talk to a tech and without really knowing much about the situation, they tell me to change SW5 on the card, they're shooting in the dark and not able to reproduce a problem which may be fixable in software. This has happened on *more* than one occasion. I am very thankful every time I get on the support line and get one of a few people whose names will not be mentioned so I can be more likely to get them ( :) ). There are others who I know not to talk to because after a few minutes, they reveal just how little they know about the equipment they're supporting. It's one thing to follow scripts and walk people through prompts. I can handle that. People need to learn sometime. Great. Put them on level 1. Having two support levels helps people like me get answers to complex questions instead of wasting level 2 experience on forgetting to plug cards in properly or other things like that. When I have done something silly, I tell the rep. (expecting level one) and we step through things carefully. That's fine. When I've already spent hours troubleshooting a problem, having been there before, I once again, look for the level two people. If I don't like the questions from person I'm talking to, I ask for someone I know who knows what they're doing. Maybe I'm not your typical support customer. As an ISP, we too have our own support staff. Our level two people handle the tough calls. People who are in training and those who have not yet demonstrated the ability to handle the tougher calls are the ones who are the front-line answering the phones and helping determine whether or not a level two person is needed. Like your team, when a level two person gets involved, the level one person stays involved so they can learn how to solve that problem. It's a win-win situation. The level one people are learning more and more by answering questions. The level two people are training level one people and freeing themselves up for the more complex problems which aren't always easy to document in a clear-cut "this is how you solve this problem" kind of way. Usually, after the call is finished, the person in level one and the person in level two have a discussion about the call to discuss other things that may have helped troubleshoot the problem and to make sure the level one person has a chance to have their own questions answered, such as, how did you know to ask this or that. Kevin Benton Network Engineer SOTA Software 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.

On Sat, 11 Jul 1998, Tatai SV Krishnan wrote: > Date: Sat, 11 Jul 1998 09:34:36 -0500 (CDT) > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > Reply-To: usr-tc@lists.xmission.com > To: Jeff Mcadams <jeffm@iglou.com> > Cc: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Netservers becoming unsupported?! > > On Sat, 11 Jul 1998, Jeff Mcadams wrote: > > > Thus spake Jamie Orzechowski > > >BTW: I was talking with a USR Level 2 support guy and he sais NETServers > > >will become unsupported this christmas ... but they will have an AMAZING > > >deal on HiPER ARC's because they are going to force the end users to upgrade > > >... so I guess that's a good thing ... =) > > > > Say WHAT?! You *are* kidding us, right? I hope? If USR/3Com pulls > > support for the Netservers by Christmas, I for one will start screaming > > bloody murder and cozy up really nice with my local Cisco rep. That is > > unless they make some *phenomenal* improvements to the HiPer equipment > > from what I've seen. At this point, the HiPer stuff just isn't up to > > snuff for what we use it for, our setup *requires* some of the protocol > > support that the netservers have that the HiPer doesn't at this point > > (yeah, yeah, its in beta, I know) and I have serious doubts that the > > support for these protocols (MPIP in specific) will be ready for prime > > time and still leave us enough time to get all of our equipment switched > > over...This isn't even considering the cost of upgrading (even with an > > AMAZING deal, it will still cost us money, how much you want to bet?) > > > > I am not sure about this - Yes the HiPer arc in beta does support > everything that the NETServer does and much more. Why don't you give it > a try. > > regards > > krish > > > Someone please tell me that this is a miscommunication somewhere along > > the way. Well, I take it that because it there was no comment about it being a miscommunication that the statement was true. Krish, I happen to agree with Jamie and I *HAVE* 16 Chassis's on the field many with NSC's, ARC's and DSP's and quite frankly, I sure as heck hope that 3Com doesn't make a terrible business decision to stop supporting the NSC's. 3Com has known *KNOWN* about our need/desire to have V.90 code for how long now? Still no code that will work with the NSC's and after many months, we are just now getting code that's supposed to work with V.90. We just bought these NSC Chassis's at the beginning of the year and already their parts are going to the circular file? Give me a break... I will be opening communication with Ascend and Cisco very shortly if I don't see some dramatic improvements here. Until today, we're nearly 100% 3Com for digital dial-up equipment. I wonder how much longer that will continue. With our current purchase rate, that would mean the loss of approximately one chassis sale a month and climbing. I think our sales rep might like to know the attitude 3Com is coming across with because of the potential loss of customers. What would we like to see? We'd like to see the netservers continue to be supported for at least three more years since our warranty support won't run out for most of that time, and if 3Com really wants us to switch to HARC's so bad because they don't want to support them any longer, 3Com ought to be offering *FREE* upgrades to the HARC's. We'd also like to see 3Com fix those well known long-term bugs like memory leaks in TCM which we've been griping about for how long now? Automatically rebooting a machine just to keep a program from crashing is not an acceptable long-term solution. Program uptime should be measured in weeks/months not minutes/hours. Someone else was saying something about crappy (OS) servers. Crappy servers come from programs which misbehave. I'm quite certain the 3Com has its own QC procedures for software. One of the procedures I use with programs I've written is to watch the size of the program to see if it increases over time. I know how big it should be and when I find that I've got a program which grows without bounds, I fix the problem. Seems to me that 3Com ought to be using this type of procedure more for its own programs (such as the RADIUS server). Lastly, please reinstate the level 1 and level 2 support definitions or at least do something to bring your new tech's up to speed a little better. When I talk to a tech and without really knowing much about the situation, they tell me to change SW5 on the card, they're shooting in the dark and not able to reproduce a problem which may be fixable in software. This has happened on *more* than one occasion. I am very thankful every time I get on the support line and get one of a few people whose names will not be mentioned so I can be more likely to get them ( :) ). There are others who I know not to talk to because after a few minutes, they reveal just how little they know about the equipment they're supporting. It's one thing to follow scripts and walk people through prompts. I can handle that. People need to learn sometime. Great. Put them on level 1. Having two support levels helps people like me get answers to complex questions instead of wasting level 2 experience on forgetting to plug cards in properly or other things like that. When I have done something silly, I tell the rep. (expecting level one) and we step through things carefully. That's fine. When I've already spent hours troubleshooting a problem, having been there before, I once again, look for the level two people. If I don't like the questions from person I'm talking to, I ask for someone I know who knows what they're doing. Maybe I'm not your typical support customer. As an ISP, we too have our own support staff. Our level two people handle the tough calls. People who are in training and those who have not yet demonstrated the ability to handle the tougher calls are the ones who are the front-line answering the phones and helping determine whether or not a level two person is needed. Like your team, when a level two person gets involved, the level one person stays involved so they can learn how to solve that problem. It's a win-win situation. The level one people are learning more and more by answering questions. The level two people are training level one people and freeing themselves up for the more complex problems which aren't always easy to document in a clear-cut "this is how you solve this problem" kind of way. Usually, after the call is finished, the person in level one and the person in level two have a discussion about the call to discuss other things that may have helped troubleshoot the problem and to make sure the level one person has a chance to have their own questions answered, such as, how did you know to ask this or that. Kevin Benton Network Engineer SOTA Software E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

OOPS - I just realized I let a message go out which I forgot to add the comment that I had chosen not to let the message go out a month ago when I had written it. I feel that now is an appropriate time since we can look back and see that we're still having the same kinds of problems with the support staff, contracts, etc. Kevin Benton Network Engineer SOTA Technologies E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

OK, another interesting one... I need to be able to account for traffic delivered by modem to particular customers. I'm intending to do this with SNMP and an SQL backend. In the case of a customer on a POTS line with a dedicated modem it's easy - poll the NETserver or NMC for the inOctets and outOctets values for their dedicated port. In the case of a customer coming in on a PRI line, it's more difficult as the customer may be on a different modem/port every call. Radius accounting is not an option as the customers must be billed monthly and calls can (and do) span months. Disconnecting customers at the end of the month is also not an option. So, I thought I'd check ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.a.b.c.d (where a.b.c.d is their static IP) and find the port that way, then read the inOctets and outOctets for that port. So far so good. But, I need to check the ifLastChange object also to see if the counters have wrapped, or the port has been reset (call dropped and brought back up). Trouble is, the ifLastChange object shows the time since the NETserver was booted, not the time since the last port status change. Am I missing something, or is this broken? As far as I can see, I have no way of knowing if the byte counter is zero because of a port reset, or a counter wrap!?! What I have also noticed is that the behaviour differs from that of a Cisco. A Cisco (at least a 1003), when the port resets will keep the inOctets and outOctets values and continue incrementing them on the next call. Which is right? The USR approach (reset on each call), or the Cisco approach (keep incrementing across calls)? Regards, Bob Purdon, Technical Manager, Southern Internet Services.

why should I "give HiPER ARC's a try" ... ? Am I just going to be dumped again in 2 years when new cards come out? As I see it .. USR used to be known as THE BEST ... MOST RELIABLE ... that has changed ... I hope they aren't banking on thinking people will still believe this if this terrible support continues ... their modem products are great ... but high end is getting worse by the minute ... We have 5 Chassis and are going to have a tremendous growth soon when an area of 100,000 population goes non long distance ... that's alot of new chassis ... as of now those new chassis are not going to be USR ... only thing I will buy from USR is modems ... -----Original Message----- >On Sat, 11 Jul 1998, Tatai SV Krishnan wrote: > >> Date: Sat, 11 Jul 1998 09:34:36 -0500 (CDT) >> From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> >> Reply-To: usr-tc@lists.xmission.com >> To: Jeff Mcadams <jeffm@iglou.com> >> Cc: usr-tc@lists.xmission.com >> Subject: Re: (usr-tc) Netservers becoming unsupported?! >> >> On Sat, 11 Jul 1998, Jeff Mcadams wrote: >> >> > Thus spake Jamie Orzechowski >> > >BTW: I was talking with a USR Level 2 support guy and he sais NETServers >> > >will become unsupported this christmas ... but they will have an AMAZING >> > >deal on HiPER ARC's because they are going to force the end users to upgrade >> > >... so I guess that's a good thing ... =) >> > >> > Say WHAT?! You *are* kidding us, right? I hope? If USR/3Com pulls >> > support for the Netservers by Christmas, I for one will start screaming >> > bloody murder and cozy up really nice with my local Cisco rep. That is >> > unless they make some *phenomenal* improvements to the HiPer equipment >> > from what I've seen. At this point, the HiPer stuff just isn't up to >> > snuff for what we use it for, our setup *requires* some of the protocol >> > support that the netservers have that the HiPer doesn't at this point >> > (yeah, yeah, its in beta, I know) and I have serious doubts that the >> > support for these protocols (MPIP in specific) will be ready for prime >> > time and still leave us enough time to get all of our equipment switched >> > over...This isn't even considering the cost of upgrading (even with an >> > AMAZING deal, it will still cost us money, how much you want to bet?) >> > >> >> I am not sure about this - Yes the HiPer arc in beta does support >> everything that the NETServer does and much more. Why don't you give it >> a try. >> >> regards >> >> krish >> >> > Someone please tell me that this is a miscommunication somewhere along >> > the way. > >Well, I take it that because it there was no comment about it being a >miscommunication that the statement was true. > >Krish, I happen to agree with Jamie and I *HAVE* 16 Chassis's on the field >many with NSC's, ARC's and DSP's and quite frankly, I sure as heck hope >that 3Com doesn't make a terrible business decision to stop supporting the >NSC's. 3Com has known *KNOWN* about our need/desire to have V.90 code for >how long now? Still no code that will work with the NSC's and after many >months, we are just now getting code that's supposed to work with V.90. >We just bought these NSC Chassis's at the beginning of the year and >already their parts are going to the circular file? Give me a break... I >will be opening communication with Ascend and Cisco very shortly if I >don't see some dramatic improvements here. Until today, we're nearly 100% >3Com for digital dial-up equipment. I wonder how much longer that will >continue. With our current purchase rate, that would mean the loss of >approximately one chassis sale a month and climbing. I think our sales >rep might like to know the attitude 3Com is coming across with because of >the potential loss of customers. > >What would we like to see? We'd like to see the netservers continue to be >supported for at least three more years since our warranty support won't >run out for most of that time, and if 3Com really wants us to switch to >HARC's so bad because they don't want to support them any longer, 3Com >ought to be offering *FREE* upgrades to the HARC's. We'd also like to see >3Com fix those well known long-term bugs like memory leaks in TCM which >we've been griping about for how long now? Automatically rebooting a >machine just to keep a program from crashing is not an acceptable >long-term solution. Program uptime should be measured in weeks/months not >minutes/hours. Someone else was saying something about crappy (OS) >servers. Crappy servers come from programs which misbehave. > >I'm quite certain the 3Com has its own QC procedures for software. One of >the procedures I use with programs I've written is to watch the size of >the program to see if it increases over time. I know how big it should be >and when I find that I've got a program which grows without bounds, I fix >the problem. Seems to me that 3Com ought to be using this type of >procedure more for its own programs (such as the RADIUS server). > >Lastly, please reinstate the level 1 and level 2 support definitions or at >least do something to bring your new tech's up to speed a little better. >When I talk to a tech and without really knowing much about the situation, >they tell me to change SW5 on the card, they're shooting in the dark and >not able to reproduce a problem which may be fixable in software. This >has happened on *more* than one occasion. I am very thankful every time I >get on the support line and get one of a few people whose names will not >be mentioned so I can be more likely to get them ( :) ). There are others >who I know not to talk to because after a few minutes, they reveal just >how little they know about the equipment they're supporting. It's one >thing to follow scripts and walk people through prompts. I can handle >that. People need to learn sometime. Great. Put them on level 1. >Having two support levels helps people like me get answers to complex >questions instead of wasting level 2 experience on forgetting to plug >cards in properly or other things like that. When I have done something >silly, I tell the rep. (expecting level one) and we step through things >carefully. That's fine. When I've already spent hours troubleshooting a >problem, having been there before, I once again, look for the level two >people. If I don't like the questions from person I'm talking to, I ask >for someone I know who knows what they're doing. Maybe I'm not your >typical support customer. As an ISP, we too have our own support staff. >Our level two people handle the tough calls. People who are in training >and those who have not yet demonstrated the ability to handle the tougher >calls are the ones who are the front-line answering the phones and helping >determine whether or not a level two person is needed. Like your team, >when a level two person gets involved, the level one person stays involved >so they can learn how to solve that problem. It's a win-win situation. >The level one people are learning more and more by answering questions. >The level two people are training level one people and freeing themselves >up for the more complex problems which aren't always easy to document in a >clear-cut "this is how you solve this problem" kind of way. Usually, >after the call is finished, the person in level one and the person in >level two have a discussion about the call to discuss other things that >may have helped troubleshoot the problem and to make sure the level one >person has a chance to have their own questions answered, such as, how did >you know to ask this or that. > >Kevin Benton >Network Engineer >SOTA Software > >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. >

Thus spake Brian McIntire >Sir, once you upgrade your NetServer to 3.8.1 you may use HiPer DSP 1.2.5 >for v.90 connections. As to your other argument; We will not be >discontinuing support for the NetServer cards for some time. The rumors >you heard pertained more to the dis-continuation of sales on the product. Then please explain this latest note I found on my latest trouble ticket I opened (several months ago...now closed without resolution)...ticket number 58316: *** 26-Aug-1998 15:25:44 *** Since Netserver is being disscontinued, this defect will very likely not be fixed. Certainly sounds like discontinuing support to me...this case was opened at the beginning of April...I practically pointed out to one of your folks where the problem was *IN YOUR OWN SOURCE CODE*. And now you're telling me that the defect isn't going to be fixed?! -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Wed, 9 Sep 1998, Kevin Benton wrote: > On Sat, 11 Jul 1998, Tatai SV Krishnan wrote: > > > Date: Sat, 11 Jul 1998 09:34:36 -0500 (CDT) > > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > > Reply-To: usr-tc@lists.xmission.com > > To: Jeff Mcadams <jeffm@iglou.com> > > Cc: usr-tc@lists.xmission.com > > Subject: Re: (usr-tc) Netservers becoming unsupported?! > > > > On Sat, 11 Jul 1998, Jeff Mcadams wrote: > > > > > Thus spake Jamie Orzechowski > > > >BTW: I was talking with a USR Level 2 support guy and he sais NETServers > > > >will become unsupported this christmas ... but they will have an AMAZING > > > >deal on HiPER ARC's because they are going to force the end users to upgrade > > > >... so I guess that's a good thing ... =) > > > > > > Say WHAT?! You *are* kidding us, right? I hope? If USR/3Com pulls > > > support for the Netservers by Christmas, I for one will start screaming > > > bloody murder and cozy up really nice with my local Cisco rep. That is > > > unless they make some *phenomenal* improvements to the HiPer equipment > > > from what I've seen. At this point, the HiPer stuff just isn't up to > > > snuff for what we use it for, our setup *requires* some of the protocol > > > support that the netservers have that the HiPer doesn't at this point > > > (yeah, yeah, its in beta, I know) and I have serious doubts that the > > > support for these protocols (MPIP in specific) will be ready for prime > > > time and still leave us enough time to get all of our equipment switched > > > over...This isn't even considering the cost of upgrading (even with an > > > AMAZING deal, it will still cost us money, how much you want to bet?) > > > > > > > I am not sure about this - Yes the HiPer arc in beta does support > > everything that the NETServer does and much more. Why don't you give it > > a try. > > > > regards > > > > krish > > > > > Someone please tell me that this is a miscommunication somewhere along > > > the way. > > Well, I take it that because it there was no comment about it being a > miscommunication that the statement was true. > > Krish, I happen to agree with Jamie and I *HAVE* 16 Chassis's on the field > many with NSC's, ARC's and DSP's and quite frankly, I sure as heck hope > that 3Com doesn't make a terrible business decision to stop supporting the > NSC's. 3Com has known *KNOWN* about our need/desire to have V.90 code for > how long now? Still no code that will work with the NSC's and after many > months, we are just now getting code that's supposed to work with V.90. > We just bought these NSC Chassis's at the beginning of the year and > already their parts are going to the circular file? Give me a break... I > will be opening communication with Ascend and Cisco very shortly if I > don't see some dramatic improvements here. Until today, we're nearly 100% > 3Com for digital dial-up equipment. I wonder how much longer that will > continue. With our current purchase rate, that would mean the loss of > approximately one chassis sale a month and climbing. I think our sales > rep might like to know the attitude 3Com is coming across with because of > the potential loss of customers. > The problem here that Jamie is address is about Quake. The Best performance that you can get with the NETServer for Quake is to use the Quad modems and terminate the calls (both analog and ISDN ) on the Quad modems. As far as v90 is concerned it has been long released for both the HiPer DSP and the QUAD. There were issues with the NETServer and the DSP but the latest code does solve those issue. Prior to the release of the NETServer code - some people have been using the DSP code with little or no problems with the NETServer. My previous email where I asked you to try the HiPer arc is not related to this question at all. All I had said was that the latest beta ( soon to be released ) HIper ARC code does support all the functionalities ( MPIP, PPTP, L2TP, IGMP etc ) and more. Since you use a lot of our products and continue to give us information - in regards to improve the product - beta testing the HiPer arc would a great idea. This was not an invitation to everyone in this list, nor it was any plan to push the HiPer arc. As far as support for the NETServer is concerned - This is still a supported product. I have not heard anything officially to say that the product will not be supported. As far as I know the product will be supported and there will be bug fixes. > What would we like to see? We'd like to see the netservers continue to be > supported for at least three more years since our warranty support won't > run out for most of that time, and if 3Com really wants us to switch to > HARC's so bad because they don't want to support them any longer, 3Com > ought to be offering *FREE* upgrades to the HARC's. Again - I have not heard anything official to say that we are not going to support the NETServer. All I know is we are and will be supporting the NETSever and will be fixing the bugs in the product. Anything in regards to NETServer support should come from our Product managers. It is the Product manager's decision - to either tell the customers to switch over or to give products free. I sure will get this matter to the attention of the Product Manager concerned. >We'd also like to see > 3Com fix those well known long-term bugs like memory leaks in TCM which > we've been griping about for how long now? Automatically rebooting a > machine just to keep a program from crashing is not an acceptable > long-term solution. Program uptime should be measured in weeks/months not > minutes/hours. Someone else was saying something about crappy (OS) > servers. Crappy servers come from programs which misbehave. > Ever product does have some issues. As far as I know there are no products that are bug free. We try to fix problems and bugs and also try to make sure that the new releases are bug free. We have a whole process of engineering/service release that address major bugs and concerns. Anytime you see a problem our priority is to fix the problem. A lot of problems have been address with TCM lately, if you still have a problem we shall be glad to fix them and solve the same. > I'm quite certain the 3Com has its own QC procedures for software. One of > the procedures I use with programs I've written is to watch the size of > the program to see if it increases over time. I know how big it should be > and when I find that I've got a program which grows without bounds, I fix > the problem. Seems to me that 3Com ought to be using this type of > procedure more for its own programs (such as the RADIUS server). > > Lastly, please reinstate the level 1 and level 2 support definitions or at > least do something to bring your new tech's up to speed a little better. > When I talk to a tech and without really knowing much about the situation, > they tell me to change SW5 on the card, they're shooting in the dark and > not able to reproduce a problem which may be fixable in software. This > has happened on *more* than one occasion. I am very thankful every time I > get on the support line and get one of a few people whose names will not > be mentioned so I can be more likely to get them ( :) ). There are others > who I know not to talk to because after a few minutes, they reveal just > how little they know about the equipment they're supporting. It's one > thing to follow scripts and walk people through prompts. I can handle > that. People need to learn sometime. Great. Put them on level 1. > Having two support levels helps people like me get answers to complex > questions instead of wasting level 2 experience on forgetting to plug > cards in properly or other things like that. When I have done something > silly, I tell the rep. (expecting level one) and we step through things > carefully. That's fine. When I've already spent hours troubleshooting a > problem, having been there before, I once again, look for the level two > people. If I don't like the questions from person I'm talking to, I ask > for someone I know who knows what they're doing. Maybe I'm not your > typical support customer. As an ISP, we too have our own support staff. > Our level two people handle the tough calls. People who are in training > and those who have not yet demonstrated the ability to handle the tougher > calls are the ones who are the front-line answering the phones and helping > determine whether or not a level two person is needed. Like your team, > when a level two person gets involved, the level one person stays involved > so they can learn how to solve that problem. It's a win-win situation. > The level one people are learning more and more by answering questions. > The level two people are training level one people and freeing themselves > up for the more complex problems which aren't always easy to document in a > clear-cut "this is how you solve this problem" kind of way. Usually, > after the call is finished, the person in level one and the person in > level two have a discussion about the call to discuss other things that > may have helped troubleshoot the problem and to make sure the level one > person has a chance to have their own questions answered, such as, how did > you know to ask this or that. > Training for the staff is a constant effort, It is good that you have mentioned this. This way I can get the attention of our management in this issue. I will sure let the management know. If you have problems with support please do let us know. I will forward your email to our support managers and the upper level management people. Defaulting the card or erasing the config without any valid reason is not acceptable in any product. Sometimes however depending on the complication of the problem eraseing the flash may be necessary. The tech however should explain this and make sure that the customer has understood the problem and the solution. As I have mentioned above - I will get this matter to the attention of our management. regards krish regards > Kevin Benton > Network Engineer > SOTA Software > > 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. >

On Wed, 9 Sep 1998, Jamie Orzechowski wrote: > why should I "give HiPER ARC's a try" ... ? > I did not ask you to give HiPer arc a try. This email goes a long way back, this email was in regards to supported feature on the NETServer/HiPer arc. Some one in this list has sent an email - stating that the reason they cannot use HiPer arc was that it did not support MPIP. The email was in that regard. > Am I just going to be dumped again in 2 years when new cards come out? > No - The new HiPer arc cards are out and have been out for nearly a year. We still support and fix bugs in the NETServer. krish > As I see it .. USR used to be known as THE BEST ... MOST RELIABLE ... that > has changed ... I hope they aren't banking on thinking people will still > believe this if this terrible support continues ... their modem products are > great ... but high end is getting worse by the minute ... We have 5 Chassis > and are going to have a tremendous growth soon when an area of 100,000 > population goes non long distance ... that's alot of new chassis ... as of > now those new chassis are not going to be USR ... only thing I will buy from > USR is modems ... > > > -----Original Message----- > From: Kevin Benton <s1kevin@tims.net> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Wednesday, September 09, 1998 10:24 AM > Subject: Re: (usr-tc) Netservers becoming unsupported?! > > > >On Sat, 11 Jul 1998, Tatai SV Krishnan wrote: > > > >> Date: Sat, 11 Jul 1998 09:34:36 -0500 (CDT) > >> From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > >> Reply-To: usr-tc@lists.xmission.com > >> To: Jeff Mcadams <jeffm@iglou.com> > >> Cc: usr-tc@lists.xmission.com > >> Subject: Re: (usr-tc) Netservers becoming unsupported?! > >> > >> On Sat, 11 Jul 1998, Jeff Mcadams wrote: > >> > >> > Thus spake Jamie Orzechowski > >> > >BTW: I was talking with a USR Level 2 support guy and he sais > NETServers > >> > >will become unsupported this christmas ... but they will have an > AMAZING > >> > >deal on HiPER ARC's because they are going to force the end users to > upgrade > >> > >... so I guess that's a good thing ... =) > >> > > >> > Say WHAT?! You *are* kidding us, right? I hope? If USR/3Com pulls > >> > support for the Netservers by Christmas, I for one will start screaming > >> > bloody murder and cozy up really nice with my local Cisco rep. That is > >> > unless they make some *phenomenal* improvements to the HiPer equipment > >> > from what I've seen. At this point, the HiPer stuff just isn't up to > >> > snuff for what we use it for, our setup *requires* some of the protocol > >> > support that the netservers have that the HiPer doesn't at this point > >> > (yeah, yeah, its in beta, I know) and I have serious doubts that the > >> > support for these protocols (MPIP in specific) will be ready for prime > >> > time and still leave us enough time to get all of our equipment > switched > >> > over...This isn't even considering the cost of upgrading (even with an > >> > AMAZING deal, it will still cost us money, how much you want to bet?) > >> > > >> > >> I am not sure about this - Yes the HiPer arc in beta does support > >> everything that the NETServer does and much more. Why don't you give it > >> a try. > >> > >> regards > >> > >> krish > >> > >> > Someone please tell me that this is a miscommunication somewhere along > >> > the way. > > > >Well, I take it that because it there was no comment about it being a > >miscommunication that the statement was true. > > > >Krish, I happen to agree with Jamie and I *HAVE* 16 Chassis's on the field > >many with NSC's, ARC's and DSP's and quite frankly, I sure as heck hope > >that 3Com doesn't make a terrible business decision to stop supporting the > >NSC's. 3Com has known *KNOWN* about our need/desire to have V.90 code for > >how long now? Still no code that will work with the NSC's and after many > >months, we are just now getting code that's supposed to work with V.90. > >We just bought these NSC Chassis's at the beginning of the year and > >already their parts are going to the circular file? Give me a break... I > >will be opening communication with Ascend and Cisco very shortly if I > >don't see some dramatic improvements here. Until today, we're nearly 100% > >3Com for digital dial-up equipment. I wonder how much longer that will > >continue. With our current purchase rate, that would mean the loss of > >approximately one chassis sale a month and climbing. I think our sales > >rep might like to know the attitude 3Com is coming across with because of > >the potential loss of customers. > > > >What would we like to see? We'd like to see the netservers continue to be > >supported for at least three more years since our warranty support won't > >run out for most of that time, and if 3Com really wants us to switch to > >HARC's so bad because they don't want to support them any longer, 3Com > >ought to be offering *FREE* upgrades to the HARC's. We'd also like to see > >3Com fix those well known long-term bugs like memory leaks in TCM which > >we've been griping about for how long now? Automatically rebooting a > >machine just to keep a program from crashing is not an acceptable > >long-term solution. Program uptime should be measured in weeks/months not > >minutes/hours. Someone else was saying something about crappy (OS) > >servers. Crappy servers come from programs which misbehave. > > > >I'm quite certain the 3Com has its own QC procedures for software. One of > >the procedures I use with programs I've written is to watch the size of > >the program to see if it increases over time. I know how big it should be > >and when I find that I've got a program which grows without bounds, I fix > >the problem. Seems to me that 3Com ought to be using this type of > >procedure more for its own programs (such as the RADIUS server). > > > >Lastly, please reinstate the level 1 and level 2 support definitions or at > >least do something to bring your new tech's up to speed a little better. > >When I talk to a tech and without really knowing much about the situation, > >they tell me to change SW5 on the card, they're shooting in the dark and > >not able to reproduce a problem which may be fixable in software. This > >has happened on *more* than one occasion. I am very thankful every time I > >get on the support line and get one of a few people whose names will not > >be mentioned so I can be more likely to get them ( :) ). There are others > >who I know not to talk to because after a few minutes, they reveal just > >how little they know about the equipment they're supporting. It's one > >thing to follow scripts and walk people through prompts. I can handle > >that. People need to learn sometime. Great. Put them on level 1. > >Having two support levels helps people like me get answers to complex > >questions instead of wasting level 2 experience on forgetting to plug > >cards in properly or other things like that. When I have done something > >silly, I tell the rep. (expecting level one) and we step through things > >carefully. That's fine. When I've already spent hours troubleshooting a > >problem, having been there before, I once again, look for the level two > >people. If I don't like the questions from person I'm talking to, I ask > >for someone I know who knows what they're doing. Maybe I'm not your > >typical support customer. As an ISP, we too have our own support staff. > >Our level two people handle the tough calls. People who are in training > >and those who have not yet demonstrated the ability to handle the tougher > >calls are the ones who are the front-line answering the phones and helping > >determine whether or not a level two person is needed. Like your team, > >when a level two person gets involved, the level one person stays involved > >so they can learn how to solve that problem. It's a win-win situation. > >The level one people are learning more and more by answering questions. > >The level two people are training level one people and freeing themselves > >up for the more complex problems which aren't always easy to document in a > >clear-cut "this is how you solve this problem" kind of way. Usually, > >after the call is finished, the person in level one and the person in > >level two have a discussion about the call to discuss other things that > >may have helped troubleshoot the problem and to make sure the level one > >person has a chance to have their own questions answered, such as, how did > >you know to ask this or that. > > > >Kevin Benton > >Network Engineer > >SOTA Software > > > >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. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Wed, 9 Sep 1998, Jamie Orzechowski wrote: > yeah ... same here ... if we move to ARC's are we going to get MPIP working? > Sure you will be working fine. We do have beta users that are currently using the HiPer arc in a HiPerarc/NETServer environment without any problems with MPIP. krish > -----Original Message----- > From: Jeff Mcadams <jeffm@iglou.com> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Wednesday, September 09, 1998 12:45 PM > Subject: Re: (usr-tc) Netservers becoming unsupported?! > > > >Thus spake Tatai SV Krishnan > >>On Wed, 9 Sep 1998, Jamie Orzechowski wrote: > >>> why should I "give HiPER ARC's a try" ... ? > > > >>I did not ask you to give HiPer arc a try. This email goes a long way > >>back, this email was in regards to supported feature on the > >>NETServer/HiPer arc. Some one in this list has sent an email - stating > >>that the reason they cannot use HiPer arc was that it did not support > >>MPIP. The email was in that regard. > > > >That would have been me...I'm still concerned about MPIP support on > >Arc's...haven't heard all that great of things about it...am going to > >try to get one to try out soon though to test it. Maybe I can at least > >get an MPIP server that doesn't have to be rebooted 4 times a day to > >keep it from loosing track of where MPIP bundles are hosted. > > > >>> Am I just going to be dumped again in 2 years when new cards come out? > > > >>No - The new HiPer arc cards are out and have been out for nearly a year. > >>We still support and fix bugs in the NETServer. > > > >Right, then what about ticket number 58316! > >-- > >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. >

Thus spake Tatai SV Krishnan >On Wed, 9 Sep 1998, Jamie Orzechowski wrote: >> why should I "give HiPER ARC's a try" ... ? >I did not ask you to give HiPer arc a try. This email goes a long way >back, this email was in regards to supported feature on the >NETServer/HiPer arc. Some one in this list has sent an email - stating >that the reason they cannot use HiPer arc was that it did not support >MPIP. The email was in that regard. That would have been me...I'm still concerned about MPIP support on Arc's...haven't heard all that great of things about it...am going to try to get one to try out soon though to test it. Maybe I can at least get an MPIP server that doesn't have to be rebooted 4 times a day to keep it from loosing track of where MPIP bundles are hosted. >> Am I just going to be dumped again in 2 years when new cards come out? >No - The new HiPer arc cards are out and have been out for nearly a year. >We still support and fix bugs in the NETServer. Right, then what about ticket number 58316! -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

> You could depend on the long term; e.g., in August, you're billed for > calls that terminate in July. Without some manual intervention, you'd > lose a few calls at the begining, but in the long term (if your > billing will be in the long term) it'd be nearly equal. Except we have calls anything up to 3 months long, and many of our account packages include a base volume allocation each month, with excess charged after that. We need to know how many bytes were used in each month :-( Regards, Bob Purdon, Technical Manager, Southern Internet Services.

yeah ... same here ... if we move to ARC's are we going to get MPIP working? -----Original Message----- >Thus spake Tatai SV Krishnan >>On Wed, 9 Sep 1998, Jamie Orzechowski wrote: >>> why should I "give HiPER ARC's a try" ... ? > >>I did not ask you to give HiPer arc a try. This email goes a long way >>back, this email was in regards to supported feature on the >>NETServer/HiPer arc. Some one in this list has sent an email - stating >>that the reason they cannot use HiPer arc was that it did not support >>MPIP. The email was in that regard. > >That would have been me...I'm still concerned about MPIP support on >Arc's...haven't heard all that great of things about it...am going to >try to get one to try out soon though to test it. Maybe I can at least >get an MPIP server that doesn't have to be rebooted 4 times a day to >keep it from loosing track of where MPIP bundles are hosted. > >>> Am I just going to be dumped again in 2 years when new cards come out? > >>No - The new HiPer arc cards are out and have been out for nearly a year. >>We still support and fix bugs in the NETServer. > >Right, then what about ticket number 58316! >-- >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. >

On Wed, 9 Sep 1998, Jeff Mcadams wrote: > Thus spake Tatai SV Krishnan > >On Wed, 9 Sep 1998, Jamie Orzechowski wrote: > >> why should I "give HiPER ARC's a try" ... ? > > >I did not ask you to give HiPer arc a try. This email goes a long way > >back, this email was in regards to supported feature on the > >NETServer/HiPer arc. Some one in this list has sent an email - stating > >that the reason they cannot use HiPer arc was that it did not support > >MPIP. The email was in that regard. > > That would have been me...I'm still concerned about MPIP support on > Arc's...haven't heard all that great of things about it...am going to > try to get one to try out soon though to test it. Maybe I can at least > get an MPIP server that doesn't have to be rebooted 4 times a day to > keep it from loosing track of where MPIP bundles are hosted. > > >> Am I just going to be dumped again in 2 years when new cards come out? > > >No - The new HiPer arc cards are out and have been out for nearly a year. > >We still support and fix bugs in the NETServer. > > Right, then what about ticket number 58316! We will address this ticket. krish > -- > 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. >

> : Except we have calls anything up to 3 months long > > It doesn't sound like random dropped connections are one of your problems! Nope, not on the POTS gear anyway. We've not had any reports of it on the PRI's either. Regards, Bob Purdon, Technical Manager, Southern Internet Services.

> > In the case of a customer coming in on a PRI line, it's more difficult as > > the customer may be on a different modem/port every call. > > True, but it doesn't have to be much harder. You can still receive > traps from modems as they process calls - if you poll those modems at > call completion (and perhaps at start for basic data), you'll have the > data you need at a modem level. One of the problems is that I need to collect data during the call - I can't afford to wait until the call completes. > The startup accounting information and/or authentication packets (or > just NETServer syslogs) can let you know what port (and thus what > modem) a user is on, so you just combine the two sets of data. I was hoping to get away with something simpler, using just SNMP. I'd like to be able to give my monitor a NETserver name, community and customer IP address and have it do the rest. Another complication is the possibility of the call being on one of many NETservers... Hmmm... > I'd have to re-check, but that sounds about right, but I think you may > be misinterpreting the object. That is, ifLastChange holds the value > of sysUpTime (timeticks since the NETServer was booted) as of the last > interface state change. Ah, OK. I've just checked one of our Cisco's and it seems that your definition is the correct one. > Of course, that's not going to serve to detect any rollover of > counters, since the rolling of a counter is not a state change of the > interface. No, but I was working on the assumption that a state-change would also have reset the counter to zero. If the sample we take now if less than the sample 5 minutes ago, and there's been a state change, then it's an interface reset. If the same applies, and there hasn't been a state change, then the counter has rolled. > instantiated. Depending on what you are looking at for the Cisco, if > it's one of it's permanent interfaces, then it's always around, > regardless of whether or not a user is online. Ah, OK. > Although one could I suppose consider the MIB slightly ambiguous in > this regard - it just documents those objects as total data > transferred, but doesn't specify if its from interface creation, or > last state change. I'd probably have to go with from creation for my > own interpretation, which I think matches both Cisco/3Com behavior > (assuming it was a permanent interface on the Cisco). Likewise - either way it fits if you look at the definition your way :-) > In terms of your data queries though, given the duration of calls and > the possibility of overrun/wrap, I don't think you'll be able to get > away with periodic polling of a session such that you can detect a > wrap. Detecting the wrap isn't too hard, as mentioned above. > It doesn't have to be frequent though - assuming a symmetric x2 > connection without RBS (64kbps) and ignoring error control overhead > and assuming a really good 4:1 compression ratio (so about 32000cps), > you'd still need about 1.5 days to wrap a 32-bit counter. So for > modem sessions, even a 24 hour polling period should be fine. Except we lose the data since the last poll, since the interface is dynamically created/destroyed as the calls come and go. We were planning on using 15 minute samples for both modem connections, ISDN, and sync serial. > This would be true even in the case of querying the modem directly via > the NMC (which is how we do things here at ANS) I prefer querying via the NMC, but querying the NETserver has some advantages in that it's consistent with querying other devices (Cisco's, etc). Either way works of course... ...and the NMC gives us access to the call duration timer in the modem... Anyway, thanks for your comments David - they were most useful and have given me a few things to think on... Regards, Bob Purdon, Technical Manager, Southern Internet Services.

> The TDM systems cannot handle the higher densities. How many TDM slots does > the chassis have now? 256? THAT is why you need two ARCs to fill the chassis > with 14 hiperDSPs, not because the ARC doesn't have the processing power. I'm not a 3COM engineer or anything, but I don't believe the above statement is true. I believe the limit is 512, and the limit with the ARC's currently comes from the software, not the hardware. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Executive Vice President - Exec-PC, Inc. |

Kevin, I have forwared your email to the people who need to addressing these issues. So Product Management and support managers will address this problem. As soon as I hear from them I will let you know regards krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Wed, 9 Sep 1998, Kevin Benton wrote: > On Wed, 9 Sep 1998, Tatai SV Krishnan wrote: > > > As far as support for the NETServer is concerned - This is still a > > supported product. I have not heard anything officially to say that the > > product will not be supported. As far as I know the product will be > > supported and there will be bug fixes. > > Once again, I'd like to hear an official date when support is planned to > be dropped so we know when to stop buying support contracts for NS > chassis's or at least be able to plan for upgrades. Growth can be a real > pain at times. If we weren't growing so rapidly, we'd probably have money > to buy ARC's. We don't. We are putting almost everything into > growth/expasion right now. > > > > What would we like to see? We'd like to see the netservers continue to be > > > supported for at least three more years since our warranty support won't > > > run out for most of that time, and if 3Com really wants us to switch to > > > HARC's so bad because they don't want to support them any longer, 3Com > > > ought to be offering *FREE* upgrades to the HARC's. > > > > Again - I have not heard anything official to say that we are not going > > to support the NETServer. All I know is we are and will be supporting > > the NETSever and will be fixing the bugs in the product. Anything in > > regards to NETServer support should come from our Product managers. It > > is the Product manager's decision - to either tell the customers to > > switch over or to give products free. I sure will get this matter to the > > attention of the Product Manager concerned. > > > > >We'd also like to see > > > 3Com fix those well known long-term bugs like memory leaks in TCM which > > > we've been griping about for how long now? Automatically rebooting a > > > machine just to keep a program from crashing is not an acceptable > > > long-term solution. Program uptime should be measured in weeks/months not > > > minutes/hours. Someone else was saying something about crappy (OS) > > > servers. Crappy servers come from programs which misbehave. > > > > Ever product does have some issues. As far as I know there are no > > products that are bug free. We try to fix problems and bugs and also try > > to make sure that the new releases are bug free. We have a whole process > > of engineering/service release that address major bugs and concerns. > > Anytime you see a problem our priority is to fix the problem. A lot of > > problems have been address with TCM lately, if you still have a problem > > we shall be glad to fix them and solve the same. > > Sure can. Even in version 6.0.7 of TCM, the scroll bars still don't > work. I have put in plenty of feature requests for the rest. You may > want to take a look at them. > > > > I'm quite certain the 3Com has its own QC procedures for software. One of > > > the procedures I use with programs I've written is to watch the size of > > > the program to see if it increases over time. I know how big it should be > > > and when I find that I've got a program which grows without bounds, I fix > > > the problem. Seems to me that 3Com ought to be using this type of > > > procedure more for its own programs (such as the RADIUS server). > > > > > > Lastly, please reinstate the level 1 and level 2 support definitions or at > > > least do something to bring your new tech's up to speed a little better. > > > When I talk to a tech and without really knowing much about the situation, > > > they tell me to change SW5 on the card, they're shooting in the dark and > > > not able to reproduce a problem which may be fixable in software. This > > > has happened on *more* than one occasion. I am very thankful every time I > > > get on the support line and get one of a few people whose names will not > > > be mentioned so I can be more likely to get them ( :) ). There are others > > > who I know not to talk to because after a few minutes, they reveal just > > > how little they know about the equipment they're supporting. It's one > > > thing to follow scripts and walk people through prompts. I can handle > > > that. People need to learn sometime. Great. Put them on level 1. > > > Having two support levels helps people like me get answers to complex > > > questions instead of wasting level 2 experience on forgetting to plug > > > cards in properly or other things like that. When I have done something > > > silly, I tell the rep. (expecting level one) and we step through things > > > carefully. That's fine. When I've already spent hours troubleshooting a > > > problem, having been there before, I once again, look for the level two > > > people. If I don't like the questions from person I'm talking to, I ask > > > for someone I know who knows what they're doing. Maybe I'm not your > > > typical support customer. As an ISP, we too have our own support staff. > > > Our level two people handle the tough calls. People who are in training > > > and those who have not yet demonstrated the ability to handle the tougher > > > calls are the ones who are the front-line answering the phones and helping > > > determine whether or not a level two person is needed. Like your team, > > > when a level two person gets involved, the level one person stays involved > > > so they can learn how to solve that problem. It's a win-win situation. > > > The level one people are learning more and more by answering questions. > > > The level two people are training level one people and freeing themselves > > > up for the more complex problems which aren't always easy to document in a > > > clear-cut "this is how you solve this problem" kind of way. Usually, > > > after the call is finished, the person in level one and the person in > > > level two have a discussion about the call to discuss other things that > > > may have helped troubleshoot the problem and to make sure the level one > > > person has a chance to have their own questions answered, such as, how did > > > you know to ask this or that. > > > > > > > Training for the staff is a constant effort, It is good that you have > > mentioned this. This way I can get the attention of our management in > > this issue. I will sure let the management know. If you have problems > > with support please do let us know. I will forward your email to our > > support managers and the upper level management people. Defaulting the > > card or erasing the config without any valid reason is not acceptable in > > any product. Sometimes however depending on the complication of the > > problem eraseing the flash may be necessary. The tech however should > > explain this and make sure that the customer has understood the problem > > and the solution. As I have mentioned above - I will get this matter to > > the attention of our management. > > I agree. My main concern in those cases has been that erasing the card > should be more of a last resort rather than something to try while > "shooting in the dark." On a few of the more recent phone calls, I ended > up teaching the person how to troubleshoot some of the things. Customers > teaching support reps how to support their own product? This is not good. > Recording calls for the purpose of coaching is not only common, but also a > great way to teach new support people how to troubleshoot issues. Knowing > which questions to ask is a big part of support as you know. Learning > which questions to ask is the key to training good support people. Being > willing to admit not knowing how to solve a problem is also important. If > your training team is having support trainee's listen to phone calls from > tape, I'm sure they'll learn plenty just by hearing how problems are > resolved. > > Kevin Benton > Network Engineer, Customer Training Director, FAA Certified Flight Instructor > SOTA Software > > E-Mail: s1kevin@tims.net > Web: http://users.sota-oh.com/~s1kevin/ > Unsolicited advertisements processing fee: $50 subject to change without notice > >

On Wed, 9 Sep 1998, Ricky Beam wrote: > Tatai SV Krishnan was heard to say: > >> Am I just going to be dumped again in 2 years when new cards come out? > >> > >No - The new HiPer arc cards are out and have been out for nearly a year. > >We still support and fix bugs in the NETServer. > > No you don't... "you" fix what ever management tells you is fixable. And, > as much as you might think otherwise, 3Com will abandon the entire TDM > based chassis products as soon as they begin shippping ATM based chassis > systems. You can say what ever you want, but this is not true. There are several people right here on the list who had problems and we solved those right away. Management does not come and tell us to fix one problem and not to fix the other. Each problem falls into a specific class regarding the type of the problem, and the fix depends on the type of the problem. > > The TDM systems cannot handle the higher densities. How many TDM slots does > the chassis have now? 256? THAT is why you need two ARCs to fill the chassis > with 14 hiperDSPs, not because the ARC doesn't have the processing power. > Again you are wrong here. Why don't you try putting 14 dsp with the latest beta code and then tell me what the problem is? krish > --Ricky > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Wed, 9 Sep 1998, Curt Shambeau wrote: > > The TDM systems cannot handle the higher densities. How many TDM slots does > > the chassis have now? 256? THAT is why you need two ARCs to fill the chassis > > with 14 hiperDSPs, not because the ARC doesn't have the processing power. > > I'm not a 3COM engineer or anything, but I don't believe the above > statement is true. I believe the limit is 512, and the limit with the > ARC's currently comes from the software, not the hardware. The HiPer DSP does not work this way. In a HiPer DSP the TDM is within the card. The modems and and span are on the card itself. So it does not matter what the limit is - the DSP does not use it at all. krish > > -------------------------------------------------------------------------- > | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | > | Executive Vice President - Exec-PC, 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. >

Jake Messinger said once upon a time: > >Has this list been down? I sent 3 emails to it last week that are only >JUST NOW showing up. No, but if you're sending from a different address than you are subscribed from, then I have to approve each message and add your sending address to a list of exceptions. Sometimes I don't get around to approvals until a few days after they are sent, which brings up another topic. I am going on my honeymoon in October and I need a Majordomo-speaking volunteer to manage the list until then. If you would be able to help me do this, please email me directly.

Tatai SV Krishnan was heard to say: >> Am I just going to be dumped again in 2 years when new cards come out? >> >No - The new HiPer arc cards are out and have been out for nearly a year. >We still support and fix bugs in the NETServer. No you don't... "you" fix what ever management tells you is fixable. And, as much as you might think otherwise, 3Com will abandon the entire TDM based chassis products as soon as they begin shippping ATM based chassis systems. The TDM systems cannot handle the higher densities. How many TDM slots does the chassis have now? 256? THAT is why you need two ARCs to fill the chassis with 14 hiperDSPs, not because the ARC doesn't have the processing power. --Ricky

Bob Purdon <bobp@southcom.com.au> writes: > One of the problems is that I need to collect data during the call - I > can't afford to wait until the call completes. Right - but you can enable a trap for call start (or key off of an accounting packet or syslog from the NETServer), and immediately query some base data, and at that point your back-end systems know that a call is present on that modem so you can do whatever you want over time, such as re-polling to update your byte count. > I was hoping to get away with something simpler, using just SNMP. I'd > like to be able to give my monitor a NETserver name, community and > customer IP address and have it do the rest. Another complication is the > possibility of the call being on one of many NETservers... Hmmm... Well, as you see, it can pretty quickly become a slippery slope in terms of trying to deal with a large, distributed set of modems. We've had really good results with a system whose purpose is to track the calls from multiple data sources (SNMP traps and queries via the NMC from the modem, and NETServer syslogs - internally translated into traps to the same SNMP data collection tool), and then generate call records with merged information. Of course, we do write the records on call completion, so you'd need a slight modification to have intermediate records (or records updated over time) indicating usage over your appropriate billing period. It's a small hurdle to get the process started, but once you have the code that hooks into call start/completion for queries and can associate NETServer data it grows pretty quickly. Sort of at the minimum, you need to associate a user with a modem. One sort of low cost way to do this dynamically in the field is to have your authentication daemon generate an SNMP trap to your SNMP statistics daemon telling it that user 'x' is now on port 'y'. That can then be merged with modem trap/query data. Of course, the integration of the data doesn't absolutely have to be done dynamically. Assume for the moment that you are collecting modem data into call records, and then just have your authentication system or accounting system store user to port mappings also with time information. You can always post-process those database entries later on to associated the two sets of data. > Except we lose the data since the last poll, since the interface is > dynamically created/destroyed as the calls come and go. We were planning > on using 15 minute samples for both modem connections, ISDN, and sync > serial. Well, when I mentioned polling, I wasn't considering that the only mechanism for data collection. Clearly you still want to trigger right on call start/end (whether by SNMP traps from the modems, or NETServer accounting logs or syslogs) to ensure you get both any initial data you need as well as the final set of data - you add the polling to that during the lifetime of an active call to ensure you catch wraparounds. Technically, our daemon does do similar polling, but not to update byte counters - rather to ensure the modem is still online and that we somehow didn't miss termination. Of course, mentioning ISDN/sync - are you pumping that directly through the NETServer or into the modems as I think most people have eventually reverted to? If directly into the NETServer, then clearly you need a NETServer-centric approach, although one could still consider that a subset of a modem+NETServer approach for other calls. In such a case, it seems to me that triggering on NETServer (accounting or syslog) as beginning and ending data samples, and then instituting periodic NETServer polling while a call is still live, would be a fairly simple combination. Accounting is probably as easy as not given it uses the existing RADIUS packet handling, is acknowledged so guaranteed delivery, and contains the appropriate data at the point of start/stop of the call - in conjunction with periodic polling you may do you should have all the data you need. > I prefer querying via the NMC, but querying the NETserver has some > advantages in that it's consistent with querying other devices (Cisco's, > etc). Either way works of course... ...and the NMC gives us access to > the call duration timer in the modem... Yeah, the big problem is the lack of anything but MIB-II in the NETServer. In almost all cases, much of the most useful information is available only via the other components in the chassis, and thus the NMC path is needed. To some extent it really sounds like you'd be doing nicely if the NETServer had implemented (I don't think it did, but only paid attention peripherally to this) the intermediate accounting packets talked about on the RADIUS list a while back, and/or added the 64-bit counter attributes to help prevent rollover. Ah well. > Anyway, thanks for your comments David - they were most useful and have > given me a few things to think on... For what it's worth, I'll include a copy of an older message where I described just how we build our call records. Probably not really relevant to your system, and in re-reading it I guess I'm not positive how much more insight it gives than I've sort of referred to here, but it might help trigger other thoughts... (In our case, we ended up pumping ISDN calls through the modems, which in the end, actually made it easier to track those calls since they worked just like the analog calls) -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/ - - - - - - - - - - - - - - - - - - - - - - - - - In-Reply-To: Your message of Thu, 10 Jul 1997 14:38:23 -0600 (MDT) Message-ID: <CMM.0.90.2.868654981.db3l@foo.ans.net> Pete Ashdown <pashdown@xmission.com> writes: > What are people using for stats? For ourselves, we use internally developed tools for statistics gathering and reporting - nothing out there really deals well with the scale of our environment. For what it's worth I can describe how we go about handling our collection and analysis as an overview of data flow and possibly to give some suggestions for a setup, but if what you're really looking for is a pointer to available code or something, feel free to skip by the rest of this message :-) We operate with a local Unix workstation as a management point for each "rack" of gear we deploy. In our case a rack typically contains 4 USR hubs for processing user sessions, so about 192-224 (T1/E1) modems per manager (at least with existing density stuff). Among other things, the manager runs a statistics gathering daemon whose primary goal in life is to create call records, and to compute certain other aggregate data points about the callers in its local rack. As input to the daemon, we enable all possible traps on each USR hub, and also process all syslog messages from any NETServers. There are some other input sources such as our authentication daemon and such that also feed information to the statistics daemon. The daemon uses those traps/syslogs to trigger other queries to the modems involved in order to query the statistics table from the modem via NMC (the mdmCs table). Some objects from the table are queried at the beginning of the call (such as modulation type), some at the end (such as characters transmitted) and some at both points (such as link rates). Once a call has completed on a particular channel, a call record for that call gets written to a local database. The statistics daemon also manages local aggregates for its rack, such as tracking total port usage in real time, and in 15-minute intervals, breakdown by user/customer, and by target/assigned address. Access to the statistics daemon is by SNMP, so we can run real-time queries across the backbone for summarization or to just check a particular site if necessary. The call record contains everything we can think of pertaining to that call such as: * Identification information (entity in system, type of call) * User information (realm/id, authentication info, etc..) * Event timestamps (arrival, train, TCP setup, teardown, hangup, etc..) and duration information. * Modem statistics (mdmCs MIB table) when appropriate. The local manager holds onto about a month of call records for its local rack. So if we have a failure on the central polling machine we can always restore from the remote managers. It also allows us to do trend analysis over time locally on the manager when troubleshooting problems. Raw logs of all events (traps, syslogs, etc..) exist for a week in order to allow post-mortems and troubleshooting based on the actual information received from the USR gear. The call records are retrieved continuously by a central statistics machine and injected into a commercial database. Due to polling cycle times and the amount of data involved, data on the central machine tends to be about 15 minutes delayed, but still usable for semi-real time analysis. We have a variety of reporting tools and engineering analysis tools.. Since we're a Unix shop a lot of stuff is done with scripts, as well as custom binaries. Most that has to do with the sort of stuff you are looking for (usage, utilization, etc.) runs off of these call records. Several tools are geared for real time use (triaging problems, checking usage) and can run locally on the management machines off of the local database. The bulk of our daily or higher order reports run from the central database, and can view the system however they like for the purpose of reporting. (...)

On Wed, 9 Sep 1998, Tatai SV Krishnan wrote: > As far as support for the NETServer is concerned - This is still a > supported product. I have not heard anything officially to say that the > product will not be supported. As far as I know the product will be > supported and there will be bug fixes. Once again, I'd like to hear an official date when support is planned to be dropped so we know when to stop buying support contracts for NS chassis's or at least be able to plan for upgrades. Growth can be a real pain at times. If we weren't growing so rapidly, we'd probably have money to buy ARC's. We don't. We are putting almost everything into growth/expasion right now. > > What would we like to see? We'd like to see the netservers continue to be > > supported for at least three more years since our warranty support won't > > run out for most of that time, and if 3Com really wants us to switch to > > HARC's so bad because they don't want to support them any longer, 3Com > > ought to be offering *FREE* upgrades to the HARC's. > > Again - I have not heard anything official to say that we are not going > to support the NETServer. All I know is we are and will be supporting > the NETSever and will be fixing the bugs in the product. Anything in > regards to NETServer support should come from our Product managers. It > is the Product manager's decision - to either tell the customers to > switch over or to give products free. I sure will get this matter to the > attention of the Product Manager concerned. > > >We'd also like to see > > 3Com fix those well known long-term bugs like memory leaks in TCM which > > we've been griping about for how long now? Automatically rebooting a > > machine just to keep a program from crashing is not an acceptable > > long-term solution. Program uptime should be measured in weeks/months not > > minutes/hours. Someone else was saying something about crappy (OS) > > servers. Crappy servers come from programs which misbehave. > > Ever product does have some issues. As far as I know there are no > products that are bug free. We try to fix problems and bugs and also try > to make sure that the new releases are bug free. We have a whole process > of engineering/service release that address major bugs and concerns. > Anytime you see a problem our priority is to fix the problem. A lot of > problems have been address with TCM lately, if you still have a problem > we shall be glad to fix them and solve the same. Sure can. Even in version 6.0.7 of TCM, the scroll bars still don't work. I have put in plenty of feature requests for the rest. You may want to take a look at them. > > I'm quite certain the 3Com has its own QC procedures for software. One of > > the procedures I use with programs I've written is to watch the size of > > the program to see if it increases over time. I know how big it should be > > and when I find that I've got a program which grows without bounds, I fix > > the problem. Seems to me that 3Com ought to be using this type of > > procedure more for its own programs (such as the RADIUS server). > > > > Lastly, please reinstate the level 1 and level 2 support definitions or at > > least do something to bring your new tech's up to speed a little better. > > When I talk to a tech and without really knowing much about the situation, > > they tell me to change SW5 on the card, they're shooting in the dark and > > not able to reproduce a problem which may be fixable in software. This > > has happened on *more* than one occasion. I am very thankful every time I > > get on the support line and get one of a few people whose names will not > > be mentioned so I can be more likely to get them ( :) ). There are others > > who I know not to talk to because after a few minutes, they reveal just > > how little they know about the equipment they're supporting. It's one > > thing to follow scripts and walk people through prompts. I can handle > > that. People need to learn sometime. Great. Put them on level 1. > > Having two support levels helps people like me get answers to complex > > questions instead of wasting level 2 experience on forgetting to plug > > cards in properly or other things like that. When I have done something > > silly, I tell the rep. (expecting level one) and we step through things > > carefully. That's fine. When I've already spent hours troubleshooting a > > problem, having been there before, I once again, look for the level two > > people. If I don't like the questions from person I'm talking to, I ask > > for someone I know who knows what they're doing. Maybe I'm not your > > typical support customer. As an ISP, we too have our own support staff. > > Our level two people handle the tough calls. People who are in training > > and those who have not yet demonstrated the ability to handle the tougher > > calls are the ones who are the front-line answering the phones and helping > > determine whether or not a level two person is needed. Like your team, > > when a level two person gets involved, the level one person stays involved > > so they can learn how to solve that problem. It's a win-win situation. > > The level one people are learning more and more by answering questions. > > The level two people are training level one people and freeing themselves > > up for the more complex problems which aren't always easy to document in a > > clear-cut "this is how you solve this problem" kind of way. Usually, > > after the call is finished, the person in level one and the person in > > level two have a discussion about the call to discuss other things that > > may have helped troubleshoot the problem and to make sure the level one > > person has a chance to have their own questions answered, such as, how did > > you know to ask this or that. > > > > Training for the staff is a constant effort, It is good that you have > mentioned this. This way I can get the attention of our management in > this issue. I will sure let the management know. If you have problems > with support please do let us know. I will forward your email to our > support managers and the upper level management people. Defaulting the > card or erasing the config without any valid reason is not acceptable in > any product. Sometimes however depending on the complication of the > problem eraseing the flash may be necessary. The tech however should > explain this and make sure that the customer has understood the problem > and the solution. As I have mentioned above - I will get this matter to > the attention of our management. I agree. My main concern in those cases has been that erasing the card should be more of a last resort rather than something to try while "shooting in the dark." On a few of the more recent phone calls, I ended up teaching the person how to troubleshoot some of the things. Customers teaching support reps how to support their own product? This is not good. Recording calls for the purpose of coaching is not only common, but also a great way to teach new support people how to troubleshoot issues. Knowing which questions to ask is a big part of support as you know. Learning which questions to ask is the key to training good support people. Being willing to admit not knowing how to solve a problem is also important. If your training team is having support trainee's listen to phone calls from tape, I'm sure they'll learn plenty just by hearing how problems are resolved. Kevin Benton Network Engineer, Customer Training Director, FAA Certified Flight Instructor SOTA Software E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

On Wed, 9 Sep 1998, Ricky Beam wrote: > Tatai SV Krishnan was heard to say: > >You can say what ever you want, but this is not true. There are several > >people right here on the list who had problems and we solved those right > >away. Management does not come and tell us to fix one problem and not to > >fix the other. Each problem falls into a specific class regarding the > >type of the problem, and the fix depends on the type of the problem. > > Fine, fix the "Quake Lag" problems on the NetServer. See, you fix what you > think needs to be fixed and everyone else does the same thing. The fact of > the matter is that some stuff never gets fixed and most likely NEVER will. > So stop wasting your time tell me 3Com is listening and fixing our problems > because there is more than enough evidence to prove otherwise. It's getting > to the point where I need to put a gun to someones head to get anything > fixed. > Quake lag is still a problem. The only best possible solution is to use the quad modems with the NETServer to terminate both isdn and analog modems. This is the best the NETServer could do currently. We are trying to make it better but this is where we are now. This problem revolves round both hardware and software. If the hardware had some chache a lot could be solved. > >> The TDM systems cannot handle the higher densities. How many TDM slots does > >> the chassis have now? 256? THAT is why you need two ARCs to fill the chassis > >> with 14 hiperDSPs, not because the ARC doesn't have the processing power. > >> > >Again you are wrong here. Why don't you try putting 14 dsp with the > >latest beta code and then tell me what the problem is? > > First, I don't have 14 PRIs or 150k$ for 14 of them cards. Perhaps you want > to discount the information that was published a year ago about the TDM bus > as modems are added to the bus? It's about as much magic as finding the > right combination of SCSI devices on a SCSI bus. (Performance increases as > you start adding devices then begins to drop off once a certain number of > devices has been added.) Maybe that's been fixed and maybe it hasn't. > > A 200MHz 603e cannot handle 332 modem connections? I find that very hard > to believe. To answer your question, the problem then is the power supply > -- I've only got one 70A supply in the test rack :-( > > Wait until we install the DMS-500 then ask me again. > You were the one who talked about the TDM. Looked like you knew what you were talking. I do not sell and sure cannot discount any products for you or for anyone ( wish I could :-) ). Anyway, the problem with 14 dsp was again software based and our HiPer arc 4.0 had many problems with more than 7 DSPs - that is the reason it was said - that you must use two HiPer arcs. The 4.1 should address this problem. Yes a 603e 230MHZ sure has a good amount of power and should be easily handling this. Sure with good programmers and good code this card should be ample to support 14 dsps. krish > --Ricky > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Wed, 9 Sep 1998, Ricky Beam wrote: > Tatai SV Krishnan was heard to say: > >The HiPer DSP does not work this way. In a HiPer DSP the TDM is within > >the card. The modems and and span are on the card itself. > >So it does not matter what the limit is - the DSP does not use it at all. > > Umm, then how does it get data to the ARC? As I understand it, there are > four TDM buses in the chassis (management bus, pri-tdm, t1-tdm, packet bus.) > Packet bus - Only packet bus. The call comes in the DSP gives it to the modem and the modem talks on the packet bus ( TDM is internal here ) krish > --Ricky > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

At the risk of being flamed for defending a 3Com employee... krish seems to be taking a good deal of the slagging here lately that is directed, and most deservedly so, at 3Com. I know for a fact that he monitors this list serv because he wants to and not because he was asked to or that it is in his job description. I just want to be sure that in our pain we are not biting the had that is trying to help us, just because it happens to be dressed in blue and white. I know myself and many others, as was stated today, get better support off this list that we generally do from 3Com proper, and a significant part of that comes from krish. And yes, I do have several Netervers (some of them brand new) and yes I am going throught the same crap all the rest of you are, and yes I think this whole thing is bs. </goodie-goodie> Steve Steve McConnell EMJ Internet http://www.emji.net

Tatai SV Krishnan was heard to say: >You can say what ever you want, but this is not true. There are several >people right here on the list who had problems and we solved those right >away. Management does not come and tell us to fix one problem and not to >fix the other. Each problem falls into a specific class regarding the >type of the problem, and the fix depends on the type of the problem. Fine, fix the "Quake Lag" problems on the NetServer. See, you fix what you think needs to be fixed and everyone else does the same thing. The fact of the matter is that some stuff never gets fixed and most likely NEVER will. So stop wasting your time tell me 3Com is listening and fixing our problems because there is more than enough evidence to prove otherwise. It's getting to the point where I need to put a gun to someones head to get anything fixed. >> The TDM systems cannot handle the higher densities. How many TDM slots does >> the chassis have now? 256? THAT is why you need two ARCs to fill the chassis >> with 14 hiperDSPs, not because the ARC doesn't have the processing power. >> >Again you are wrong here. Why don't you try putting 14 dsp with the >latest beta code and then tell me what the problem is? First, I don't have 14 PRIs or 150k$ for 14 of them cards. Perhaps you want to discount the information that was published a year ago about the TDM bus as modems are added to the bus? It's about as much magic as finding the right combination of SCSI devices on a SCSI bus. (Performance increases as you start adding devices then begins to drop off once a certain number of devices has been added.) Maybe that's been fixed and maybe it hasn't. A 200MHz 603e cannot handle 332 modem connections? I find that very hard to believe. To answer your question, the problem then is the power supply -- I've only got one 70A supply in the test rack :-( Wait until we install the DMS-500 then ask me again. --Ricky

Tatai SV Krishnan was heard to say: >The HiPer DSP does not work this way. In a HiPer DSP the TDM is within >the card. The modems and and span are on the card itself. >So it does not matter what the limit is - the DSP does not use it at all. Umm, then how does it get data to the ARC? As I understand it, there are four TDM buses in the chassis (management bus, pri-tdm, t1-tdm, packet bus.) --Ricky

> Tatai SV Krishnan was heard to say: > >Quake lag is still a problem. The only best possible solution is to use > >the quad modems with the NETServer to terminate both isdn and analog > >modems. This is the best the NETServer could do currently. We are > >trying to make it better but this is where we are now. This problem > >revolves round both hardware and software. If the hardware had some > >chache a lot could be solved. > > While possiblly true, I simply cannot buy it. I've got 386dx40 netblazers > running circles around the 486dx4-100 netserver -- and the netblazer has > 4M of ram. (Of course, having seen some of the NetServer source, I'm > surprised it works as well as it does :-)) > Again there are several layes that has to be modified in the code and having a cache on the card will surely help. netblazer's handling the call is quite different when compared to the NETServer. The delay in quake could be anywhere - in the ppp stack, in the router engine or even in the modem. That is one of the reason why we have a settable paramerter on the netserver to tell the quad to send all packets. set forward 0 will tell the modem not to have the packet stored anywhere but to forward it to the NETServer - irrespective on how small the packet is. > >You were the one who talked about the TDM. Looked like you knew what you > > [with alot of '?'s It's been a year since I looked at the TDM bus data.] > > >were talking. I do not sell and sure cannot discount any products for > >you or for anyone ( wish I could :-) ). Anyway, the problem with 14 dsp > >was again software based and our HiPer arc 4.0 had many problems with > >more than 7 DSPs - that is the reason it was said - that you must use two > >HiPer arcs. The 4.1 should address this problem. > > Well, power is also a concern. From my "top secret" power document... > 80-002092 HiPerDSP Set (domestic) 4.9A * 14 = 68.6A > 80-002267 HiPerARC Set (Enet) 6.0A * 2 = 12.0A > Backplane 1.5A * 1 = 1.5A > ----- > 82.1A > (And that's not counting the 3.0A+ from the NMC.) > > >Yes a 603e 230MHZ sure has a good amount of power and should be easily > >handling this. Sure with good programmers and good code this card should > >be ample to support 14 dsps. > > Even with "bad code" it should still do it... That's a *lot* of packet > slingin' power. We do have a 130 A power supplies now - just for this reason. krish > > --Ricky >

Thus spake Ricky Beam >Tatai SV Krishnan was heard to say: >>The HiPer DSP does not work this way. In a HiPer DSP the TDM is within >>the card. The modems and and span are on the card itself. >>So it does not matter what the limit is - the DSP does not use it at all. >Umm, then how does it get data to the ARC? As I understand it, there are >four TDM buses in the chassis (management bus, pri-tdm, t1-tdm, packet bus.) Well...my understanding is that the packet bus, is just that...the packet bus...not a tdm bus. Meaning you can throw as much data onto that bus as you want, but eventually, you're going to start seeing some degredation in performance. Putting 2 Arc's in the chassis won't affect this as it doesn't change the bus or the contention for the bus at all. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Tatai SV Krishnan was heard to say: >Quake lag is still a problem. The only best possible solution is to use >the quad modems with the NETServer to terminate both isdn and analog >modems. This is the best the NETServer could do currently. We are >trying to make it better but this is where we are now. This problem >revolves round both hardware and software. If the hardware had some >chache a lot could be solved. While possiblly true, I simply cannot buy it. I've got 386dx40 netblazers running circles around the 486dx4-100 netserver -- and the netblazer has 4M of ram. (Of course, having seen some of the NetServer source, I'm surprised it works as well as it does :-)) >You were the one who talked about the TDM. Looked like you knew what you [with alot of '?'s It's been a year since I looked at the TDM bus data.] >were talking. I do not sell and sure cannot discount any products for >you or for anyone ( wish I could :-) ). Anyway, the problem with 14 dsp >was again software based and our HiPer arc 4.0 had many problems with >more than 7 DSPs - that is the reason it was said - that you must use two >HiPer arcs. The 4.1 should address this problem. Well, power is also a concern. From my "top secret" power document... 80-002092 HiPerDSP Set (domestic) 4.9A * 14 = 68.6A 80-002267 HiPerARC Set (Enet) 6.0A * 2 = 12.0A Backplane 1.5A * 1 = 1.5A ----- 82.1A (And that's not counting the 3.0A+ from the NMC.) >Yes a 603e 230MHZ sure has a good amount of power and should be easily >handling this. Sure with good programmers and good code this card should >be ample to support 14 dsps. Even with "bad code" it should still do it... That's a *lot* of packet slingin' power. --Ricky

Has anyone on this list had any long term experience wiht the HiPer Card Chassis. I have ordered 2 PRI's and have yet to purchase the access server. I am looking at either the HiPer chassis or a Livingston PM3. I am familiar with the PM3 and Livingston's Tech support. Can anyone tell me how the HiPer chassis and 3COM Support stack up against the PM3 and Livingston? Would you buy either again? Did you feel good about the purchase two months later? Any information would be great. Comments are welcome from USR/3COM. Sincerely, Flint E. Barber

I'm about to replace netserver card code 3.7.24 with the new 3.8.1. Has anyone had trouble with 3.8.1? Does it work? The documentation listed bug fixes a mile long. That made me worry about 3.7.24! I can live with quake lag, for now. - andrew

same here ... we had USR support that would actually call me back 5 times to make sure everything was ok! .. now 3Com canada is basically nothing .. a few people ... no support ... terriblly lame ... -----Original Message----- > >> krish seems to be taking a good deal of the slagging here lately that >> is directed, and most deservedly so, at 3Com. I know for a fact that >> he monitors this list serv because he wants to and not because he was >> asked to or that it is in his job description. > >Krish is a great example of exactly the type of support we had from USR - >helpful, responsive, and fairly flexible. > >Now I can't speak for the US, but many of the USR staff no longer work at >3COM/USR in Australia (downsizing), and therefore we no longer have access >to many of the helpful, responsive, and flexible people we did before. > >They've closed their Melbourne warehouse, so getting new stuff can be >slow as the resellers have to import from the US. For those in Aus - >tried buying a Courier modem lately? We've been waiting several months >for the units we ordered... > >Anyone in Aus tried getting things fixed under warranty? The smaller >items seem to be OK now, after an initial hurdle while things were >internally reorganised, but we're trying to get 4 NETserver's replaced >(under warranty) and it's an awful process. > >> I just want to be sure that in our pain we are not biting the had that >> is trying to help us, just because it happens to be dressed in blue >> and white. > >Not at all - the input that Krish, and the other 3COM people, give on this >list is invaluable. Can't say the same of the rest of USR though. Many >of the staff are very helpful, but I can't help feeling that they're VERY >constrained in what they can do by management. > >Regards, > >Bob Purdon, >Technical Manager, >Southern Internet Services. > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

I was wondering what the MSS value should be set to on the NETServer?? right now I have "set mss 0" would it be faster if I set mss 576 or 1500? -----Original Message----- > >> in the modem. That is one of the reason why we have a settable >> paramerter on the netserver to tell the quad to send all packets. >> set forward 0 will tell the modem not to have the packet stored >> anywhere but to forward it to the NETServer - irrespective on how >> small the packet is. > >Why is it that these commands aren't documented anywhere? Since I've been >on this list I've seen numerous useful commands that aren't documented >anywhere... > >Regards, > >Bob Purdon, >Technical Manager, >Southern Internet Services. > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Ricky Beam <jfbeam@Interpath.net> writes: > Umm, then how does it get data to the ARC? The packet bus. > As I understand it, there are > four TDM buses in the chassis (management bus, pri-tdm, t1-tdm, packet bus.) There are 4 buses (but you've really only listed three - "pri-tdm" and "t1-tdm" just control the use of a combination of TDM/packet), but only one TDM bus. A TC chassis has a TDM bus, a packet bus, a management bus, and a power distribution bus. The management and power distribution buses aren't really relevant to this discussion, but neither are TDM. The power is just fixed distribution of power signals, and the management is a serial bus run by UARTs (not NS, but some other chip, I forget). Actually, calling the management path a "bus" was always a slight stretch to my mind, since there are independent channels from the NMC to each card, with the NMC being the only card with access to all channels. This is related to why the NMC must be in slot 17 as well as why slot 17 is the only slot not to have access to the packet bus. If I recall correctly, the original TDM bus was for 192 64K timeslots, although something seems to make me think they managed to get 240 out of it at some point (might be wrong on that though). That's where the limit of 5 Dual-T1 or PRI cards came from, if used for ISDN to the NETServer , since you needed the TDM to funnel the traffic from the inbound DS1 to the NETServer. From the point of analog traffic, the quad modem density was a much lower limiting factor than the TDM bus, pre-HDM. This bus is only used to circuit switch DS0 channels from the Dual-T1 or PRI cards to the quad modems or to other cards such as a NETServer with the Munich ISDN daughtercard. And obviously, since it is TDM, there is a fixed bandwidth path for the number of timeslots supported - there is no performance degredation as more channels are added, although there is a hard limit on the number of channels available on the bus. The TDM bus is completely unimportant to the HDM cards, since the communication between the circuit (DS0 level) and the modem is all intra-card (and I don't think is implemented as the same kind of bus at all but simply software using shared hardware). It never touches the TDM bus, nor uses any of the timeslots. The programming you do for quad modems for "pri-tdm" or "t1-tdm" does not represent separate TDM buses, but rather how the negotiation for a specific TDM bus channel takes place. The "t1-tdm" setting is for the original design, where the modems listened to a fixed timeslot on the TDM bus based on the slot in which they were inserted. This mapped to the fixed mapping used by the original Dual-T1 card as well as the channelized T1 code running on the 386 card. In such a configuration, the "modem status" as portrayed by the Dual-T1 card is an indication of a fixed data pattern on the fixed TDM bus slot, which can be controlled by the modem to indiciate idle, busy, etc.. The "pri-tdm" setting instructs the modems to also expect a control connection from the Dual-T1/PRI card on the packet bus (see below). Under idle conditions, the modem does not tie into any specific TDM timeslot, but rather when a call occurs, the PRI card "finds" a modem using the packet bus control connections and then the two cards agree on a timeslot to use. But the underlying TDM bus is the same physical bus. When you have a quad modem incorrectly configured as t1-tdm in a PRI chassis, the fact that the PRI card indicates that the modem is "unavailable" is actually indicating that it was unable to establish a packet bus control channel to the indicated modem. If I recall correctly, the PRI communication starts from the highest TDM timeslot down, whereas the previous fixed T1 configuration started from the low end up (the lowest timeslot started in slot 2, worked up to 16 and then wrapped to 1 - that's because originally you couldn't put a quad card in slot 1). This permits an overlap of the original T1 configuration and the newer configuration - which eventually permitted an older channelized T1 and a PRI card to share a chassis, although that wasn't a very common configuration. Now, the remaining bus is the packet bus. This is a general purpose shared datagram bus. It's probably easiest to think of it as an internal ethernet - although that's not entirely appropriate given that it's a bus run from a common master clock - but from a congestion, contention and throughput perspective it's similar. Any card in slots 1-16 can communicate on this bus and as a shared media it has no real fixed timeslots (it's not TDM) but just lots of addressed datagrams flying. The primary function of this bus is to get traffic from the modem cards into gateway cards like the NETServer. This traffic might be coming from quad cards (which originally got the data off of the TDM bus) or from HDM cards (which took the data internally from the circuit task), but in any case it is sent as a packet of data to the NETServer. Since it was a convenient general communication path, it was also adopted as the mechanism for handling call setup between the Dual-T1/PRI cards with PRI code and the quad modems. Additionally, I expect it will see more use as a control channel communication path between HDM cards as they begin to need to coordinate activities across separate HDM cards. And sure, this bus can over time begin to slow down as it becomes more congested, but although I forget the exact bandwidth, it's somewhere in the .5-1 Gigabit/sec range. So you'd have to have aggregate throughput (including packet bus framing overhead) through a hub in that range to see degredation from the bus itself. Of course, if all that traffic is targeted at a single card, such as the NETServer, the card may begin to have problems servicing the load of traffic. That's why NETServers have limits on the simultaneous ports they can support, and the ARCs can handle more, but even there may be desirable (required?) to have two ARCs for a fully outfitted HDM chassis. So, in the original configuration (dual card, quads, NETServer), the traffic would flow from the ingress circuit, be switched at the DS0 level onto a timeslot on the TDM bus - either fixed or negotiated with the modem depending on the circuit card - and then sent from the modem over the packet bus to the NETServer. In an HDM only configuration, traffic from the ingress DS0 is processed internally to the HDM by the modem task, and then shipped directly to the NETServer over the packet bus. The TDM bus (and it's fixed capacity limitations) never comes into play. That's why you can stuff a chassis full of HDMs and still not have a problem - providing you have enough horsepower on the gateway card servicing all of those packet bus links. Hope this helps. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

"Jamie Orzechowski" <mhz@recorder.ca> writes: > right now I have "set mss 0" > > would it be faster if I set mss 576 or 1500? It depends on the remote host's TCP/IP stack, and only if you are talking about TCP sessions formed from the NETServer (e.g., netdata TCP sessions for async users) to a remote (not on the local wire) host. This has no bearing on PPP dialup or on the dialup side of the connection at all. By default (both the original NETServer code which didn't have this setting, and current code with a setting of 0), when the NETServer forms a TCP session (e.g., if you telnet off of the NETServer, or if a netdata user logs on and is connected to a remote host), the initial TCP SYN packet does not include any TCP "MAXSEG" option. Most modern stacks nowadays include that option with a segment size related to the local media (such as the ethernet) to let the remote server side know a segment size that won't be fragmented at least at the last hop. Depending on the target host, the lack of such an option in the SYN, in conjunection with the fact (if true) that the NETServer is not on the local wire, forces the host to default to an "off wire" default segment size - often 576 for BSD based kernels. On some systems this default value can be manually set higher. The disadvantage to this is that you get packets from the server to the NETServer a bit more fragmented than necessary, so you have a higher overhead for the TCP packets within the network. Although not dynamic, the later NETServer codes (probably around the 3.2.x timeframe) got this new setting - if non-zero, then the programmed value is inserted into the TCP SYN as the value of the MAXSEG option. For an ethernet attached NETServer, an appropriate value would be 1460 (leave room in the 1500 ethernet MTU for the TCP header). Depending on the target host of the TCP connections formed by the NETServer, this could force a larger segment sized to be used on the TCP session. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

i installed it on one of our chassis' and it seems to work just fine. i was surprised to see how many things it addressed. matthew andy wrote: > > I'm about to replace netserver card code 3.7.24 with the new 3.8.1. Has > anyone had trouble with 3.8.1? Does it work? The documentation listed bug > fixes a mile long. That made me worry about 3.7.24! I can live with quake > lag, for now. > > - > andrew > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Does it do the same for a soft busy? I've always used a soft busy on the T1 span, then monitor for any idle time to kick the user off Eric T. Billeter Cable One Internet Engineer 1314 North 3rd Street ebilleter@cableone.net Phoenix, AZ 85004 -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mark R. Lindsey Sent: Wednesday, September 09, 1998 7:39 PM Howdy, y'all. I've been using Netservers with dual T1 cards for a while. Recently, I have realized that I do not have any consistent ability to busy-out DS0s. Typically, when I set one to hard busy, any connection does drop, but the CO switch still sends calls to those terminals in the hunt group (rollover), and I get ring-no-answers (RNAs). Occasionally one will busy-out properly, but it's *very* rare. What might the problem be? The T1 card seems to process calls perfectly well. I'm absolutely sure about these details: Our lines are all provisioned ESF/B8ZS, they're all ground start trunks, and the CO's switch is currently a 5ESS. (That's being replaced by a DMS100 soon.) An example system setup follows. I would certainly appreciate any help or insight or things to try; the current conditions make maintenance *very* difficult. Note, also, that when we restore service on those channels, they start taking calls again perfectly well. Dual T1 Application Card Revision 4.2.1 (Card Id:27) Framing Mode ESF Line Coding B8ZS Remotely Initiated Loopback Respond Jitter Attenuation Transmitter Transmit Line Build Out 0.0 dB Automatic Busy-out Enabled Fractional T1 Byte Pattern FE Hex Short Haul NIC Line Length Not Applicable Dial-in/Dial-out Trunk Type Ground Start Dial-in/Dial-out Trunk Start Dial Tone Dial-in Expected Address No Address Dial-in Address Acknowledge Wink Disable Dial-out Address Delay 70 Dial-in No-Add. timeout no answer (0 fast-ans) 0 This might be related: when we power cycle a NIC or chassis to which a T1 span line is connected, or when we unplug a T1 cable in the rare cases that require it, the CO's switch often records that connections are active to several of the terminals in our hunt group. We have to find and report the exact terminals having trouble, and staff at the CO have to _manually_ `release' those lines so they can take calls again. Again, I'd appreciate any help. :) Mark - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

I read that I can terminate the ISDN calls on the modems ... I did this by setting slot 0 for the ISDN-GW slot ...is this correct? .... also ... what about DSP's??? do they terminate calls on the I ports or on the S ports?

andy was heard to say: >I'm about to replace netserver card code 3.7.24 with the new 3.8.1. Has >anyone had trouble with 3.8.1? Does it work? The documentation listed bug >fixes a mile long. That made me worry about 3.7.24! I can live with quake >lag, for now. A few bugs introduced... don't expect dialout to work correctly with pbctrl turned on (at all? I've not had any luck with HDM dialout from the NS 3.8.1) The string lengths allowed for just about everything was shortened... login prompt - 14 characters, login banner message - 240 chars. etc. --Ricky

If anyone has a Cisco 2501 laying around gathering dust and would be interested in selling it....drop me a line.....Must be in good working order! Thanks gowens@magnolia-net.com Greg Owens Magnolia InterNet Services

Thus spake Jamie Orzechowski >I read that I can terminate the ISDN calls on the modems ... I did this by >setting slot 0 for the ISDN-GW slot ...is this correct? Yes. >.... also ... what >about DSP's??? do they terminate calls on the I ports or on the S ports? Don't have any personally, but they should terminate on S ports. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

I am currently running 3 Single Sided Quad A/D's and 12 Double Sided Quad A/D's in a 2059 with a NETSever Card, not using PRI. For some reason the second SS Quad answers the line but will not authenticate and the user gets dumped almost immediately. Also, the last 3 DS Quads which will not answer at all. The Quad's are running 5.10.9 and 5.9.9 respectively while the Net Server has code revision 3.7.24. I have used the modem copy command to copy the respective working modem settings to those that are not working. The Line Interface Source is set to nic. Can someone please point me in the right direction or give me some ideas about what I should be looking at and what might fix this situation. I also have a number of other Quad's that I've tried swapping in without any luck, so I can only assume that this must be either a NETServer or NMC configuration problem. thanks, aj

Got a couple of HiPerDSP cards connected to telco with PRIs. They're in slot 14 and 15. There's a phone number which starts its hunt with the line in slot 15, then to 14. Customers have indicated that they are getting some busy signals, which is odd since we've never had 46 concurrent calls since the installation. When I check under TCM's span line performance, it shows a bunch of "No Idle Modem Available"s for slot 15. I'm wondering if the busy signals aren't happening when we're full on s15 and falling over to s14. The question is what is going on here...how do I track down why and when we're giving out busy signals when we're not using all the modems. Any guidance will be appreciated....(except the people on this list who will only respond by advising me to buy a lucent PMS4...I hold the average spammer in higher regard). Speaking of the anti-3com sentiment of late on this list, shouldn't it be obvious to any reasonably intelligent observer that the only 3com people that see the spew on this list are the ones that want to help? That the ones who are responsible for some of the horrendous policies of late 1) aren't on the list, and 2) couldn't care less? I can understand the need to vent your frustrations, but Krish, et al, aren't the ones to try to convince to give you a free HARC because you can't play Quake. [actually, given the widespread knowlege that the NetServer had problems with Quake since the beginning, one wonders why you bought one if Quake was mission-critical to you....it's not 3com's fault if you didn't do your research, blindly believing anything a salesdroid said] </rant>

First and foremost, I'd like to say that I've had more problems solved by Krish on this list than all of the innumerable calls to 3-Com tech support combined. Krish is doing a wonderful job and I hope he sticks around. However, this paragraph is what I have the most complaints about. Our modems are working fairly well, but there is much functionality missing which our customers need which aren't implemented well in our existing code. There are also some serious intermittent problems which appear to be software-related (e.g. customer calls, modem answers, but customer gets an error stating that the computer they were dialing into did not answer). Unless I fork over more mega-bucks to 3-Com, I will never get these problems fixed, or these needed "enhancements" added. I refuse to spend another dollar for 3-Com tech support on these modems as long as I don't feel I am getting my money's worth. Personally, when I developed a product with known bugs, I fixed the product - no questions asked and no dollars accepted. This used to be the way it worked in many industries, and it also helps to build brand loyalty. With the current situation, I am anything but loyal to 3-Com and my next batch of modem servers will not be 3-Com. Again, thanks for the good work, Krish. If you can pass these comments on to someone who gives a shit, we'd all appreciate it. Tatai SV Krishnan wrote: > > My previous email where I asked you to try the HiPer arc is not related > to this question at all. All I had said was that the latest beta ( soon > to be released ) HIper ARC code does support all the functionalities ( > MPIP, PPTP, L2TP, IGMP etc ) and more. Since you use a lot of our > products and continue to give us information - in regards to improve the > product - beta testing the HiPer arc would a great idea. This was not an > invitation to everyone in this list, nor it was any plan to push the > HiPer arc. > -- ======================================================= =========== Andrew Aken - President ========= ====== GlobalEyes Communications, Inc. ====== =Southern Illinois' Fastest Connection to the Internet= ========== http://www.GlobalEyes.net ======== =======================================================

Howdy, y'all. I've been using Netservers with dual T1 cards for a while. Recently, I have realized that I do not have any consistent ability to busy-out DS0s. Typically, when I set one to hard busy, any connection does drop, but the CO switch still sends calls to those terminals in the hunt group (rollover), and I get ring-no-answers (RNAs). Occasionally one will busy-out properly, but it's *very* rare. What might the problem be? The T1 card seems to process calls perfectly well. I'm absolutely sure about these details: Our lines are all provisioned ESF/B8ZS, they're all ground start trunks, and the CO's switch is currently a 5ESS. (That's being replaced by a DMS100 soon.) An example system setup follows. I would certainly appreciate any help or insight or things to try; the current conditions make maintenance *very* difficult. Note, also, that when we restore service on those channels, they start taking calls again perfectly well. Dual T1 Application Card Revision 4.2.1 (Card Id:27) Framing Mode ESF Line Coding B8ZS Remotely Initiated Loopback Respond Jitter Attenuation Transmitter Transmit Line Build Out 0.0 dB Automatic Busy-out Enabled Fractional T1 Byte Pattern FE Hex Short Haul NIC Line Length Not Applicable Dial-in/Dial-out Trunk Type Ground Start Dial-in/Dial-out Trunk Start Dial Tone Dial-in Expected Address No Address Dial-in Address Acknowledge Wink Disable Dial-out Address Delay 70 Dial-in No-Add. timeout no answer (0 fast-ans) 0 This might be related: when we power cycle a NIC or chassis to which a T1 span line is connected, or when we unplug a T1 cable in the rare cases that require it, the CO's switch often records that connections are active to several of the terminals in our hunt group. We have to find and report the exact terminals having trouble, and staff at the CO have to _manually_ `release' those lines so they can take calls again. Again, I'd appreciate any help. :) Mark

: Does it do the same for a soft busy? I've always used : a soft busy on the T1 span, then monitor for any idle time : to kick the user off It behaves similarly, waiting until the current call is dropped, then acting strangely. Mark Original message: : I've been using Netservers with dual T1 cards for a while. Recently, I : have realized that I do not have any consistent ability to busy-out : DS0s. Typically, when I set one to hard busy, any connection does drop, : but the CO switch still sends calls to those terminals in the hunt : group (rollover), and I get ring-no-answers (RNAs). [snip]

Bob Purdon was heard to say: >It also occurs to me that the only way for management to get the drift is >to let the people who *are* listening know what's happening. I'm sure And let me tell you there's no better way to get things done than scream and bitch about. Of course, it works more effectivity if you bitch to those who can do something about it. I've got an office full of 3Com stuffs -- bribes? Courier V.Everything, I-Modem, several Office Connect toys, even a Palm Pilot. Man did giving me a pilot backfire -- if you assume I was given a pilot to distract me for awhile ... "Here's a Palm Pilot. (that should keep him occupied for a weeks.)" :-) I've still got USR TT#'s in there from 3/97. <grin> >I'd e-mail the relevent people direct, but I don't have their e-mail >addresses. Do you have e-mail addresses for management within 3COM? I >don't. Strange that you should ask... I have several management level peoples email addresses. I don't think many of them have much to do with actual dialup code or hardware. (Mostly RADIUS and tech support folks. And two sales engineers.) --Ricky

Eric Billeter was heard to say: >Does it do the same for a soft busy? I've always used >a soft busy on the T1 span, then monitor for any idle time >to kick the user off And I go the extra mile... put the span in loopback. --Ricky

: Eric Billeter was heard to say: : >Does it do the same for a soft busy? I've always used : >a soft busy on the T1 span, then monitor for any idle time : >to kick the user off : : And I go the extra mile... put the span in loopback. How is telco equipment *supposed* to react to such alarms (LOS and loopback)? Ideally, I'd think, it'd just roll over those circuits -- here in the Land Of The Beast, err, I mean, BellSouth, the switch just seems to go bonkers. How does it work for y'all? --- Mark R. Lindsey, mark@datasys.net Internet Engineering, DSS Online LLC Voice: 912.241.0607; Fax: 912.241.0190

Mark R. Lindsey was heard to say: >How is telco equipment *supposed* to react to such alarms (LOS and loopback)? LOS should send an alarm. Loopback will send an alarm if they set it up to do so. Sometimes the switch will not drop the loop unless LOS is seen so I have to reset the card to get it out of loop, but what do I care... I did have the span forced down. >Ideally, I'd think, it'd just roll over those circuits -- here in the Land >Of The Beast, err, I mean, BellSouth, the switch just seems to go bonkers. >How does it work for y'all? With all our Sprint and BellSouth (even BTI it hunts at all :-)) will roll past the "bad" span. We also have a dial number assigned to each PRI/T1 so we can hand out the number beyond the bad spot if necessary. With a PRI, it's supposed to "busy out" all the DS0's with the D channel down. Of course, your millage will vary widly. If you want to see weird, I can have the BTI "PRI" call you and let you see what it reports as the originating phone number -- basically all you get is the area code; it doesn't even report its own address on inbound calls :-) (I'm not gonna ask how that thing's constructed as it's got an 800# pointed at it.) --Ricky

> already their parts are going to the circular file? Give me a > break... I will be opening communication with Ascend and Cisco very > shortly if I don't see some dramatic improvements here. We've already opened communication with our local Livingston rep, and like you, if things don't change shortly we'll be taking our cash elsewhere. We're likely to be in the market for another 60+ port chassis in the next 3-4 months. > Until today, we're nearly 100% 3Com for digital dial-up equipment. I > wonder how much longer that will continue. Ditto. We use 3COM Total Control (NETserver/Quad based) exclusively. > With our current purchase rate, that would mean the loss of > approximately one chassis sale a month and climbing. I think our > sales rep might like to know the attitude 3Com is coming across with > because of the potential loss of customers. I'm forwarding most of the negative comments back to our OLD account rep (since we're not privileged enough to have a 3COM rep these days). Not sure what he's doing with them, but... > What would we like to see? We'd like to see the netservers continue > to be supported for at least three more years since our warranty > support won't run out for most of that time, and if 3Com really wants > us to switch to HARC's so bad because they don't want to support them > any longer, 3Com ought to be offering *FREE* upgrades to the HARC's. Agreed. > We'd also like to see 3Com fix those well known long-term bugs like > memory leaks in TCM which we've been griping about for how long now? > Automatically rebooting a machine just to keep a program from crashing > is not an acceptable long-term solution. Program uptime should be > measured in weeks/months not minutes/hours. Interesting. I run TCM in the office on a (get ready) 486DX2/66 with 8mb RAM (under Win95 of course) and it's run for months on end without rebooting. > When I talk to a tech and without really knowing much about the > situation, they tell me to change SW5 on the card, they're shooting in > the dark and not able to reproduce a problem which may be fixable in > software. Ha. Sounds like IBM. Back when I was working with AIX, about 50% of our support calls got advice like "reinstall AIX". They obviously had no understanding of the fact that people buy their $1m boxes for serious, critical, production work, and taking one down for 4+ hours to reinstall everything is not an option! Regards, Bob Purdon, Technical Manager, Southern Internet Services.

> krish seems to be taking a good deal of the slagging here lately that > is directed, and most deservedly so, at 3Com. I know for a fact that > he monitors this list serv because he wants to and not because he was > asked to or that it is in his job description. Krish is a great example of exactly the type of support we had from USR - helpful, responsive, and fairly flexible. Now I can't speak for the US, but many of the USR staff no longer work at 3COM/USR in Australia (downsizing), and therefore we no longer have access to many of the helpful, responsive, and flexible people we did before. They've closed their Melbourne warehouse, so getting new stuff can be slow as the resellers have to import from the US. For those in Aus - tried buying a Courier modem lately? We've been waiting several months for the units we ordered... Anyone in Aus tried getting things fixed under warranty? The smaller items seem to be OK now, after an initial hurdle while things were internally reorganised, but we're trying to get 4 NETserver's replaced (under warranty) and it's an awful process. > I just want to be sure that in our pain we are not biting the had that > is trying to help us, just because it happens to be dressed in blue > and white. Not at all - the input that Krish, and the other 3COM people, give on this list is invaluable. Can't say the same of the rest of USR though. Many of the staff are very helpful, but I can't help feeling that they're VERY constrained in what they can do by management. Regards, Bob Purdon, Technical Manager, Southern Internet Services.

> in the modem. That is one of the reason why we have a settable > paramerter on the netserver to tell the quad to send all packets. > set forward 0 will tell the modem not to have the packet stored > anywhere but to forward it to the NETServer - irrespective on how > small the packet is. Why is it that these commands aren't documented anywhere? Since I've been on this list I've seen numerous useful commands that aren't documented anywhere... Regards, Bob Purdon, Technical Manager, Southern Internet Services.

> > > in the modem. That is one of the reason why we have a settable > > paramerter on the netserver to tell the quad to send all packets. > > set forward 0 will tell the modem not to have the packet stored > > anywhere but to forward it to the NETServer - irrespective on how > > small the packet is. > > Why is it that these commands aren't documented anywhere? Since I've been > on this list I've seen numerous useful commands that aren't documented > anywhere... Most of them are and the once that are. Some of them are not - however I do have a website you can search for commands like these http://interproc.ae.usr.com/tkb.html regards krish > > Regards, > > Bob Purdon, > Technical Manager, > Southern Internet Services. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Hi Again, I am having some problems setting the DTE interface on my Total Control. Using the TCM, I can set the Interface to Packet Bus and save it, But when I come back and look at the the settings, it has somehow returned to the NIC settings. I have one modem out of 48 that will stay "Packet Bus" but all others will revert back,,,,,, All of the other settings for the 1 good modem and all 47 others are the same. I have replaced the Net Mgt Card with no changes.... thanks

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jamie Orzechowski |Sent: Wednesday, September 09, 1998 6:56 PM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) NETserver 3.8.1 | | |I read that I can terminate the ISDN calls on the modems ... I did this by |setting slot 0 for the ISDN-GW slot ...is this correct? Yes. | .... also ... what about DSP's??? do they terminate calls on the I ports |or on the S ports? | S-ports. I ports are for calls terminated by the Munich daugher board. -Mike Mike Wronski (mike@coredump.ae.usr.com) Rogue 3Com Network Systems Engineer / BETA Engineer PGP:http://coredump.ae.usr.com/pgp "If at first you do succeed, try not to look astonished."

We are probably going to get an ARC soon ... going to have 10 DSP's in the chassis ... I have a setup question ... could someone please tell me how to setup a chassis (10 DSPs) ... what I need to know is how do I asign the class C addresses to the box? ... 24 lines * 10 slots = 240 addresses ... or one class C ... let's say I have the class 207.236.51.0/24 ... how to I assign the entire class to the ARC .. then set the modem pool size (240) ... then set the gateway (206.47.98.1) ... and anything else needed to do to get this working ... could someone just post a quick ARC setup ... basically just for assigning class c's to the chassis ... and mabey show me how to assign 2 class C's to one chassis ... and then set the limit ... thanks! ... Jamie Orzechowski RipNET Internet System Administrator Tel.: (613)342-3946 ext 293 Tel.: (800)267-4434 ext 293 Fax.: (613)342-8672 Page.: (613)341-0883 EMail.: mailto:mhz@recorder.ca Web.: http://www.moonchilli.com There is a $50 Fee for the processing of unsolicited EMail send to this address. "One World, One Web, One Program" - Microsoft Promotional Ad "Ein Reich, Ein Volk, Ein Fuhrer" - Adolf Hitler

On Thu, 10 Sep 1998, Jamie Orzechowski wrote: > We are probably going to get an ARC soon ... > > going to have 10 DSP's in the chassis ... I have a setup question ... > > > could someone please tell me how to setup a chassis (10 DSPs) ... what I > need to know is how do I asign the class C addresses to the box? ... 24 > lines * 10 slots = 240 addresses ... or one class C ... > > let's say I have the class 207.236.51.0/24 ... how to I assign the entire > class to the ARC .. then set the modem pool size (240) ... then set the > gateway (206.47.98.1) ... and anything else needed to do to get this working > ... It is very easy. The easy way out is to use the quick setup but some people may not like to do it. In any case you have to do the following: 1. Setup an ip address for an interface add ip network <network name > address <ip address>/<netmask a,b,or number> interface <ethernet interface eth:1 or eth:2> 2. Add a default gateway add ip defaultroute gateway <ip address> metric <number> 3. Set the number of slots active or if using nmc and one gateway card forget about this. set cha slot <slot1-slot10> owner yes type static card_type hdm_24 ports 24 4. Add ip pool add ip pool <poolname> innitial address <ip address> size <number of address> Now you can make then aggregate or non aggregate here. Meaning either send updates to the whole pool or to each individual address and also you can enable ip pool filtering or disable that - depending upon the how you want to handle the pools. Generally it is set to non-aggregate. The pool is public - thus everyone is assigned an address from the pool or you can set it to private and use the vsa to specifiy the address. That is to it. krish Ps: In ppp you may want to set ccp to all and also you may want to use the authentication prefrence to pap set ppp ccp all set ppp auth pap > > could someone just post a quick ARC setup ... basically just for assigning > class c's to the chassis ... and mabey show me how to assign 2 class C's to > one chassis ... and then set the limit ... thanks! ... > > -------------------------------------------------------------- > Jamie Orzechowski > RipNET Internet System Administrator > > Tel.: (613)342-3946 ext 293 > Tel.: (800)267-4434 ext 293 > Fax.: (613)342-8672 > Page.: (613)341-0883 > EMail.: mailto:mhz@recorder.ca > Web.: http://www.moonchilli.com > > There is a $50 Fee for the processing of unsolicited EMail send to this > address. > > "One World, One Web, One Program" > - Microsoft Promotional Ad > "Ein Reich, Ein Volk, Ein Fuhrer" > - Adolf Hitler > -------------------------------------------------------------- > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

BTW: in my last message I only need to know how to setup a dialin access for PPP and what is the difference between aggregate and no_aggregate ?? what should I use? Jamie Orzechowski RipNET Internet System Administrator Tel.: (613)342-3946 ext 293 Tel.: (800)267-4434 ext 293 Fax.: (613)342-8672 Page.: (613)341-0883 EMail.: mailto:mhz@recorder.ca Web.: http://www.moonchilli.com There is a $50 Fee for the processing of unsolicited EMail send to this address. "One World, One Web, One Program" - Microsoft Promotional Ad "Ein Reich, Ein Volk, Ein Fuhrer" - Adolf Hitler

I've recently upgraded/taken out the quad cards I had here to put in HiperARC and DSP chassis. I've had a rash of phone calls from users with Lucent Tech v.90 LTWinmodems that are unable to connect, and I have yet to find a working init string that'll enable them to connect. If anyone knows of any known issues with v90 (or non-56k) modem brands and their fixes for HiperDSPs, it'd be much appreciated. I've got a few users with this problem. Thanks. -- Gilles Melanson ViaNet Internet Solutions System Administrator 128 Larch St. Suite 301 gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8 "One World, One Web, One Program" - Microsoft Promotional Ad "Ein Reich, Ein Volk, Ein Fuhrer" - Adolf Hitler

Hi, We've got a TC chassis with dual 70A power supplies. We just recieved 2 130A power supplies for an upgrade. Can this upgrade be done "live" or do we need to shut the production unit down to do the switch? -Brian -- # Brian Biggs | Sonic / Sonoma Interconnect # # Sys Admin / Programmer | v707.522.1000 fax707.547.2199 d707.522.1001 # # mailto:bb@sonic.net | http://www.sonic.net mailto:support@sonic.net #

try using the extra setting "-V90=0" this disables V.90 ... -v90=1 enables it ... -----Original Message----- >I've recently upgraded/taken out the quad cards I had here to put in >HiperARC and DSP chassis. I've had a rash of phone calls from users >with Lucent Tech v.90 LTWinmodems that are unable to connect, and I have >yet to find a working init string that'll enable them to connect. > >If anyone knows of any known issues with v90 (or non-56k) modem brands and >their fixes for HiperDSPs, it'd be much appreciated. I've got a few users >with this problem. > >Thanks. > >-- >Gilles Melanson ViaNet Internet Solutions >System Administrator 128 Larch St. Suite 301 >gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8 > >"One World, One Web, One Program" >- Microsoft Promotional Ad >"Ein Reich, Ein Volk, Ein Fuhrer" >- Adolf Hitler > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

This may or may not be helpful, but the way I generally get around it is to unplug our T's from the telco jack. We colo with a CLEC, and they put loopback plugs in for us. So as soon as the plug is pulled, calls hunt around it... Somewhat clunky, but it works. I generally go on site for upgrades do to superstition, so physical access to the jacks is not an issue... Charles On Wed, 9 Sep 1998, Ricky Beam wrote: > Date: Wed, 9 Sep 1998 23:52:09 -0400 (EDT) > From: Ricky Beam <jfbeam@Interpath.net> > Reply-To: usr-tc@lists.xmission.com > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Busy-outs now impossible: huh? > > Mark R. Lindsey was heard to say: > >How is telco equipment *supposed* to react to such alarms (LOS and loopback)? > > LOS should send an alarm. Loopback will send an alarm if they set it up to > do so. Sometimes the switch will not drop the loop unless LOS is seen so > I have to reset the card to get it out of loop, but what do I care... I did > have the span forced down. > > >Ideally, I'd think, it'd just roll over those circuits -- here in the Land > >Of The Beast, err, I mean, BellSouth, the switch just seems to go bonkers. > >How does it work for y'all? > > With all our Sprint and BellSouth (even BTI it hunts at all :-)) will > roll past the "bad" span. We also have a dial number assigned to each > PRI/T1 so we can hand out the number beyond the bad spot if necessary. > With a PRI, it's supposed to "busy out" all the DS0's with the D channel > down. > > Of course, your millage will vary widly. If you want to see weird, I can > have the BTI "PRI" call you and let you see what it reports as the originating > phone number -- basically all you get is the area code; it doesn't even > report its own address on inbound calls :-) (I'm not gonna ask how that > thing's constructed as it's got an 800# pointed at it.) > > --Ricky > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

> try using the extra setting "-V90=0" > > this disables V.90 ... -v90=1 enables it ... That likely won't be enough. I'd imagine that by default, they have v90 enabled on these units. The problem is pretty much an endless handshake, or a connection that gets dropped as soon as data gets tossed overtop of it. Flakey, to say the least. /gm > -----Original Message----- > From: Gilles Melanson <gilles@vianet.on.ca> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Thursday, September 10, 1998 10:28 AM > Subject: (usr-tc) LTWinmodems and HiperDSP > > > >I've recently upgraded/taken out the quad cards I had here to put in > >HiperARC and DSP chassis. I've had a rash of phone calls from users > >with Lucent Tech v.90 LTWinmodems that are unable to connect, and I have > >yet to find a working init string that'll enable them to connect. > > > >If anyone knows of any known issues with v90 (or non-56k) modem brands and > >their fixes for HiperDSPs, it'd be much appreciated. I've got a few users > >with this problem. > > > >Thanks. > > > >-- > >Gilles Melanson ViaNet Internet Solutions > >System Administrator 128 Larch St. Suite 301 > >gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8 > > > >"One World, One Web, One Program" > >- Microsoft Promotional Ad > >"Ein Reich, Ein Volk, Ein Fuhrer" > >- Adolf Hitler > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and 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. > -- Gilles Melanson ViaNet Internet Solutions System Administrator 128 Larch St. Suite 301 gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8 "One World, One Web, One Program" - Microsoft Promotional Ad "Ein Reich, Ein Volk, Ein Fuhrer" - Adolf Hitler

The box is ok. However, there is no comparison regarding service. 3COM = zero Livingston=9 Ascend = 6 3com so bad that to ignore the issue, you are risking your investment(: Tim On Wed, 9 Sep 1998, Flint E. Barber wrote: > Has anyone on this list had any long term experience wiht the HiPer > Card Chassis. I have ordered 2 PRI's and have yet to purchase the access > server. I am looking at either the HiPer chassis or a Livingston PM3. I > am familiar with the PM3 and Livingston's Tech support. Can anyone tell > me how the HiPer chassis and 3COM Support stack up against the PM3 and > Livingston? Would you buy either again? Did you feel good about the > purchase two months later? > Any information would be great. Comments are welcome from USR/3COM. > > Sincerely, > Flint E. Barber > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Jamie Orzechowski said once upon a time: >could someone please tell me how to setup a chassis (10 DSPs) ... what I >need to know is how do I asign the class C addresses to the box? ... 24 >lines * 10 slots = 240 addresses ... or one class C ... Better yet, use 11 slots, and you get 253 addresses, one short of a class C. >let's say I have the class 207.236.51.0/24 ... how to I assign the entire >class to the ARC .. then set the modem pool size (240) ... then set the >gateway (206.47.98.1) ... and anything else needed to do to get this working >... add ip pool nameofpool initial 207.236.51.1 size 254 route aggregate >could someone just post a quick ARC setup ... basically just for assigning >class c's to the chassis ... and mabey show me how to assign 2 class C's to >one chassis ... and then set the limit ... thanks! ... Duplicate the above line for additional pools. Here's my latest ARC setup script, modify where necessary: disable nmc chassis_awareness set chassis slot 1 car hdm_24 own yes type static ports 23 set chassis slot 2 car hdm_24 own yes type static ports 23 set chassis slot 3 car hdm_24 own yes type static ports 23 set chassis slot 4 car hdm_24 own yes type static ports 23 set chassis slot 5 car hdm_24 own yes type static ports 23 set chassis slot 6 car hdm_24 own yes type static ports 23 set chassis slot 7 car hdm_24 own yes type static ports 23 set chassis slot 8 car hdm_24 own yes type static ports 23 set chassis slot 9 car hdm_24 own yes type static ports 23 set chassis slot 10 car hdm_24 own yes type static ports 23 set chassis slot 11 car hdm_24 own yes type static ports 23 set interface slot:1/mod:[1-23] filter_access on set interface slot:2/mod:[1-23] filter_access on set interface slot:3/mod:[1-23] filter_access on set interface slot:4/mod:[1-23] filter_access on set interface slot:5/mod:[1-23] filter_access on set interface slot:6/mod:[1-23] filter_access on set interface slot:7/mod:[1-23] filter_access on set interface slot:8/mod:[1-23] filter_access on set interface slot:9/mod:[1-23] filter_access on set interface slot:10/mod:[1-23] filter_access on set interface slot:11/mod:[1-23] filter_access on add ip defaultroute gateway X.X.X.X metric 1 add user guest password "" login_service rlogin type login set login user guest login_host_ip_address X.X.X.X set login user guest terminal_type dialup enable user guest add dns server X.X.X.X preference 1 add dns server X.X.X.X preference 2 set dns domain_name xmission.com set modem_group all message "Welcome to XMission Internet Access\r\n\r\n Type 'guest' for Guest Services\r\n\r\n 'account' for PPP\r\n 'account@slip' for SLIP\r\n 'account@shell' for Shell\r\n\r\n" set modem_group all prompt "popname-tc login: " disable ip network ip set ip network ip routing_protocol ripv2 set ip network ip rip_policies_update no_ripv1_receive set ip network ip rip_policies_update no_send_compat enable ip network ip set authentication primary_server X.X.X.X set accounting primary_server X.X.X.X set authentication primary_secret SECRET set accounting primary_secret SECRET set system name XMission set system contact support@xmission.com set command prompt popname-tc set syslog X.X.X.X facility log_local3 set ppp receive_authentication pap add ip pool poolname initial X.X.X.X size 254 route aggregate enable ip security_option disallow_source_route_options set ntp primary_server X.X.X.X set ntp secondary_server X.X.X.X set ntp enabled yes

Save yourself and buy a PM3. -----Original Message----- >Has anyone on this list had any long term experience wiht the HiPer >Card Chassis. I have ordered 2 PRI's and have yet to purchase the access >server. I am looking at either the HiPer chassis or a Livingston PM3. I >am familiar with the PM3 and Livingston's Tech support. Can anyone tell >me how the HiPer chassis and 3COM Support stack up against the PM3 and >Livingston? Would you buy either again? Did you feel good about the >purchase two months later? > Any information would be great. Comments are welcome from USR/3COM. > >Sincerely, >Flint E. Barber > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

> Speaking of the anti-3com sentiment of late on this list, shouldn't it > be obvious to any reasonably intelligent observer that the only 3com > people that see the spew on this list are the ones that want to help? I agree 100% It also occurs to me that the only way for management to get the drift is to let the people who *are* listening know what's happening. I'm sure nobody on this list is having a go at Krish (or the others), but rather making their thoughts on 3COM generally known. What's Krish doing - as far as I can tell, he's passing the comments on to the relevant people. I'd e-mail the relevent people direct, but I don't have their e-mail addresses. Do you have e-mail addresses for management within 3COM? I don't. Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Thus spake Mark Ross >I am having some problems setting the DTE interface on my Total Control. >Using the TCM, I can set the Interface to Packet Bus and save it, But when >I come back and look at the the settings, it has somehow returned to the >NIC settings. I have one modem out of 48 that will stay "Packet Bus" but >all others will revert back,,,,,, All of the other settings for the 1 >good modem and all 47 others are the same. >I have replaced the Net Mgt Card with no changes.... Hop on your netserver and do a set modem s5-s52 active, save all, reset all, and when you look at the modems, they'll show as packet bus...that setting is really control'ed from the netserver. Don't know the equivalent setting for the HARC. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

mark@vielle.datasys.net (Mark R. Lindsey) writes: > Occasionally one will busy-out properly, but it's *very* rare. What > might the problem be? The T1 card seems to process calls perfectly well. > I'm absolutely sure about these details: Our lines are all provisioned > ESF/B8ZS, they're all ground start trunks, and the CO's switch is > currently a 5ESS. (That's being replaced by a DMS100 soon.) It's the ground start part that is probably hurting you. There is no official way to "busy out" a ground start circuit. This is unlike, for example, an E&M circuit where a specific A/B bit pattern (1/1) is defined to permit the indication of busy from either end. In the case of ground start, placing a DS0 in a busy state (no matter how you do it - soft or hard) - uses an A/B bit pattern of 0/0. This is equivalent to taking the circuit off hook, which is about as close as you can get. In the vast majority of cases, we've found this to work fine with ground start circuits. But because ground start T1s are rarely digital all the way (it's almost always fed into channel banks which then have individual analog copper pairs on the back end), often older channel banks don't handle the off hook condition properly. In most cases, this exhibits itself only when you've placed a number of channels on the same span offhook, since older channel banks weren't geared towards handling that many phones "pulling dial tone" at the same time. If, however, you're finding this happen even with single channels, it's also possible that the channel bank simply isn't reflecting the off hook status of it's DS0 back over the analog pair into the switch, so the switch never knows that the DS0 is supposed to be avoided. We've virtually eliminated ground start in our network at this point (in favor of either E&M CT1 or PRI) and are much happier - in general GS spans tend to fail in any number of harder ways to diagnose/fix (mostly because of all of those copper pairs that can fail individually - it's like having separate POTS lines, but they are hidden back at the telco switching office) than the other signaling types. But at the same time, at one point we probably had 50% of our channelized circuits in this mode, and of that, probably 90% worked fine for busying things out. So I'd bring this up with your telco, and perhaps have them monitor the channel bank at the point when you busy out the channel and verify that the channel state is making it all the way back to the actual switch. It's possible that they've got a misconfiguration in that respect. To them, your busy operation can be considered taking that channel off hook, or pulling dial tone, and it's implemented by an A/B pattern of 0/0 on that channel. It is, however, also possible that you're going into a CO with channel banks that the per-channel operation won't work correctly with. As others have mentioned, if you don't mind working at the span level, _and_ don't mind being destructive to existing calls, changing circuit configurations at the span level can often take an entire span out of service even when individual busy operations won't work (this holds true for PRI configurations that don't support service messages as well). My personal favorite is taking the span out of frame. Of course, in any of those methods you do run a risk that an overanxious telco technician is going to put a hard loop up or something to eliminate any alarms, and you'll have some effort getting it back into service if it's been out for a bit. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

The problems you (and many others) are seeing with LT Winmodems have been duplicated here. We have a fix in the lab for the "endless handshake" (just retrains over and over). We were able to make a timer a bit more tolerant to accomodate them. But we are still trying to nail the disconnect issue that many are reporting with that modem before we put any engineering code out. We are able to duplicate it, but the root cause is elusive. JP Gilles Melanson <gilles@vianet.on.ca> on 09/10/98 10:13:26 AM Please respond to usr-tc@lists.xmission.com cc: (John Powell/MW/US/3Com) > try using the extra setting "-V90=0" > > this disables V.90 ... -v90=1 enables it ... That likely won't be enough. I'd imagine that by default, they have v90 enabled on these units. The problem is pretty much an endless handshake, or a connection that gets dropped as soon as data gets tossed overtop of it. Flakey, to say the least. /gm > -----Original Message----- > From: Gilles Melanson <gilles@vianet.on.ca> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Thursday, September 10, 1998 10:28 AM > Subject: (usr-tc) LTWinmodems and HiperDSP > > > >I've recently upgraded/taken out the quad cards I had here to put in > >HiperARC and DSP chassis. I've had a rash of phone calls from users > >with Lucent Tech v.90 LTWinmodems that are unable to connect, and I have > >yet to find a working init string that'll enable them to connect. > > > >If anyone knows of any known issues with v90 (or non-56k) modem brands and > >their fixes for HiperDSPs, it'd be much appreciated. I've got a few users > >with this problem. > > > >Thanks. > > > >-- > >Gilles Melanson ViaNet Internet Solutions > >System Administrator 128 Larch St. Suite 301 > >gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8 > > > >"One World, One Web, One Program" > >- Microsoft Promotional Ad > >"Ein Reich, Ein Volk, Ein Fuhrer" > >- Adolf Hitler > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and 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. > -- Gilles Melanson ViaNet Internet Solutions System Administrator 128 Larch St. Suite 301 gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8 "One World, One Web, One Program" - Microsoft Promotional Ad "Ein Reich, Ein Volk, Ein Fuhrer" - Adolf Hitler - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

On Wed, 2 Sep 1998, Tim Patterson wrote: > Thanks to John, I resolved connecting a MP8/16 to a > Livingston Portmaster-2. These guys will make you custom cables and already have the pinouts as they have made me hundreds for the pm 25 and pm 2: Curtis Connections 441 East Bay Blvd. Provo, Utah 84606 (800) 877-9143 (801) 344-7155 FAX www.curtisconnections.com Scott Yergensen syergensen@curtisconnect.com (800)877-9143 ~~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ Jake Messinger, VP. ph:713-772-6690 Lucent Dealer AMS, Inc. fx:713-774-3498 Medical Billing 8300 Bissonnet #400 jake@ams.com , ICQ# 4403734 Internet Services Houston, Texas 77074 www.ams.com/~jake and Hardware Adjunct Professor University of Houston, CBA jake@uh.edu ~~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~

We sure would like to know what kind of fix this is... Is it register settings or is it actually in the v.90 code for the LTWinmodem? ============================================================================== 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, 10 Sep 1998, John Powell wrote: > The problems you (and many others) are seeing with LT Winmodems have been > duplicated here. We have a fix in the lab for the "endless handshake" > (just retrains over and over). We were able to make a timer a bit more > tolerant to accomodate them. > > But we are still trying to nail the disconnect issue that many are > reporting with that modem before we put any engineering code out. We are > able to duplicate it, but the root cause is elusive. > > JP > > > > > > Gilles Melanson <gilles@vianet.on.ca> on 09/10/98 10:13:26 AM > > Please respond to usr-tc@lists.xmission.com > > To: usr-tc@lists.xmission.com > cc: (John Powell/MW/US/3Com) > Subject: Re: (usr-tc) LTWinmodems and HiperDSP > > > > > > try using the extra setting "-V90=0" > > > > this disables V.90 ... -v90=1 enables it ... > > That likely won't be enough. I'd imagine that by default, they have v90 > enabled on these units. The problem is pretty much an endless handshake, > or a connection that gets dropped as soon as data gets tossed overtop of > it. Flakey, to say the least. > > /gm > > > -----Original Message----- > > From: Gilles Melanson <gilles@vianet.on.ca> > > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > > Date: Thursday, September 10, 1998 10:28 AM > > Subject: (usr-tc) LTWinmodems and HiperDSP > > > > > > >I've recently upgraded/taken out the quad cards I had here to put in > > >HiperARC and DSP chassis. I've had a rash of phone calls from users > > >with Lucent Tech v.90 LTWinmodems that are unable to connect, and I have > > >yet to find a working init string that'll enable them to connect. > > > > > >If anyone knows of any known issues with v90 (or non-56k) modem brands > and > > >their fixes for HiperDSPs, it'd be much appreciated. I've got a few > users > > >with this problem. > > > > > >Thanks. > > > > > >-- > > >Gilles Melanson ViaNet Internet Solutions > > >System Administrator 128 Larch St. Suite 301 > > >gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8 > > > > > >"One World, One Web, One Program" > > >- Microsoft Promotional Ad > > >"Ein Reich, Ein Volk, Ein Fuhrer" > > >- Adolf Hitler > > > > > > > > >- > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and 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. > > > > -- > Gilles Melanson ViaNet Internet Solutions > System Administrator 128 Larch St. Suite 301 > gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8 > > "One World, One Web, One Program" > - Microsoft Promotional Ad > "Ein Reich, Ein Volk, Ein Fuhrer" > - Adolf Hitler > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and 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. >

Right now we use time.nist.gov as an NTP server. Does anyone know of any other publically usable NTP servers? Brian Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Have I got a site for you... For everything NTP related, go check out http://www.clock.org. You'll find links to everything, including a list of public ntp servers. Most stratum 1 clocks request that you tell them that you're using them. The polite thing to do is to run one or two ntp servers (xntpd seems nice) at your site and have them slave off of a nearby primary and/or secondary(s). Then point all your other machines at your own servers. It's well worth it when you need to go around looking at logs of a related event on multiple hosts... Charles On Thu, 10 Sep 1998, Brian wrote: > Date: Thu, 10 Sep 1998 16:30:54 -0500 (CDT) > From: Brian <signal@shreve.net> > Reply-To: usr-tc@lists.xmission.com > To: USRobotics TC Mailing List <usr-tc@xmission.com> > Subject: (usr-tc) Secondary NTP needed > > Right now we use time.nist.gov as an NTP server. Does anyone know of any > other publically usable NTP servers? > > Brian > > > -------------------------------------------------------------------------- > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

Does anyone know what this error means and what can fix it? Sep 10 15:50:09 xxx At 15:49:57, Facility "IP", Level "COMMON":: ../../net/ip_ondemand.c<3934>: user_string_get failed, No more framed routes for user: ((bad status)) Sep 10 15:50:40 xxx At 15:50:28, Facility "Filter Manager Process", Level "COMMON":: FM: No RADIUS rules available for user_handle=48e002, status=554d650c These errors are showing up when users dialin.. Thanks... Andy Johnson Network Engineer ParaCom Technologies, Inc

Anyone heard any rumors of bundle prices or double-ups after the current specials run out Sept. 30? We're getting ready to expand and I'm wondering if there are better deals around the corner. Thanks, Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com

Getting at least firmware version 5.15 for the LT Winmodems helps a LOT. We've seen some that flat out wouldn't connect, period, and upgrading them to 5.20 fixed it. I think it's at www.digitan.com. Of course, if they can't get online in the first place, it's sorta hard for them to download the update... :) Mike Andrews (MA12) icq 6602506 -------------- mandrews@dcr.net Senior Systems/Network Administrator --- mandrews@termfrost.org Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "If Barbie is so popular, why do you have to buy her friends?..." On Thu, 10 Sep 1998, Gilles Melanson wrote: > I've recently upgraded/taken out the quad cards I had here to put in > HiperARC and DSP chassis. I've had a rash of phone calls from users > with Lucent Tech v.90 LTWinmodems that are unable to connect, and I have > yet to find a working init string that'll enable them to connect. > > If anyone knows of any known issues with v90 (or non-56k) modem brands and > their fixes for HiperDSPs, it'd be much appreciated. I've got a few users > with this problem. > > Thanks. > > -- > Gilles Melanson ViaNet Internet Solutions > System Administrator 128 Larch St. Suite 301 > gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8 > > "One World, One Web, One Program" > - Microsoft Promotional Ad > "Ein Reich, Ein Volk, Ein Fuhrer" > - Adolf Hitler > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Once upon a time Jamin Cummings shaped the electrons to say... >anyway ... my question is, does anyone out there know of any better >equipment? if not better, how about equaly as good, but without the Lucent PortMaster series - and since you've been using the NetServer you know the OS style, as 3Com/USR licensed it from Lucent/Livingston. Only the PM's version is newer, with more features - like OSPF. Free 30-day trial for new ISP users, give it a shot - can't hurt, right? -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

> I am having some problems setting the DTE interface on my Total Control. > Using the TCM, I can set the Interface to Packet Bus and save it, But when > I come back and look at the the settings, it has somehow returned to the > NIC settings. Are the relevant ports enabled on the NETserver? From memory, if they are, the modem will revert back to packet-bus. Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Brian, Check www.clock.org for a complete list. We use the following: clock.psu.edu navobs1.oar.net Jeff U>Right now we use time.nist.gov as an NTP server. Does anyone know of U>any other publically usable NTP servers? U>Brian U>---------------------------------------------------------------------- U>---- Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service U>Provider Network Administrator | Shreveport, Louisiana - U>http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual U>Domains, Storefronts, (318)222-2NET x 109 | Database/Web U>Integration, 56k, ISDN, T1 U>- U> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" U> with "unsubscribe usr-tc" in the body of the message. U> For information on digests or retrieving files and old messages send U> "help" to the same address. Do not use quotes in your message. CMPQwk 1.42 9999

On Thu, 10 Sep 1998, Johnson, Andy wrote: > Does anyone know what this error means and what can fix it? > > Sep 10 15:50:09 xxx At 15:49:57, Facility "IP", Level "COMMON":: > ../../net/ip_ondemand.c<3934>: user_string_get failed, No more framed routes > for user: ((bad status)) > This is not an error - It is a common facility, that basically means that a user has just connected and he has no framed routes in his radius profile. > Sep 10 15:50:40 xxx At 15:50:28, Facility "Filter Manager Process", Level > "COMMON":: FM: No RADIUS rules available for user_handle=48e002, > status=554d650c > This means that there is no filter rules for the user. In the syslog set what level is the syslog set to Common or Critical. Typically you must set it to critical, and these messages should not show up. But then again in certain version even when set to critical you will see this info. There is nothing to worry about these messages. krish > > These errors are showing up when users dialin.. > > Thanks... > > Andy Johnson > Network Engineer > ParaCom Technologies, 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. >

We will be putting a fix in our code for the HiPerDSP to patch around the issue. It appears the problem is on the LT side, but since we can just make the timer more tolerant on our side, we will. This is not a register, this is an internal timer in our code. The ultimate fix would be a fix in the LT code. As Mike Andrews mentions, there may be later code from LT that addresses this problem. We are trying to nail as many of the Rockwell and Lucent problems as we can. Regardless of whether they are problems in their code, problems in our code, or just "gray area" stuff in the spec, we are doing our best to get them resolved. We hope to get as many of these (at least what we can patch or fix on our side) as we can wrapped into an ER (Engineering Release) in the very near future. I do not want to put one out now just to fix the "infinite retrain" problem as that will only solve part of the problem. JP pferraro <pferraro@wna-linknet.com> on 09/10/98 02:47:54 PM Please respond to usr-tc@lists.xmission.com cc: usr-tc@lists.xmission.com We sure would like to know what kind of fix this is... Is it register settings or is it actually in the v.90 code for the LTWinmodem? =========================================================================== === 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, 10 Sep 1998, John Powell wrote: > The problems you (and many others) are seeing with LT Winmodems have been > duplicated here. We have a fix in the lab for the "endless handshake" > (just retrains over and over). We were able to make a timer a bit more > tolerant to accomodate them. > > But we are still trying to nail the disconnect issue that many are > reporting with that modem before we put any engineering code out. We are > able to duplicate it, but the root cause is elusive. > > JP > > > > > > Gilles Melanson <gilles@vianet.on.ca> on 09/10/98 10:13:26 AM > > Please respond to usr-tc@lists.xmission.com > > To: usr-tc@lists.xmission.com > cc: (John Powell/MW/US/3Com) > Subject: Re: (usr-tc) LTWinmodems and HiperDSP > > > > > > try using the extra setting "-V90=0" > > > > this disables V.90 ... -v90=1 enables it ... > > That likely won't be enough. I'd imagine that by default, they have v90 > enabled on these units. The problem is pretty much an endless handshake, > or a connection that gets dropped as soon as data gets tossed overtop of > it. Flakey, to say the least. > > /gm > > > -----Original Message----- > > From: Gilles Melanson <gilles@vianet.on.ca> > > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > > Date: Thursday, September 10, 1998 10:28 AM > > Subject: (usr-tc) LTWinmodems and HiperDSP > > > > > > >I've recently upgraded/taken out the quad cards I had here to put in > > >HiperARC and DSP chassis. I've had a rash of phone calls from users > > >with Lucent Tech v.90 LTWinmodems that are unable to connect, and I have > > >yet to find a working init string that'll enable them to connect. > > > > > >If anyone knows of any known issues with v90 (or non-56k) modem brands > and > > >their fixes for HiperDSPs, it'd be much appreciated. I've got a few > users > > >with this problem. > > > > > >Thanks. > > > > > >-- > > >Gilles Melanson ViaNet Internet Solutions > > >System Administrator 128 Larch St. Suite 301 > > >gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8 > > > > > >"One World, One Web, One Program" > > >- Microsoft Promotional Ad > > >"Ein Reich, Ein Volk, Ein Fuhrer" > > >- Adolf Hitler > > > > > > > > >- > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and 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. > > > > -- > Gilles Melanson ViaNet Internet Solutions > System Administrator 128 Larch St. Suite 301 > gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8 > > "One World, One Web, One Program" > - Microsoft Promotional Ad > "Ein Reich, Ein Volk, Ein Fuhrer" > - Adolf Hitler > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and 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.

>Getting at least firmware version 5.15 for the LT Winmodems helps a LOT. >We've seen some that flat out wouldn't connect, period, and upgrading them >to 5.20 fixed it. I think it's at www.digitan.com. Thanks Mike. That might be a little dangerous for the uninitiated. As LTs are customized to some degree for each OEM (at least the big guys) the code may not work in all modems and could cause a big problem restoring it back. I haven't tried personally, but the risk is high that a non-computer literate person might have serious problems trying to install generic code for a customized modem. I may be wrong, but it seems risky. >Of course, if they can't get online in the first place, it's sorta hard >for them to download the update... :) I know you were sorta kidding, but do note that adding "-V90=0" to the LT's init string should allow them to connect V.34 at least. I would interested in hearing from anyone that has problems with this, I connected 100% of the time using this. Obviously not a long-term solution, but it is sure better than not connecting at all or having to try several times. JP

You should really have a central NTP server that your inside clients peer off of. Don't point all of your routers and TC's to an outside server, it is all that efficient and it isn't friendly either. Most Ciscos can be a central NTP server, but I prefer just using xntpd on a UNIX box. Jeff Binkley said once upon a time: >Check www.clock.org for a complete list. We use the following: > >clock.psu.edu >navobs1.oar.net > > >Jeff > > >U>Right now we use time.nist.gov as an NTP server. Does anyone know of >U>any other publically usable NTP servers?

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of K Mitchell |Sent: Friday, September 11, 1998 1:57 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) Syslog Error | | |At 08:44 AM 9/11/98 -0500, you wrote: |>On Thu, 10 Sep 1998, Johnson, Andy wrote: |> |>> Does anyone know what this error means and what can fix it? |>> |>> Sep 10 15:50:09 xxx At 15:49:57, Facility "IP", Level "COMMON":: |>> ../../net/ip_ondemand.c<3934>: user_string_get failed, No more framed |routes |>> for user: ((bad status)) |>> |>This is not an error - It is a common facility, that basically means that |>a user has just connected and he has no framed routes in his radius profile. | |Geez, if routine messages contain statements like "user_string_get failed" |and "((bad status))", how in the hell are we supposed to recognize actual |problem messages? Do they say things like |"go_back_to_sleep_dear_everything's_fine" or "((chillin))"? | Thats why there is a log level.. Pay attention to UNUSUAL and CRITICAL not COMMON.. Use of the COMMON log level will just fill your drives with useless logs. -M

At 08:44 AM 9/11/98 -0500, you wrote: >On Thu, 10 Sep 1998, Johnson, Andy wrote: > >> Does anyone know what this error means and what can fix it? >> >> Sep 10 15:50:09 xxx At 15:49:57, Facility "IP", Level "COMMON":: >> ../../net/ip_ondemand.c<3934>: user_string_get failed, No more framed routes >> for user: ((bad status)) >> >This is not an error - It is a common facility, that basically means that >a user has just connected and he has no framed routes in his radius profile. Geez, if routine messages contain statements like "user_string_get failed" and "((bad status))", how in the hell are we supposed to recognize actual problem messages? Do they say things like "go_back_to_sleep_dear_everything's_fine" or "((chillin))"? Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

What is your phone number? Please send it to me I would like to talk to you and also get the manager on phone. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Fri, 11 Sep 1998, Kevin Benton wrote: > Well, Krish, it happened again. The support rep (whose voice I > recognized) told me to switch dip switches without asking me any questions > *AGAIN*. If memory serves me correctly, this is the same person who told > me to do this before when I ended up teaching them how to troubleshoot. > I'd like to tell you what case number it was but the person who told me > what case number I should use for it gave me the wrong case number. There > was no case number opened for the ticket up until that point. Here's what > happened... > > I needed help using PCSDL to fix an ARC that was basically lost. (Since, > I have fixed the problem). > > I called because I didn't have a way to download code to the ARC except > through the console, however, I could not get PCSDL to send the dmf file > to the ARC. I was calling to ask for the proper way to get PCSDL to send > the file to the ARC. > > I got to the female support rep whose name I do not know, I told the above > to... > > I began to read the parameters to her for PCSDL and she put me on hold for > about 5 minutes. When she came back, she asked me to read the parameters > again. I read "pcsdl -p2 -r9600" and then said "What's the rest?" > > She said "I need you to pull out your ARC and change switches for me." > I asked her why. She said she wanted me to change the baud rate. I just > about lost it. Why are support people telling me to mess around with > switches when it has absolutely nothing to do with the problem? I was > already talking to the card at 9600 before. Someone ought to put a sign > over all the beginner's desks - "If it ain't broke, don't fix it!" I > asked for one of my favorite people and she said he was probably at lunch. > At that point, she asked me why I wanted to talk to someone else. I was > not going to get into an argument with her. I said bye and hung up. > > What's worse is that when I called back to talk to a tech support manager, > the person I got to (because I intentionally didn't put in my case number > or contract number) told me that I had to have a case number if I talked > to an engineer. This is totally not true. (Explicitives not given). > When he told me that, I told him, okay, what's the case number. When I > went back to the web to look it up, the case number that person gave me > was for something totally unrelated to what I was talking about (above). > > Needless to say, I'm a litle hot about this entire deal (slight > understatement). I ended up leaving a voice mail for one of the support > managers and told him I never want to talk to that person again. > Unfortunately, I ended up giving him that case number before I checked it. > Well, needless to say, I'll have to leave it up to you to straighten it > out. It would be nice if one of your support managers would give me a > call and help me understand why things like that happen and what I am > doing wrong so I can prevent it from happening to me again. > > Kevin Benton > Network Engineer > SOTA Technolgies > > 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. >

Sir, I can't speak to your concerns about phone support but I would like to help you with your problem. You can not use PCSDL to flash a HiPer ARC. You will need to use Z modem transfer protocol. Follow the below procedures: 1. Connect to the console with Hyper Terminal and get command line access 2. type reboot 3. Wait for the first line of text after the HiPer ARC starts coming back up. (It will say something like Boot Prom version 1.15) 4. Imediately type this AT{Z} 5. If the HiPer ARC does not tell you to begin download now type it again or repeat the above steps. 6. Once you see begin download now go to the top of your Hyper terminal and click on Transfer/Send a File/browse and select the dmf file you wish to flash it with and click open. It's that simple. Hope this helps Kevin Benton <s1kevin@tims.net> on 09/11/98 04:03:02 PM Please respond to usr-tc@lists.xmission.com cc: (Brian McIntire/MW/US/3Com) Well, Krish, it happened again. The support rep (whose voice I recognized) told me to switch dip switches without asking me any questions *AGAIN*. If memory serves me correctly, this is the same person who told me to do this before when I ended up teaching them how to troubleshoot. I'd like to tell you what case number it was but the person who told me what case number I should use for it gave me the wrong case number. There was no case number opened for the ticket up until that point. Here's what happened... I needed help using PCSDL to fix an ARC that was basically lost. (Since, I have fixed the problem). I called because I didn't have a way to download code to the ARC except through the console, however, I could not get PCSDL to send the dmf file to the ARC. I was calling to ask for the proper way to get PCSDL to send the file to the ARC. I got to the female support rep whose name I do not know, I told the above to... I began to read the parameters to her for PCSDL and she put me on hold for about 5 minutes. When she came back, she asked me to read the parameters again. I read "pcsdl -p2 -r9600" and then said "What's the rest?" She said "I need you to pull out your ARC and change switches for me." I asked her why. She said she wanted me to change the baud rate. I just about lost it. Why are support people telling me to mess around with switches when it has absolutely nothing to do with the problem? I was already talking to the card at 9600 before. Someone ought to put a sign over all the beginner's desks - "If it ain't broke, don't fix it!" I asked for one of my favorite people and she said he was probably at lunch. At that point, she asked me why I wanted to talk to someone else. I was not going to get into an argument with her. I said bye and hung up. What's worse is that when I called back to talk to a tech support manager, the person I got to (because I intentionally didn't put in my case number or contract number) told me that I had to have a case number if I talked to an engineer. This is totally not true. (Explicitives not given). When he told me that, I told him, okay, what's the case number. When I went back to the web to look it up, the case number that person gave me was for something totally unrelated to what I was talking about (above). Needless to say, I'm a litle hot about this entire deal (slight understatement). I ended up leaving a voice mail for one of the support managers and told him I never want to talk to that person again. Unfortunately, I ended up giving him that case number before I checked it. Well, needless to say, I'll have to leave it up to you to straighten it out. It would be nice if one of your support managers would give me a call and help me understand why things like that happen and what I am doing wrong so I can prevent it from happening to me again. Kevin Benton Network Engineer SOTA Technolgies 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.

Well, Krish, it happened again. The support rep (whose voice I recognized) told me to switch dip switches without asking me any questions *AGAIN*. If memory serves me correctly, this is the same person who told me to do this before when I ended up teaching them how to troubleshoot. I'd like to tell you what case number it was but the person who told me what case number I should use for it gave me the wrong case number. There was no case number opened for the ticket up until that point. Here's what happened... I needed help using PCSDL to fix an ARC that was basically lost. (Since, I have fixed the problem). I called because I didn't have a way to download code to the ARC except through the console, however, I could not get PCSDL to send the dmf file to the ARC. I was calling to ask for the proper way to get PCSDL to send the file to the ARC. I got to the female support rep whose name I do not know, I told the above to... I began to read the parameters to her for PCSDL and she put me on hold for about 5 minutes. When she came back, she asked me to read the parameters again. I read "pcsdl -p2 -r9600" and then said "What's the rest?" She said "I need you to pull out your ARC and change switches for me." I asked her why. She said she wanted me to change the baud rate. I just about lost it. Why are support people telling me to mess around with switches when it has absolutely nothing to do with the problem? I was already talking to the card at 9600 before. Someone ought to put a sign over all the beginner's desks - "If it ain't broke, don't fix it!" I asked for one of my favorite people and she said he was probably at lunch. At that point, she asked me why I wanted to talk to someone else. I was not going to get into an argument with her. I said bye and hung up. What's worse is that when I called back to talk to a tech support manager, the person I got to (because I intentionally didn't put in my case number or contract number) told me that I had to have a case number if I talked to an engineer. This is totally not true. (Explicitives not given). When he told me that, I told him, okay, what's the case number. When I went back to the web to look it up, the case number that person gave me was for something totally unrelated to what I was talking about (above). Needless to say, I'm a litle hot about this entire deal (slight understatement). I ended up leaving a voice mail for one of the support managers and told him I never want to talk to that person again. Unfortunately, I ended up giving him that case number before I checked it. Well, needless to say, I'll have to leave it up to you to straighten it out. It would be nice if one of your support managers would give me a call and help me understand why things like that happen and what I am doing wrong so I can prevent it from happening to me again. Kevin Benton Network Engineer SOTA Technolgies E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

I wonder if the Female you are talking about is "Lei" ... When I get her I pray I go on hold then I just dump the call and call back hopeing to get someone else ... -----Original Message----- >Well, Krish, it happened again. The support rep (whose voice I >recognized) told me to switch dip switches without asking me any questions >*AGAIN*. If memory serves me correctly, this is the same person who told >me to do this before when I ended up teaching them how to troubleshoot. >I'd like to tell you what case number it was but the person who told me >what case number I should use for it gave me the wrong case number. There >was no case number opened for the ticket up until that point. Here's what >happened... > >I needed help using PCSDL to fix an ARC that was basically lost. (Since, >I have fixed the problem). > >I called because I didn't have a way to download code to the ARC except >through the console, however, I could not get PCSDL to send the dmf file >to the ARC. I was calling to ask for the proper way to get PCSDL to send >the file to the ARC. > >I got to the female support rep whose name I do not know, I told the above >to... > >I began to read the parameters to her for PCSDL and she put me on hold for >about 5 minutes. When she came back, she asked me to read the parameters >again. I read "pcsdl -p2 -r9600" and then said "What's the rest?" > >She said "I need you to pull out your ARC and change switches for me." >I asked her why. She said she wanted me to change the baud rate. I just >about lost it. Why are support people telling me to mess around with >switches when it has absolutely nothing to do with the problem? I was >already talking to the card at 9600 before. Someone ought to put a sign >over all the beginner's desks - "If it ain't broke, don't fix it!" I >asked for one of my favorite people and she said he was probably at lunch. >At that point, she asked me why I wanted to talk to someone else. I was >not going to get into an argument with her. I said bye and hung up. > >What's worse is that when I called back to talk to a tech support manager, >the person I got to (because I intentionally didn't put in my case number >or contract number) told me that I had to have a case number if I talked >to an engineer. This is totally not true. (Explicitives not given). >When he told me that, I told him, okay, what's the case number. When I >went back to the web to look it up, the case number that person gave me >was for something totally unrelated to what I was talking about (above). > >Needless to say, I'm a litle hot about this entire deal (slight >understatement). I ended up leaving a voice mail for one of the support >managers and told him I never want to talk to that person again. >Unfortunately, I ended up giving him that case number before I checked it. >Well, needless to say, I'll have to leave it up to you to straighten it >out. It would be nice if one of your support managers would give me a >call and help me understand why things like that happen and what I am >doing wrong so I can prevent it from happening to me again. > >Kevin Benton >Network Engineer >SOTA Technolgies > >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. >

Kevin Benton <s1kevin@tims.net> writes: > I needed help using PCSDL to fix an ARC that was basically lost. (Since, > I have fixed the problem). Well, PCSDL isn't related to the ARC at all - it's an SDL-2 based card (basically anything using a DMF file), which uses a Z-Modem console download as the alternative to the NMC based download. The PCSDL utility is for the older cards that use a SDL/NAC file combination. Note of course that you can often download new code to a card via the NMC even when the card is for other purposes unresponsive. As long as it's reflecting an operational management state via the NMC it should accept a download. But back to the console - the exact procedure should be in the ARC documentation, but in short - you boot the ARC, wait for the initial download prompt on the console (it'll only delay a few seconds, so you have to be quick), enter the sequence AT{Z} (or AT{Z{F}} if you want to format flash first), and then send the DMF file using Z-Modem. I think with the ARC that you can also just send the file using Z-Modem at the boot prompt, but the AT procedure works on both the ARC and the HDM. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Not to get into it too much in public, but the short of it is that if this is the same person I spoke with, she is much more of a harm than a help, and I am not exaggerating one bit. Terrible abuse of two things; the hold button (we're talking about cumulative times of more than two hours on one call), and the urge to "log into your chassis" to "look around" rather than ask questions. One of the worst experiences I've had... Not worth $3000. Check out case #77303, I believe she was the initial contact. C On Fri, 11 Sep 1998, Jamie Orzechowski wrote: > Date: Fri, 11 Sep 1998 17:49:14 -0400 > From: Jamie Orzechowski <mhz@recorder.ca> > Reply-To: usr-tc@lists.xmission.com > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Support Issues > > I wonder if the Female you are talking about is "Lei" ... When I get her I > pray I go on hold then I just dump the call and call back hopeing to get > someone else ... > > -----Original Message----- > From: Kevin Benton <s1kevin@tims.net> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Friday, September 11, 1998 5:08 PM > Subject: (usr-tc) Support Issues > > > >Well, Krish, it happened again. The support rep (whose voice I > >recognized) told me to switch dip switches without asking me any questions > >*AGAIN*. If memory serves me correctly, this is the same person who told > >me to do this before when I ended up teaching them how to troubleshoot. > >I'd like to tell you what case number it was but the person who told me > >what case number I should use for it gave me the wrong case number. There > >was no case number opened for the ticket up until that point. Here's what > >happened... > > > >I needed help using PCSDL to fix an ARC that was basically lost. (Since, > >I have fixed the problem). > > > >I called because I didn't have a way to download code to the ARC except > >through the console, however, I could not get PCSDL to send the dmf file > >to the ARC. I was calling to ask for the proper way to get PCSDL to send > >the file to the ARC. > > > >I got to the female support rep whose name I do not know, I told the above > >to... > > > >I began to read the parameters to her for PCSDL and she put me on hold for > >about 5 minutes. When she came back, she asked me to read the parameters > >again. I read "pcsdl -p2 -r9600" and then said "What's the rest?" > > > >She said "I need you to pull out your ARC and change switches for me." > >I asked her why. She said she wanted me to change the baud rate. I just > >about lost it. Why are support people telling me to mess around with > >switches when it has absolutely nothing to do with the problem? I was > >already talking to the card at 9600 before. Someone ought to put a sign > >over all the beginner's desks - "If it ain't broke, don't fix it!" I > >asked for one of my favorite people and she said he was probably at lunch. > >At that point, she asked me why I wanted to talk to someone else. I was > >not going to get into an argument with her. I said bye and hung up. > > > >What's worse is that when I called back to talk to a tech support manager, > >the person I got to (because I intentionally didn't put in my case number > >or contract number) told me that I had to have a case number if I talked > >to an engineer. This is totally not true. (Explicitives not given). > >When he told me that, I told him, okay, what's the case number. When I > >went back to the web to look it up, the case number that person gave me > >was for something totally unrelated to what I was talking about (above). > > > >Needless to say, I'm a litle hot about this entire deal (slight > >understatement). I ended up leaving a voice mail for one of the support > >managers and told him I never want to talk to that person again. > >Unfortunately, I ended up giving him that case number before I checked it. > >Well, needless to say, I'll have to leave it up to you to straighten it > >out. It would be nice if one of your support managers would give me a > >call and help me understand why things like that happen and what I am > >doing wrong so I can prevent it from happening to me again. > > > >Kevin Benton > >Network Engineer > >SOTA Technolgies > > > >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. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

Well, in Kevin's issue, she was trying to set the baud rate to 57600 instea= d of 9600 (I guess she is a new tech and does not know that you cannot do the pcsdl to the Hiper ARC)=2E Eventhough, I do not know what went on in the phone conversation, she was only trying to make your download easier and quicker=2E =20= ____________________Reply Separator____________________ Author: s1kevin@tims=2Enet Well, Krish, it happened again=2E The support rep (whose voice I recognized) told me to switch dip switches without asking me any questions *AGAIN*=2E If memory serves me correctly, this is the same person who told me to do this before when I ended up teaching them how to troubleshoot=2E I'd like to tell you what case number it was but the person who told me what case number I should use for it gave me the wrong case number=2E There was no case number opened for the ticket up until that point=2E Here's what happened=2E=2E=2E I needed help using PCSDL to fix an ARC that was basically lost=2E (Since, I have fixed the problem)=2E I called because I didn't have a way to download code to the ARC except through the console, however, I could not get PCSDL to send the dmf file to the ARC=2E I was calling to ask for the proper way to get PCSDL to send the file to the ARC=2E I got to the female support rep whose name I do not know, I told the above to=2E=2E=2E I began to read the parameters to her for PCSDL and she put me on hold for about 5 minutes=2E When she came back, she asked me to read the parameters again=2E I read "pcsdl -p2 -r9600" and then said "What's the rest?" She said "I need you to pull out your ARC and change switches for me=2E" I asked her why=2E She said she wanted me to change the baud rate=2E I just about lost it=2E Why are support people telling me to mess around with switches when it has absolutely nothing to do with the problem? I was already talking to the card at 9600 before=2E Someone ought to put a sign over all the beginner's desks - "If it ain't broke, don't fix it!" I asked for one of my favorite people and she said he was probably at lunch=2E At that point, she asked me why I wanted to talk to someone else=2E I was not going to get into an argument with her=2E I said bye and hung up=2E What's worse is that when I called back to talk to a tech support manager, the person I got to (because I intentionally didn't put in my case number or contract number) told me that I had to have a case number if I talked to an engineer=2E This is totally not true=2E (Explicitives not given)=2E When he told me that, I told him, okay, what's the case number=2E When I went back to the web to look it up, the case number that person gave me was for something totally unrelated to what I was talking about (above)=2E Needless to say, I'm a litle hot about this entire deal (slight understatement)=2E I ended up leaving a voice mail for one of the support managers and told him I never want to talk to that person again=2E Unfortunately, I ended up giving him that case number before I checked it=2E Well, needless to say, I'll have to leave it up to you to straighten it out=2E It would be nice if one of your support managers would give me a call and help me understand why things like that happen and what I am doing wrong so I can prevent it from happening to me again=2E Kevin Benton Network Engineer SOTA Technolgies E-Mail: s1kevin@tims=2Enet Web: http://users=2Esota-oh=2Ecom/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without=20= notice - To unsubscribe to usr-tc, send an email to "majordomo@xmission=2Ecom" with "unsubscribe usr-tc" in the body of the message=2E For information on digests or retrieving files and old messages send "help" to the same address=2E Do not use quotes in your message=2E

On Fri, 11 Sep 1998 jcusmano@westcon.com wrote: > Well, in Kevin's issue, she was trying to set the baud rate to 57600 instead of > 9600 (I guess she is a new tech and does not know that you cannot do the pcsdl > to the Hiper ARC). Regardless of whether she's new (I had her about 5 or 6 months ago), she's breaking one of the rules of tech support which is "Tell the user why you are asking them to do things". Especially if it involves powering off the chassis or a pulling a card, or flipping a dip switch. It's bad practice not to do so, and it's also a bit rude. I can see a *user* making the mistake of not knowing that pcsdl doesn't work with the ARC, but there's no excuse for a *tech-support* person to not know this. Especially when the caller is paying upwards of $3000/yr. to get that support. > Eventhough, I do not know what went on in the phone > conversation, she was only trying to make your download easier and quicker. Right, you assumed that, and maybe she did too, but the user wasn't told that and was left wondering "does she know what she's doing?". I am wondering that too. If I ever have problems using pcsdl on a non-Hiper card, my first reaction is to go to a lower speed rather than a higher speed... I think I'm missing your point here. As a 3com reseller, shouldn't you be getting on the phone with your 3com associates and asking about the sorry state of these expensive support contracts that you sell instead of making excuses for a first-level support team that is mostly clueless but occasionally dangerous??? Which relationship is more important, the one with a customer or the one with your suppliers??? Our contract has just expired, and we're just getting over the shock of the price increases and the "must buy" rule for all chassis. This is a very serious issue. 3com wants us to pay more than Cisco/Ascend/Livingston or anyone else I can think of charges for support that is generally suboptimal. For the money they want I'd expect on site service. Charles > > > > > ____________________Reply Separator____________________ > Subject: (usr-tc) Support Issues > Author: s1kevin@tims.net > Date: 9/11/98 5:06 PM > > Well, Krish, it happened again. The support rep (whose voice I > recognized) told me to switch dip switches without asking me any questions > *AGAIN*. If memory serves me correctly, this is the same person who told > me to do this before when I ended up teaching them how to troubleshoot. > I'd like to tell you what case number it was but the person who told me > what case number I should use for it gave me the wrong case number. There > was no case number opened for the ticket up until that point. Here's what > happened... > > I needed help using PCSDL to fix an ARC that was basically lost. (Since, > I have fixed the problem). > > I called because I didn't have a way to download code to the ARC except > through the console, however, I could not get PCSDL to send the dmf file > to the ARC. I was calling to ask for the proper way to get PCSDL to send > the file to the ARC. > > I got to the female support rep whose name I do not know, I told the above > to... > > I began to read the parameters to her for PCSDL and she put me on hold for > about 5 minutes. When she came back, she asked me to read the parameters > again. I read "pcsdl -p2 -r9600" and then said "What's the rest?" > > She said "I need you to pull out your ARC and change switches for me." > I asked her why. She said she wanted me to change the baud rate. I just > about lost it. Why are support people telling me to mess around with > switches when it has absolutely nothing to do with the problem? I was > already talking to the card at 9600 before. Someone ought to put a sign > over all the beginner's desks - "If it ain't broke, don't fix it!" I > asked for one of my favorite people and she said he was probably at lunch. > At that point, she asked me why I wanted to talk to someone else. I was > not going to get into an argument with her. I said bye and hung up. > > What's worse is that when I called back to talk to a tech support manager, > the person I got to (because I intentionally didn't put in my case number > or contract number) told me that I had to have a case number if I talked > to an engineer. This is totally not true. (Explicitives not given). > When he told me that, I told him, okay, what's the case number. When I > went back to the web to look it up, the case number that person gave me > was for something totally unrelated to what I was talking about (above). > > Needless to say, I'm a litle hot about this entire deal (slight > understatement). I ended up leaving a voice mail for one of the support > managers and told him I never want to talk to that person again. > Unfortunately, I ended up giving him that case number before I checked it. > Well, needless to say, I'll have to leave it up to you to straighten it > out. It would be nice if one of your support managers would give me a > call and help me understand why things like that happen and what I am > doing wrong so I can prevent it from happening to me again. > > Kevin Benton > Network Engineer > SOTA Technolgies > > 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. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

On Tue, 1 Sep 1998, Tim Patterson wrote: > Trying to hook a Modem Pool 16 to a Portmaster 2 > Does anyone know the pin outs and or other > issues. Did you get my message with the pinouts and the info on Curtis who can make those cables for you: Curtis Connections 441 East Bay Blvd. Provo, Utah 84606 (800) 877-9143 (801) 344-7155 FAX www.curtisconnections.com Scott Yergensen syergensen@curtisconnect.com (800)877-9143 ~~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ Jake Messinger, VP. ph:713-772-6690 Lucent Dealer AMS, Inc. fx:713-774-3498 Medical Billing 8300 Bissonnet #400 jake@ams.com , ICQ# 4403734 Internet Services Houston, Texas 77074 www.ams.com/~jake and Hardware Adjunct Professor University of Houston, CBA jake@uh.edu ~~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~

i just upgraded to 3.8.1, and so far so good.. probably the smoothest transition i've seen yet, since in the past i've seen tables get mangled and other bizarre things happen, settings getting changed and lost.. i think usr has finally done things right this time, they've certainly put a lot of changes into this release and apparently tested it thoroughly.. (not sure about any changes in udp performance yet) just trying to put out a good word on this list.. it needs it :) - lv

I just downgraded one chassis from 3.8.1 to 3.7.24 and quake pings are not great! ... very strange ... 3.8.1 caused terrible pings and the game locked up ... -----Original Message----- >i just upgraded to 3.8.1, and so far so good.. probably the smoothest >transition i've seen yet, since in the past i've seen tables get mangled >and other bizarre things happen, settings getting changed and lost.. > >i think usr has finally done things right this time, they've certainly put >a lot of changes into this release and apparently tested it thoroughly.. >(not sure about any changes in udp performance yet) > >just trying to put out a good word on this list.. it needs it :) > >- lv > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

I'm sure I'm overlooking something obvious, but I just set up a Dual PRI/NetServer chassis with 12 quads and I can't get it to take analog calls. I'm to the point where it answers and the modem led goes amber, but the modem doesn't attempt to establish a connection - just dead silence. I'm running the latest and greatest code on everything but the netserver - it doesn't have 3.8.1 yet. The quads are single-sided. I should also mention that if I plug the PRI into a HiPER DSP/ARC setup it takes calls just fine so it doesn't appear to be a provisioning problem. Thanks for any clues, Mike Stankavich CTO, NorFab/ISP, Inc. Portland OR mike@ethergate.com

Are any of you billing your customers through Email? In the past we have always billed our customers through snail mail, but we have grown (but still very small compared to most of you) to the point that this is becoming expensive to do. We would like to bill by email, but can't afford some of the $2000.00 programs out there. We do not bill by usage so that is not a factor. Anyone have a suggestion that would fit the pocket book of a new but growing ISP. Credit cards are not an option where we are at. (To long to explain why) Many Thanks!! Greg Owens Magnolia InterNet Services

G. Owens was heard to say: >Are any of you billing your customers through Email? In the past we have >always billed our customers through snail mail, but we have grown (but still >very small compared to most of you) to the point that this is becoming >expensive to do. We would like to bill by email, but can't afford some of >the $2000.00 programs out there. We do not bill by usage so that is not a >factor. Anyone have a suggestion that would fit the pocket book of a new >but growing ISP. Credit cards are not an option where we are at. (To long to >explain why) Many Thanks!! > Greg Owens > Magnolia InterNet Services I'd recommend just rolling your own... Depending on what features you want, it could be a simple bit of perl. Basically, you just need some sort of mapping between login ID and email address for the bill and a rate schedule. (I once started to roll this into the thing I run monthly to generate usage totals, but the accounting department too offense to me putting their entire department into a few lines in a perl script -- actuall awk at the time.) --Ricky

We use ISPTRAK which is available at http://www.cyberacs.com . The software works out very well for us, and is very economical. At 10:09 PM 9/12/98 -0500, you wrote: >Are any of you billing your customers through Email? In the past we have >always billed our customers through snail mail, but we have grown (but still >very small compared to most of you) to the point that this is becoming >expensive to do. We would like to bill by email, but can't afford some of >the $2000.00 programs out there. We do not bill by usage so that is not a >factor. Anyone have a suggestion that would fit the pocket book of a new >but growing ISP. Credit cards are not an option where we are at. (To long to >explain why) Many Thanks!! > Greg Owens > Magnolia InterNet Services > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > 73's John Campbell - KC4LWI Owner - Roanoke Virginia Net http://www.roava.net mailto:sparky@roava.net

At 10:09 PM 9/12/98 -0500, you wrote: >Are any of you billing your customers through Email? In the past we have >always billed our customers through snail mail, but we have grown (but still >very small compared to most of you) to the point that this is becoming >expensive to do. We would like to bill by email, but can't afford some of >the $2000.00 programs out there. We do not bill by usage so that is not a >factor. Anyone have a suggestion that would fit the pocket book of a new >but growing ISP. Credit cards are not an option where we are at. (To long to >explain why) Many Thanks!! We've been using NTPaymaster, http://www.imagen.net/paymaster/ and have had no problem generating email invoices. As a whole, I would have given NTPaymaster maybe a mid-to-high 5 out of 10 as far as workibility and our satisfaction with it, but, since their new release that includes 'Crystal Reports', they've jumped to a strong 8+. Not bad for under a grand. I had tried a cheaper option, specifically ISPTrak, but gave up on it after 3-4 weeks of incessant problems and poor support. You do get what you pay for and, as important as accurate billing is, you're far better to spend extra for a solid program than to pick up the Dollar Store knock-off. Just my $.02 Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

On Sun, 13 Sep 1998, K Mitchell wrote: [SNIP] > weeks of incessant problems and poor support. You do get what you pay for > and, as important as accurate billing is, you're far better to spend extra > for a solid program than to pick up the Dollar Store knock-off. > I agree. Spend the money now and you won't regret it later! Actually if you don't have the money up front, there are lot's of lease companies which allow you to lease software. That way you can afford to get something good and pay as you go. Also your lease payments are considered an operating expense and tax deductible (talk to your tax person). Make sure you get a $1 buy out or something at the end of the term so you own it. FWIW, we use Platypus and we are quite happy with it. Good support and very flexible. If you want more info, mail me privately. Eric ============================================================================= Eric Merkel | URL: www.metalink.net | Local Access in MetaLink Technologies, Inc | EMail: merkel@defnet.com | Defiance, Fulton, 419-782-3472 Ext. 4 | Sales: 1-888-999-8002 | Henry, & Williams Co. =============================================================================

David Bolen said: : Mark R. Lindsey said: : > I'm absolutely sure about these details: Our lines are all provisioned : > ESF/B8ZS, they're all ground start trunks, and the CO's switch is : > currently a 5ESS. (That's being replaced by a DMS100 soon.) : : It's the ground start part that is probably hurting you. : : There is no official way to "busy out" a ground start circuit. Ugh, ugh. We moved earlier this year, and I had all of our new lines provisioned as ground-start trunks per USR's documentation on the cht1 card. Having them changed would be painful. : If, however, you're finding this happen even with single channels, : it's also possible that the channel bank simply isn't reflecting the : off hook status of it's DS0 back over the analog pair into the switch, : so the switch never knows that the DS0 is supposed to be avoided. That's been one of my theories. If we can get them re-provisioned, should they be E&M Type II? Thanks for the information, of course. I'll contact The Beast to find what I can about potential problems with their channel banks.

Mark, PRI is obviously the most desireable, but your suggestion of E&M type 2 is definitely second best. I don't know if you plan to do V.90, but E&Ms are almost always full-digital (no channel banks) and will allow for x2/V.90 as well as better V.34 performance (no quantization noise from the A/D). Note, if the switch is analog you won't have the option. GS and LS are the only options as a Channel bank is necessary to digitize them and I don't know of any E&M channel banks (not to say that would be impossible, just never heard of one in use). JP PS. Could you let me know what doc recommended GS? If it is true I would like to get it changed. The provisioning doc I know of states we support GS and LS, but recommends E&M type 2 or PRI (and requires them for PCM modem use). mark@vielle.datasys.net (Mark R. Lindsey) on 09/13/98 03:31:24 PM Please respond to usr-tc@lists.xmission.com cc: (John Powell/MW/US/3Com) David Bolen said: : Mark R. Lindsey said: : > I'm absolutely sure about these details: Our lines are all provisioned : > ESF/B8ZS, they're all ground start trunks, and the CO's switch is : > currently a 5ESS. (That's being replaced by a DMS100 soon.) : : It's the ground start part that is probably hurting you. : : There is no official way to "busy out" a ground start circuit. Ugh, ugh. We moved earlier this year, and I had all of our new lines provisioned as ground-start trunks per USR's documentation on the cht1 card. Having them changed would be painful. : If, however, you're finding this happen even with single channels, : it's also possible that the channel bank simply isn't reflecting the : off hook status of it's DS0 back over the analog pair into the switch, : so the switch never knows that the DS0 is supposed to be avoided. That's been one of my theories. If we can get them re-provisioned, should they be E&M Type II? Thanks for the information, of course. I'll contact The Beast to find what I can about potential problems with their channel banks. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

mark@vielle.datasys.net (Mark R. Lindsey) writes: > If we can get them re-provisioned, should they be E&M Type II? That's my favorite for any channelized T1 circuits. In all but a few rare cases, such circuits are also trunk side (and digital all the way into the switch), so they are also just fine for x2/V.90, which ground start will almost never support. In most cases, the difference users receive with CT1-E&M circuits at the server side versus PRI is negligible. Of course, part of the reason that we also had a lot of ground start was economical. CAPs/CLECs often have good tariff pricing for E&M, but the original LECs often have that bundled with other services (such as DID) which can drive the price up significantly when compared to a ground start scenario. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

On Fri, 11 Sep 1998, John Powell wrote: > >Getting at least firmware version 5.15 for the LT Winmodems helps a LOT. > >We've seen some that flat out wouldn't connect, period, and upgrading them > >to 5.20 fixed it. I think it's at www.digitan.com. > > Thanks Mike. That might be a little dangerous for the uninitiated. As LTs > are customized to some degree for each OEM (at least the big guys) the code > may not work in all modems and could cause a big problem restoring it back. > I haven't tried personally, but the risk is high that a non-computer > literate person might have serious problems trying to install generic code > for a customized modem. I may be wrong, but it seems risky. Interesting, because I've heard the opposite -- even though lots of people OEM the modem, the firmware is (so I've heard) "one size fits all". We did use the digitan 5.20 code in whatever modem HP puts in Pavillions, and it worked fine. > >Of course, if they can't get online in the first place, it's sorta hard > >for them to download the update... :) > > I know you were sorta kidding, but do note that adding "-V90=0" to the LT's > init string should allow them to connect V.34 at least. I would interested > in hearing from anyone that has problems with this, I connected 100% of the > time using this. Obviously not a long-term solution, but it is sure better > than not connecting at all or having to try several times. Good point. Mike Andrews (MA12) icq 6602506 -------------- mandrews@dcr.net Senior Systems/Network Administrator --- mandrews@termfrost.org Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "If Barbie is so popular, why do you have to buy her friends?..."

>Interesting, because I've heard the opposite -- even though lots of people >OEM the modem, the firmware is (so I've heard) "one size fits all". We >did use the digitan 5.20 code in whatever modem HP puts in Pavillions, and >it worked fine. You are probably right for most of them, but I would still be careful. Definitely have the old code, from the proper vendor, around just in case you need to reverse the process. I am going to try the digitran code for kicks, but I know I would not suggest that my mom try. But, of course, she has a Courier (nothing but the best for mom). JP

We use Ibiller. You actually get to talk to Bob Czopek who wrote the software when he is home. You can do a demo by downloading a trial version from his web site http://www.interbiller.com Mario M. Bustamante, President AccessPro Communications Inc. Miami, Florida http://www.AccessPro.net mario@accesspro.net _______________________________________________ > > Are any of you billing your customers through Email? > In the past we have > always billed our customers through snail mail, but we > have grown (but still > very small compared to most of you) to the point that > this is becoming > expensive to do. We would like to bill by email, but > can't afford some of > the $2000.00 programs out there. We do not bill by > usage so that is not a > factor. Anyone have a suggestion that would fit the > pocket book of a new > but growing ISP. Credit cards are not an option where > we are at. (To long to > explain why) Many Thanks!! > Greg Owens > Magnolia InterNet Services > > >

NTPayMaster V3.0 is being released this week, with support for MS SQL Server and MS Access, as you choose. It is of course capable of email billing in beautiful HTML if desired. Your customers can view their usage via the Web using the provided TimeOnline utility. Even VoIP billing is included for a limited time. We also offer two payments over 60 days (full price is $890US for unlimited users)and as USR-TC users ourselves, we can probably help you out in many ways. Nothing is more critical to your success than a power billing program, and none offer more plans than NTPayMaster. Demo at www.imagen.net Best Regards; � Dwight Jones, CEO djones@imagen.net <mailto:djones@imagen.net> Imagen Communications Inc. http://www.imagen.net Information Architects TM > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of G. Owens > Sent: Saturday, September 12, 1998 8:09 PM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) email billing > > > Are any of you billing your customers through Email? In the past we have > always billed our customers through snail mail, but we have grown > (but still > very small compared to most of you) to the point that this is becoming > expensive to do. We would like to bill by email, but can't afford some of > the $2000.00 programs out there. We do not bill by usage so that is not a > factor. Anyone have a suggestion that would fit the pocket book of a new > but growing ISP. Credit cards are not an option where we are at. > (To long to > explain why) Many Thanks!! > Greg Owens > Magnolia InterNet Services > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

What kind of a response is that? Do you agree that 3Com's policy is great or needs some improvement? We are the ones that are buying the TC hubs, some undoubtedly from your firm from participants here. I know I bought my 3Com support agreement from your firm. I pay for support on one chassis and we don't use it for the following reasons. Its difficult to get a human on line and actually address our problem in a timely manner. If this mail list did not exist, I have no idea where some of us would be tech support wise. If 3Com wants to sell lots of support contracts, they should find a way to end our discourse here. I still have equipment that functions most of the time without much for me to address. That part is good. There is a serious problem with the netserver card that 3Com refuses to address. Finally they come up with a plan where I can spend $3200 per chassis to upgrade to the Hypercard and hope that fixes quake lag. There have been times when we had a problem and called at 5pm on a Friday only to be told that someone would call back. A couple of hours later we called again only to be informed that someone would be paged and it would be a while til someone could call us back. We called again Sat morning and were put on hold for a long time. In the meantime, we got our answer here. Nice 24/7 coverage, eh? I don't like to pay for maintenance agreements but I DO like to think I'm getting something of value for the money that I am laying out. We bought the agreement because 3Com demanded that we do that in order to enable the x2 in the hub. So I bought it and rationalized it was a decent insurance policy too. The parts in the hubs are expensive a la carte. I have a problem with the netserver card and a support agreement covering it. Why won't 3Com replace my card under the agreement? Our experience with the service side has been miserable. We choose not to use it so I guess I agree with your statement below. Do I feel warm and fuzzy about it? You decide. At 09:10 AM 9/14/98 -0500, you wrote: >If you feel like this, you shouldn't be asking for technical support. > > > > >___________________Reply Separator____________________ >Subject: Re:(usr-tc) Support Issues >Author: spork@inch.com >Date: 9/11/98 8:03 PM > >On Fri, 11 Sep 1998 jcusmano@westcon.com wrote: > >> Well, in Kevin's issue, she was trying to set the baud rate to 57600 instead of >> 9600 (I guess she is a new tech and does not know that you cannot do the pcsdl >> to the Hiper ARC). > >Regardless of whether she's new (I had her about 5 or 6 months ago), she's >breaking one of the rules of tech support which is "Tell the user why you >are asking them to do things". Especially if it involves powering off the >chassis or a pulling a card, or flipping a dip switch. It's bad practice >not to do so, and it's also a bit rude. > >I can see a *user* making the mistake of not knowing that pcsdl doesn't >work with the ARC, but there's no excuse for a *tech-support* person to >not know this. Especially when the caller is paying upwards of $3000/yr. >to get that support. > >> Eventhough, I do not know what went on in the phone >> conversation, she was only trying to make your download easier and quicker. > >Right, you assumed that, and maybe she did too, but the user wasn't told >that and was left wondering "does she know what she's doing?". I am >wondering that too. If I ever have problems using pcsdl on a non-Hiper >card, my first reaction is to go to a lower speed rather than a higher >speed... > >I think I'm missing your point here. As a 3com reseller, shouldn't you be >getting on the phone with your 3com associates and asking about the sorry >state of these expensive support contracts that you sell instead of making >excuses for a first-level support team that is mostly clueless but >occasionally dangerous??? Which relationship is more important, the one >with a customer or the one with your suppliers??? > >Our contract has just expired, and we're just getting over the shock of >the price increases and the "must buy" rule for all chassis. This is a >very serious issue. 3com wants us to pay more than >Cisco/Ascend/Livingston or anyone else I can think of charges for support >that is generally suboptimal. For the money they want I'd expect on site >service. > >Charles > >> > > > > ____________________Reply Separator____________________ >> Subject: (usr-tc) Support Issues >> Author: s1kevin@tims.net >> Date: 9/11/98 5:06 PM >> > Well, Krish, it happened again. The support rep (whose voice I >> recognized) told me to switch dip switches without asking me any questions >> *AGAIN*. If memory serves me correctly, this is the same person who told >> me to do this before when I ended up teaching them how to troubleshoot. >> I'd like to tell you what case number it was but the person who told me >> what case number I should use for it gave me the wrong case number. There >> was no case number opened for the ticket up until that point. Here's what >> happened... >> > I needed help using PCSDL to fix an ARC that was basically lost. (Since, >> I have fixed the problem). >> > I called because I didn't have a way to download code to the ARC except >> through the console, however, I could not get PCSDL to send the dmf file >> to the ARC. I was calling to ask for the proper way to get PCSDL to send >> the file to the ARC. >> > I got to the female support rep whose name I do not know, I told the above >> to... >> > I began to read the parameters to her for PCSDL and she put me on hold for >> about 5 minutes. When she came back, she asked me to read the parameters >> again. I read "pcsdl -p2 -r9600" and then said "What's the rest?" >> > She said "I need you to pull out your ARC and change switches for me." >> I asked her why. She said she wanted me to change the baud rate. I just >> about lost it. Why are support people telling me to mess around with >> switches when it has absolutely nothing to do with the problem? I was >> already talking to the card at 9600 before. Someone ought to put a sign >> over all the beginner's desks - "If it ain't broke, don't fix it!" I >> asked for one of my favorite people and she said he was probably at lunch. >> At that point, she asked me why I wanted to talk to someone else. I was >> not going to get into an argument with her. I said bye and hung up. >> > What's worse is that when I called back to talk to a tech support manager, >> the person I got to (because I intentionally didn't put in my case number >> or contract number) told me that I had to have a case number if I talked >> to an engineer. This is totally not true. (Explicitives not given). >> When he told me that, I told him, okay, what's the case number. When I >> went back to the web to look it up, the case number that person gave me >> was for something totally unrelated to what I was talking about (above). >> > Needless to say, I'm a litle hot about this entire deal (slight >> understatement). I ended up leaving a voice mail for one of the support >> managers and told him I never want to talk to that person again. >> Unfortunately, I ended up giving him that case number before I checked it. >> Well, needless to say, I'll have to leave it up to you to straighten it >> out. It would be nice if one of your support managers would give me a >> call and help me understand why things like that happen and what I am >> doing wrong so I can prevent it from happening to me again. >> > Kevin Benton >> Network Engineer >> SOTA Technolgies >> > 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. >> > > > - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > >=-----------------= = | Charles Sprickman Internet Channel | >| INCH System Administration Team (212)243-5200 | >| spork@inch.com access@inch.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. > > ______________________________________________________ Thanks, Greg Coffey 307-234-5443 Fax 307-234-5446 CoffeyNet v.90 56k Access for Casper & Douglas 142 S. Center St. Casper, WY 82601 http://www.coffey.com

Struggle with a mp 8/16 with X2. The dialup connection speeds are running 14.4 to 19.2, but with multi-techs, on the same trunk group, getting 31.4+ Current init is at&f1 Any suggestions? Thank you, Tim Patterson Harborside Internet

If you feel like this, you shouldn't be asking for technical support=2E ___________________Reply Separator____________________ Author: spork@inch=2Ecom On Fri, 11 Sep 1998 jcusmano@westcon=2Ecom wrote: > Well, in Kevin's issue, she was trying to set the baud rate to 57600=20= instead of > 9600 (I guess she is a new tech and does not know that you cannot do the=20= pcsdl > to the Hiper ARC)=2E Regardless of whether she's new (I had her about 5 or 6 months ago), she's breaking one of the rules of tech support which is "Tell the user why you are asking them to do things"=2E Especially if it involves powering off the chassis or a pulling a card, or flipping a dip switch=2E It's bad practice not to do so, and it's also a bit rude=2E I can see a *user* making the mistake of not knowing that pcsdl doesn't work with the ARC, but there's no excuse for a *tech-support* person to not know this=2E Especially when the caller is paying upwards of $3000/yr=2E to get that support=2E > Eventhough, I do not know what went on in the phone > conversation, she was only trying to make your download easier and quicker=2E=20= Right, you assumed that, and maybe she did too, but the user wasn't told that and was left wondering "does she know what she's doing?"=2E I am wondering that too=2E If I ever have problems using pcsdl on a non-Hiper card, my first reaction is to go to a lower speed rather than a higher speed=2E=2E=2E I think I'm missing your point here=2E As a 3com reseller, shouldn't you be getting on the phone with your 3com associates and asking about the sorry state of these expensive support contracts that you sell instead of making excuses for a first-level support team that is mostly clueless but occasionally dangerous??? Which relationship is more important, the one with a customer or the one with your suppliers??? Our contract has just expired, and we're just getting over the shock of the price increases and the "must buy" rule for all chassis=2E This is a very serious issue=2E 3com wants us to pay more than Cisco/Ascend/Livingston or anyone else I can think of charges for support that is generally suboptimal=2E For the money they want I'd expect on site service=2E Charles > > > > > ____________________Reply Separator____________________ > Subject: (usr-tc) Support Issues > Author: s1kevin@tims=2Enet > Date: 9/11/98 5:06 PM > > Well, Krish, it happened again=2E The support rep (whose voice I > recognized) told me to switch dip switches without asking me any questions > *AGAIN*=2E If memory serves me correctly, this is the same person who told > me to do this before when I ended up teaching them how to troubleshoot=2E > I'd like to tell you what case number it was but the person who told me > what case number I should use for it gave me the wrong case number=2E There > was no case number opened for the ticket up until that point=2E Here's what > happened=2E=2E=2E > > I needed help using PCSDL to fix an ARC that was basically lost=2E (Since, > I have fixed the problem)=2E > > I called because I didn't have a way to download code to the ARC except > through the console, however, I could not get PCSDL to send the dmf file > to the ARC=2E I was calling to ask for the proper way to get PCSDL to send > the file to the ARC=2E > > I got to the female support rep whose name I do not know, I told the above > to=2E=2E=2E > > I began to read the parameters to her for PCSDL and she put me on hold for > about 5 minutes=2E When she came back, she asked me to read the parameters > again=2E I read "pcsdl -p2 -r9600" and then said "What's the rest?" > > She said "I need you to pull out your ARC and change switches for me=2E" > I asked her why=2E She said she wanted me to change the baud rate=2E I just > about lost it=2E Why are support people telling me to mess around with > switches when it has absolutely nothing to do with the problem? I was > already talking to the card at 9600 before=2E Someone ought to put a sign > over all the beginner's desks - "If it ain't broke, don't fix it!" I > asked for one of my favorite people and she said he was probably at lunch=2E > At that point, she asked me why I wanted to talk to someone else=2E I was > not going to get into an argument with her=2E I said bye and hung up=2E > > What's worse is that when I called back to talk to a tech support manager, > the person I got to (because I intentionally didn't put in my case number > or contract number) told me that I had to have a case number if I talked > to an engineer=2E This is totally not true=2E (Explicitives not given)=2E > When he told me that, I told him, okay, what's the case number=2E When I > went back to the web to look it up, the case number that person gave me > was for something totally unrelated to what I was talking about (above)=2E > > Needless to say, I'm a litle hot about this entire deal (slight > understatement)=2E I ended up leaving a voice mail for one of the support > managers and told him I never want to talk to that person again=2E > Unfortunately, I ended up giving him that case number before I checked it=2E > Well, needless to say, I'll have to leave it up to you to straighten it > out=2E It would be nice if one of your support managers would give me a > call and help me understand why things like that happen and what I am > doing wrong so I can prevent it from happening to me again=2E > > Kevin Benton > Network Engineer > SOTA Technolgies > > E-Mail: s1kevin@tims=2Enet > Web: http://users=2Esota-oh=2Ecom/~s1kevin/ > Unsolicited advertisements processing fee: $50 subject to change without=20= notice > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission=2Ecom" > with "unsubscribe usr-tc" in the body of the message=2E > For information on digests or retrieving files and old messages send > "help" to the same address=2E Do not use quotes in your message=2E > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission=2Ecom" > with "unsubscribe usr-tc" in the body of the message=2E > For information on digests or retrieving files and old messages send > "help" to the same address=2E Do not use quotes in your message=2E > =3D-----------------=3D =3D | Charles=20= Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch=2Ecom access@inch=2Ecom | =3D =3D----------------=3D - To unsubscribe to usr-tc, send an email to "majordomo@xmission=2Ecom" with "unsubscribe usr-tc" in the body of the message=2E For information on digests or retrieving files and old messages send "help" to the same address=2E Do not use quotes in your message=2E

Thus spake jcusmano@westcon.com >If you feel like this, you shouldn't be asking for technical support=2E Pardon me? Feel like what? Like we're not getting decent support for the thousands of dollars that we're paying for support contracts? I pay less money for *6* Cisco router support contracts (including 12 hour advanced replacement and onsite service if necessary) than I do for *software only* support from 3Com for *one* TC...we're talking, no onsite service at all, no hardware replacement at all, crappy tech support, buggy code, and all... And you know what? If I was going to drop any support contract, it would be the support contract on the 3Com stuff because despite the support contract on the 3Com stuff, I *still* have to use my Cisco boxes to make up for the myriad defficiencies in the 3Com equipment (routing protocol support for one). >___________________Reply Separator____________________ >Subject: Re:(usr-tc) Support Issues >Author: spork@inch=2Ecom >Date: 9/11/98 8:03 PM >On Fri, 11 Sep 1998 jcusmano@westcon=2Ecom wrote: >> Well, in Kevin's issue, she was trying to set the baud rate to 57600=20= >instead of >> 9600 (I guess she is a new tech and does not know that you cannot do the=20= >pcsdl >> to the Hiper ARC)=2E >Regardless of whether she's new (I had her about 5 or 6 months ago), she's >breaking one of the rules of tech support which is "Tell the user why you >are asking them to do things"=2E Especially if it involves powering off the >chassis or a pulling a card, or flipping a dip switch=2E It's bad practice >not to do so, and it's also a bit rude=2E >I can see a *user* making the mistake of not knowing that pcsdl doesn't >work with the ARC, but there's no excuse for a *tech-support* person to >not know this=2E Especially when the caller is paying upwards of $3000/yr=2E >to get that support=2E >> Eventhough, I do not know what went on in the phone >> conversation, she was only trying to make your download easier and quicker=2E=20= >Right, you assumed that, and maybe she did too, but the user wasn't told >that and was left wondering "does she know what she's doing?"=2E I am >wondering that too=2E If I ever have problems using pcsdl on a non-Hiper >card, my first reaction is to go to a lower speed rather than a higher >speed=2E=2E=2E >I think I'm missing your point here=2E As a 3com reseller, shouldn't you be >getting on the phone with your 3com associates and asking about the sorry >state of these expensive support contracts that you sell instead of making >excuses for a first-level support team that is mostly clueless but >occasionally dangerous??? Which relationship is more important, the one >with a customer or the one with your suppliers??? >Our contract has just expired, and we're just getting over the shock of >the price increases and the "must buy" rule for all chassis=2E This is a >very serious issue=2E 3com wants us to pay more than >Cisco/Ascend/Livingston or anyone else I can think of charges for support >that is generally suboptimal=2E For the money they want I'd expect on site >service=2E >Charles >> > > > > ____________________Reply Separator____________________ >> Subject: (usr-tc) Support Issues >> Author: s1kevin@tims=2Enet >> Date: 9/11/98 5:06 PM >> > Well, Krish, it happened again=2E The support rep (whose voice I >> recognized) told me to switch dip switches without asking me any questions >> *AGAIN*=2E If memory serves me correctly, this is the same person who told >> me to do this before when I ended up teaching them how to troubleshoot=2E >> I'd like to tell you what case number it was but the person who told me >> what case number I should use for it gave me the wrong case number=2E There >> was no case number opened for the ticket up until that point=2E Here's what >> happened=2E=2E=2E >> > I needed help using PCSDL to fix an ARC that was basically lost=2E (Since, >> I have fixed the problem)=2E >> > I called because I didn't have a way to download code to the ARC except >> through the console, however, I could not get PCSDL to send the dmf file >> to the ARC=2E I was calling to ask for the proper way to get PCSDL to send >> the file to the ARC=2E >> > I got to the female support rep whose name I do not know, I told the above >> to=2E=2E=2E >> > I began to read the parameters to her for PCSDL and she put me on hold for >> about 5 minutes=2E When she came back, she asked me to read the parameters >> again=2E I read "pcsdl -p2 -r9600" and then said "What's the rest?" >> > She said "I need you to pull out your ARC and change switches for me=2E" >> I asked her why=2E She said she wanted me to change the baud rate=2E I just >> about lost it=2E Why are support people telling me to mess around with >> switches when it has absolutely nothing to do with the problem? I was >> already talking to the card at 9600 before=2E Someone ought to put a sign >> over all the beginner's desks - "If it ain't broke, don't fix it!" I >> asked for one of my favorite people and she said he was probably at lunch=2E >> At that point, she asked me why I wanted to talk to someone else=2E I was >> not going to get into an argument with her=2E I said bye and hung up=2E >> > What's worse is that when I called back to talk to a tech support manager, >> the person I got to (because I intentionally didn't put in my case number >> or contract number) told me that I had to have a case number if I talked >> to an engineer=2E This is totally not true=2E (Explicitives not given)=2E >> When he told me that, I told him, okay, what's the case number=2E When I >> went back to the web to look it up, the case number that person gave me >> was for something totally unrelated to what I was talking about (above)=2E >> > Needless to say, I'm a litle hot about this entire deal (slight >> understatement)=2E I ended up leaving a voice mail for one of the support >> managers and told him I never want to talk to that person again=2E >> Unfortunately, I ended up giving him that case number before I checked it=2E >> Well, needless to say, I'll have to leave it up to you to straighten it >> out=2E It would be nice if one of your support managers would give me a >> call and help me understand why things like that happen and what I am >> doing wrong so I can prevent it from happening to me again=2E >> > Kevin Benton >> Network Engineer >> SOTA Technolgies >> > E-Mail: s1kevin@tims=2Enet >> Web: http://users=2Esota-oh=2Ecom/~s1kevin/ >> Unsolicited advertisements processing fee: $50 subject to change without=20= >notice >> > > - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission=2Ecom" >> with "unsubscribe usr-tc" in the body of the message=2E >> For information on digests or retrieving files and old messages send >> "help" to the same address=2E Do not use quotes in your message=2E >> > > > - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission=2Ecom" >> with "unsubscribe usr-tc" in the body of the message=2E >> For information on digests or retrieving files and old messages send >> "help" to the same address=2E Do not use quotes in your message=2E >> >=3D-----------------=3D =3D | Charles=20= >Sprickman Internet Channel | >| INCH System Administration Team (212)243-5200 | >| spork@inch=2Ecom access@inch=2Ecom | >=3D =3D----------------=3D >- >To unsubscribe to usr-tc, send an email to "majordomo@xmission=2Ecom" >with "unsubscribe usr-tc" in the body of the message=2E >For information on digests or retrieving files and old messages send >"help" to the same address=2E Do not use quotes in your message=2E >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Mon, 14 Sep 1998 jcusmano@westcon.com wrote: > If you feel like this, you shouldn't be asking for technical support. What are you talking about? Because I think the USR support contracts are the worst value in the industry I'm not entitled to support? Let me go make some annotations to our Rolodex under "Westcon"... Charles > > > > > ___________________Reply Separator____________________ > Subject: Re:(usr-tc) Support Issues > Author: spork@inch.com > Date: 9/11/98 8:03 PM > > On Fri, 11 Sep 1998 jcusmano@westcon.com wrote: > > > Well, in Kevin's issue, she was trying to set the baud rate to 57600 instead of > > 9600 (I guess she is a new tech and does not know that you cannot do the pcsdl > > to the Hiper ARC). > > Regardless of whether she's new (I had her about 5 or 6 months ago), she's > breaking one of the rules of tech support which is "Tell the user why you > are asking them to do things". Especially if it involves powering off the > chassis or a pulling a card, or flipping a dip switch. It's bad practice > not to do so, and it's also a bit rude. > > I can see a *user* making the mistake of not knowing that pcsdl doesn't > work with the ARC, but there's no excuse for a *tech-support* person to > not know this. Especially when the caller is paying upwards of $3000/yr. > to get that support. > > > Eventhough, I do not know what went on in the phone > > conversation, she was only trying to make your download easier and quicker. > > Right, you assumed that, and maybe she did too, but the user wasn't told > that and was left wondering "does she know what she's doing?". I am > wondering that too. If I ever have problems using pcsdl on a non-Hiper > card, my first reaction is to go to a lower speed rather than a higher > speed... > > I think I'm missing your point here. As a 3com reseller, shouldn't you be > getting on the phone with your 3com associates and asking about the sorry > state of these expensive support contracts that you sell instead of making > excuses for a first-level support team that is mostly clueless but > occasionally dangerous??? Which relationship is more important, the one > with a customer or the one with your suppliers??? > > Our contract has just expired, and we're just getting over the shock of > the price increases and the "must buy" rule for all chassis. This is a > very serious issue. 3com wants us to pay more than > Cisco/Ascend/Livingston or anyone else I can think of charges for support > that is generally suboptimal. For the money they want I'd expect on site > service. > > Charles > > > > > > > ____________________Reply Separator____________________ > > Subject: (usr-tc) Support Issues > > Author: s1kevin@tims.net > > Date: 9/11/98 5:06 PM > > > Well, Krish, it happened again. The support rep (whose voice I > > recognized) told me to switch dip switches without asking me any questions > > *AGAIN*. If memory serves me correctly, this is the same person who told > > me to do this before when I ended up teaching them how to troubleshoot. > > I'd like to tell you what case number it was but the person who told me > > what case number I should use for it gave me the wrong case number. There > > was no case number opened for the ticket up until that point. Here's what > > happened... > > > I needed help using PCSDL to fix an ARC that was basically lost. (Since, > > I have fixed the problem). > > > I called because I didn't have a way to download code to the ARC except > > through the console, however, I could not get PCSDL to send the dmf file > > to the ARC. I was calling to ask for the proper way to get PCSDL to send > > the file to the ARC. > > > I got to the female support rep whose name I do not know, I told the above > > to... > > > I began to read the parameters to her for PCSDL and she put me on hold for > > about 5 minutes. When she came back, she asked me to read the parameters > > again. I read "pcsdl -p2 -r9600" and then said "What's the rest?" > > > She said "I need you to pull out your ARC and change switches for me." > > I asked her why. She said she wanted me to change the baud rate. I just > > about lost it. Why are support people telling me to mess around with > > switches when it has absolutely nothing to do with the problem? I was > > already talking to the card at 9600 before. Someone ought to put a sign > > over all the beginner's desks - "If it ain't broke, don't fix it!" I > > asked for one of my favorite people and she said he was probably at lunch. > > At that point, she asked me why I wanted to talk to someone else. I was > > not going to get into an argument with her. I said bye and hung up. > > > What's worse is that when I called back to talk to a tech support manager, > > the person I got to (because I intentionally didn't put in my case number > > or contract number) told me that I had to have a case number if I talked > > to an engineer. This is totally not true. (Explicitives not given). > > When he told me that, I told him, okay, what's the case number. When I > > went back to the web to look it up, the case number that person gave me > > was for something totally unrelated to what I was talking about (above). > > > Needless to say, I'm a litle hot about this entire deal (slight > > understatement). I ended up leaving a voice mail for one of the support > > managers and told him I never want to talk to that person again. > > Unfortunately, I ended up giving him that case number before I checked it. > > Well, needless to say, I'll have to leave it up to you to straighten it > > out. It would be nice if one of your support managers would give me a > > call and help me understand why things like that happen and what I am > > doing wrong so I can prevent it from happening to me again. > > > Kevin Benton > > Network Engineer > > SOTA Technolgies > > > 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. > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > =-----------------= = | Charles Sprickman Internet Channel | > | INCH System Administration Team (212)243-5200 | > | spork@inch.com access@inch.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. > =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

I one of the older total control racks with the 4M Netserver that we enabled RIP version 2 on. The problem I seem to be having with it now is while it's broadcasting the mask information correctly it's not announcing the propper IP block, e.g. when I do a sho route on the TC it reports 192.168.10.208/27 and yet I see the same announcement on my Cisco as 192.168.10.0/27. Needless to say, this is a huge problem. Anyone seen this before? Is there any trick to setting up RIP v2 on a TC other than set ripv2 on? Peter Stemwedel Network Engineer InterAccess Co. petes@interaccess.com 168 N. Clinton (312) 496-4694 Office Chicago, IL 60661 (312) 496-4499 FAX

: PS. Could you let me know what doc recommended GS? If it is true I would : like to get it changed. The provisioning doc I know of states we support : GS and LS, but recommends E&M type 2 or PRI (and requires them for PCM : modem use). I read about GS vs LS signalling in the Single/Dual T1 Card (186) Reference; t1all/t1ref186.pdf on the CD.

On Mon, 14 Sep 1998 jcusmano@westcon.com wrote: > Date: Mon, 14 Sep 1998 9:49:27 -0500 > From: jcusmano@westcon.com > To: s1kevin@tims.net > Subject: Re[2]: Re[2]:(usr-tc) Support Issues > > Whatever, but rebooting the chassis and reseating the cards are troubleshooting > procedures. Take it from me, I also give phone support for these Total Control > Hubs and it is not easy work. > Being this paranoid makes it more difficult for us Total Control techs. You may want to check with Westcon to see if they want you representing them the way you're coming across. We left Westcon a *LONG* time ago in part due to the attitude I'm getting now from you. It's all part of what we call "follow through" which, according to a survey I read recently, is the number one reason which makes or breaks a sale to 73% of the buying public. What I'm hearing from you is that you don't want customers to be customers and expect us to want to know what we need all the time, always have time to read 500-5,000 page manuals before calling for support. Give me a break. Yes, power cycling is part of the troubleshooting process, however, when you're talking about resetting 25%-100% of an area's phone line capacity, it should never be the first thing to "try." Helping customers understand how the equipment works is an essential part of "good" technical support. Remember that people who pay for support, especially at the rate of $3,000 / chassis / year are going to demand a lot. It makes sense. 3Com demands a very high price for support. Customers should expect to get their money's worth. Kevin "Just another 3Com product owner" Benton Network Engineer SOTA Technologies E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

: e.g. when I do a sho route on the TC it reports : 192.168.10.208/27 and yet I see the same announcement on my Cisco as : 192.168.10.0/27. Needless to say, this is a huge problem. Anyone seen : this before? Is there any trick to setting up RIP v2 on a TC other than : set ripv2 on? Sorry -- I haven't seen that. My Netservers regularly quite announcing RIPv2, though. That gets a little old.

> FWIW, we use Platypus and we are quite happy with it. Good support and > very flexible. If you want more info, mail me privately. > > Eric > We use Platypus as well, 5 star product. > ============================================================================= > Eric Merkel | URL: www.metalink.net | Local Access in > MetaLink Technologies, Inc | EMail: merkel@defnet.com | Defiance, Fulton, > 419-782-3472 Ext. 4 | Sales: 1-888-999-8002 | Henry, & Williams Co. > ============================================================================= > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

On Mon, 14 Sep 1998 jcusmano@westcon.com wrote: > If you feel like this, you shouldn't be asking for technical support. What? Just what are you talking about? > > > > > ___________________Reply Separator____________________ > Subject: Re:(usr-tc) Support Issues > Author: spork@inch.com > Date: 9/11/98 8:03 PM > > On Fri, 11 Sep 1998 jcusmano@westcon.com wrote: > > > Well, in Kevin's issue, she was trying to set the baud rate to 57600 instead of > > 9600 (I guess she is a new tech and does not know that you cannot do the pcsdl > > to the Hiper ARC). > > Regardless of whether she's new (I had her about 5 or 6 months ago), she's > breaking one of the rules of tech support which is "Tell the user why you > are asking them to do things". Especially if it involves powering off the > chassis or a pulling a card, or flipping a dip switch. It's bad practice > not to do so, and it's also a bit rude. > > I can see a *user* making the mistake of not knowing that pcsdl doesn't > work with the ARC, but there's no excuse for a *tech-support* person to > not know this. Especially when the caller is paying upwards of $3000/yr. > to get that support. > > > Eventhough, I do not know what went on in the phone > > conversation, she was only trying to make your download easier and quicker. > > Right, you assumed that, and maybe she did too, but the user wasn't told > that and was left wondering "does she know what she's doing?". I am > wondering that too. If I ever have problems using pcsdl on a non-Hiper > card, my first reaction is to go to a lower speed rather than a higher > speed... > > I think I'm missing your point here. As a 3com reseller, shouldn't you be > getting on the phone with your 3com associates and asking about the sorry > state of these expensive support contracts that you sell instead of making > excuses for a first-level support team that is mostly clueless but > occasionally dangerous??? Which relationship is more important, the one > with a customer or the one with your suppliers??? > > Our contract has just expired, and we're just getting over the shock of > the price increases and the "must buy" rule for all chassis. This is a > very serious issue. 3com wants us to pay more than > Cisco/Ascend/Livingston or anyone else I can think of charges for support > that is generally suboptimal. For the money they want I'd expect on site > service. > > Charles > > > > > > > ____________________Reply Separator____________________ > > Subject: (usr-tc) Support Issues > > Author: s1kevin@tims.net > > Date: 9/11/98 5:06 PM > > > Well, Krish, it happened again. The support rep (whose voice I > > recognized) told me to switch dip switches without asking me any questions > > *AGAIN*. If memory serves me correctly, this is the same person who told > > me to do this before when I ended up teaching them how to troubleshoot. > > I'd like to tell you what case number it was but the person who told me > > what case number I should use for it gave me the wrong case number. There > > was no case number opened for the ticket up until that point. Here's what > > happened... > > > I needed help using PCSDL to fix an ARC that was basically lost. (Since, > > I have fixed the problem). > > > I called because I didn't have a way to download code to the ARC except > > through the console, however, I could not get PCSDL to send the dmf file > > to the ARC. I was calling to ask for the proper way to get PCSDL to send > > the file to the ARC. > > > I got to the female support rep whose name I do not know, I told the above > > to... > > > I began to read the parameters to her for PCSDL and she put me on hold for > > about 5 minutes. When she came back, she asked me to read the parameters > > again. I read "pcsdl -p2 -r9600" and then said "What's the rest?" > > > She said "I need you to pull out your ARC and change switches for me." > > I asked her why. She said she wanted me to change the baud rate. I just > > about lost it. Why are support people telling me to mess around with > > switches when it has absolutely nothing to do with the problem? I was > > already talking to the card at 9600 before. Someone ought to put a sign > > over all the beginner's desks - "If it ain't broke, don't fix it!" I > > asked for one of my favorite people and she said he was probably at lunch. > > At that point, she asked me why I wanted to talk to someone else. I was > > not going to get into an argument with her. I said bye and hung up. > > > What's worse is that when I called back to talk to a tech support manager, > > the person I got to (because I intentionally didn't put in my case number > > or contract number) told me that I had to have a case number if I talked > > to an engineer. This is totally not true. (Explicitives not given). > > When he told me that, I told him, okay, what's the case number. When I > > went back to the web to look it up, the case number that person gave me > > was for something totally unrelated to what I was talking about (above). > > > Needless to say, I'm a litle hot about this entire deal (slight > > understatement). I ended up leaving a voice mail for one of the support > > managers and told him I never want to talk to that person again. > > Unfortunately, I ended up giving him that case number before I checked it. > > Well, needless to say, I'll have to leave it up to you to straighten it > > out. It would be nice if one of your support managers would give me a > > call and help me understand why things like that happen and what I am > > doing wrong so I can prevent it from happening to me again. > > > Kevin Benton > > Network Engineer > > SOTA Technolgies > > > 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. > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > =-----------------= = | Charles Sprickman Internet Channel | > | INCH System Administration Team (212)243-5200 | > | spork@inch.com access@inch.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. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

On Mon, 14 Sep 1998, Peter Stemwedel wrote: > I one of the older total control racks with the 4M Netserver that we > enabled RIP version 2 on. The problem I seem to be having with it now is > while it's broadcasting the mask information correctly it's not announcing > the propper IP block, e.g. when I do a sho route on the TC it reports > 192.168.10.208/27 and yet I see the same announcement on my Cisco as > 192.168.10.0/27. Needless to say, this is a huge problem. Anyone seen > this before? Is there any trick to setting up RIP v2 on a TC other than > set ripv2 on? For a detailed explaination on how to get this to work, see www.shreve.net/tcs but basically you want "no auto-summary" on the router turned on and a few other things: ! router rip version 2 timers basic 30 30 2 60 300 passive-interface Serial0/0.1 network 208.206.76.0 no auto-summary > > > > Peter Stemwedel > Network Engineer > InterAccess Co. petes@interaccess.com > 168 N. Clinton (312) 496-4694 Office > Chicago, IL 60661 (312) 496-4499 FAX > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

> You may want to check with Westcon to see if they want you representing > them the way you're coming across. We left Westcon a *LONG* time ago in I agree. Westcon has tried to sell us support contracts, yet they have been posting quite a few "trivial" questions to the list lately......I generally prefer my tech support contracts to be held with those more cluefull than I. > part due to the attitude I'm getting now from you. It's all part of what > we call "follow through" which, according to a survey I read recently, is > the number one reason which makes or breaks a sale to 73% of the buying > public. What I'm hearing from you is that you don't want customers to be > customers and expect us to want to know what we need all the time, always > have time to read 500-5,000 page manuals before calling for support. Give > me a break. Yes, power cycling is part of the troubleshooting process, > however, when you're talking about resetting 25%-100% of an area's phone > line capacity, it should never be the first thing to "try." Helping > customers understand how the equipment works is an essential part of > "good" technical support. Remember that people who pay for support, > especially at the rate of $3,000 / chassis / year are going to demand a > lot. It makes sense. 3Com demands a very high price for support. > Customers should expect to get their money's worth. > > Kevin "Just another 3Com product owner" Benton > Network Engineer > SOTA Technologies > > 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. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Is there any way that we can have a slight change on the SRO tracking screen? It'd be nice to know with a warranty/repair SRO a bit more than whether or not it's been shipped back to us. It would be really nice if the description of what's happening with the card while it's at 3Com or once it's in-route back to its owner that what was fixed is posted to the SRO tracking screen. Kevin E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

> If you feel like this, you shouldn't be asking for technical support. Excuse me? So, if i'm paying for support, and I feel I'm not getting the quality of service that I deserve (and get from other vendors), I should just roll over and forget it? Not bloody likely. Unbelievable. ...and you sell this stuff? Regards, Bob Purdon, Technical Manager, Southern Internet Services.

> I *still* have to use my Cisco boxes to make up for the myriad > defficiencies in the 3Com equipment (routing protocol support for > one). Ditto here - we're having to redistribute RIPv2 into OSPF because the NETserver *still* doesn't do OSPF. Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Never seen this before, but we cannot dial into a particular NETServer with ANY isdn dial equipment. Before a few days ago all seemed well. I am willing to believe a telco issue as nothing has changed on our end. When looking at the sh isdn screen, all we see is the 64k-v120 connection and the NETserver sitting at the USERNAME prompt. (ISDN calls are being terminated at the netserver) Any ideas? ========================== Installed over 18 months with no ISDN issues. U.S. Robotics Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.7.24 Build date: Dec 31 1997 Build time: 13:12:45 Network Interface Card: Ethernet & Frame Relay Combination (26) ISDN Interface Card : MUNICH32 (4) Packet Bus Circuit : Enhanced Marshall Morgan Internet Doorway, Inc (aka NETDOOR) http://www.netdoor.com 601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Marshall Morgan |Sent: Tuesday, September 15, 1998 10:03 AM |To: 'usr-tc@lists.xmission.com' |Subject: (usr-tc) ISDN Dialup trouble on NETserver. | | |Never seen this before, but we cannot dial into a particular NETServer with ANY |isdn dial equipment. Before a few days ago all seemed well. I am willing to |believe a telco issue as nothing has changed on our end. | |When looking at the sh isdn screen, all we see is the 64k-v120 connection and |the NETserver sitting at the USERNAME prompt. (ISDN calls are being terminated |at the netserver) | |Any ideas? | To rule out a problem with your Munich board, change the termination to the Quads instead of the NS.. Have you looked at your PRI card stats for errors, etc?? -M

On Tuesday, September 15, 1998 10:18 AM, Mike Wronski [SMTP:mike@coredump.ae.usr.com] wrote: > > To rule out a problem with your Munich board, change the termination to the > Quads > instead of the NS.. Have you looked at your PRI card stats for errors, etc?? We can try that but we already changed the NETserver out and still same effect. Anything else we can look at? Marshall Morgan Internet Doorway, Inc (aka NETDOOR) http://www.netdoor.com 601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838

I was wondering if anyone read the article in Telecommunications on Mega-Deals. A sentence from the article: "However, the companies in the most trouble over the next few years are second-tier players such as Cabletron and 3Com, if they remains independent, analysts said. 'They are structurally sommed as independent organizations becuase in a few years they can't still be generalized providers of enterprise data networking equipment'." The article was basically about the mergers going on: Lucent/Summa Four, Nortel/Bay, Alcatel/DSC, Tellabs/Ciena, etc. Brian Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

No, but according to CNNfn, 3Com is expecting to post record profits for the current period. And 3Com Stock is up based on rumours Intel is going to buy them out. http://biz.yahoo.com/finance/external/cbsm/*http://cbs.marketwatch.com/archi ve/19980915/news/current/coms.htx?dist=yhoo&source=htx/yhoo >I was wondering if anyone read the article in Telecommunications on >Mega-Deals. A sentence from the article: > >"However, the companies in the most trouble over the next few years are >second-tier players such as Cabletron and 3Com, if they remains >independent, analysts said. 'They are structurally sommed as independent >organizations becuase in a few years they can't still be generalized >providers of enterprise data networking equipment'." > >The article was basically about the mergers going on: Lucent/Summa Four, >Nortel/Bay, Alcatel/DSC, Tellabs/Ciena, etc. > >Brian > > >-------------------------------------------------------------------------- >Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider >Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ >signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, >(318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 was heard to say: >"However, the companies in the most trouble over the next few years are >second-tier players such as Cabletron and 3Com, if they remains >independent, analysts said. 'They are structurally sommed as independent >organizations becuase in a few years they can't still be generalized >providers of enterprise data networking equipment'." > >The article was basically about the mergers going on: Lucent/Summa Four, >Nortel/Bay, Alcatel/DSC, Tellabs/Ciena, etc. I think they've forgotten a few things... namely the 3Com/USR merger. While that does not make 3Com own of the big telco system providers. But then, lucent, nortel, nor the rest of those companies make network cards and pcmcia toys either. 3Com is spread across some rather dispersed markets. I don't see 3Com going away anytime soon. Of course, the carrier services division needs to go rent a clue for awhile to get their act together. --Ricky

Just one of the obvious... Is the "Maximum Active B-Channels" at the bottom of Show Glob set to a decent number? (As opposed to zero) Is it just dropping ISDN calls, or is it also dropping analog calls? >Never seen this before, but we cannot dial into a particular NETServer with ANY >isdn dial equipment. -snip-

We had the same issue, we had to move this setting to the individual user entry in Radius, instead of inside the Default user entry. -Frank -----Original Message----- >OK, I'm *still* having problems with this. Someone check me and make sure >I'm not doing something stupid or insane. > >We have two NETservers and an ARC in service. Our DEFAULT entry in Radius >looks like this: > >DEFAULT Auth-Type = System > Port-Limit = 1, > Session-Timeout = 43200, > Idle-Timeout = 1800, > User-Service-Type = Framed-User, > Framed-Protocol = PPP, > Framed-Address = 255.255.255.254, > Framed-Netmask = 255.255.255.255, > Framed-Routing = Listen, > Framed-Compression = Van-Jacobsen-TCP-IP, > Framed-MTU = 596, > Framed-Filter-Id = "dialup" > >With this entry, if someone attempts to bring up a 128K ISDN connection, >the NETserver logs "max session count reached on this bundle". Changing >port-limit to 2 allows them to do it. In other words, it works like it's >supposed to. :) > >The ARC, however, allows them to bring up a 128K connection with >port-limit set to 1. This is Not A Good Thing(tm). > >Searching through some previous responses to this question, it was >suggested using the VSA Max_Channels (0x9802) instead of the standard >Port-Count. Fine, except for the minor detail that my Radius server >doesn't grok 3com VSA's correctly. > >And even if it did, what affect would that have on the NETserver? > >Does ANYONE have this actually working in a mixed Netserver + ARC >environment, with or without VSA support in your Radius server? Any >suggestions on how to fix my default entry above? > >This brings me to a bug report. > >Feeling brave, I attempted to hack up my (Livingston) Radius server to >handle VSA's on authentication packets. (I've already hacked it up >successfully to log VSA's in accounting packets.) I goofed up somehow and >sent a trashed response, and the ARC *rebooted*, knocking quite a few >people offline. OUCH! And it rebooted repeatedly, every time it got a >response packet, until I finally figured out what the hell was happening >and put my old Radius server back online. MORE OUCH. Methinks there >needs to be more error checking in the ARC code.... I mean, sure it >wouldn't have happened if I had written clean code, but that's a pretty >rotten way to handle corrupt packets. > >Not being real thrilled about the idea of paying out the nose for a >support contract, I suppose I'm forever stuck with this bug too. > > >Mike Andrews (MA12) icq 6602506 -------- mandrews@termfrost.org >VP 'n' Systems/Network Administrator --------- mandrews@dcr.net >Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ >"If Barbie is so popular, why do you have to buy her friends?..." > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

FYI for everyone... We have an NMC which normally looses the ability to route its own data to a class C other than its own on the LAN. Example: The NMC is 209.190.81.xxx. The lan has 209.190.80 - 209.190.82. When we boot the card, all IP's on the LAN can talk to the NMC. The router can talk to the NMC. Ip's talking through the router can talk to the NMC. After roughly an hour, the NMC looses the ability to talk to 80 and 82 on the same LAN. The router talks to all IP's on the LAN, and all IP's except that NMC talk to other IP's on the LAN. The card has been moved to a different IP on the same C as it was before, and that didn't help. We also replaced the card with another NMC and that *did* help. When we set the defective card back up, on the same class C but on a different chassis, the problem continued to follow the defective card. We are now SRO'ing the card to be replaced. If anyone else has the same problem, please let me know. This is for version 5.5.1 through 5.5.5 of the NMC. Kevin Benton Network Engineer SOTA Technologies E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

Can you send me a snoop trace or tcpdump of the packet that causes the reboot? And what version of code were you using? As for what will a NS do with the VSA for MAX Channels.. It will ignore it.. You can have both in your DEFAULT entry and it will for for HARC and NS. -M |-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Andrews |Sent: Tuesday, September 15, 1998 5:05 PM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) Preventing multi-channel connections on ARC 4.0.30 | | |OK, I'm *still* having problems with this. Someone check me and make sure |I'm not doing something stupid or insane. | |We have two NETservers and an ARC in service. Our DEFAULT entry in Radius |looks like this: | |DEFAULT Auth-Type = System | Port-Limit = 1, | Session-Timeout = 43200, | Idle-Timeout = 1800, | User-Service-Type = Framed-User, | Framed-Protocol = PPP, | Framed-Address = 255.255.255.254, | Framed-Netmask = 255.255.255.255, | Framed-Routing = Listen, | Framed-Compression = Van-Jacobsen-TCP-IP, | Framed-MTU = 596, | Framed-Filter-Id = "dialup" | |With this entry, if someone attempts to bring up a 128K ISDN connection, |the NETserver logs "max session count reached on this bundle". Changing |port-limit to 2 allows them to do it. In other words, it works like it's |supposed to. :) | |The ARC, however, allows them to bring up a 128K connection with |port-limit set to 1. This is Not A Good Thing(tm). | |Searching through some previous responses to this question, it was |suggested using the VSA Max_Channels (0x9802) instead of the standard |Port-Count. Fine, except for the minor detail that my Radius server |doesn't grok 3com VSA's correctly. | |And even if it did, what affect would that have on the NETserver? | |Does ANYONE have this actually working in a mixed Netserver + ARC |environment, with or without VSA support in your Radius server? Any |suggestions on how to fix my default entry above? | |This brings me to a bug report. | |Feeling brave, I attempted to hack up my (Livingston) Radius server to |handle VSA's on authentication packets. (I've already hacked it up |successfully to log VSA's in accounting packets.) I goofed up somehow and |sent a trashed response, and the ARC *rebooted*, knocking quite a few |people offline. OUCH! And it rebooted repeatedly, every time it got a |response packet, until I finally figured out what the hell was happening |and put my old Radius server back online. MORE OUCH. Methinks there |needs to be more error checking in the ARC code.... I mean, sure it |wouldn't have happened if I had written clean code, but that's a pretty |rotten way to handle corrupt packets. | |Not being real thrilled about the idea of paying out the nose for a |support contract, I suppose I'm forever stuck with this bug too. | | |Mike Andrews (MA12) icq 6602506 -------- mandrews@termfrost.org |VP 'n' Systems/Network Administrator --------- mandrews@dcr.net |Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ |"If Barbie is so popular, why do you have to buy her friends?..." | | |- | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" | with "unsubscribe usr-tc" in the body of the message. | For information on digests or retrieving files and old messages send | "help" to the same address. Do not use quotes in your message. |

OK, I'm *still* having problems with this. Someone check me and make sure I'm not doing something stupid or insane. We have two NETservers and an ARC in service. Our DEFAULT entry in Radius looks like this: DEFAULT Auth-Type = System Port-Limit = 1, Session-Timeout = 43200, Idle-Timeout = 1800, User-Service-Type = Framed-User, Framed-Protocol = PPP, Framed-Address = 255.255.255.254, Framed-Netmask = 255.255.255.255, Framed-Routing = Listen, Framed-Compression = Van-Jacobsen-TCP-IP, Framed-MTU = 596, Framed-Filter-Id = "dialup" With this entry, if someone attempts to bring up a 128K ISDN connection, the NETserver logs "max session count reached on this bundle". Changing port-limit to 2 allows them to do it. In other words, it works like it's supposed to. :) The ARC, however, allows them to bring up a 128K connection with port-limit set to 1. This is Not A Good Thing(tm). Searching through some previous responses to this question, it was suggested using the VSA Max_Channels (0x9802) instead of the standard Port-Count. Fine, except for the minor detail that my Radius server doesn't grok 3com VSA's correctly. And even if it did, what affect would that have on the NETserver? Does ANYONE have this actually working in a mixed Netserver + ARC environment, with or without VSA support in your Radius server? Any suggestions on how to fix my default entry above? This brings me to a bug report. Feeling brave, I attempted to hack up my (Livingston) Radius server to handle VSA's on authentication packets. (I've already hacked it up successfully to log VSA's in accounting packets.) I goofed up somehow and sent a trashed response, and the ARC *rebooted*, knocking quite a few people offline. OUCH! And it rebooted repeatedly, every time it got a response packet, until I finally figured out what the hell was happening and put my old Radius server back online. MORE OUCH. Methinks there needs to be more error checking in the ARC code.... I mean, sure it wouldn't have happened if I had written clean code, but that's a pretty rotten way to handle corrupt packets. Not being real thrilled about the idea of paying out the nose for a support contract, I suppose I'm forever stuck with this bug too. Mike Andrews (MA12) icq 6602506 -------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "If Barbie is so popular, why do you have to buy her friends?..."

On Tue, 15 Sep 1998, Mike Andrews wrote: > I goofed up somehow and > sent a trashed response, and the ARC *rebooted*, knocking quite a few > people offline. OUCH! And it rebooted repeatedly, every time it got a > response packet, until I finally figured out what the hell was happening > and put my old Radius server back online. MORE OUCH. Methinks there > needs to be more error checking in the ARC code.... I mean, sure it > wouldn't have happened if I had written clean code, but that's a pretty > rotten way to handle corrupt packets. Hey, call it an exploit and mail it to Bugtraq... DoS is popular these days. The script kiddies could try and blackout AOL dialups for weeks... C > Not being real thrilled about the idea of paying out the nose for a > support contract, I suppose I'm forever stuck with this bug too. The wonderful thing is you could pay for it and still be stuck with bugs... > > > Mike Andrews (MA12) icq 6602506 -------- mandrews@termfrost.org > VP 'n' Systems/Network Administrator --------- mandrews@dcr.net > Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ > "If Barbie is so popular, why do you have to buy her friends?..." > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

Thus spake Mike Wronski (slightly edited to have something close to sane margins) >Can you send me a snoop trace or tcpdump of the packet that causes the reboot? >And what version of code were you using? >As for what will a NS do with the VSA for MAX Channels.. It will ignore >it.. You >can have both in your DEFAULT entry and it will for for HARC and NS. The question then arises... Why on God's green earth did 3Com decide to go with a VSA for this?! The *standard* Port-Limit attribute worked fine for this, what was the problem, were you scared to be more compliant to the RADIUS standard than Ascend? Sheesh...yet another reason that I don't want to move to the HARC. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

US>Struggle with a mp 8/16 with X2. US>The dialup connection speeds are running 14.4 to 19.2, US>but with multi-techs, on the same trunk group, getting 31.4+ US>Current init is at&f1 US>Any suggestions? US>Thank you, Not sure what our init string is but here is our ati4 screen... we usually get between 45-51k connects. USRobotics Total Control MP I-modem with ISDN/V.34 Settings... B0 C1 E0 F1 Q1 V1 X7 BAUD=115200 PARITY=N WORDLEN=8 DIAL=PULSE ON HOOK TIMER &A3 &B1 &C1 &D2 &G0 &H1 &I0 &K3 &M4 &N0 &P0 &R2 &S0 &T5 &U0 &X0 &Y1 %N6 *V=0 S00=001 S01=000 S02=043 S03=013 S04=010 S05=008 S06=002 S07=060 S08=002 S09=006 S10=020 S11=070 S12=050 S13=000 S14=001 S15=000 S16=000 S17=000 S18=000 S19=000 S20=000 S21=010 S22=017 S23=019 S24=150 S25=005 S26=001 S27=000 S28=008 S29=020 S30=000 S31=000 S32=009 S33=000 S34=000 S35=000 S36=000 S37=000 S38=000 S39=000 S40=000 S41=000 S42=126 S43=200 S44=015 S45=000 S46=255 S47=000 S48=000 S49=016 S50=100 S51=000 S52=005 S53=064 S54=064 S55=000 S56=000 S57=000 S58=000 S59=000 S60=000 S61=000 S62=000 S63=000 S64=000 S65=000 S66=000 S67=000 S68=000 S69=000 LAST DIALED #: Give that a try... On another note, has anyone heard if v.90 for the MPI/16's is coming anytime soon? Len Haggblad Mainline Information Service MtnMail V3.05: "Bother," said Pooh as he parked O.J.'s white Bronco. Sent via mainline.ab.ca (403)247-3900

> > The ARC, however, allows them to bring up a 128K connection with > port-limit set to 1. This is Not A Good Thing(tm). Port-Limit works on my ARC, I ran 4.0.30-33 code for a while. Radiator is the RADIUS server. > Not being real thrilled about the idea of paying out the nose for a > support contract, I suppose I'm forever stuck with this bug too. > > > Mike Andrews (MA12) icq 6602506 -------- mandrews@termfrost.org > VP 'n' Systems/Network Administrator --------- mandrews@dcr.net > Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ > "If Barbie is so popular, why do you have to buy her friends?..." > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

On Tue, 15 Sep 1998, Jeff Mcadams wrote: > Thus spake Mike Wronski (slightly edited to have something close to sane > margins) > >Can you send me a snoop trace or tcpdump of the packet that causes the reboot? > >And what version of code were you using? > > >As for what will a NS do with the VSA for MAX Channels.. It will ignore > >it.. You > >can have both in your DEFAULT entry and it will for for HARC and NS. > > The question then arises... > > Why on God's green earth did 3Com decide to go with a VSA for this?! > The *standard* Port-Limit attribute worked fine for this, what was the > problem, were you scared to be more compliant to the RADIUS standard > than Ascend? Sheesh...yet another reason that I don't want to move to > the HARC. I agree that VSA's should only be used if they have something to bring to the table above the standard draft. Is their anywhere where you can get a breakdown of each VSA in the dictionary and what exactly it does? Like a draft for 3Com's VSA's? Does it exist? > -- > 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. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Be sure to check that your DTE speed on your COM port is set correctly. USR modems will not connect higher than the DTE speed. As long as your serial ports can handle it, I recommend 115200, but in almost all cases it should be at least 57600. You can verify the setting on the I4 screen (obviously obtained through the serial port you use in production). This is the most common config error that will cause this problem. It is not likely to be an init string problem (&F1 is usually quite sufficient). Hope that helps! If not, shoot me a private email with the I4 and POP number (no ID needed) and I will shoot a call into it to look for the trouble from this end. JP Tim Patterson <tim@harborside.com> on 09/14/98 10:13:52 AM Please respond to usr-tc@lists.xmission.com cc: (John Powell/MW/US/3Com) Struggle with a mp 8/16 with X2. The dialup connection speeds are running 14.4 to 19.2, but with multi-techs, on the same trunk group, getting 31.4+ Current init is at&f1 Any suggestions? Thank you, Tim Patterson Harborside Internet - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Whoa, wait a second. Brian says it works... you say it works if you use it in an individual user entry instead of the default entry... Are either of you using the Max_Channels VSA? Brian, are you using separate Radius entries for all your users? Why should that make any difference? Now I'm even more confused. But I guess the answer is "use the VSA", then? I can do that. Pain the ass to hack the Radius server up for it, but I can do that. (I know, I know... buy Radiator. Sometime...) I had the same thought Jeff did (i.e. why the hell do you have to use a VSA for this) but I just didn't say anything -- the last 3 questions I've posted there have created lots of anti-3com email. How do I manage to have this effect on people? :) Mike, I'll try to get a tcpdump of it to you at some point, but as the card in question is a production unit, I'm a bit reluctant to make the thing reboot spontaneously right now. :) I'll have to move some PRI's back over to Quads/NETservers temporarily (thus pissing off all our Quake players) and try it at some off-time later in the week. I can tell you that I probably trashed a pointer trying to insert the VSA into the auth response packet, if that helps, and commenting out all the VSA code fixed it. Mike Andrews (MA12) icq 6602506 -------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "If Barbie is so popular, why do you have to buy her friends?..." On Tue, 15 Sep 1998, Frank Basso wrote: > We had the same issue, we had to move this setting to the individual user > entry in Radius, instead of inside the Default user entry.

Suncoast Networking USR Mailbox was heard to say: >No, but according to CNNfn, 3Com is expecting to post record profits >for the current period. I wonder if all those overpriced support contracts are making that much of a difference? Aside from support, I think the USR (err, 3Com) modem hardware is in the top of the bunch. >And 3Com Stock is up based on rumours Intel is going to buy them out. Oh, joy, that's all we need -- two companies who make routers but have yet to obtain a clue as to how to make a good one. --Ricky

Charles Sprickman was heard to say: >On Tue, 15 Sep 1998, Mike Andrews wrote: >> I goofed up somehow and >> sent a trashed response, and the ARC *rebooted*, knocking quite a few >> people offline. OUCH! And it rebooted repeatedly, every time it got a >> response packet, until I finally figured out what the hell was happening >> and put my old Radius server back online. MORE OUCH. Methinks there >> needs to be more error checking in the ARC code.... I mean, sure it >> wouldn't have happened if I had written clean code, but that's a pretty >> rotten way to handle corrupt packets. Heh, never used a PalmPilot have you :-) (I forgive them -- memory is tight.) >Hey, call it an exploit and mail it to Bugtraq... DoS is popular these >days. The script kiddies could try and blackout AOL dialups for weeks... Heh, there are lots of bugs one *could* use to knock stuff off or destroy databases... I think it's safe to share with the world what I found in the USR RADIUS server (and that was before I had the source to the ugly little thing.) The code never did any sanity checking on what it was handed as the username. As a result (and I guessed the line of code...) *anyone* could submit an SQL statement to the database behind the RADIUS server. I noticed this due to a "fast PPP" startup that sent PPP crap before it logged in. There was a single quote in the text and that caused the database server to error out -- the query was garbage. All it takes is a little care and you can trick it to running any query you can fit in the username field (80 characters.) Eg: Login: '; drop table USERS; Login: '; update USERS set PASSWORD='foo Just remember it's going to add the trailing "';". If you've still got a version of SA4, put it in debug mode and have fun. The actual C/C++ line will be left up to the reader to imagine. I very quickly added "'" checks to the username processing WELL before and database queries are called. It took awhile to convince USR that a) this existed and b) it was a bad thing. >> Not being real thrilled about the idea of paying out the nose for a >> support contract, I suppose I'm forever stuck with this bug too. > >The wonderful thing is you could pay for it and still be stuck with >bugs... Always demand source for critical components... for when 24hrs ain't fast enough. --Ricky

>From: Mike Andrews <mandrews@termfrost.org> > >Feeling brave, I attempted to hack up my (Livingston) Radius server to >handle VSA's on authentication packets. (I've already hacked it up >successfully to log VSA's in accounting packets.) I goofed up somehow and >sent a trashed response, and the ARC *rebooted*, knocking quite a few >people offline. OUCH! And it rebooted repeatedly, every time it got a >response packet, until I finally figured out what the hell was happening >and put my old Radius server back online. MORE OUCH. Methinks there >needs to be more error checking in the ARC code.... I mean, sure it >wouldn't have happened if I had written clean code, but that's a pretty >rotten way to handle corrupt packets. Umm, let me guess, you sent the HARC a vendor specific attribute of the wrong size -- which is to say not adhering to the USR spec for such a thing? Basically [26 02] is a legal attribute, but I'd bet it has the same problem their RADIUS server has... it flat out crashes as it assumes there's more data than there is. (That's unreported DoS #2. I'm not sure this has been fixed, BTW.) I had a merit radius server kill both USR RADIUS servers (SA4) and a NetServer once when setting up proxied access. I was lucky in that I was monitoring the packets between us AND had the source to fix the blasted bug. (Being able to run gdb on a core file and get a straight answer is just heavenly.) I'll add, the server was crashing before the script was ever called, so *anything* could crash it without a peep. --Ricky

Bob Purdon was heard to say: >> And 3Com Stock is up based on rumours Intel is going to buy them out. > >Ah, so the PowerPC based HiPerDSP and HiPerARC will be orphaned in a year >os so too? <grin> They're gonna have a hell of a time keeping a Xeon cool in there. (much less fitting it in the chassis. Guess we'll need a new chassis too.) --Ricky

Sorry for this message that's somewhat off topic. Does anyone know of a v.34 or v.90 modem that's available that'll return remote-ring messages when calling out? The Telebit Trailblazers and Worldblazers can do this. (E.g., if you want to call 242-0123, you might see ATDT2420123 RRING RRING CONNECT 19200/PEP if the remote line rang twice before picking up.) If you know of one that can -- possibly via wacky configuration -- I'd love to know about it. This is for a service monitoring program I'm writing, and I'd like to be able to differentiate between ring-no-answers and modems that won't handshake. Thanks! Mark

We call this the "Dead Air" Syndrome, you have to , as Nick Suggested, lock your port assignments on your DSP cards (The Default) and then have your Telco switch your hunting pattern to :"Next Available" instead of "First Available", it may be called different names depending on your area, but basically calls come in and pass through your entire hunt trunk before going to port one of the hunt again. This allows the modems that are disconnecting calls to reset before another call hits them, hence preventing dead air. -Frank -----Original Message----- >I had the same problem a while ago. Make sure that modem hunting on the >DSP is set to fixed assignment and your telco has your trunks set to >round robin. > >Save the config and then reboot the DSP. > >That worked for most of ours but some had to be rebooted multiple times >before they were working correctly. > >Regds > >Nick Lott > >Robert von Bismarck wrote: >> >> I just got a phone call from a telco tech, asking me if it was normal >> that my HiperDSP were rejecting between 18 and 20% calls. >> You can guess what my answer was ;-) >> The tech explained that the rejects were coming from the DSP going to >> the switch and resulting in a "fast busy". The reject happens during the >> incoming call negotiation between the switch (which is a brand-new >> Siemens EWSD feeding other providers with Lucent and Ascend equipment >> who don't have this problem, it's specific of the TC) and the TC. >> We have checked the cabling on site with layer 1 analyzers after a >> discussion with the 3com techs, and found it's okay even tho it's not >> "real" PRI 120ohm cabling. >> The problem is that the calls are not being rejected by one single >> board, but by 10 boards in a seemingly random fashion. I simply can't >> believe that half my boards are dead (!)... >> >> Now we'll be running a protocol analyzer on the 2nd layer of the PRI >> link (D-channel messaging) but the telco only has one of those systems >> and we'd like to run multiple tests on all the boards. I reprogrammed a >> PM-2e top serve as terminal server and plugged the console cables into >> it, so I can telnet into the consoles of the DSP's. >> Now I have following questions : >> - Can we see the 2nd layer messaging in the Hiperdsp ? (through >> a "trc dbg" command or something similar) >> - Are there ways to trap these failures with syslog or snmptrap >> ? >> - what other messaging can I see that could help me ? >> - has anyone seen similar problems ? >> >> Here's the configuration of my chassis : >> >> chassis 1 : 10 HiperDSP with software 1.2.2 >> 2 HiperARC with software 4.0.29 >> 1 NMC with 5.5.5 >> >> chassis 2 : see chassis 1 ;-) >> >> Here are some messages I've seen on the HiperDSP console while logged >> on, could they be related ? >> >> (Ch.255): 09:04:10:014 >> uccuGetMdmChId scReserveResource unavail 22 >> >> (Ch.255): 09:04:10:015 >> npCcPkgSetupInd uccu_get_new_usr_cid fail -1 >> >> (Ch.22): 09:05:34:134 >> TDM Connect Failed - Reason => -2 >> >> This message was repeated several times (like 3 or 4 times) >> here's the result of the "disp spnstat" command >> >> span1> disp spnstat >> Span1 Near Time Elapsed is: 869 seconds >> Span1 Near Valid Intervals is: 96 >> Span1 Line Status is: >> NO ALARM = TRUE >> RCV FAR END LOF = FALSE >> XMT FAR END LOF = FALSE >> RCV AIS = FALSE >> XMT AIS = FALSE >> OUT OF FRAME = FALSE >> LOSS OF SIGNAL = FALSE >> LOOPBACK STATE = FALSE >> T16 AIS = FALSE >> RCV FAR END LOMF = FALSE >> XMT FAR END LOMF = FALSE >> RCV TEST CODE = FALSE >> OTHER FAILURE = FALSE >> -MORE- >> Span1 Send Code is: SEND NO CODE >> Span1 dsx1 Loopback Configuration is: NO LOOP >> Span1 Receiver Gain is: 0.0 DB GAIN >> Span1 Continuous CRC Error is: FALSE >> Span1 Physical State is: F1 OPERATIONAL >> Span1 Loopback Init Originate is: NONE >> Span1 Modem Not Available Count is: 4815 >> Span1 Invalid Bearer Capability Count is: 0 >> Span1 Invalid Channel ID Count is: 0 >> Span1 Invalid Progress Indicator Count is: 0 >> Span1 Invalid Calling Party Count is: 0 >> Span1 Invalid Called Party Count is: 0 >> Span1 Call Block Failure Count is: 0 >> Span1 No Ring Off Failure Count is: 0 >> Span1 Telco Disconnect Failure Count is: 0 >> Span1 TELCO Failed To Wink Count is: 0 >> Span1 TELCO Wink Too Short Count is: 0 >> Span1 No Channel Available Count is: 0 >> Span1 Dial In No Resp To Disc Count is: 2 >> -MORE- >> Span1 Dial Out No Resp To Disc Count is: 0 >> Span1 Gnd Start No Resp To Disc Count is: 0 >> Span1 Switch Type Active is: ICTR4 >> Span1 D-channel Operational is: UP >> Span1 Signal Mode Active is: MESSAGE ORIENTED >> >> span1> >> >> What I think is some sort of an indicator is following line : >> >> Span1 Modem Not Available Count is: 4815 >> >> A little bit high, don't you think... >> >> Thanks for any information >> >> Robert von Bismarck >> Petrel Communications SA >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and 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. >

> And 3Com Stock is up based on rumours Intel is going to buy them out. Ah, so the PowerPC based HiPerDSP and HiPerARC will be orphaned in a year os so too? (For the humor impaired, I'm joking...) Regards, Bob Purdon, Technical Manager, Southern Internet Services.

> As for what will a NS do with the VSA for MAX Channels.. It will > ignore it.. You can have both in your DEFAULT entry and it will for > for HARC and NS. Is there any particular reason that the HiPerARC doesn't grok the standard Port-Limit attribute, rather than requiring a VSA? is this just a code oversight? Regards, Bob Purdon, Technical Manager, Southern Internet Services.

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Andrews |Sent: Tuesday, September 15, 1998 5:05 PM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) Preventing multi-channel connections on ARC 4.0.30 | | |OK, I'm *still* having problems with this. Someone check me and make sure |I'm not doing something stupid or insane. | |We have two NETservers and an ARC in service. Our DEFAULT entry in Radius |looks like this: | |DEFAULT Auth-Type = System | Port-Limit = 1, | Session-Timeout = 43200, | Idle-Timeout = 1800, | User-Service-Type = Framed-User, | Framed-Protocol = PPP, | Framed-Address = 255.255.255.254, | Framed-Netmask = 255.255.255.255, | Framed-Routing = Listen, | Framed-Compression = Van-Jacobsen-TCP-IP, | Framed-MTU = 596, | Framed-Filter-Id = "dialup" | |With this entry, if someone attempts to bring up a 128K ISDN connection, |the NETserver logs "max session count reached on this bundle". Changing |port-limit to 2 allows them to do it. In other words, it works like it's |supposed to. :) | |The ARC, however, allows them to bring up a 128K connection with |port-limit set to 1. This is Not A Good Thing(tm). | What version of HARC code was the above observed in? -M

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Bob Purdon |Sent: Tuesday, September 15, 1998 6:47 PM |To: usr-tc@lists.xmission.com |Subject: RE: (usr-tc) Preventing multi-channel connections on ARC 4.0.30 | | | |> As for what will a NS do with the VSA for MAX Channels.. It will |> ignore it.. You can have both in your DEFAULT entry and it will for |> for HARC and NS. | |Is there any particular reason that the HiPerARC doesn't grok the standard |Port-Limit attribute, rather than requiring a VSA? is this just a code |oversight? | This is beeing worked out as you read this.. -M

Before I get flamed.. I just actually read the Subject of the message.. Port-Limit is broken in 4.0.30 and the VSA should be used.. We are working to resolve the two attribute issues in 4.1.x code that is in BETA now. -M

The 3Com/USR Courier will do this. It prints "RINGING" when it detects ring-back tones (just verified with the latest V.90 code, in the default config, it works fine). I did check a Sportster also, doesn't do it, so don't bother. That should work quite well for what you are looking for. Do be careful not to make too much out of that though. There are plenty of conditions where you will get ring-back, but the call is not actually presented to the other end. As you describe your application (differntiating between ring-no-answer and failed handshake) it will work fine. JP mark@vielle.datasys.net (Mark R. Lindsey) on 09/16/98 08:09:25 AM Please respond to usr-tc@lists.xmission.com cc: (John Powell/MW/US/3Com) Sorry for this message that's somewhat off topic. Does anyone know of a v.34 or v.90 modem that's available that'll return remote-ring messages when calling out? The Telebit Trailblazers and Worldblazers can do this. (E.g., if you want to call 242-0123, you might see ATDT2420123 RRING RRING CONNECT 19200/PEP if the remote line rang twice before picking up.) If you know of one that can -- possibly via wacky configuration -- I'd love to know about it. This is for a service monitoring program I'm writing, and I'd like to be able to differentiate between ring-no-answers and modems that won't handshake. Thanks! Mark - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Couriers do this. I would guess Sportsters do too. But on our TC setup, with PRI's, you'll never hear a ring -- the modems either pick up immediately, or, if they're hosed, you'll get about a 6 second pause followed by a fast busy. Mike Andrews (MA12) icq 6602506 -------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "If Barbie is so popular, why do you have to buy her friends?..." On Wed, 16 Sep 1998, Mark R. Lindsey wrote: > Sorry for this message that's somewhat off topic. Does anyone know > of a v.34 or v.90 modem that's available that'll return remote-ring > messages when calling out? The Telebit Trailblazers and Worldblazers > can do this. (E.g., if you want to call 242-0123, you might see > ATDT2420123 > RRING > RRING > CONNECT 19200/PEP > if the remote line rang twice before picking up.) > > If you know of one that can -- possibly via wacky configuration -- > I'd love to know about it. This is for a service monitoring program > I'm writing, and I'd like to be able to differentiate between ring-no-answers > and modems that won't handshake.

No, but was able to get it figured out. Had two pins switch Thank you, Tim Patterson @harborside On Fri, 11 Sep 1998, Jake Messinger wrote: > On Tue, 1 Sep 1998, Tim Patterson wrote: > > > Trying to hook a Modem Pool 16 to a Portmaster 2 > > Does anyone know the pin outs and or other > > issues. > > Did you get my message with the pinouts and the info on Curtis who can > make those cables for you: > > Curtis Connections > 441 East Bay Blvd. > Provo, Utah 84606 > (800) 877-9143 > (801) 344-7155 FAX > > www.curtisconnections.com > > Scott Yergensen > syergensen@curtisconnect.com > (800)877-9143 > > ~~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ > Jake Messinger, VP. ph:713-772-6690 Lucent Dealer > AMS, Inc. fx:713-774-3498 Medical Billing > 8300 Bissonnet #400 jake@ams.com , ICQ# 4403734 Internet Services > Houston, Texas 77074 www.ams.com/~jake and Hardware > > Adjunct Professor University of Houston, CBA jake@uh.edu > ~~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Robert von Bismarck said once upon a time: >The problem is that the calls are not being rejected by one single >board, but by 10 boards in a seemingly random fashion. I simply can't >believe that half my boards are dead (!)... They're not. There is just a bug that smacks channels into a down-state that rejects calls on a continuous basis. The funny thing is that the stats for "rejected-calls" on the channel continues to climb, so the board knows it is getting calls, it just doesn't want to answer them. :-( This is what I wrote my recently posted perl script for. It monitors the count of calls rejected vs. calls accepted. If it goes above a set threshold, then the board is busied out and the script waits two hours for calls to clear before resetting it. It has made life with the HiPer much easier.

Ricky Beam said once upon a time: >Heh, there are lots of bugs one *could* use to knock stuff off or destroy >databases... I think it's safe to share with the world what I found in >the USR RADIUS server (and that was before I had the source to the ugly >little thing.) The code never did any sanity checking on what it was >handed as the username. As a result (and I guessed the line of code...) I think it is a good idea to block access to both your Netserver/ARCs and your RADIUS server from the outside world via router filters. Even better yet, permit accesses between the two and block everything else.

Suncoast Networking USR Mailbox said once upon a time: >And 3Com Stock is up based on rumours Intel is going to buy them out. I guess that means we can look forward to the PowerPC-based HiPers being the next in line to get chucked.

I had the same problem a while ago. Make sure that modem hunting on the DSP is set to fixed assignment and your telco has your trunks set to round robin. Save the config and then reboot the DSP. That worked for most of ours but some had to be rebooted multiple times before they were working correctly. Regds Nick Lott Robert von Bismarck wrote: > > I just got a phone call from a telco tech, asking me if it was normal > that my HiperDSP were rejecting between 18 and 20% calls. > You can guess what my answer was ;-) > The tech explained that the rejects were coming from the DSP going to > the switch and resulting in a "fast busy". The reject happens during the > incoming call negotiation between the switch (which is a brand-new > Siemens EWSD feeding other providers with Lucent and Ascend equipment > who don't have this problem, it's specific of the TC) and the TC. > We have checked the cabling on site with layer 1 analyzers after a > discussion with the 3com techs, and found it's okay even tho it's not > "real" PRI 120ohm cabling. > The problem is that the calls are not being rejected by one single > board, but by 10 boards in a seemingly random fashion. I simply can't > believe that half my boards are dead (!)... > > Now we'll be running a protocol analyzer on the 2nd layer of the PRI > link (D-channel messaging) but the telco only has one of those systems > and we'd like to run multiple tests on all the boards. I reprogrammed a > PM-2e top serve as terminal server and plugged the console cables into > it, so I can telnet into the consoles of the DSP's. > Now I have following questions : > - Can we see the 2nd layer messaging in the Hiperdsp ? (through > a "trc dbg" command or something similar) > - Are there ways to trap these failures with syslog or snmptrap > ? > - what other messaging can I see that could help me ? > - has anyone seen similar problems ? > > Here's the configuration of my chassis : > > chassis 1 : 10 HiperDSP with software 1.2.2 > 2 HiperARC with software 4.0.29 > 1 NMC with 5.5.5 > > chassis 2 : see chassis 1 ;-) > > Here are some messages I've seen on the HiperDSP console while logged > on, could they be related ? > > (Ch.255): 09:04:10:014 > uccuGetMdmChId scReserveResource unavail 22 > > (Ch.255): 09:04:10:015 > npCcPkgSetupInd uccu_get_new_usr_cid fail -1 > > (Ch.22): 09:05:34:134 > TDM Connect Failed - Reason => -2 > > This message was repeated several times (like 3 or 4 times) > here's the result of the "disp spnstat" command > > span1> disp spnstat > Span1 Near Time Elapsed is: 869 seconds > Span1 Near Valid Intervals is: 96 > Span1 Line Status is: > NO ALARM = TRUE > RCV FAR END LOF = FALSE > XMT FAR END LOF = FALSE > RCV AIS = FALSE > XMT AIS = FALSE > OUT OF FRAME = FALSE > LOSS OF SIGNAL = FALSE > LOOPBACK STATE = FALSE > T16 AIS = FALSE > RCV FAR END LOMF = FALSE > XMT FAR END LOMF = FALSE > RCV TEST CODE = FALSE > OTHER FAILURE = FALSE > -MORE- > Span1 Send Code is: SEND NO CODE > Span1 dsx1 Loopback Configuration is: NO LOOP > Span1 Receiver Gain is: 0.0 DB GAIN > Span1 Continuous CRC Error is: FALSE > Span1 Physical State is: F1 OPERATIONAL > Span1 Loopback Init Originate is: NONE > Span1 Modem Not Available Count is: 4815 > Span1 Invalid Bearer Capability Count is: 0 > Span1 Invalid Channel ID Count is: 0 > Span1 Invalid Progress Indicator Count is: 0 > Span1 Invalid Calling Party Count is: 0 > Span1 Invalid Called Party Count is: 0 > Span1 Call Block Failure Count is: 0 > Span1 No Ring Off Failure Count is: 0 > Span1 Telco Disconnect Failure Count is: 0 > Span1 TELCO Failed To Wink Count is: 0 > Span1 TELCO Wink Too Short Count is: 0 > Span1 No Channel Available Count is: 0 > Span1 Dial In No Resp To Disc Count is: 2 > -MORE- > Span1 Dial Out No Resp To Disc Count is: 0 > Span1 Gnd Start No Resp To Disc Count is: 0 > Span1 Switch Type Active is: ICTR4 > Span1 D-channel Operational is: UP > Span1 Signal Mode Active is: MESSAGE ORIENTED > > span1> > > What I think is some sort of an indicator is following line : > > Span1 Modem Not Available Count is: 4815 > > A little bit high, don't you think... > > Thanks for any information > > Robert von Bismarck > Petrel Communications SA > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

On Wed, 16 Sep 1998, Mike Andrews wrote: > Whoa, wait a second. Brian says it works... you say it works if you use > it in an individual user entry instead of the default entry... Are either > of you using the Max_Channels VSA? Brian, are you using separate Radius > entries for all your users? Why should that make any difference? Ok, here is how it is here. First, we have a default entry for all "joe blow" users: User-Service-Type = "Framed-User", Framed-Protocol = "PPP", Framed-Address = "255.255.255.254", Framed-Netmask = "255.255.255.255", Framed-MTU = "1500", Port-Limit = "1", Framed-Routing = "None", Framed-Compression = "Van-Jacobson-TCP-IP This will not allow users to have dual channel. I can confirm this for ARC releases 4.0.30 (release) thru 4.0.33-2 ER. If a user were a dual channel user, we would simply give them their own Reply Attributes and change Port-Limit to "2". Port-Limit does not prevent seperate instances of a login, but DOES prevent MPP bonding of more than n number of ports. > > Now I'm even more confused. But I guess the answer is "use the VSA", > then? I can do that. Pain the ass to hack the Radius server up for it, > but I can do that. (I know, I know... buy Radiator. Sometime...) You shouldn't have to use VSA's, we never did. We used merit 3.4.23(c) for the longest time, then recently switched to Radiator, which is great, because check/reply attr's come from a database in house. The default items are sent to any user that has a NULL reply attribute. > > I had the same thought Jeff did (i.e. why the hell do you have to use a > VSA for this) but I just didn't say anything -- the last 3 questions I've > posted there have created lots of anti-3com email. How do I manage to > have this effect on people? :) > > Mike, I'll try to get a tcpdump of it to you at some point, but as the > card in question is a production unit, I'm a bit reluctant to make the > thing reboot spontaneously right now. :) I'll have to move some PRI's > back over to Quads/NETservers temporarily (thus pissing off all our Quake > players) and try it at some off-time later in the week. I can tell you > that I probably trashed a pointer trying to insert the VSA into the auth > response packet, if that helps, and commenting out all the VSA code fixed > it. > > > Mike Andrews (MA12) icq 6602506 -------- mandrews@termfrost.org > VP 'n' Systems/Network Administrator --------- mandrews@dcr.net > Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ > "If Barbie is so popular, why do you have to buy her friends?..." > > On Tue, 15 Sep 1998, Frank Basso wrote: > > > We had the same issue, we had to move this setting to the individual user > > entry in Radius, instead of inside the Default user entry. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

On Wed, 16 Sep 1998, Ricky Beam wrote: > Charles Sprickman was heard to say: > >On Tue, 15 Sep 1998, Mike Andrews wrote: > >> I goofed up somehow and > >> sent a trashed response, and the ARC *rebooted*, knocking quite a few > >> people offline. OUCH! And it rebooted repeatedly, every time it got a > >> response packet, until I finally figured out what the hell was happening > >> and put my old Radius server back online. MORE OUCH. Methinks there > >> needs to be more error checking in the ARC code.... I mean, sure it > >> wouldn't have happened if I had written clean code, but that's a pretty > >> rotten way to handle corrupt packets. > > Heh, never used a PalmPilot have you :-) (I forgive them -- memory is tight.) I love my Pilot (1000 upgraded to OS2.0 and 1meg). Anyone want to write a Pilot HARM? (jk :) ) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

On Wed, 16 Sep 1998, Mike Wronski wrote: > Before I get flamed.. I just actually read the Subject of the message.. > Port-Limit is broken in 4.0.30 and the VSA should be used.. We are working to > resolve the two attribute issues in 4.1.x code that is in BETA now. Interesting, I mostly used 4.0.33-2 ER, and I am reasonably sure that Port-Limit *works* in that code. I guess I didn't use the other members of the 4.0.x family long enough to be sure, but we ran 4.0.33-2 for a while. > > -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. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

I just got a phone call from a telco tech, asking me if it was normal that my HiperDSP were rejecting between 18 and 20% calls. You can guess what my answer was ;-) The tech explained that the rejects were coming from the DSP going to the switch and resulting in a "fast busy". The reject happens during the incoming call negotiation between the switch (which is a brand-new Siemens EWSD feeding other providers with Lucent and Ascend equipment who don't have this problem, it's specific of the TC) and the TC. We have checked the cabling on site with layer 1 analyzers after a discussion with the 3com techs, and found it's okay even tho it's not "real" PRI 120ohm cabling. The problem is that the calls are not being rejected by one single board, but by 10 boards in a seemingly random fashion. I simply can't believe that half my boards are dead (!)... Now we'll be running a protocol analyzer on the 2nd layer of the PRI link (D-channel messaging) but the telco only has one of those systems and we'd like to run multiple tests on all the boards. I reprogrammed a PM-2e top serve as terminal server and plugged the console cables into it, so I can telnet into the consoles of the DSP's. Now I have following questions : - Can we see the 2nd layer messaging in the Hiperdsp ? (through a "trc dbg" command or something similar) - Are there ways to trap these failures with syslog or snmptrap ? - what other messaging can I see that could help me ? - has anyone seen similar problems ? Here's the configuration of my chassis : chassis 1 : 10 HiperDSP with software 1.2.2 2 HiperARC with software 4.0.29 1 NMC with 5.5.5 chassis 2 : see chassis 1 ;-) Here are some messages I've seen on the HiperDSP console while logged on, could they be related ? (Ch.255): 09:04:10:014 uccuGetMdmChId scReserveResource unavail 22 (Ch.255): 09:04:10:015 npCcPkgSetupInd uccu_get_new_usr_cid fail -1 (Ch.22): 09:05:34:134 TDM Connect Failed - Reason => -2 This message was repeated several times (like 3 or 4 times) here's the result of the "disp spnstat" command span1> disp spnstat Span1 Near Time Elapsed is: 869 seconds Span1 Near Valid Intervals is: 96 Span1 Line Status is: NO ALARM = TRUE RCV FAR END LOF = FALSE XMT FAR END LOF = FALSE RCV AIS = FALSE XMT AIS = FALSE OUT OF FRAME = FALSE LOSS OF SIGNAL = FALSE LOOPBACK STATE = FALSE T16 AIS = FALSE RCV FAR END LOMF = FALSE XMT FAR END LOMF = FALSE RCV TEST CODE = FALSE OTHER FAILURE = FALSE -MORE- Span1 Send Code is: SEND NO CODE Span1 dsx1 Loopback Configuration is: NO LOOP Span1 Receiver Gain is: 0.0 DB GAIN Span1 Continuous CRC Error is: FALSE Span1 Physical State is: F1 OPERATIONAL Span1 Loopback Init Originate is: NONE Span1 Modem Not Available Count is: 4815 Span1 Invalid Bearer Capability Count is: 0 Span1 Invalid Channel ID Count is: 0 Span1 Invalid Progress Indicator Count is: 0 Span1 Invalid Calling Party Count is: 0 Span1 Invalid Called Party Count is: 0 Span1 Call Block Failure Count is: 0 Span1 No Ring Off Failure Count is: 0 Span1 Telco Disconnect Failure Count is: 0 Span1 TELCO Failed To Wink Count is: 0 Span1 TELCO Wink Too Short Count is: 0 Span1 No Channel Available Count is: 0 Span1 Dial In No Resp To Disc Count is: 2 -MORE- Span1 Dial Out No Resp To Disc Count is: 0 Span1 Gnd Start No Resp To Disc Count is: 0 Span1 Switch Type Active is: ICTR4 Span1 D-channel Operational is: UP Span1 Signal Mode Active is: MESSAGE ORIENTED span1> What I think is some sort of an indicator is following line : Span1 Modem Not Available Count is: 4815 A little bit high, don't you think... Thanks for any information Robert von Bismarck Petrel Communications SA

On Tuesday, September 15, 1998 4:16 PM, Suncoast Networking USR Mailbox [SMTP:usrtcmail@flasuncoast.Net] wrote: > Just one of the obvious... Is the "Maximum Active B-Channels" at the bottom > of > Show Glob set to a decent number? (As opposed to zero) Is it just dropping > ISDN calls, or is it also dropping analog calls? > We replaced the Netserver and called in with no trouble. Still cannot tell what was happening, but then I guess 3com would tell me get an ARC! Marshall Morgan Internet Doorway, Inc (aka NETDOOR) http://www.netdoor.com 601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838

Hi, I'm using a Netserver 16 with V.34 modems. I'm running version 3.3.0, because I found versions 4.x to behave strange with Radius (reporting wrong Port ID, etc). I use the Cistron Radius daemon. My problem is that I want the server to give the DNS to the users. It seems that by default, this does not happen. I have to manually set the DNS on users computer, which is pretty annoying. Does anyone know of some workaround for this, using another code version or some other gizmo ? If this is impossible on the Netserver, I'd like to know this too :-) Many thanks, Bogdan Bogdan Pelinescu <bpelin@itcnet.ro> | R&D Engineer | Tel: (401) 232 2770 Institute for Computers | Networks & Communications Dept. | Fax: (401) 230 7845 Bucharest, Romania |

We tried it to no avail..... Another USR blunder -----Original Message----- >would i get the same benefit if my telco uses a first available hunting >patern but the DSP uses a round robin mode? > >Leon >-----Original Message----- > >>We call this the "Dead Air" Syndrome, you have to , as Nick Suggested, lock >>your port assignments on your DSP cards (The Default) and then have your >>Telco switch your hunting pattern to :"Next Available" instead of "First >>Available", it may be called different names depending on your area, but >>basically calls come in and pass through your entire hunt trunk before >going >>to port one of the hunt again. This allows the modems that are >disconnecting >>calls to reset before another call hits them, hence preventing dead air. >> >>-Frank >> >>-----Original Message----- >>From: Nick Lott <nick@uk.insight.com> >>To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >>Date: Wednesday, September 16, 1998 9:08 AM >>Subject: Re: (usr-tc) Call reject rate on HiperDSP = 20% ?! >> >> >>>I had the same problem a while ago. Make sure that modem hunting on the >>>DSP is set to fixed assignment and your telco has your trunks set to >>>round robin. >>> >>>Save the config and then reboot the DSP. >>> >>>That worked for most of ours but some had to be rebooted multiple times >>>before they were working correctly. >>> >>>Regds >>> >>>Nick Lott >>> >>>Robert von Bismarck wrote: >>>> >>>> I just got a phone call from a telco tech, asking me if it was normal >>>> that my HiperDSP were rejecting between 18 and 20% calls. >>>> You can guess what my answer was ;-) >>>> The tech explained that the rejects were coming from the DSP going to >>>> the switch and resulting in a "fast busy". The reject happens during the >>>> incoming call negotiation between the switch (which is a brand-new >>>> Siemens EWSD feeding other providers with Lucent and Ascend equipment >>>> who don't have this problem, it's specific of the TC) and the TC. >>>> We have checked the cabling on site with layer 1 analyzers after a >>>> discussion with the 3com techs, and found it's okay even tho it's not >>>> "real" PRI 120ohm cabling. >>>> The problem is that the calls are not being rejected by one single >>>> board, but by 10 boards in a seemingly random fashion. I simply can't >>>> believe that half my boards are dead (!)... >>>> >>>> Now we'll be running a protocol analyzer on the 2nd layer of the PRI >>>> link (D-channel messaging) but the telco only has one of those systems >>>> and we'd like to run multiple tests on all the boards. I reprogrammed a >>>> PM-2e top serve as terminal server and plugged the console cables into >>>> it, so I can telnet into the consoles of the DSP's. >>>> Now I have following questions : >>>> - Can we see the 2nd layer messaging in the Hiperdsp ? (through >>>> a "trc dbg" command or something similar) >>>> - Are there ways to trap these failures with syslog or snmptrap >>>> ? >>>> - what other messaging can I see that could help me ? >>>> - has anyone seen similar problems ? >>>> >>>> Here's the configuration of my chassis : >>>> >>>> chassis 1 : 10 HiperDSP with software 1.2.2 >>>> 2 HiperARC with software 4.0.29 >>>> 1 NMC with 5.5.5 >>>> >>>> chassis 2 : see chassis 1 ;-) >>>> >>>> Here are some messages I've seen on the HiperDSP console while logged >>>> on, could they be related ? >>>> >>>> (Ch.255): 09:04:10:014 >>>> uccuGetMdmChId scReserveResource unavail 22 >>>> >>>> (Ch.255): 09:04:10:015 >>>> npCcPkgSetupInd uccu_get_new_usr_cid fail -1 >>>> >>>> (Ch.22): 09:05:34:134 >>>> TDM Connect Failed - Reason => -2 >>>> >>>> This message was repeated several times (like 3 or 4 times) >>>> here's the result of the "disp spnstat" command >>>> >>>> span1> disp spnstat >>>> Span1 Near Time Elapsed is: 869 seconds >>>> Span1 Near Valid Intervals is: 96 >>>> Span1 Line Status is: >>>> NO ALARM = TRUE >>>> RCV FAR END LOF = FALSE >>>> XMT FAR END LOF = FALSE >>>> RCV AIS = FALSE >>>> XMT AIS = FALSE >>>> OUT OF FRAME = FALSE >>>> LOSS OF SIGNAL = FALSE >>>> LOOPBACK STATE = FALSE >>>> T16 AIS = FALSE >>>> RCV FAR END LOMF = FALSE >>>> XMT FAR END LOMF = FALSE >>>> RCV TEST CODE = FALSE >>>> OTHER FAILURE = FALSE >>>> -MORE- >>>> Span1 Send Code is: SEND NO CODE >>>> Span1 dsx1 Loopback Configuration is: NO LOOP >>>> Span1 Receiver Gain is: 0.0 DB GAIN >>>> Span1 Continuous CRC Error is: FALSE >>>> Span1 Physical State is: F1 OPERATIONAL >>>> Span1 Loopback Init Originate is: NONE >>>> Span1 Modem Not Available Count is: 4815 >>>> Span1 Invalid Bearer Capability Count is: 0 >>>> Span1 Invalid Channel ID Count is: 0 >>>> Span1 Invalid Progress Indicator Count is: 0 >>>> Span1 Invalid Calling Party Count is: 0 >>>> Span1 Invalid Called Party Count is: 0 >>>> Span1 Call Block Failure Count is: 0 >>>> Span1 No Ring Off Failure Count is: 0 >>>> Span1 Telco Disconnect Failure Count is: 0 >>>> Span1 TELCO Failed To Wink Count is: 0 >>>> Span1 TELCO Wink Too Short Count is: 0 >>>> Span1 No Channel Available Count is: 0 >>>> Span1 Dial In No Resp To Disc Count is: 2 >>>> -MORE- >>>> Span1 Dial Out No Resp To Disc Count is: 0 >>>> Span1 Gnd Start No Resp To Disc Count is: 0 >>>> Span1 Switch Type Active is: ICTR4 >>>> Span1 D-channel Operational is: UP >>>> Span1 Signal Mode Active is: MESSAGE ORIENTED >>>> >>>> span1> >>>> >>>> What I think is some sort of an indicator is following line : >>>> >>>> Span1 Modem Not Available Count is: 4815 >>>> >>>> A little bit high, don't you think... >>>> >>>> Thanks for any information >>>> >>>> Robert von Bismarck >>>> Petrel Communications SA >>>> >>>> - >>>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >>>> with "unsubscribe usr-tc" in the body of the message. >>>> For information on digests or retrieving files and 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. >

would i get the same benefit if my telco uses a first available hunting patern but the DSP uses a round robin mode? Leon -----Original Message----- >We call this the "Dead Air" Syndrome, you have to , as Nick Suggested, lock >your port assignments on your DSP cards (The Default) and then have your >Telco switch your hunting pattern to :"Next Available" instead of "First >Available", it may be called different names depending on your area, but >basically calls come in and pass through your entire hunt trunk before going >to port one of the hunt again. This allows the modems that are disconnecting >calls to reset before another call hits them, hence preventing dead air. > >-Frank > >-----Original Message----- >From: Nick Lott <nick@uk.insight.com> >To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >Date: Wednesday, September 16, 1998 9:08 AM >Subject: Re: (usr-tc) Call reject rate on HiperDSP = 20% ?! > > >>I had the same problem a while ago. Make sure that modem hunting on the >>DSP is set to fixed assignment and your telco has your trunks set to >>round robin. >> >>Save the config and then reboot the DSP. >> >>That worked for most of ours but some had to be rebooted multiple times >>before they were working correctly. >> >>Regds >> >>Nick Lott >> >>Robert von Bismarck wrote: >>> >>> I just got a phone call from a telco tech, asking me if it was normal >>> that my HiperDSP were rejecting between 18 and 20% calls. >>> You can guess what my answer was ;-) >>> The tech explained that the rejects were coming from the DSP going to >>> the switch and resulting in a "fast busy". The reject happens during the >>> incoming call negotiation between the switch (which is a brand-new >>> Siemens EWSD feeding other providers with Lucent and Ascend equipment >>> who don't have this problem, it's specific of the TC) and the TC. >>> We have checked the cabling on site with layer 1 analyzers after a >>> discussion with the 3com techs, and found it's okay even tho it's not >>> "real" PRI 120ohm cabling. >>> The problem is that the calls are not being rejected by one single >>> board, but by 10 boards in a seemingly random fashion. I simply can't >>> believe that half my boards are dead (!)... >>> >>> Now we'll be running a protocol analyzer on the 2nd layer of the PRI >>> link (D-channel messaging) but the telco only has one of those systems >>> and we'd like to run multiple tests on all the boards. I reprogrammed a >>> PM-2e top serve as terminal server and plugged the console cables into >>> it, so I can telnet into the consoles of the DSP's. >>> Now I have following questions : >>> - Can we see the 2nd layer messaging in the Hiperdsp ? (through >>> a "trc dbg" command or something similar) >>> - Are there ways to trap these failures with syslog or snmptrap >>> ? >>> - what other messaging can I see that could help me ? >>> - has anyone seen similar problems ? >>> >>> Here's the configuration of my chassis : >>> >>> chassis 1 : 10 HiperDSP with software 1.2.2 >>> 2 HiperARC with software 4.0.29 >>> 1 NMC with 5.5.5 >>> >>> chassis 2 : see chassis 1 ;-) >>> >>> Here are some messages I've seen on the HiperDSP console while logged >>> on, could they be related ? >>> >>> (Ch.255): 09:04:10:014 >>> uccuGetMdmChId scReserveResource unavail 22 >>> >>> (Ch.255): 09:04:10:015 >>> npCcPkgSetupInd uccu_get_new_usr_cid fail -1 >>> >>> (Ch.22): 09:05:34:134 >>> TDM Connect Failed - Reason => -2 >>> >>> This message was repeated several times (like 3 or 4 times) >>> here's the result of the "disp spnstat" command >>> >>> span1> disp spnstat >>> Span1 Near Time Elapsed is: 869 seconds >>> Span1 Near Valid Intervals is: 96 >>> Span1 Line Status is: >>> NO ALARM = TRUE >>> RCV FAR END LOF = FALSE >>> XMT FAR END LOF = FALSE >>> RCV AIS = FALSE >>> XMT AIS = FALSE >>> OUT OF FRAME = FALSE >>> LOSS OF SIGNAL = FALSE >>> LOOPBACK STATE = FALSE >>> T16 AIS = FALSE >>> RCV FAR END LOMF = FALSE >>> XMT FAR END LOMF = FALSE >>> RCV TEST CODE = FALSE >>> OTHER FAILURE = FALSE >>> -MORE- >>> Span1 Send Code is: SEND NO CODE >>> Span1 dsx1 Loopback Configuration is: NO LOOP >>> Span1 Receiver Gain is: 0.0 DB GAIN >>> Span1 Continuous CRC Error is: FALSE >>> Span1 Physical State is: F1 OPERATIONAL >>> Span1 Loopback Init Originate is: NONE >>> Span1 Modem Not Available Count is: 4815 >>> Span1 Invalid Bearer Capability Count is: 0 >>> Span1 Invalid Channel ID Count is: 0 >>> Span1 Invalid Progress Indicator Count is: 0 >>> Span1 Invalid Calling Party Count is: 0 >>> Span1 Invalid Called Party Count is: 0 >>> Span1 Call Block Failure Count is: 0 >>> Span1 No Ring Off Failure Count is: 0 >>> Span1 Telco Disconnect Failure Count is: 0 >>> Span1 TELCO Failed To Wink Count is: 0 >>> Span1 TELCO Wink Too Short Count is: 0 >>> Span1 No Channel Available Count is: 0 >>> Span1 Dial In No Resp To Disc Count is: 2 >>> -MORE- >>> Span1 Dial Out No Resp To Disc Count is: 0 >>> Span1 Gnd Start No Resp To Disc Count is: 0 >>> Span1 Switch Type Active is: ICTR4 >>> Span1 D-channel Operational is: UP >>> Span1 Signal Mode Active is: MESSAGE ORIENTED >>> >>> span1> >>> >>> What I think is some sort of an indicator is following line : >>> >>> Span1 Modem Not Available Count is: 4815 >>> >>> A little bit high, don't you think... >>> >>> Thanks for any information >>> >>> Robert von Bismarck >>> Petrel Communications SA >>> >>> - >>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >>> with "unsubscribe usr-tc" in the body of the message. >>> For information on digests or retrieving files and 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.

Yes. -----Original Message----- >I'm using quads with 2 HiperDSP connected to Netserver cards. will it fail >as well? > >Leon > >-----Original Message----- >From: Nick Lott <nick@uk.insight.com> >To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >Date: Thursday, September 17, 1998 11:17 AM >Subject: Re: (usr-tc) Call reject rate on HiperDSP = 20% ?! > > >>Leon McCalla wrote: >>> >>> would i get the same benefit if my telco uses a first available hunting >>> patern but the DSP uses a round robin mode? >> >>No. There is a bug in the HARC card which cases calls to fail when the >>DSP's use anything other than fixed assignment. >> >> >> >>Nick >>> >>> Leon >>> -----Original Message----- >>> >>> >We call this the "Dead Air" Syndrome, you have to , as Nick Suggested, >lock >>> >your port assignments on your DSP cards (The Default) and then have your >>> >Telco switch your hunting pattern to :"Next Available" instead of "First >>> >Available", it may be called different names depending on your area, but >>> >basically calls come in and pass through your entire hunt trunk before >>> going >>> >to port one of the hunt again. This allows the modems that are >>> disconnecting >>> >calls to reset before another call hits them, hence preventing dead air. >>> > >>> >-Frank >>> > >>> >-----Original Message----- >>> >From: Nick Lott <nick@uk.insight.com> >>> >To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >>> >Date: Wednesday, September 16, 1998 9:08 AM >>> >Subject: Re: (usr-tc) Call reject rate on HiperDSP = 20% ?! >>> > >>> > >>> >>I had the same problem a while ago. Make sure that modem hunting on >the >>> >>DSP is set to fixed assignment and your telco has your trunks set to >>> >>round robin. >>> >> >>> >>Save the config and then reboot the DSP. >>> >> >>> >>That worked for most of ours but some had to be rebooted multiple times >>> >>before they were working correctly. >>> >> >>> >>Regds >>> >> >>> >>Nick Lott >>> >> >>> >>Robert von Bismarck wrote: >>> >>> >> >>> >>> - >>> >>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >>> >>> with "unsubscribe usr-tc" in the body of the message. >>> >>> For information on digests or retrieving files and 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. >

We use STAC and it seems stable on the Netserver Units but a bad idea on the HiPer Arc Units. Same results, just shut off the compression and all will be well. -Frank -----Original Message----- >I have a customer running the lastest p50 code (6.0.10), and is >experiencing lockups every 12-15 hours or so. They are using STAC >compression. I noticed that the P50 actually supports: > >STAC >STAC-9 >MS-Comp >None > >I set it to None and am having her try that. Does anyone know what could >be the issue? Which compression type is preffered? > >Brian > > >-------------------------------------------------------------------------- >Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider >Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ >signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, >(318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

I have a customer running the lastest p50 code (6.0.10), and is experiencing lockups every 12-15 hours or so. They are using STAC compression. I noticed that the P50 actually supports: STAC STAC-9 MS-Comp None I set it to None and am having her try that. Does anyone know what could be the issue? Which compression type is preffered? Brian Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

I'm using quads with 2 HiperDSP connected to Netserver cards. will it fail as well? Leon -----Original Message----- >Leon McCalla wrote: >> >> would i get the same benefit if my telco uses a first available hunting >> patern but the DSP uses a round robin mode? > >No. There is a bug in the HARC card which cases calls to fail when the >DSP's use anything other than fixed assignment. > > > >Nick >> >> Leon >> -----Original Message----- >> >> >We call this the "Dead Air" Syndrome, you have to , as Nick Suggested, lock >> >your port assignments on your DSP cards (The Default) and then have your >> >Telco switch your hunting pattern to :"Next Available" instead of "First >> >Available", it may be called different names depending on your area, but >> >basically calls come in and pass through your entire hunt trunk before >> going >> >to port one of the hunt again. This allows the modems that are >> disconnecting >> >calls to reset before another call hits them, hence preventing dead air. >> > >> >-Frank >> > >> >-----Original Message----- >> >From: Nick Lott <nick@uk.insight.com> >> >To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >> >Date: Wednesday, September 16, 1998 9:08 AM >> >Subject: Re: (usr-tc) Call reject rate on HiperDSP = 20% ?! >> > >> > >> >>I had the same problem a while ago. Make sure that modem hunting on the >> >>DSP is set to fixed assignment and your telco has your trunks set to >> >>round robin. >> >> >> >>Save the config and then reboot the DSP. >> >> >> >>That worked for most of ours but some had to be rebooted multiple times >> >>before they were working correctly. >> >> >> >>Regds >> >> >> >>Nick Lott >> >> >> >>Robert von Bismarck wrote: >> >>> > >> >>> - >> >>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> >>> with "unsubscribe usr-tc" in the body of the message. >> >>> For information on digests or retrieving files and 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.

On Thu, 17 Sep 1998, Frank Basso wrote: > We use STAC and it seems stable on the Netserver Units but a bad idea on the > HiPer Arc Units. Same results, just shut off the compression and all will be > well. Gotcha. And what are your experiences with STAC on the ARC to warrant shutting it off? Brian > > -Frank > > -----Original Message----- > From: Brian <signal@shreve.net> > To: USRobotics TC Mailing List <usr-tc@xmission.com> > Date: Thursday, September 17, 1998 10:53 AM > Subject: (usr-tc) Pipeline 50 and ARC/HDM > > > >I have a customer running the lastest p50 code (6.0.10), and is > >experiencing lockups every 12-15 hours or so. They are using STAC > >compression. I noticed that the P50 actually supports: > > > >STAC > >STAC-9 > >MS-Comp > >None > > > >I set it to None and am having her try that. Does anyone know what could > >be the issue? Which compression type is preffered? > > > >Brian > > > > > >-------------------------------------------------------------------------- > >Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > >Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > >signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > >(318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Never heard that terminology (OE) so can't comment directly (telcos have their own languages, with many unintelligible dialects). It is likely to have to do with padding. A "trunk" assumes the device on the other end (TCH in your case) is capable of handling it's own loss plan. Typically this would be a PBX or CO-class equipment. I always recommend trunks, as our modems like all the signal they can get and do not have any problems with levels or echo (which is what the loss plan is trying deal with) as they are pure digital. The other thing about trunks is that the are almost always pure digital, no channel banks. JP mark@vielle.datasys.net (Mark R. Lindsey) on 09/17/98 01:59:22 PM Please respond to usr-tc@lists.xmission.com cc: (John Powell/MW/US/3Com) We're having immense trouble with our telco, BellSouth (known hereafter as The BEAST). One representative of The BEAST, who works at the CO locally, told us that all of our lines are `OEs' (Pronounced Oh-Ees), and that we might have better results with trunks. What's the difference? - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

As many of you are probably about to hear (it has hit several online rags today) the FCC announced that they will be opening up the topic of power levels. This is NOT an "official 3Com statement" on the issue, but I did want to answer a few questions I have received in email, and I figured you folks (at least in North America) would like to know: - First, they have not made any decisions, they have just opened the topic for discussion. I have no idea what kind of timeframe would apply here, but it won't be tomorrow ;) This is very good news though, it is an important first step! - This only applies to the US. Canada and Japan would need to take their own separate action, though it would not surprise me if they took an active interest in the proceedings. To the best of my knowledge, no other countries restrict "encoded analog content". - The change would only require modifications on the head-end (digital side) and they would be child's play (change a table in code basically). - I can't speak for all clients, but V.90 was designed with this in mind, and clients should not need any changes whatsoever. I can speak for 3Com clients, no problem whatsoever, they just take orders from the server. They find the "right" constellation that does not exceed the max put out by the server. Same goes for x2 for that matter. I suspect clients from Rockwell, Lucent and others will operate the same (the mechanism for this in V.90 is quite effective). Hope that answers your questions before you asked them! JP

We have had strange timeouts on connections, very slow throughput, less than 28.8 modem speed with dual channels enabled and mysterious dropping of telnet sessions. -Frank -----Original Message----- >On Thu, 17 Sep 1998, Frank Basso wrote: > >> We use STAC and it seems stable on the Netserver Units but a bad idea on the >> HiPer Arc Units. Same results, just shut off the compression and all will be >> well. > >Gotcha. And what are your experiences with STAC on the ARC to warrant >shutting it off? > >Brian > > >> >> -Frank >> >> -----Original Message----- >> From: Brian <signal@shreve.net> >> To: USRobotics TC Mailing List <usr-tc@xmission.com> >> Date: Thursday, September 17, 1998 10:53 AM >> Subject: (usr-tc) Pipeline 50 and ARC/HDM >> >> >> >I have a customer running the lastest p50 code (6.0.10), and is >> >experiencing lockups every 12-15 hours or so. They are using STAC >> >compression. I noticed that the P50 actually supports: >> > >> >STAC >> >STAC-9 >> >MS-Comp >> >None >> > >> >I set it to None and am having her try that. Does anyone know what could >> >be the issue? Which compression type is preffered? >> > >> >Brian >> > >> > >> >-------------------------------------------------------------------------- >> >Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider >> >Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ >> >signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, >> >(318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 >> > >> > >> >- >> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> > with "unsubscribe usr-tc" in the body of the message. >> > For information on digests or retrieving files and 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) | ShreveNet Inc. - Premium Internet Service Provider >Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ >signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, >(318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Leon McCalla wrote: > > would i get the same benefit if my telco uses a first available hunting > patern but the DSP uses a round robin mode? No. There is a bug in the HARC card which cases calls to fail when the DSP's use anything other than fixed assignment. Nick > > Leon > -----Original Message----- > > >We call this the "Dead Air" Syndrome, you have to , as Nick Suggested, lock > >your port assignments on your DSP cards (The Default) and then have your > >Telco switch your hunting pattern to :"Next Available" instead of "First > >Available", it may be called different names depending on your area, but > >basically calls come in and pass through your entire hunt trunk before > going > >to port one of the hunt again. This allows the modems that are > disconnecting > >calls to reset before another call hits them, hence preventing dead air. > > > >-Frank > > > >-----Original Message----- > >From: Nick Lott <nick@uk.insight.com> > >To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > >Date: Wednesday, September 16, 1998 9:08 AM > >Subject: Re: (usr-tc) Call reject rate on HiperDSP = 20% ?! > > > > > >>I had the same problem a while ago. Make sure that modem hunting on the > >>DSP is set to fixed assignment and your telco has your trunks set to > >>round robin. > >> > >>Save the config and then reboot the DSP. > >> > >>That worked for most of ours but some had to be rebooted multiple times > >>before they were working correctly. > >> > >>Regds > >> > >>Nick Lott > >> > >>Robert von Bismarck wrote: > >>> > >>> - > >>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >>> with "unsubscribe usr-tc" in the body of the message. > >>> For information on digests or retrieving files and 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.

Do Netservers and/or HiperARCs support MCPPP? Haven't been able to ind any info about this yet... thanks angela

Thus spake Angela A. Burford >Do Netservers and/or HiperARCs support MCPPP? Haven't been able to ind any >info about this yet... Well...if my MCPPP, then you're generically defining it, then yes...if that's a specific protocol used by a specific vendor, then no. To give a good idea of what they do support... netservers have supported MPIP (USR/3Com's proprietary multi-chassis MP solution) for quite some time...HiPer Arc's support of MPIP is in beta I believe. These do not interoperate with other vendors' equipment. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

We're having immense trouble with our telco, BellSouth (known hereafter as The BEAST). One representative of The BEAST, who works at the CO locally, told us that all of our lines are `OEs' (Pronounced Oh-Ees), and that we might have better results with trunks. What's the difference?

I meant to send this out yesterday, thought you folks would be interested..... Wednesday September 16, 6:59 am Eastern Time Company Press Release 3Com Applauds ITU's Final Decision for V.90 56K Standard SANTA CLARA, Calif.--(BUSINESS WIRE)--Sept. 16, 1998--3Com Corporation (Nasdaq:COMS - news) applauds the International Telecommunications Union's (ITU) final decision regarding the ratification of the V.90 56K(a) standard at its conference in Geneva, Switzerland. This decision cements the specifications for the standard that manufacturers agreed upon at an ITU meeting in February 1998. ``The ITU's decision offers further encouragement to consumers and Internet Service Providers (ISPs) when considering an upgrade or deployment of V.90,'' said Neil Clemmons, vice president of consumer marketing for 3Com. ``As streaming media transforms the way people use the Web, users will enjoy an improved Internet experience and the universal compatibility of an official ITU standard.'' More than 800 ISPs across North America and nearly 1,500 ISPs worldwide are now offering live V.90 service. These ISPs include industry leaders such as America Online, and when combined they represent nearly 20 million Internet users. In North America, there are now over 40,000 local dialup numbers that are live with V.90, making it far and away the world's most widely available high-speed Internet access technology. 56K modem sales have vastly improved over the past few months, according to PC Data. Year-to-date through June (1998 vs. 1997), the number of units sold have increased 7%. Meanwhile, sales for the month of June, 1998 are up 15% when compared to June, 1997. Additionally, in its July, 1998 report, research firm Dataquest forecasts an increase of more than 249% in 56K modems shipped worldwide (1998 vs. 1997). These figures are particularly significant because June has traditionally been a slow month for modem sales -- but demand for V.90 continues to grow. ``The final decision of the ITU 56K standard is good news for modem vendors,'' said Lisa Pelgrim, senior analyst at Dataquest. ``Both consumer and corporate buyers worldwide are now protected from risk and have the assurance that comes with international standards. This means the industry could see increased demand in the last quarter of 1998.'' Evolution Of The 56K Standard In September 1996, 3Com was the first company to submit a proposal to the ITU calling for a 56K recommendation. The work toward a standard began in North America within the ITU's Telecommunications Industry Association (TIA) committee, and in April 1997, the ITU officially set up a rapporteur's group with the goal of determining an international 56K standard as quickly as possible. In February 1998, a 56K standard specification was determined and assigned an official V-series number -- V.90. The technical aspects of the determined standard were thereby frozen. Because the technical aspects of the specification do not change, 3Com began shipping standards-based products and upgrades in calendar Q1 1998. The established practice of shipping standards-based products before the final and formal ratification is clearly a benefit for consumers, speeding the path toward universal compatibility and interoperability. At today's meeting, the ITU completed the formalities at which time the determined 56K recommendation became a ``decision,'' also referred to as ratification. About 3Com Corporation 3Com Corporation enables individuals and organizations worldwide to stay more connected by communicating and sharing information and resources at anytime, anywhere. As one of the world's preeminent suppliers of data, voice and video communications technology, 3Com has delivered networking solutions to more than 200 million customers worldwide. The company provides large enterprises, network service providers and carriers, small business and consumers with comprehensive, innovative information access products and system solutions for building intelligent, reliable and high performance local and wide area networks. For further information, visit 3Com's World Wide Web site at http://www.3com.com, or the press site at http://www.3com.com/pressbox. Note: (a) Capable of receiving at up to 56 Kbps and sending at up to 31.2 Kbps. Due to FCC regulations on power output, receiving speeds limited to 53 Kbps. Actual speeds may vary. Requires compatible phone line and server equipment. See www.3com.com/56k for details. Note to Editors: 3Com is a registered trademark of 3Com Corporation. Contact: 3Com Public Relations Craig Grabiner, 847/262-2329 craig_grabiner@3com.com or Coltrin & Associates Brad Thatcher, 212/221-1616 brad_thatcher@coltrin.com

>netservers have supported MPIP (USR/3Com's proprietary multi-chassis MP >solution) for quite some time...HiPer Arc's support of MPIP is in beta I >believe. These do not interoperate with other vendors' equipment. To further clarify this point. Yes, MPIP requires all 3Com equipment in the hunt. MPIP enables MLPPP to be accomplished across chassis. The resulting MLPPP does indeed interoperate with other vendor's implementations of MLPPP. Not intended as a correction, just didn't want anyone to get the idea you needed 3Com equipment on the dialing end to take advantage of MPIP on the head-end. JP

Thus spake John Powell >>netservers have supported MPIP (USR/3Com's proprietary multi-chassis MP >>solution) for quite some time...HiPer Arc's support of MPIP is in beta I >>believe. These do not interoperate with other vendors' equipment. >To further clarify this point. Yes, MPIP requires all 3Com equipment in >the hunt. MPIP enables MLPPP to be accomplished across chassis. The >resulting MLPPP does indeed interoperate with other vendor's >implementations of MLPPP. >Not intended as a correction, just didn't want anyone to get the idea you >needed 3Com equipment on the dialing end to take advantage of MPIP on the >head-end. Wuuf...thanks for the clarification...I hadn't even thought of that interpretation. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Once upon a time Brian shaped the electrons to say... >STAC This is a pre-RFC whack at it. >STAC-9 This is the RFC standard Option 3 <- use this. >MS-Comp This is aka MS-Stac - RFC standard Option 4. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

Once upon a time Angela A. Burford shaped the electrons to say... >Do Netservers and/or HiperARCs support MCPPP? Haven't been able to ind any >info about this yet... MCPPP is Lucent RABU's Multi-Chassis PPP. That's vendor specific. More generically 3Com does support stacking chassis, their system is called MPIP. Supported on the NetServer, but not yet on the HiPer ARC. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

I tried netserver 3.8.1 in a chassis with 12 quads and 2 hdms. I upgraded the hdms to 1.2.5 to try out the v.90 support. In short the chassis is running the firmware versions listed in TCS 3.1.2. The problem is I see severe UDP/Quake lag on both the quads and hdms. Six other racks running netserver 3.7.24 do not have this problem. The 3.8.1 release notes say there are fixes for Quake POD (pause of death?) but it looks worse than ever. Is anyone running 3.7.24 with the hdm 1.2.5 code? Any problems? Is anyone running 3.8.1 and not getting complaints from Quake players? SubSpace is another UDP based network game and it also lags badly using 3.8.1 but works fine using 3.7.24. In all cases I'm calling from the same PC using the same modem (Courier v.everything v.90) and same phone. Thanks, --- Brian K. Uechi Email: brianu@lava.net Technical Support Engineer Phone: 808-545-5282 LavaNet, Inc. FAX : 808-545-7020

On Thu, 17 Sep 1998, MegaZone wrote: > X-Trade-Organization-1: Internet Service Providers' Consortium (ISP/C) > X-Trade-Organization-2: Director At Large <URL:http://www.ispc.org/> > X-SHOW-1: ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. > X-SHOW-2: Three days of clues, news, and views from the industry's best and > X-SHOW-3: brightest. http://www.ispf.com/ for information and registration. > X-Mailer: ELM [version 2.4ME+ PL38 (25)] > MIME-Version: 1.0 > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: 7bit > Sender: owner-usr-tc@lists.xmission.com > Precedence: bulk > Reply-To: usr-tc@lists.xmission.com > > Once upon a time Angela A. Burford shaped the electrons to say... > >Do Netservers and/or HiperARCs support MCPPP? Haven't been able to ind any > >info about this yet... > > MCPPP is Lucent RABU's Multi-Chassis PPP. That's vendor specific. > > More generically 3Com does support stacking chassis, their system is called > MPIP. Supported on the NetServer, but not yet on the HiPer ARC. Correction - MPIP is supported in both HiPer arc and NETServer. HiPer arc MPIP support is in the latest code - 4.1.11 krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec > > -MZ > -- > <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. > Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> > "A little nonsense now and then, is relished by the wisest men" 781-788-0130 > <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia! > ==================================================================== > ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. > Three days of clues, news, and views from the industry's best and > brightest. http://www.ispf.com/ for information and registration. > ==================================================================== > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

What's the command to clear a Netserver back to factory default settings? I have modem access to the console port so reconfiguring the IP address, etc. won't be a problem. This is a remote unit so I can't flip DIP switches. Thanks, --- Brian K. Uechi Email: brianu@lava.net Technical Support Engineer Phone: 808-545-5282 LavaNet, Inc. FAX : 808-545-7020

>Wuuf...thanks for the clarification...I hadn't even thought of that >interpretation. :) OK, so I am paranoid ;) I deserved that abuse. JP

Thanks, it works great. On Fri, 18 Sep 1998, Ricky Beam wrote: > Brian Uechi was heard to say: > >What's the command to clear a Netserver back to factory default > >settings? I have modem access to the console port so reconfiguring > >the IP address, etc. won't be a problem. This is a remote unit so I > >can't flip DIP switches. > > 'erase flash' (I think) It will commit an empty config to the flash. > It will not erase the IP settings tho' so you can still get into it. > > --Ricky

Brian Uechi was heard to say: >What's the command to clear a Netserver back to factory default >settings? I have modem access to the console port so reconfiguring >the IP address, etc. won't be a problem. This is a remote unit so I >can't flip DIP switches. 'erase flash' (I think) It will commit an empty config to the flash. It will not erase the IP settings tho' so you can still get into it. --Ricky

Hello, I am the gentleman that is known for posting ill-informed, overly general questions due to the fact that I do not have anything to do with my ISP's modem pools except for the fact that configure our end-users for our modems. Here is my question. What would cause a WindowsNT user with a Sportster 28.8/33.6 External running on Com 1 to get "Error 629 : The port was disconnected by the remote machine". Sean -----Original Message----- >Thanks, it works great. > >On Fri, 18 Sep 1998, Ricky Beam wrote: > >> Brian Uechi was heard to say: >> >What's the command to clear a Netserver back to factory default >> >settings? I have modem access to the console port so reconfiguring >> >the IP address, etc. won't be a problem. This is a remote unit so I >> >can't flip DIP switches. >> >> 'erase flash' (I think) It will commit an empty config to the flash. >> It will not erase the IP settings tho' so you can still get into it. >> >> --Ricky > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian Uechi |Sent: Thursday, September 17, 1998 11:57 PM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) Netserver 3.8.1 and UDP lag | | |I tried netserver 3.8.1 in a chassis with 12 quads and 2 hdms. I |upgraded the hdms to 1.2.5 to try out the v.90 support. In short the |chassis is running the firmware versions listed in TCS 3.1.2. | |The problem is I see severe UDP/Quake lag on both the quads and hdms. |Six other racks running netserver 3.7.24 do not have this problem. |The 3.8.1 release notes say there are fixes for Quake POD (pause of |death?) but it looks worse than ever. | |Is anyone running 3.7.24 with the hdm 1.2.5 code? Any problems? |Is anyone running 3.8.1 and not getting complaints from Quake |players? SubSpace is another UDP based network game and it also |lags badly using 3.8.1 but works fine using 3.7.24. | Do the chassis running 3.7.24 that do not have the POD problem contain 2 DSP's & 12 quads as well?? -M

How do I get a HARC to use the ip pool I set up? It always assigns the dialin user 0.0.0.0. Thanks, Ted

Hello, Sorry if it is covered by a FAQ but I didn't find such FAQ. I had problems upgrading netserver firmware to 3.8.1 with the TCM. So i uploaded it with the netserver manager. Now, when I connect with TCM it still shows the netserver being 3.7.24 whereas the version shown by the "version" command in a telnet session with the netserver is 3.8.1. In the software download window of the TCM, it shows me I should download 3.8.1 of netserver and 5.5.5 of NMC. But it's show NMC version as 5.5.5 in the inventory !! When we had to upgrade quad modems it didn't show me quad modems with old versions in red show it doesn't work well ! Do you have an explanation of that ? Is something wrong in my TC or it is only a problem with TCM ? Regards, Luc.

I also got this error when setting up dialup networking for WinNT 4.0. When using the DUN wizard, under Server settings, I did not check the last option: The non-Windows NT server I am calling expects me to type login... I realized that this option must be checked since I wasn't using a script to connect. This allowed me to get passed the 629 error to establish a connection. Some of my users are now getting error 629 when setting up Windows 98. I haven't fixed this problem yet. The error doesn't come up all the time. Does anyone have a reason on why this is happening? Thanks in advance. | Cassandra M. Perkins | People usually get what's coming to | | Network Operations | them... unless it's been mailed. | | The Loop Internet Switch Co., LLC | -fortune | On Fri, 18 Sep 1998, Sean Bober wrote: > Hello, > > I am the gentleman that is known for posting ill-informed, overly general > questions due to the fact that I do not have anything to do with my ISP's > modem pools except for the fact that configure our end-users for our modems. > Here is my question. What would cause a WindowsNT user with a Sportster > 28.8/33.6 External running on Com 1 to get "Error 629 : The port was > disconnected by the remote machine". > > > > Sean > -----Original Message----- > From: Brian Uechi <brianu@lava.net> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Friday, September 18, 1998 5:59 AM > Subject: Re: (usr-tc) Clearing Netserver config to defaults > > > >Thanks, it works great. > > > >On Fri, 18 Sep 1998, Ricky Beam wrote: > > > >> Brian Uechi was heard to say: > >> >What's the command to clear a Netserver back to factory default > >> >settings? I have modem access to the console port so reconfiguring > >> >the IP address, etc. won't be a problem. This is a remote unit so I > >> >can't flip DIP switches. > >> > >> 'erase flash' (I think) It will commit an empty config to the flash. > >> It will not erase the IP settings tho' so you can still get into it. > >> > >> --Ricky > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and 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. >

Why does my radius server receive User-Service-Type = Login-User from my HARC? I need to change this to User-Service-Type = Framed-User. Thanks, Ted

ARC 4.1.11 was released yesterday on TotalService. This code has MPIP support which appears here to be working. Brian Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

See if the user has anything in the "domain" line on the page that has the username and password. If they do remove it. If that fails try making a new phonebook entry. Chris Gruttke Level 2 Tech Frontier Globalcenter cgruttke@globalcenter.net At 04:00 PM 9/18/98 -0400, you wrote: >Sean Bober wrote: > >> I am the gentleman that is known for posting ill-informed, overly general >> questions due to the fact that I do not have anything to do with my ISP's >> modem pools except for the fact that configure our end-users for our modems. >> Here is my question. What would cause a WindowsNT user with a Sportster >> 28.8/33.6 External running on Com 1 to get "Error 629 : The port was >> disconnected by the remote machine". > >good question. i've tried for about 6 months now to get an answer. 3comhasn't >been any help. they telneted into my tc hub and all the settings were >fine. after making sure it had nothing to do with us, we are now trying >to fight with the phone company to check their switches. it's only been >two days, and already they found a ton of problems with the way their >tech's programed the switches for our POTS. > >hopefully when whey fix the problem with the programming, everything >will work fine. i'll let everyone know what i find. > >c-ya! :-) > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Could someone help me figure out why I can't use all the built in accounting features of the Accounting Server. Specifically, when I do an accounting report, select a user name, and select "Call statistics by day", it comes back with #Error all over the form. Can anyone help? thanks, craig

On Fri, 18 Sep 1998, Jamin Cummings wrote: > Chris Gruttke wrote: > > > See if the user has anything in the "domain" line on the page that has the > > username and password. If they do remove it. If that fails try making a new > > phonebook entry. > We have seen this problem when Hellsouth runs their SLC's in mode2........might want to check that.......perhaps someone on here can give the technical explaination about why mode2 sucks for modem connections, but basically I believe it cuts the available channel bandwidth in half, sometimes allowing slow connections only like 14.4 or 9600, or possibly nothing. > most of our users use win95. but it happens no matter what operating > systemtheir using. win 3.x, win95, win98, winNT, etc ... it's something wrong > with the way the modems themselfs are talking to eachother, or the phone > lines themselfs. > > it doesn't even have to be when your trying to connect with tcp/ip either. > when you dial in with hyper-terminal or any program like that (even > dos versions of terminal programs) it happens. so there's no way it > can be software related ... at least with my problem. > > c-ya! :-) > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Sean Bober wrote: > I am the gentleman that is known for posting ill-informed, overly general > questions due to the fact that I do not have anything to do with my ISP's > modem pools except for the fact that configure our end-users for our modems. > Here is my question. What would cause a WindowsNT user with a Sportster > 28.8/33.6 External running on Com 1 to get "Error 629 : The port was > disconnected by the remote machine". good question. i've tried for about 6 months now to get an answer. 3comhasn't been any help. they telneted into my tc hub and all the settings were fine. after making sure it had nothing to do with us, we are now trying to fight with the phone company to check their switches. it's only been two days, and already they found a ton of problems with the way their tech's programed the switches for our POTS. hopefully when whey fix the problem with the programming, everything will work fine. i'll let everyone know what i find. c-ya! :-)

It means the remote system disconnected the NT or Win95 system because of improper protocol or improper authorization. My quess is you have encrypted passwords selected on your NT system. Check that "Allow Clear Text Passwords" -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Sean Bober Sent: Friday, September 18, 1998 6:56 AM Hello, I am the gentleman that is known for posting ill-informed, overly general questions due to the fact that I do not have anything to do with my ISP's modem pools except for the fact that configure our end-users for our modems. Here is my question. What would cause a WindowsNT user with a Sportster 28.8/33.6 External running on Com 1 to get "Error 629 : The port was disconnected by the remote machine". Sean -----Original Message----- >Thanks, it works great. > >On Fri, 18 Sep 1998, Ricky Beam wrote: > >> Brian Uechi was heard to say: >> >What's the command to clear a Netserver back to factory default >> >settings? I have modem access to the console port so reconfiguring >> >the IP address, etc. won't be a problem. This is a remote unit so I >> >can't flip DIP switches. >> >> 'erase flash' (I think) It will commit an empty config to the flash. >> It will not erase the IP settings tho' so you can still get into it. >> >> --Ricky > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and 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.

I am wanting to make a mib.txt from the latest nmc mibs but I have forgotten how. You can't just "cat *.mib >> mib.txt", I think it was David Bolen that said something about leaving certain mibs out. I know about the header (what to change at the top of the mib file), but I am uncertain about which mibs you leave out and include, and whether or not the order was important. If anyone knows please let me know. The mib I am using doesnt have v90 modulation types etc. Brian Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

On Fri, 18 Sep 1998, Jamin Cummings wrote: > Brian wrote: > > > We have seen this problem when Hellsouth runs their SLC's in > > mode2........might want to check that.......perhaps someone on here can > > give the technical explaination about why mode2 sucks for modem > > connections, but basically I believe it cuts the available channel > > bandwidth in half, sometimes allowing slow connections only like 14.4 or > > 9600, or possibly nothing. > > finaly ... something to start with. thanks brian. i've tried posting messages > in here before, but no sucess. now that someone else has the same problem > maybe we can come up with something. (can you tell i'm a little stressed, > 6 months of angree customers does that to a guy). ;-) > > anyway ... what does SLC stand for? i just want to know when i suggest > this to bell atlantic. Subscriber Loop Carrier > > thanks in advace to anyone that helps out with this problem. c-ya! :-) > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Chris Gruttke wrote: > See if the user has anything in the "domain" line on the page that has the > username and password. If they do remove it. If that fails try making a new > phonebook entry. most of our users use win95. but it happens no matter what operating systemtheir using. win 3.x, win95, win98, winNT, etc ... it's something wrong with the way the modems themselfs are talking to eachother, or the phone lines themselfs. it doesn't even have to be when your trying to connect with tcp/ip either. when you dial in with hyper-terminal or any program like that (even dos versions of terminal programs) it happens. so there's no way it can be software related ... at least with my problem. c-ya! :-)

On Fri, 18 Sep 1998, Jamin Cummings wrote: > Brian wrote: > > > On Fri, 18 Sep 1998, Jamin Cummings wrote: > > > > > anyway ... what does SLC stand for? i just want to know when i suggest > > > this to bell atlantic. > > > > Subscriber Loop Carrier > > i'm on the phone with bell atlantic right now. how exactly do i explainabout the > SLC and the mode 2? what do i have them check? Your phone lines from your house run into a SLC. If its in mode2 then it could cause problems. I have seen this in hellsouth, and after they moved them from mode 2 to mode 1 things cleared up. I think the mode has to do with the level of concentration going on, thus reducing the amount of datapath available for your subscriber line. Although it works well for voice, data pays the price.....but then again bell only guarantees 9600, at least that's how it use to be. > > c-ya! :-) > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

It sounds like it might be a RADIUS problem. Maybe it's timing out when trying to get an Ack from your RADIUS server. It especially sounds suspicious if you dial in with a terminal emulator and it still disconnects you. We had this happen sometimes when our radius server got bogged down. Sometimes it happened even if it failed over to secondary RADIUS. Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com -----Original Message----- >it doesn't even have to be when your trying to connect with tcp/ip either. >when you dial in with hyper-terminal or any program like that (even >dos versions of terminal programs) it happens. so there's no way it >can be software related ... at least with my problem. > >c-ya! :-)

Brian wrote: > We have seen this problem when Hellsouth runs their SLC's in > mode2........might want to check that.......perhaps someone on here can > give the technical explaination about why mode2 sucks for modem > connections, but basically I believe it cuts the available channel > bandwidth in half, sometimes allowing slow connections only like 14.4 or > 9600, or possibly nothing. finaly ... something to start with. thanks brian. i've tried posting messages in here before, but no sucess. now that someone else has the same problem maybe we can come up with something. (can you tell i'm a little stressed, 6 months of angree customers does that to a guy). ;-) anyway ... what does SLC stand for? i just want to know when i suggest this to bell atlantic. thanks in advace to anyone that helps out with this problem. c-ya! :-)

Peter D. Mayer wrote: > It sounds like it might be a RADIUS problem. Maybe it's timing out when > trying to get an Ack from your RADIUS server. It especially sounds > suspicious if you dial in with a terminal emulator and it still disconnects > you. We had this happen sometimes when our radius server got bogged down. > Sometimes it happened even if it failed over to secondary RADIUS. with my problem ... it happens exactly 3 seconds after the connection is made. and it's not radius (already tried 3 different software programs), because it hangs up on people right in the middle of the tc hub "saying" username at the login prompt. it says user then dies. it never gets anywhere near asking radius for authenication. thanks. c-ya! :-)

Brian <signal@shreve.net> writes: > I am wanting to make a mib.txt from the latest nmc mibs but I have > forgotten how. You're talking about for the CMU SNMP library right? > You can't just "cat *.mib >> mib.txt", I think it was David Bolen that > said something about leaving certain mibs out. Here's an excerpt from a note back in April covering this - it should probably still hold: In-Reply-To: Your message of Thu, 2 Apr 1998 17:55:43 -0500 (EST) Message-ID: <CMM.0.90.2.891560532.db3l@valheru.ny.ans.net> Horace Demmink <horace@pathwaynet.com> writes: > Hello, does anyone have a copy of the 3.1 mibs that is compatible with > MRTG and cmu-snmp snmpwalk/snmpget/etc. I am trying to get information > from these racks and am currently limited to the generic mibs that come > with it. I don't have any built at the moment, but you can pretty much use the MIBs that are distributed as part of TCS 3.1 with just a small amount of file munging. You do need to do the following: * Prepend them with a copy of the SNMPv1 SMI (RFC-1155) * Prepend them with a copy of MIB-II (RFC-1213) or at a minimum, include the textual convention for DisplayString. * Don't include the chs_trap.mib file - just leave it out. In the CMU tree, the default mib.txt has this stuff although it also has a bunch of other things, but if you just stuff all the USR MIB files after it into a single file you should be ok. If you want it a bit smaller, just prefixing the following (the SMI plus the textual convention) should work: RFC1155-SMI DEFINITIONS ::= BEGIN; nullOID OBJECT IDENTIFIER ::= { ccitt 0 } internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 } directory OBJECT IDENTIFIER ::= { internet 1 } mgmt OBJECT IDENTIFIER ::= { internet 2 } experimental OBJECT IDENTIFIER ::= { internet 3 } private OBJECT IDENTIFIER ::= { internet 4 } enterprises OBJECT IDENTIFIER ::= { private 1 } -- Cheat (not really part of 1155) DisplayString ::= OCTET STRING END but if you leave out RFC1213 and include RFC1406 (DS1) as included with the TC MIBs, you'll get a complaint about being unable to link the ds1 object into the transmission tree - it should work anyway though, unless you wanted to query those objects :-) (Note the extra semicolon in the above after the BEGIN - that's to get around a CMU parsing error when a MIB doesn't have any IMPORTS/EXPORTS) Doing the above (without the display string) and RFC1213, followed by the TC MIBs should be fine and include everything. (...) -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Brian wrote: > On Fri, 18 Sep 1998, Jamin Cummings wrote: > > > anyway ... what does SLC stand for? i just want to know when i suggest > > this to bell atlantic. > > Subscriber Loop Carrier i'm on the phone with bell atlantic right now. how exactly do i explainabout the SLC and the mode 2? what do i have them check? c-ya! :-)

Brian wrote: > Your phone lines from your house run into a SLC. If its in mode2 then it > could cause problems. I have seen this in hellsouth, and after they moved > them from mode 2 to mode 1 things cleared up. I think the mode has to do > with the level of concentration going on, thus reducing the amount of > datapath available for your subscriber line. Although it works well for > voice, data pays the price.....but then again bell only guarantees 9600, > at least that's how it use to be. thanks for the info. i just got off the phone with bell atlantic. the peoplethere couldn't help me. they are going to have a forman call me monday morning. the lady i spoke with said that are records don't show us using a SLC. so is that on our subscribers side? the good thing about talking to bell atlantic is i can slam them hard because we have another site about 5 towns east of here that is running the same exact equipment setup the exact same way and it's working fine. so i've got proof it's their fault (at least it would seem that way). if anyone else has any ideas on what to tell/ask them let me know. maybe i can get a straight answer and a solution to help out you guys in the future. i'll let you all know what i find out. c-ya! :-)

Brian was heard to say: >We have seen this problem when Hellsouth runs their SLC's in >mode2........might want to check that.......perhaps someone on here can >give the technical explaination about why mode2 sucks for modem >connections, but basically I believe it cuts the available channel >bandwidth in half, sometimes allowing slow connections only like 14.4 or >9600, or possibly nothing. Isn't "mode2" "multiplexed to hell and only part way back"? --Ricky

Brian was heard to say: >I am wanting to make a mib.txt from the latest nmc mibs but I have >forgotten how. > >You can't just "cat *.mib >> mib.txt", I think it was David Bolen that >said something about leaving certain mibs out. I know about the header >(what to change at the top of the mib file), but I am uncertain about >which mibs you leave out and include, and whether or not the order was >important. If anyone knows please let me know. The mib I am using doesnt >have v90 modulation types etc. That's basically what I did... I had to remove all the TRAP entries as CMU-SNMP doesn't grok them critters. It makes for a huge mib file, tho'. --Ricky

Brian was heard to say: >Your phone lines from your house run into a SLC. If its in mode2 then it >could cause problems. I have seen this in hellsouth, and after they moved >them from mode 2 to mode 1 things cleared up. I think the mode has to do >with the level of concentration going on, thus reducing the amount of >datapath available for your subscriber line. Although it works well for >voice, data pays the price.....but then again bell only guarantees 9600, >at least that's how it use to be. Consult the FCC... it's a "voice" line. If your ears cannot detect any different, then it's perfectly ok. There are measured tolerances that the FCC does enforce (or can if you alert them to it.) Depends on the telco as to what they will do to "fix" the problem -- strictly speaking, they don't have to replace it. --Ricky

On Fri, 18 Sep 1998, Jamin Cummings wrote: > Brian wrote: > > > Your phone lines from your house run into a SLC. If its in mode2 then it > > could cause problems. I have seen this in hellsouth, and after they moved > > them from mode 2 to mode 1 things cleared up. I think the mode has to do > > with the level of concentration going on, thus reducing the amount of > > datapath available for your subscriber line. Although it works well for > > voice, data pays the price.....but then again bell only guarantees 9600, > > at least that's how it use to be. > > thanks for the info. i just got off the phone with bell atlantic. the peoplethere > couldn't help me. they are going to have a forman call me monday > morning. the lady i spoke with said that are records don't show us using > a SLC. so is that on our subscribers side? Yes, its entirley a subscriber side device for individule lines. The people dialing into you may be going thru it. I wasn't saying YOUR lines are on the SLC, its your subscribers. > > the good thing about talking to bell atlantic is i can slam them hard because > we have another site about 5 towns east of here that is running the same > exact equipment setup the exact same way and it's working fine. so i've got > proof it's their fault (at least it would seem that way). > > if anyone else has any ideas on what to tell/ask them let me know. maybe > i can get a straight answer and a solution to help out you guys in the future. > > i'll let you all know what i find out. > > c-ya! :-) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

On Fri, 18 Sep 1998, Ricky Beam wrote: > Brian was heard to say: > >We have seen this problem when Hellsouth runs their SLC's in > >mode2........might want to check that.......perhaps someone on here can > >give the technical explaination about why mode2 sucks for modem > >connections, but basically I believe it cuts the available channel > >bandwidth in half, sometimes allowing slow connections only like 14.4 or > >9600, or possibly nothing. > > Isn't "mode2" "multiplexed to hell and only part way back"? yes, thats mode 2 :) > > --Ricky > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Is anyone else having trouble getting a Netserver 3.8.1 to bring up a multilink PPP session? It seems the one I'm playing with is not even allowing MP to be negotiated at all. --Ricky

On Wed, 31 Jan 1990, Clayton Zekelman wrote: From all this we can probably deduce that the tech was saying right now he's served line side and that the customer would be better served with a trunk side connection... I can't tell if the original poster was dealing with individual POTS lines or a CT1. Charles > Date: Wed, 31 Jan 1990 01:02:49 +0000 > From: Clayton Zekelman <clayton@MNSi.Net> > Reply-To: usr-tc@lists.xmission.com > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) `trunks' versus `OEs' -- difference? > > An "OE" in DMS speak is physical port your equipment is connected to. Its > the way the switch identifies an individual line port, exclusive of the > phone number assigned to it. Not sure what he's trying to tell you from > that though. > > > At 02:59 PM 9/17/98 -0400, you wrote: > > > >We're having immense trouble with our telco, BellSouth (known hereafter > >as The BEAST). One representative of The BEAST, who works at the CO locally, > >told us that all of our lines are `OEs' (Pronounced Oh-Ees), and that we > might > >have better results with trunks. > > > >What's the difference? > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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. > 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. > =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

> Do the chassis running 3.7.24 that do not have the POD problem contain 2 DSP's & > 12 quads as well?? I have 2 chassises with 3.7.24, 12 quads and 2 hdms and no POD. I'm doing more testing to verify this though.

Thus spake Brian >On Fri, 18 Sep 1998, Ricky Beam wrote: >> Brian was heard to say: >> >We have seen this problem when Hellsouth runs their SLC's in >> >mode2........might want to check that.......perhaps someone on here can >> >give the technical explaination about why mode2 sucks for modem >> >connections, but basically I believe it cuts the available channel >> >bandwidth in half, sometimes allowing slow connections only like 14.4 or >> >9600, or possibly nothing. >> Isn't "mode2" "multiplexed to hell and only part way back"? >yes, thats mode 2 :) Only part way back? :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

I've got a 56k frame relay circuit to my home that has been nothing but problems since last November. Lately they have been spending a lot of time trying to fix this monster once and for all. It will work well for days and then totally shut down for hours. Just this week, they told me it was running through a SLC out here. I think they said it was mode 3, could that cause the problem? If 2 is hellacious, would 3 be better or worse? At 06:54 PM 9/18/98 -0500, you wrote: >On Fri, 18 Sep 1998, Ricky Beam wrote: > >> Brian was heard to say: >> >We have seen this problem when Hellsouth runs their SLC's in >> >mode2........might want to check that.......perhaps someone on here can >> >give the technical explaination about why mode2 sucks for modem >> >connections, but basically I believe it cuts the available channel >> >bandwidth in half, sometimes allowing slow connections only like 14.4 or >> >9600, or possibly nothing. >> >> Isn't "mode2" "multiplexed to hell and only part way back"? > >yes, thats mode 2 :) > >> >> --Ricky >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider >Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ >signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, >(318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 v.90 56k access in Casper & Douglas CoffeyNet Casper, Douglas, Rawlins, Lusk, Lander, Pinedale 142 S. Center St http://www.coffey.com Casper, WY 82610 Open 8-6 M-F 10-2 Sat 307-234-5443 Til 8PM on Thurs

We started out with what you are describing, line side trunks. You will not be able to get a 56k connect because they are not digital all the way to you. There is a conversion because they have a two wire connect to the switch instead of the 4 wire you need for digital. Two wire by definition is analog. "Trunk side" is the important term or 4 wire E&M will get you where you want to be. This was a very expensive lesson for me to deal with 18 months ago. I don't completely understand it all but I suspect that I could probably sit up in bed when I'm 90 at two o'clock in the morning and cite you the difference. At 10:07 PM 9/18/98 -0400, you wrote: >: From all this we can probably deduce that the tech was saying right now >: he's served line side and that the customer would be better served with a >: trunk side connection... I can't tell if the original poster was dealing >: with individual POTS lines or a CT1. > >Original poster here -- we use CT1s, provisioned ESF/B8ZS/Ground Start. >The CO has a 1AESS switch right now, and they've assured us that we >can't have trunk-side CT1s until they do the switch upgrade in 9 weeks. > >He did comment that all of our competition's lines are `trunks', though. >Is it possible to have trunk-side T1s with an analog switch? > >When our lines work, they work fine. But we can't busy out individual >channels (DS0s), we can't busy out whole CT1s by putting them in >loopback, and we have to report channels hung in the switch that are >causing RNA almost every day. > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 v.90 56k access in Casper & Douglas CoffeyNet Casper, Douglas, Rawlins, Lusk, Lander, Pinedale 142 S. Center St http://www.coffey.com Casper, WY 82610 Open 8-6 M-F 10-2 Sat 307-234-5443 Til 8PM on Thurs

: From all this we can probably deduce that the tech was saying right now : he's served line side and that the customer would be better served with a : trunk side connection... I can't tell if the original poster was dealing : with individual POTS lines or a CT1. Original poster here -- we use CT1s, provisioned ESF/B8ZS/Ground Start. The CO has a 1AESS switch right now, and they've assured us that we can't have trunk-side CT1s until they do the switch upgrade in 9 weeks. He did comment that all of our competition's lines are `trunks', though. Is it possible to have trunk-side T1s with an analog switch? When our lines work, they work fine. But we can't busy out individual channels (DS0s), we can't busy out whole CT1s by putting them in loopback, and we have to report channels hung in the switch that are causing RNA almost every day.

Jeff Mcadams was heard to say: >>> Isn't "mode2" "multiplexed to hell and only part way back"? > >>yes, thats mode 2 :) > >Only part way back? :) Heh, yeah, translation: a little piece of you is stuck in hell. (I'm sure you know the feeling :-)) --Ricky

Tatai SV Krishnan was heard to say: >In order to get this working with IP address do this > >enable auth hint >set ppp session_stat "PPP starting from or whate ever %client_ip %server_ip Can you explain why v4.1.11 will not do as you would expect with the following: set ppp session_start "PPP session from (%server_ip) to (%client_ip) beginning...\r\n" ??? Neither the "\r\n" part nor the "%blah" parts work correctly. Without the "()" it I get the IP's (I think) but no "\n"??? Methinks there maybe some coding foofoo in there somewhere. (Why do I feel like I can make the ARC crash if I start getting fancy?) --Ricky

Thus spake Mark R. Lindsey >Original poster here -- we use CT1s, provisioned ESF/B8ZS/Ground Start. >The CO has a 1AESS switch right now, and they've assured us that we >can't have trunk-side CT1s until they do the switch upgrade in 9 weeks. Heh...have fun...one of the main reasons we went with ICG...we were on a 1A with BellSouth. We actually resorted to ordering PRI from BellSouth a little bit (even though it was more expensive) so they would *have* to foreign exchange us since they wouldn't do it under normal circumstances. And this is the company that talks about winning customer service awards? >He did comment that all of our competition's lines are `trunks', though. >Is it possible to have trunk-side T1s with an analog switch? They would have to be on a different switch. >When our lines work, they work fine. But we can't busy out individual >channels (DS0s), we can't busy out whole CT1s by putting them in >loopback, and we have to report channels hung in the switch that are >causing RNA almost every day. Personally, I think they should foreign exchange you for customer service reasons, but there's no way on earth they'll do that...and with the switch being upgraded in 9 weeks...well...it'd proly take them that long to get the foreign exchange stuff worked out anyway. :/ -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

That is funny that you mentioned that. I was just thinking the same thing. I've only configured one of these things before. We shall see what happens. Sean -----Original Message----- >It means the remote system disconnected the NT or Win95 system because of >improper protocol or improper authorization. My quess is you have encrypted >passwords selected on your NT system. Check that "Allow Clear Text >Passwords" > > > >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Sean Bober >Sent: Friday, September 18, 1998 6:56 AM >To: usr-tc@lists.xmission.com >Subject: (usr-tc) Error 629 > > >Hello, > >I am the gentleman that is known for posting ill-informed, overly general >questions due to the fact that I do not have anything to do with my ISP's >modem pools except for the fact that configure our end-users for our modems. >Here is my question. What would cause a WindowsNT user with a Sportster >28.8/33.6 External running on Com 1 to get "Error 629 : The port was >disconnected by the remote machine". > > > >Sean >-----Original Message----- >From: Brian Uechi <brianu@lava.net> >To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >Date: Friday, September 18, 1998 5:59 AM >Subject: Re: (usr-tc) Clearing Netserver config to defaults > > >>Thanks, it works great. >> >>On Fri, 18 Sep 1998, Ricky Beam wrote: >> >>> Brian Uechi was heard to say: >>> >What's the command to clear a Netserver back to factory default >>> >settings? I have modem access to the console port so reconfiguring >>> >the IP address, etc. won't be a problem. This is a remote unit so I >>> >can't flip DIP switches. >>> >>> 'erase flash' (I think) It will commit an empty config to the flash. >>> It will not erase the IP settings tho' so you can still get into it. >>> >>> --Ricky >> >> >>- >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and 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. >

I have had the EXACT same results ... I have 13 Quads and 2 DSP`s (96 lines) per + chassis ... 3.8.0 worked and so did 3.7.73 (3.8.0 had a few pauses) ... but 3. +8.1 would not even work with quake2 ... (or any UDP based game for that matter) + ... I could play for mabey 30 seconds and then my netgraph would just show a l +arge green bar and ping time would shoot upto 1175 ... I usually test new (and +old code) ... I tried 3.7.24 on this box and I have never seen better quake2 pl +ay (on a USR box) ... it still is bad but at least it`s playable on ISDN at lea +st .... just wondering what all these PPP latency fixes are supposed to do beca +use they are not working for me ... I also installed SUBSPACe and tried it anda +lso got the same results ... 3.7.24 works for it but 3.8.1 lags bad ... Quoting usr-tc@lists.xmission.com: > I tried netserver 3.8.1 in a chassis with 12 quads and 2 hdms. I > upgraded the hdms to 1.2.5 to try out the v.90 support. In short the > chassis is running the firmware versions listed in TCS 3.1.2. > > The problem is I see severe UDP/Quake lag on both the quads and hdms. > Six other racks running netserver 3.7.24 do not have this problem. > The 3.8.1 release notes say there are fixes for Quake POD (pause of > death?) but it looks worse than ever. > > Is anyone running 3.7.24 with the hdm 1.2.5 code? Any problems? > Is anyone running 3.8.1 and not getting complaints from Quake > players? SubSpace is another UDP based network game and it also > lags badly using 3.8.1 but works fine using 3.7.24. > > In all cases I'm calling from the same PC using the same modem > (Courier v.everything v.90) and same phone. > > Thanks, > --- > Brian K. Uechi Email: brianu@lava.net > Technical Support Engineer Phone: 808-545-5282 > LavaNet, Inc. FAX : 808-545-7020 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Hey guys! Thanks for giving me so much to work with. I truly appreciate all of the help that you have given me on this topic. I will keep you informed as to what the outcome of this undertaking is. The Vague One<----Sean Bober

It is me again..."The Vague One" I figured that, since everybody has been so responsive to my last vague post, I would post another vague one. My latest work in vagueness has to do with the possible configurations of Windows 95/98 users. Here goes: What configuration change to would cause clients who were configured to have server assigned DNS information (not DHCP) to not be able to connect? The only way they now connect is by specifying DNS information in both the "network" area and the "dial-up networking area". Disabling wins resolution doesn't hurt their ability to dial-up either (once they have specified the DNS information). -----Original Message----- >That is funny that you mentioned that. I was just thinking the same thing. >I've only configured one of these things before. We shall see what happens. > > > >Sean >-----Original Message----- >From: Jose de Leon <jadiel@thevision.net> >To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >Date: Friday, September 18, 1998 6:12 PM >Subject: RE: (usr-tc) Error 629 > > >>It means the remote system disconnected the NT or Win95 system because of >>improper protocol or improper authorization. My quess is you have >encrypted >>passwords selected on your NT system. Check that "Allow Clear Text >>Passwords" >> >> >> >>-----Original Message----- >>From: owner-usr-tc@lists.xmission.com >>[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Sean Bober >>Sent: Friday, September 18, 1998 6:56 AM >>To: usr-tc@lists.xmission.com >>Subject: (usr-tc) Error 629 >> >> >>Hello, >> >>I am the gentleman that is known for posting ill-informed, overly general >>questions due to the fact that I do not have anything to do with my ISP's >>modem pools except for the fact that configure our end-users for our >modems. >>Here is my question. What would cause a WindowsNT user with a Sportster >>28.8/33.6 External running on Com 1 to get "Error 629 : The port was >>disconnected by the remote machine". >> >> >> >>Sean >>-----Original Message----- >>From: Brian Uechi <brianu@lava.net> >>To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >>Date: Friday, September 18, 1998 5:59 AM >>Subject: Re: (usr-tc) Clearing Netserver config to defaults >> >> >>>Thanks, it works great. >>> >>>On Fri, 18 Sep 1998, Ricky Beam wrote: >>> >>>> Brian Uechi was heard to say: >>>> >What's the command to clear a Netserver back to factory default >>>> >settings? I have modem access to the console port so reconfiguring >>>> >the IP address, etc. won't be a problem. This is a remote unit so I >>>> >can't flip DIP switches. >>>> >>>> 'erase flash' (I think) It will commit an empty config to the flash. >>>> It will not erase the IP settings tho' so you can still get into it. >>>> >>>> --Ricky >>> >>> >>>- >>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >>> with "unsubscribe usr-tc" in the body of the message. >>> For information on digests or retrieving files and 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. >

Anyone, I'm trying to find the best way to configure a Netserver-based RAC in = providing dial in as well as dial out access. Currently the chassis is configured for dial out access only. 1 dual T1/PRI (with one Ch T1) 6 quad modem cards 1 Netserver 1 NMC (Running system release 3.0.2) The chassis was configured to provide dial out access direct from the = NIC's DTE port by doing the set device packet buss control off. Does this command render the the packet buss unusable in the chassis? I'm thinking I will need to set packet buss control back on, and then = upon the installation of an additional Ch T1, and 6 more Quad modem = cards, set the S-ports associated with dial-out to "inactive" and set = their DTE interface source to "NIC". Then, for the 6 Quads used for = dial-in access, set those S-ports to "active", and set their DTE = interface source to packet buss. Does this sound correct?=20 Is anyone else doing Dial-in AND Dial-out throught the use of the NIC's = DTE interface? We are using dial-out configured this way because we = experienced too many odd problems telnetting through the Netserver and = out the S-ports. hence we would like to leave the dial-out configuration = as is. Thanks to any and all in advance, o o =20 \_ _/=20 <(@@)> ----------------000----()----000------------------- RickyZ@mindspring.com THE TRUTH IS OUT THERE 00O O00 =A9

I thought y'all might appreciate this amid this discussion of trunk/line types: all of lines are CT1s with ground-start signalling. They're terminated into a channel bank connected eventually to a 1AESS in a CO that's a stone's-throw away. WEIRD We have three HDMs and have verified, repeatable reports of PART: getting X2 connections with them. The typical X2 connect rates are around 43k, but it can only be done by a few people living in different sections of town. Strange, but true. I've seen it myself, and transferred data at that rate just to see it done. The calls are made from regular 1FBs and 1FRs. Any theories on why it might work? The BEAST (BellSouth) does have a lot of fiber installed locally; they were getting SONET ring happy when I visited the CO last year. (Maybe that matters.) : We started out with what you are describing, line side trunks. You will : not be able to get a 56k connect because they are not digital all the way : to you. There is a conversion because they have a two wire connect to the : switch instead of the 4 wire you need for digital. Two wire by definition : is analog. "Trunk side" is the important term or 4 wire E&M will get you : where you want to be. This was a very expensive lesson for me to deal with : 18 months ago. I don't completely understand it all but I suspect that I : could probably sit up in bed when I'm 90 at two o'clock in the morning and : cite you the difference. : : At 10:07 PM 9/18/98 -0400, you wrote: : >: From all this we can probably deduce that the tech was saying right now : >: he's served line side and that the customer would be better served with a : >: trunk side connection... I can't tell if the original poster was dealing : >: with individual POTS lines or a CT1. : > : >Original poster here -- we use CT1s, provisioned ESF/B8ZS/Ground Start. : >The CO has a 1AESS switch right now, and they've assured us that we : >can't have trunk-side CT1s until they do the switch upgrade in 9 weeks. : > : >He did comment that all of our competition's lines are `trunks', though. : >Is it possible to have trunk-side T1s with an analog switch? : > : >When our lines work, they work fine. But we can't busy out individual : >channels (DS0s), we can't busy out whole CT1s by putting them in : >loopback, and we have to report channels hung in the switch that are : >causing RNA almost every day. : > : > : >- : > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" : > with "unsubscribe usr-tc" in the body of the 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 v.90 56k access in Casper & Douglas : CoffeyNet Casper, Douglas, Rawlins, Lusk, Lander, Pinedale : 142 S. Center St http://www.coffey.com : Casper, WY 82610 Open 8-6 M-F 10-2 Sat : 307-234-5443 Til 8PM on Thurs : : - : To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" : with "unsubscribe usr-tc" in the body of the message. : For information on digests or retrieving files and old messages send : "help" to the same address. Do not use quotes in your message.

On Fri, 18 Sep 1998, Greg Coffey wrote: > I've got a 56k frame relay circuit to my home that has been nothing but > problems since last November. Lately they have been spending a lot of time > trying to fix this monster once and for all. It will work well for days > and then totally shut down for hours. Just this week, they told me it was > running through a SLC out here. I think they said it was mode 3, could > that cause the problem? If 2 is hellacious, would 3 be better or worse? I know with ISDN, not sure about FR, but if the slot next to yours is occupied you can have problems, so they are suppose to leave it blank. Maybe its like that with ISDN because its 128k, I don't know. Perhaps when others use timeslots they step on you? > > At 06:54 PM 9/18/98 -0500, you wrote: > >On Fri, 18 Sep 1998, Ricky Beam wrote: > > > >> Brian was heard to say: > >> >We have seen this problem when Hellsouth runs their SLC's in > >> >mode2........might want to check that.......perhaps someone on here can > >> >give the technical explaination about why mode2 sucks for modem > >> >connections, but basically I believe it cuts the available channel > >> >bandwidth in half, sometimes allowing slow connections only like 14.4 or > >> >9600, or possibly nothing. > >> > >> Isn't "mode2" "multiplexed to hell and only part way back"? > > > >yes, thats mode 2 :) > > > >> > >> --Ricky > >> > >> > >> - > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider > >Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > >signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > >(318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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 v.90 56k access in Casper & Douglas > CoffeyNet Casper, Douglas, Rawlins, Lusk, Lander, Pinedale > 142 S. Center St http://www.coffey.com > Casper, WY 82610 Open 8-6 M-F 10-2 Sat > 307-234-5443 Til 8PM on Thurs > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

On Sat, 19 Sep 1998, Mike Andrews wrote: > Where's the list of bug fixes for ARC 4.1.11? The release notes only list > the new features. > > I'm mostly interested in finding out if Port-Limit is fixed and no longer > requires a VSA. A list of any other glitches, like sending two stop > records to the accounting server, and some of the off-by-one attribute > logging stuff, that were fixed would be kinda nice. :) I know the stop records are fixed........ Port-Limit they are working on as far as I know...... > > Will an ARC serve as an MPIP server for two NETserver cards without too > much trouble? I'd imagine it would work better, given the faster CPU... > > > Mike Andrews (MA12) icq 6602506 -------- mandrews@termfrost.org > VP 'n' Systems/Network Administrator --------- mandrews@dcr.net > Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ > "If Barbie is so popular, why do you have to buy her friends?..." > > On Wed, 16 Sep 1998, Mike Wronski wrote: > > > Before I get flamed.. I just actually read the Subject of the message.. > > Port-Limit is broken in 4.0.30 and the VSA should be used.. We are working to > > resolve the two attribute issues in 4.1.x code that is in BETA now. > > > > -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. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Where's the list of bug fixes for ARC 4.1.11? The release notes only list the new features. I'm mostly interested in finding out if Port-Limit is fixed and no longer requires a VSA. A list of any other glitches, like sending two stop records to the accounting server, and some of the off-by-one attribute logging stuff, that were fixed would be kinda nice. :) Will an ARC serve as an MPIP server for two NETserver cards without too much trouble? I'd imagine it would work better, given the faster CPU... Mike Andrews (MA12) icq 6602506 -------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "If Barbie is so popular, why do you have to buy her friends?..." On Wed, 16 Sep 1998, Mike Wronski wrote: > Before I get flamed.. I just actually read the Subject of the message.. > Port-Limit is broken in 4.0.30 and the VSA should be used.. We are working to > resolve the two attribute issues in 4.1.x code that is in BETA now. > > -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. >

Is their a list that exists that explains all the Terminate Cause Codes? Brian Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Where can I find the meaning of the messages in the syslog generated by TC/ARC? For example, what is this? --syslog capture: bfe9b2f5 slot:1/mod:11 --syslog capture:stop I'm having lots of these entries. or, Facility "GWC Modem Driver", Level "CRITICAL":: GWCMDM, Incoming call, but no portal attached: interface slot:1/mod:6 Is there a list with these messages? - Marcelo

*************************************************************************** ****************** I thought y'all might appreciate this amid this discussion of trunk/line types: all of lines are CT1s with ground-start signalling. They're terminated into a channel bank connected eventually to a 1AESS in a CO that's a stone's-throw away. WEIRD We have three HDMs and have verified, repeatable reports of PART: getting X2 connections with them. The typical X2 connect rates are around 43k, but it can only be done by a few people living in different sections of town. Strange, but true. I've seen it myself, and transferred data at that rate just to see it done. The calls are made from regular 1FBs and 1FRs. Any theories on why it might work? The BEAST (BellSouth) does have a lot of fiber installed locally; they were getting SONET ring happy when I visited the CO last year. (Maybe that matters.) *************************************************************************** ****************** It IS possible to occasionally get x2/V.90/K56 connections through double A/Ds. If the two ends are timed damn near perfectly, the moon is in the right position, etc. Those connections are very rare, and rarely stay in x2 (will often fallback to V.34 mid-call). In a case of channel bank fed CT1s, it would not surprise me if everything is timed real nicely off the COs cesium clock, so it could happen. I would bet the farm on it, but that could explain it. If you want, send me the number of the POP in question (no passwords wanted or needed) in a private email and I will tell you whether you have a double conversion (this weekend as I am about to do some marathon travelling). If you do, you are best off just disabling x2 and V.90, the extra training steps slow down train time and increase the possibility of connection failures. JP

On Sat, 19 Sep 1998, Mark R. Lindsey wrote: > WEIRD We have three HDMs and have verified, repeatable reports of > PART: getting X2 connections with them. The typical X2 connect > rates are around 43k, but it can only be done by a few people > living in different sections of town. Yeah, I've got a similar situation in our office. Our dialup is elsewhere and colo'd with the 5E (cheap, no line troubles, ever). Now the lines in our office all come through an "SLC" which is connected line side at the CO. The plant engineer swears up and down that that is the case. So that's an A/D here and an A/D at the CO. Using v.34 I cannnot connect anywhere above 26400, and typical connects are 21600. When I got an X2 sampler from USR, I dialed our POP and got a solid X2 connection in the mid 30's. Shouldn't work, right? Any explanations? When I upgraded the Courier to v.90, it all went down the toilet. I'd connect at the same rate, but the error correct LED flashes constantly and the throughput is horrid and just about unusable. Very strange. Charles > > Strange, but true. I've seen it myself, and transferred data at that > rate just to see it done. The calls are made from regular 1FBs and > 1FRs. > > Any theories on why it might work? The BEAST (BellSouth) does have a lot > of fiber installed locally; they were getting SONET ring happy when > I visited the CO last year. (Maybe that matters.) > > : We started out with what you are describing, line side trunks. You will > : not be able to get a 56k connect because they are not digital all the way > : to you. There is a conversion because they have a two wire connect to the > : switch instead of the 4 wire you need for digital. Two wire by definition > : is analog. "Trunk side" is the important term or 4 wire E&M will get you > : where you want to be. This was a very expensive lesson for me to deal with > : 18 months ago. I don't completely understand it all but I suspect that I > : could probably sit up in bed when I'm 90 at two o'clock in the morning and > : cite you the difference. > : > : At 10:07 PM 9/18/98 -0400, you wrote: > : >: From all this we can probably deduce that the tech was saying right now > : >: he's served line side and that the customer would be better served with a > : >: trunk side connection... I can't tell if the original poster was dealing > : >: with individual POTS lines or a CT1. > : > > : >Original poster here -- we use CT1s, provisioned ESF/B8ZS/Ground Start. > : >The CO has a 1AESS switch right now, and they've assured us that we > : >can't have trunk-side CT1s until they do the switch upgrade in 9 weeks. > : > > : >He did comment that all of our competition's lines are `trunks', though. > : >Is it possible to have trunk-side T1s with an analog switch? > : > > : >When our lines work, they work fine. But we can't busy out individual > : >channels (DS0s), we can't busy out whole CT1s by putting them in > : >loopback, and we have to report channels hung in the switch that are > : >causing RNA almost every day. > : > > : > > : >- > : > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > : > with "unsubscribe usr-tc" in the body of the 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 v.90 56k access in Casper & Douglas > : CoffeyNet Casper, Douglas, Rawlins, Lusk, Lander, Pinedale > : 142 S. Center St http://www.coffey.com > : Casper, WY 82610 Open 8-6 M-F 10-2 Sat > : 307-234-5443 Til 8PM on Thurs > : > : - > : To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > : with "unsubscribe usr-tc" in the body of the message. > : For information on digests or retrieving files and 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. > =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

Does anyone have a dictionary from 3Com's RADIUS with all of their attributes and VSAs that they could email me? I'm trying to help someone sort some stuff out. Thanks. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

Mike Andrews was heard to say: >I'm mostly interested in finding out if Port-Limit is fixed and no longer >requires a VSA. A list of any other glitches, like sending two stop >records to the accounting server, and some of the off-by-one attribute >logging stuff, that were fixed would be kinda nice. :) It does not send two ACCT_STATUS_TYPE=2 records (as i've seen, it's never done that?) There are still several off by one things in there. (Modulation type, connect speeds, etc.) >Will an ARC serve as an MPIP server for two NETserver cards without too >much trouble? I'd imagine it would work better, given the faster CPU... In an ARC and NETServer setup, the ARC has to be the MPIP server. And yes, MPIP will work with the ARC as the server with itself and other NETServers as clients. Bugs in v4.1.11: I've managed to crash the ARC four times in the span of an hour trying to login as a static PPP users (single host address.) If gets to the point of address neg. and then hangs up the line. The netserver will work just fine inplace of the ARC, all other things being the same. CCP (software compression) is known to be unstable and has resulted in a few crashes. (Your millage may vary.) --Ricky

> Bugs in v4.1.11: I've managed to crash the ARC four times in the span of > an hour trying to login as a static PPP users (single host address.) If > gets to the point of address neg. and then hangs up the line. The netserver > will work just fine inplace of the ARC, all other things being the same. Our static users can get on fine with 4.1.11, here is a radius snapshot: kenk Auth-Type = "Unix-PW" User-Service-Type = "Framed-User", Framed-Protocol = "PPP", Framed-Address = "208.214.45.190", Framed-Netmask = "255.255.255.255", Framed-MTU = "1500", Port-Limit = "2", Framed-Compression = "Van-Jacobson-TCP-IP" > > CCP (software compression) is known to be unstable and has resulted in a few > crashes. (Your millage may vary.) We run it, I have seen problems with client side not working right, so have had a few clients disable it. > > --Ricky > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

On Mon, 21 Sep 1998, Gilles Melanson wrote: > Just ran into a stupid problem. > > I'm rather new to the ARC.. new to the point where, well, something's > behaving strangely, and someone might be able to answer this question. > > I have 69 ports, and a 69 IP pool set up. It seems like I may be running > into the 'my box doesn't release enough ips' problem at night. (when it's > busier on that chassis). As far as I know, you may want to have your "pool" a few IP's larger than your max ports, just so you don't have the problem of a call needing an IP seconds before one is totally released. I am not sure if this is still an issue, but it used to be. > > That's fine - I was going to assign a bigger 'size' to the pool. > > Can you change certain values in the ARC? (ie: can I modify the 'size' > attribute from 69 to 75?) > > I deleted the pool, rebooted the box, and was going to re-add the pool > with the new size. 'lo and behold, the old pool magically reappeared on > reboot, even though I did a 'save all' when I deleted it. What gives? The ARC may or may not let you modify the state of a pool when their are calls in place on that pool. A better thing to have done would be: busy out chassis, drop all callers, change pool. or something to that effect. > > Can anyone clarify this for me? > Thanks. > > -- > Gilles Melanson ViaNet Internet Solutions > System Administrator 128 Larch St. Suite 301 > gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8 > > "One World, One Web, One Program" > - Microsoft Promotional Ad > "Ein Reich, Ein Volk, Ein Fuhrer" > - Adolf Hitler > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Just ran into a stupid problem. I'm rather new to the ARC.. new to the point where, well, something's behaving strangely, and someone might be able to answer this question. I have 69 ports, and a 69 IP pool set up. It seems like I may be running into the 'my box doesn't release enough ips' problem at night. (when it's busier on that chassis). That's fine - I was going to assign a bigger 'size' to the pool. Can you change certain values in the ARC? (ie: can I modify the 'size' attribute from 69 to 75?) I deleted the pool, rebooted the box, and was going to re-add the pool with the new size. 'lo and behold, the old pool magically reappeared on reboot, even though I did a 'save all' when I deleted it. What gives? Can anyone clarify this for me? Thanks. -- Gilles Melanson ViaNet Internet Solutions System Administrator 128 Larch St. Suite 301 gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8 "One World, One Web, One Program" - Microsoft Promotional Ad "Ein Reich, Ein Volk, Ein Fuhrer" - Adolf Hitler

remove

I have many old Netservers that have 4 meg. I ordered an upgrade kit from USR to add Ram and flash. I rebooted and now the car come up unrecognized. I thought it was because I needed to add code. I tried but it says it busie. I have power cycled the unit and I still get a big question mark on the netserver card. Chris Havelka Network Engineer InterAccess Co. Chicago Il chavelka@interaccess.com

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Chris Havelka |Sent: Monday, September 21, 1998 2:33 PM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) Flash upgrade problem | | |I have many old Netservers that have 4 meg. I ordered an upgrade kit from |USR to add Ram and flash. I rebooted and now the car come up unrecognized. | |I thought it was because I needed to add code. I tried but it says it busie. | |I have power cycled the unit and I still get a big question mark on the |netserver card. | You need to use PCSDL to re-flash the card after a flash & RAM upgrade. -M

Does anyone know the command for changing the accounting secret on the Netserver ? Thank you, -- Frank Basso Senior Network Engineer Got.Net? Santa Cruz, California Voice: 831-460-2000 x117 FAX: 831-460-2004 When they took the fourth amendment, I was quiet because I didn't deal drugs. When they took the sixth amendment, I was quiet because I was innocent. When they took the second amendment, I was quiet because I didn't own a gun. Now they've taken the first amendment, and I can say nothing about it.

I am trying to setup an entry in RADIUS that just takes a user to a specific machine on our network, but it fails. Anyone know why? (all items below are reply attributes, no check attributes are set) download User-Service-Type = "Login-User", Login-Service = "Telnet", Login-Host = "208.206.76.2" Source-IP Src-Port Destination-IP Dest-Port Id Packet-Type 208.206.76.35 1645 208.206.76.23 1645 46 Access-Request User-Name : download User-Password : xxxxxxxxxx NAS-IP-Address : 208.206.76.35 NAS-Port : 3 Acct-Session-Id : 149271 Interface-Index : 1259 Service-Type : 1 Chasis-Call-Slot : 1 Chasis-Call-Span : 1 Chasis-Call-Channel : 3 Calling-Station-Id : 3182132640 Called-Station-Id : 3182134600 NAS-Port-Type : 0 Source-IP Src-Port Destination-IP Dest-Port Id Packet-Type 208.206.76.23 1645 208.206.76.35 1645 46 Access-Reject Reply-Message : Request Denied Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Are these radius users? check your radius server and let me know if you are getting any rejects from the server. Also if you could try with a local user and let me know. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Mon, 21 Sep 1998, Brian Gordon wrote: > Anyone else having problems with WEB TV dialins.??? > > I upgrade my Hyper Arc's today to 4.1.11 and know no Web TV People can > Connect???? > > > Brian Gordon, MCP > Westelcom Internet Administrator > http://www.westelcom.com > 518-566-8376 Voice > 518-566-8348 Fax > administrator@westelcom.com > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian > > Sent: Monday, September 21, 1998 4:17 PM > > To: USRobotics TC Mailing List > > Subject: (usr-tc) login user > > > > > > I am trying to setup an entry in RADIUS that just takes a user to a > > specific machine on our network, but it fails. Anyone know why? (all > > items below are reply attributes, no check attributes are set) > > > > > > download > > User-Service-Type = "Login-User", > > Login-Service = "Telnet", > > Login-Host = "208.206.76.2" > > > > > > --------------------------------------------------------------------- > > Source-IP Src-Port Destination-IP Dest-Port Id Packet-Type > > --------------------------------------------------------------------- > > 208.206.76.35 1645 208.206.76.23 1645 46 Access-Request > > --------------------------------------------------------------------- > > > > User-Name : download > > User-Password : xxxxxxxxxx > > NAS-IP-Address : 208.206.76.35 > > NAS-Port : 3 > > Acct-Session-Id : 149271 > > Interface-Index : 1259 > > Service-Type : 1 > > Chasis-Call-Slot : 1 > > Chasis-Call-Span : 1 > > Chasis-Call-Channel : 3 > > Calling-Station-Id : 3182132640 > > Called-Station-Id : 3182134600 > > NAS-Port-Type : 0 > > > > --------------------------------------------------------------------- > > Source-IP Src-Port Destination-IP Dest-Port Id Packet-Type > > --------------------------------------------------------------------- > > 208.206.76.23 1645 208.206.76.35 1645 46 Access-Reject > > --------------------------------------------------------------------- > > > > Reply-Message : Request Denied > > > > > > -------------------------------------------------------------------------- > > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service > > Provider > > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and 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. >

On Fri, 18 Sep 1998, Theodore Cekan wrote: > How do I get a HARC to use the ip pool I set up? It always assigns the > dialin user 0.0.0.0. If you saw that when you did a Show Remote user <username> its because thats what the ARC shows when it has done a dynamic IP assignment such as from an address pool. to really see what IP the user was assigned, do "list ip networks". Brian > > Thanks, > > Ted > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

On Fri, 18 Sep 1998, Theodore Cekan wrote: > Why does my radius server receive User-Service-Type = Login-User from my > HARC? I need to change this to User-Service-Type = Framed-User. I believe you would want to examine the attributes for user "default" show user default and make sure the Type is "NETWORK" and the Network Service is "PPP" or whatever you would like for a network service. Brian > > Thanks, > > Ted > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Anyone else having problems with WEB TV dialins.??? I upgrade my Hyper Arc's today to 4.1.11 and know no Web TV People can Connect???? Brian Gordon, MCP Westelcom Internet Administrator http://www.westelcom.com 518-566-8376 Voice 518-566-8348 Fax administrator@westelcom.com > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian > Sent: Monday, September 21, 1998 4:17 PM > To: USRobotics TC Mailing List > Subject: (usr-tc) login user > > > I am trying to setup an entry in RADIUS that just takes a user to a > specific machine on our network, but it fails. Anyone know why? (all > items below are reply attributes, no check attributes are set) > > > download > User-Service-Type = "Login-User", > Login-Service = "Telnet", > Login-Host = "208.206.76.2" > > > --------------------------------------------------------------------- > Source-IP Src-Port Destination-IP Dest-Port Id Packet-Type > --------------------------------------------------------------------- > 208.206.76.35 1645 208.206.76.23 1645 46 Access-Request > --------------------------------------------------------------------- > > User-Name : download > User-Password : xxxxxxxxxx > NAS-IP-Address : 208.206.76.35 > NAS-Port : 3 > Acct-Session-Id : 149271 > Interface-Index : 1259 > Service-Type : 1 > Chasis-Call-Slot : 1 > Chasis-Call-Span : 1 > Chasis-Call-Channel : 3 > Calling-Station-Id : 3182132640 > Called-Station-Id : 3182134600 > NAS-Port-Type : 0 > > --------------------------------------------------------------------- > Source-IP Src-Port Destination-IP Dest-Port Id Packet-Type > --------------------------------------------------------------------- > 208.206.76.23 1645 208.206.76.35 1645 46 Access-Reject > --------------------------------------------------------------------- > > Reply-Message : Request Denied > > > -------------------------------------------------------------------------- > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service > Provider > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

How do I know if a user is being successfully assigned a filter I have created for them in RADIUS? Here is the RADIUS entry: User-Service-Type = "Framed-User", Framed-Protocol = "PPP",Framed-Address = "255.255.255.254", Framed-Netmask = "255.255.255.255", Framed-MTU = "1500", Port-Limit = "1", Framed-Routing = "None",Framed-Compression = "Van-Jacobson-TCP-IP", USR-IP-Input-Filter = "IP:", USR-IP-Input-Filter = "1 DENY src-addr != %a;" I do a MONITOR RADIUS, and don't see the filter attributes going accross, should they? Also don't let the %a throw you off, that is a Radiator variable which gets substituted by the current users IP address for Dynamic Filtering.......... I do a SHOW REMOTE USER <username> and don't see the filter either, but then again I am not sure if that should show up their. Just curious how to tell if the filter is in place Brian Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

I figured this out. I was setting the attribute with the wrong name. show remote user < username > and monitor radius both show the filter information correctly now. BTW, Dynamic Filters kick *ss!! Brian On Mon, 21 Sep 1998, Brian wrote: > How do I know if a user is being successfully assigned a filter I have > created for them in RADIUS? > > Here is the RADIUS entry: > > User-Service-Type = "Framed-User", > Framed-Protocol = "PPP",Framed-Address = "255.255.255.254", > Framed-Netmask = "255.255.255.255", > Framed-MTU = "1500", > Port-Limit = "1", > Framed-Routing = "None",Framed-Compression = "Van-Jacobson-TCP-IP", > USR-IP-Input-Filter = "IP:", > USR-IP-Input-Filter = "1 DENY src-addr != %a;" > > > I do a MONITOR RADIUS, and don't see the filter attributes going accross, > should they? Also don't let the %a throw you off, that is a Radiator > variable which gets substituted by the current users IP address for > Dynamic Filtering.......... > > I do a SHOW REMOTE USER <username> and don't see the filter either, but > then again I am not sure if that should show up their. Just curious how > to tell if the filter is in place > > Brian > > -------------------------------------------------------------------------- > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

At 02:44 PM 9/18/98 -0700, you wrote: >Could someone help me figure out why I can't use all the built in accounting >features of the Accounting Server. Specifically, when I do an accounting >report, select a user name, and select "Call statistics by day", it comes >back with #Error all over the form. I've had the same problem for the last 5 months with no satisfactory answer. Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

These are radius users...I am trying to make them a local user and then have them try it...no one has got back to me yet to tell me if it works. Brian Gordon, MCP Westelcom Internet Administrator http://www.westelcom.com 518-566-8376 Voice 518-566-8348 Fax administrator@westelcom.com > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan > Sent: Monday, September 21, 1998 5:19 PM > To: Brian Gordon > Cc: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) login user > > > Are these radius users? check your radius server and let me know if you > are getting any rejects from the server. Also if you could try with a > local user and let me know. > > krish > > ----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ > tkrishna@bubba.ae.usr.com > ----------------------------/ http://interproc.ae.usr.com ----/ > The Yadda Yadda Search - for simple anwers - > http://interproc.ae.usr.com/tkb.html > -------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec > -------------------------------------------------------------------------/ > > On Mon, 21 Sep 1998, Brian Gordon wrote: > > > Anyone else having problems with WEB TV dialins.??? > > > > I upgrade my Hyper Arc's today to 4.1.11 and know no Web TV People can > > Connect???? > > > > > > Brian Gordon, MCP > > Westelcom Internet Administrator > > http://www.westelcom.com > > 518-566-8376 Voice > > 518-566-8348 Fax > > administrator@westelcom.com > > > > > -----Original Message----- > > > From: owner-usr-tc@lists.xmission.com > > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian > > > Sent: Monday, September 21, 1998 4:17 PM > > > To: USRobotics TC Mailing List > > > Subject: (usr-tc) login user > > > > > > > > > I am trying to setup an entry in RADIUS that just takes a user to a > > > specific machine on our network, but it fails. Anyone know why? (all > > > items below are reply attributes, no check attributes are set) > > > > > > > > > download > > > User-Service-Type = "Login-User", > > > Login-Service = "Telnet", > > > Login-Host = "208.206.76.2" > > > > > > > > > --------------------------------------------------------------------- > > > Source-IP Src-Port Destination-IP Dest-Port Id Packet-Type > > > --------------------------------------------------------------------- > > > 208.206.76.35 1645 208.206.76.23 1645 46 > Access-Request > > > --------------------------------------------------------------------- > > > > > > User-Name : download > > > User-Password : xxxxxxxxxx > > > NAS-IP-Address : 208.206.76.35 > > > NAS-Port : 3 > > > Acct-Session-Id : 149271 > > > Interface-Index : 1259 > > > Service-Type : 1 > > > Chasis-Call-Slot : 1 > > > Chasis-Call-Span : 1 > > > Chasis-Call-Channel : 3 > > > Calling-Station-Id : 3182132640 > > > Called-Station-Id : 3182134600 > > > NAS-Port-Type : 0 > > > > > > --------------------------------------------------------------------- > > > Source-IP Src-Port Destination-IP Dest-Port Id Packet-Type > > > --------------------------------------------------------------------- > > > 208.206.76.23 1645 208.206.76.35 1645 46 > Access-Reject > > > --------------------------------------------------------------------- > > > > > > Reply-Message : Request Denied > > > > > > > > > > -------------------------------------------------------------------------- > > > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service > > > Provider > > > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > > > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > > > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and 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. >

3Com: How can I try out 3.8.0? I can't deploy 3.8.1 in its current state. Or how about releasing a version of 3.7.24 with only the changes to support the v.90 hdms? 3.7.24 has been rock solid for us. All PRI spans, no MPIP, modems only (no ISDN access). On Sat, 19 Sep 1998, SysAdmin wrote: > I have had the EXACT same results ... I have 13 Quads and 2 DSP`s (96 lines) per > + chassis ... 3.8.0 worked and so did 3.7.73 (3.8.0 had a few pauses) ... but 3. > +8.1 would not even work with quake2 ... (or any UDP based game for that matter) > + ... I could play for mabey 30 seconds and then my netgraph would just show a l > +arge green bar and ping time would shoot upto 1175 ... I usually test new (and > +old code) ... I tried 3.7.24 on this box and I have never seen better quake2 pl > +ay (on a USR box) ... it still is bad but at least it`s playable on ISDN at lea > +st .... just wondering what all these PPP latency fixes are supposed to do beca > +use they are not working for me ... I also installed SUBSPACe and tried it anda > +lso got the same results ... 3.7.24 works for it but 3.8.1 lags bad ... > > > Quoting usr-tc@lists.xmission.com: > > > I tried netserver 3.8.1 in a chassis with 12 quads and 2 hdms. I > > upgraded the hdms to 1.2.5 to try out the v.90 support. In short the > > chassis is running the firmware versions listed in TCS 3.1.2. > > > > The problem is I see severe UDP/Quake lag on both the quads and hdms. > > Six other racks running netserver 3.7.24 do not have this problem. > > The 3.8.1 release notes say there are fixes for Quake POD (pause of > > death?) but it looks worse than ever. > > > > Is anyone running 3.7.24 with the hdm 1.2.5 code? Any problems? > > Is anyone running 3.8.1 and not getting complaints from Quake > > players? SubSpace is another UDP based network game and it also > > lags badly using 3.8.1 but works fine using 3.7.24. > > > > In all cases I'm calling from the same PC using the same modem > > (Courier v.everything v.90) and same phone.

Recheck all your settings on the Hiper ARC and also the DSP or quad modems (whatever you have). The last time a upgraded my Hiper Arc code it reverted rather loaded an old saved session ( I thought it was erased). Brian Gordon wrote: > > It still does not work even if adding the user locally. > > I got about twenty users that cannot get on! > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan > > Sent: Monday, September 21, 1998 5:19 PM > > To: Brian Gordon > > Cc: usr-tc@lists.xmission.com > > Subject: RE: (usr-tc) login user > > > > > > Are these radius users? check your radius server and let me know if you > > are getting any rejects from the server. Also if you could try with a > > local user and let me know. > > > > krish > > > > ----------------------------------------- > > \ T.S.V. Krishnan \ > > \ Network System Engineer \ ( : - : ) >

At 05:12 PM 9/21/98 -0500, you wrote: >How do I know if a user is being successfully assigned a filter I have >created for them in RADIUS? [snip] >I do a SHOW REMOTE USER <username> and don't see the filter either, but >then again I am not sure if that should show up their. Just curious how >to tell if the filter is in place On a console connection to my HiPer ARC; The possible SHOW FILTER commands are: SHOW FILTER <filter_name>PROTOCOL <interface_names_list> SHOW FILTER <filter_name> I don't know if this applies to radius filters though. Hope it helps. Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

It still does not work even if adding the user locally. I got about twenty users that cannot get on! > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan > Sent: Monday, September 21, 1998 5:19 PM > To: Brian Gordon > Cc: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) login user > > > Are these radius users? check your radius server and let me know if you > are getting any rejects from the server. Also if you could try with a > local user and let me know. > > krish > > ----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ > tkrishna@bubba.ae.usr.com > ----------------------------/ http://interproc.ae.usr.com ----/ > The Yadda Yadda Search - for simple anwers - > http://interproc.ae.usr.com/tkb.html > -------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec > -------------------------------------------------------------------------/ > > On Mon, 21 Sep 1998, Brian Gordon wrote: > > > Anyone else having problems with WEB TV dialins.??? > > > > I upgrade my Hyper Arc's today to 4.1.11 and know no Web TV People can > > Connect???? > > > > > > Brian Gordon, MCP > > Westelcom Internet Administrator > > http://www.westelcom.com > > 518-566-8376 Voice > > 518-566-8348 Fax > > administrator@westelcom.com > > > > > -----Original Message----- > > > From: owner-usr-tc@lists.xmission.com > > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian > > > Sent: Monday, September 21, 1998 4:17 PM > > > To: USRobotics TC Mailing List > > > Subject: (usr-tc) login user > > > > > > > > > I am trying to setup an entry in RADIUS that just takes a user to a > > > specific machine on our network, but it fails. Anyone know why? (all > > > items below are reply attributes, no check attributes are set) > > > > > > > > > download > > > User-Service-Type = "Login-User", > > > Login-Service = "Telnet", > > > Login-Host = "208.206.76.2" > > > > > > > > > --------------------------------------------------------------------- > > > Source-IP Src-Port Destination-IP Dest-Port Id Packet-Type > > > --------------------------------------------------------------------- > > > 208.206.76.35 1645 208.206.76.23 1645 46 > Access-Request > > > --------------------------------------------------------------------- > > > > > > User-Name : download > > > User-Password : xxxxxxxxxx > > > NAS-IP-Address : 208.206.76.35 > > > NAS-Port : 3 > > > Acct-Session-Id : 149271 > > > Interface-Index : 1259 > > > Service-Type : 1 > > > Chasis-Call-Slot : 1 > > > Chasis-Call-Span : 1 > > > Chasis-Call-Channel : 3 > > > Calling-Station-Id : 3182132640 > > > Called-Station-Id : 3182134600 > > > NAS-Port-Type : 0 > > > > > > --------------------------------------------------------------------- > > > Source-IP Src-Port Destination-IP Dest-Port Id Packet-Type > > > --------------------------------------------------------------------- > > > 208.206.76.23 1645 208.206.76.35 1645 46 > Access-Reject > > > --------------------------------------------------------------------- > > > > > > Reply-Message : Request Denied > > > > > > > > > > -------------------------------------------------------------------------- > > > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service > > > Provider > > > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > > > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > > > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and 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. >

Maybe you might need to check to make sure the ARC is setup for PAP authentication... If this is not set properly they may not get authenticated. There was a change, I believe from the way the netserver handled this. PAP needs to be set vice setting it to either or CHAP Just my .02 worth! We handle them fine here on our ARC, but are still running the 4.0.30 code! ============================================================================== 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 Mon, 21 Sep 1998, Brian Gordon wrote: > It still does not work even if adding the user locally. > > I got about twenty users that cannot get on! > > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan > > Sent: Monday, September 21, 1998 5:19 PM > > To: Brian Gordon > > Cc: usr-tc@lists.xmission.com > > Subject: RE: (usr-tc) login user > > > > > > Are these radius users? check your radius server and let me know if you > > are getting any rejects from the server. Also if you could try with a > > local user and let me know. > > > > krish > > > > ----------------------------------------- > > \ T.S.V. Krishnan \ > > \ Network System Engineer \ ( : - : ) > > \ 3Com ............ \ > > ----------------------------------------------/ > > tkrishna@bubba.ae.usr.com > > ----------------------------/ http://interproc.ae.usr.com ----/ > > The Yadda Yadda Search - for simple anwers - > > http://interproc.ae.usr.com/tkb.html > > -------------------------------------------------------------------------\ > > Any Sufficiently advanced bug is indistinguishable for a feature. > > - Rick Kulawiec > > -------------------------------------------------------------------------/ > > > > On Mon, 21 Sep 1998, Brian Gordon wrote: > > > > > Anyone else having problems with WEB TV dialins.??? > > > > > > I upgrade my Hyper Arc's today to 4.1.11 and know no Web TV People can > > > Connect???? > > > > > > > > > Brian Gordon, MCP > > > Westelcom Internet Administrator > > > http://www.westelcom.com > > > 518-566-8376 Voice > > > 518-566-8348 Fax > > > administrator@westelcom.com > > > > > > > -----Original Message----- > > > > From: owner-usr-tc@lists.xmission.com > > > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian > > > > Sent: Monday, September 21, 1998 4:17 PM > > > > To: USRobotics TC Mailing List > > > > Subject: (usr-tc) login user > > > > > > > > > > > > I am trying to setup an entry in RADIUS that just takes a user to a > > > > specific machine on our network, but it fails. Anyone know why? (all > > > > items below are reply attributes, no check attributes are set) > > > > > > > > > > > > download > > > > User-Service-Type = "Login-User", > > > > Login-Service = "Telnet", > > > > Login-Host = "208.206.76.2" > > > > > > > > > > > > --------------------------------------------------------------------- > > > > Source-IP Src-Port Destination-IP Dest-Port Id Packet-Type > > > > --------------------------------------------------------------------- > > > > 208.206.76.35 1645 208.206.76.23 1645 46 > > Access-Request > > > > --------------------------------------------------------------------- > > > > > > > > User-Name : download > > > > User-Password : xxxxxxxxxx > > > > NAS-IP-Address : 208.206.76.35 > > > > NAS-Port : 3 > > > > Acct-Session-Id : 149271 > > > > Interface-Index : 1259 > > > > Service-Type : 1 > > > > Chasis-Call-Slot : 1 > > > > Chasis-Call-Span : 1 > > > > Chasis-Call-Channel : 3 > > > > Calling-Station-Id : 3182132640 > > > > Called-Station-Id : 3182134600 > > > > NAS-Port-Type : 0 > > > > > > > > --------------------------------------------------------------------- > > > > Source-IP Src-Port Destination-IP Dest-Port Id Packet-Type > > > > --------------------------------------------------------------------- > > > > 208.206.76.23 1645 208.206.76.35 1645 46 > > Access-Reject > > > > --------------------------------------------------------------------- > > > > > > > > Reply-Message : Request Denied > > > > > > > > > > > > > > -------------------------------------------------------------------------- > > > > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service > > > > Provider > > > > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > > > > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > > > > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and 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. >

I just called Tech support to alert them of the problem, They are working on a fix for this. My suggestion do not upgrade to 4.1.11. It does NOT work with web tv!!!!!!!! Brian Gordon, MCP Westelcom Internet Administrator http://home.westelcom.com 518-566-8376 Voice 518-566-8348 Fax administrator@westelcom.com > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of pferraro > Sent: Monday, September 21, 1998 7:33 PM > To: Brian Gordon > Cc: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) RE: WEB TV > > > > Maybe you might need to check to make sure the ARC is setup for > PAP authentication... If this is not set properly they may not get > authenticated. There was a change, I believe from the way the netserver > handled this. PAP needs to be set vice setting it to either or CHAP > > Just my .02 worth! > > We handle them fine here on our ARC, but are still running the 4.0.30 > code! > > ================================================================== > ============ > 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 Mon, 21 Sep 1998, Brian Gordon wrote: > > > It still does not work even if adding the user locally. > > > > I got about twenty users that cannot get on! > > > > > > > -----Original Message----- > > > From: owner-usr-tc@lists.xmission.com > > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan > > > Sent: Monday, September 21, 1998 5:19 PM > > > To: Brian Gordon > > > Cc: usr-tc@lists.xmission.com > > > Subject: RE: (usr-tc) login user > > > > > > > > > Are these radius users? check your radius server and let me > know if you > > > are getting any rejects from the server. Also if you could try with a > > > local user and let me know. > > > > > > krish > > > > > > ----------------------------------------- > > > \ T.S.V. Krishnan \ > > > \ Network System Engineer \ ( : - : ) > > > \ 3Com ............ \ > > > ----------------------------------------------/ > > > tkrishna@bubba.ae.usr.com > > > ----------------------------/ http://interproc.ae.usr.com ----/ > > > The Yadda Yadda Search - for simple anwers - > > > http://interproc.ae.usr.com/tkb.html > > > > -------------------------------------------------------------------------\ > > > Any Sufficiently advanced bug is indistinguishable for a feature. > > > - Rick Kulawiec > > > > -------------------------------------------------------------------------/ > > > > > > On Mon, 21 Sep 1998, Brian Gordon wrote: > > > > > > > Anyone else having problems with WEB TV dialins.??? > > > > > > > > I upgrade my Hyper Arc's today to 4.1.11 and know no Web TV > People can > > > > Connect???? > > > > > > > > > > > > Brian Gordon, MCP > > > > Westelcom Internet Administrator > > > > http://www.westelcom.com > > > > 518-566-8376 Voice > > > > 518-566-8348 Fax > > > > administrator@westelcom.com > > > > > > > > > -----Original Message----- > > > > > From: owner-usr-tc@lists.xmission.com > > > > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian > > > > > Sent: Monday, September 21, 1998 4:17 PM > > > > > To: USRobotics TC Mailing List > > > > > Subject: (usr-tc) login user > > > > > > > > > > > > > > > I am trying to setup an entry in RADIUS that just takes a > user to a > > > > > specific machine on our network, but it fails. Anyone > know why? (all > > > > > items below are reply attributes, no check attributes are set) > > > > > > > > > > > > > > > download > > > > > User-Service-Type = "Login-User", > > > > > Login-Service = "Telnet", > > > > > Login-Host = "208.206.76.2" > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > Source-IP Src-Port Destination-IP Dest-Port Id > Packet-Type > > > > > > --------------------------------------------------------------------- > > > > > 208.206.76.35 1645 208.206.76.23 1645 46 > > > Access-Request > > > > > > --------------------------------------------------------------------- > > > > > > > > > > User-Name : download > > > > > User-Password : xxxxxxxxxx > > > > > NAS-IP-Address : 208.206.76.35 > > > > > NAS-Port : 3 > > > > > Acct-Session-Id : 149271 > > > > > Interface-Index : 1259 > > > > > Service-Type : 1 > > > > > Chasis-Call-Slot : 1 > > > > > Chasis-Call-Span : 1 > > > > > Chasis-Call-Channel : 3 > > > > > Calling-Station-Id : 3182132640 > > > > > Called-Station-Id : 3182134600 > > > > > NAS-Port-Type : 0 > > > > > > > > > > > --------------------------------------------------------------------- > > > > > Source-IP Src-Port Destination-IP Dest-Port Id > Packet-Type > > > > > > --------------------------------------------------------------------- > > > > > 208.206.76.23 1645 208.206.76.35 1645 46 > > > Access-Reject > > > > > > --------------------------------------------------------------------- > > > > > > > > > > Reply-Message : Request Denied > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------------- > > > > > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service > > > > > Provider > > > > > Network Administrator | Shreveport, Louisiana - > http://www.shreve.net/ > > > > > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > > > > > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > > > > > > > > > > > > > - > > > > > To unsubscribe to usr-tc, send an email to > "majordomo@xmission.com" > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > For information on digests or retrieving files and 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. >

my quake users left me a year ago so a worse quake lag doesn't really bother me. I am running 3.8.1 because i need V.90 on my HDM and it also fixes an MPIP leak. Leon -----Original Message----- >I have had the EXACT same results ... I have 13 Quads and 2 DSP`s (96 lines) per >+ chassis ... 3.8.0 worked and so did 3.7.73 (3.8.0 had a few pauses) ... but 3. >+8.1 would not even work with quake2 ... (or any UDP based game for that matter) >+ ... I could play for mabey 30 seconds and then my netgraph would just show a l >+arge green bar and ping time would shoot upto 1175 ... I usually test new (and >+old code) ... I tried 3.7.24 on this box and I have never seen better quake2 pl >+ay (on a USR box) ... it still is bad but at least it`s playable on ISDN at lea >+st .... just wondering what all these PPP latency fixes are supposed to do beca >+use they are not working for me ... I also installed SUBSPACe and tried it anda >+lso got the same results ... 3.7.24 works for it but 3.8.1 lags bad ... >

set secret (enter secret)<enter> save all "Frank Basso" <frank@got.net> on 09/21/98 05:26:28 PM Please respond to usr-tc@lists.xmission.com cc: (Eugene Carpenter/US/3Com) Does anyone know the command for changing the accounting secret on the Netserver ? Thank you, -- Frank Basso Senior Network Engineer Got.Net? Santa Cruz, California Voice: 831-460-2000 x117 FAX: 831-460-2004 When they took the fourth amendment, I was quiet because I didn't deal drugs. When they took the sixth amendment, I was quiet because I was innocent. When they took the second amendment, I was quiet because I didn't own a gun. Now they've taken the first amendment, and I can say nothing about it. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Some observations on ARC 4.1.11: 1) The problem with Port-Limit=1 not working is NOT fixed in 4.1.11. 2) The problem where a corrupted Radius authentication response packet crashed my 4.0.30 card *IS* fixed, however. This let me finally finish hacking up my Livingston 2.01 Radius server to send the Max_Sessions VSA, thereby working around the problem above. I've tested it and people can no longer bring up 128K (or dual analog) connections on an ARC when I don't want them to. Good enough for me for now. (Since Mike wanted to know, the corrupt packets had, among other problems, an attribute length of zero... the attribute/value pair basically started with 0x1a 0x00 followed by lots of garbage. 4.1.11 was very tolerant of this and other badly mangled packets I generated during my hackery. :-) 3) ARC 4.1.11 seems to send Radius accounting packets to ALL available accounting servers simultaneously. I think it was previously logging to the secondary only when the primary is down. 4) Also, our ARC wants to only contact our secondary authentication server, despite the primary being up. Maybe this is related to the above... It doesn't seem to want to kick back over to the primary. "show authentic" indicates this too -- it lists the active server as being our secondary. This actually caused some problems for us today, because the passwd database was only copied to the secondary server once a day. (It's now copied every 30 minutes.) Did the algorithm for selecting a server change? 5) I'm having some MPIP problems, but I think they are really NETserver related. Before I even upgraded the ARC, I was (and still am) having the following problem: 5a) When I bring up a multilink connection with a Windows NT machine and two analog modems, and the two channels land on separate NETservers, one channel comes up but the second channel fails. It appears that the MPIP bundle is getting created, but the second card is trying to give the second channel a different IP address. The misbehaving NETserver sits in the "CONNECTING" state until you finally give up on it. I'm hoping this is just something I've misconfigured... I'm assuming that since the bundle came up, the client/server lists are OK and the shared secrets are OK. Bad assumption? 5b) Also, I'm running into a problem with stale bundles hanging around and piling up. I think our neighbor Jeff Mcadams reported this once with his NETserver-only setup.... We have a user with Windows 95, DUN 1.2, a 3com Impact IQ, set for multilink but only authorized for 64K. With our ARC running as the MPIP server for our two NETservers (3.7.24), I'm getting this: tank-arc> list mpip bund MPIP Bundles Bundle EndPointDescriminator No. User Owner Value Type Links Name 206.240.130.10 35303236393630363930 5 39 xxxxxx where 206.240.130.10 is one of the NETservers. The "No. Links" has been increasing for the last few days -- basically by one every time he calls. At the time that "list mpip bund" was entered, he was actually not online at all. Now he's been unable to log in at all, except on an analog line. Rebooting the NETserver card cleared it up (for now?) and his stale bundles no longer show up. We'll see how things play out this week. I'm really interested in getting the first MPIP problem (5a) fixed up, and that's probably not an ARC issue. 6) While I'm here, does ARC 4.1.11 provide any way yet of finding how long a session has been idle? I couldn't find it in the new MIB offhand. 7) The "off by one" thing I mentioned reeeal briefly in my last msg is, I think, really a HiPer DSP problem, not an ARC problem. Basically I have the NMC logging modem hangups since that's the only way to get the start/end connect rates, disconnect reasons, and so on. The v.90 DSP code seems to have an off-by-one problem with several fields -- connect speed and modulation being two of them. I think this was working in the non-v.90 DSP code. I've gotten around it by hacking our Radius server to tweak the response coming from that particular NMC (bleah barf ick site specific code yuk). I wonder how much more I'm going to get to butcher my Radius server. :) Mike Andrews (MA12) icq 6602506 -------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "If Barbie is so popular, why do you have to buy her friends?..."

Thus spake Mike Andrews >5) I'm having some MPIP problems, but I think they are really NETserver >related. Before I even upgraded the ARC, I was (and still am) having the >following problem: >5a) When I bring up a multilink connection with a Windows NT machine and >two analog modems, and the two channels land on separate NETservers, one >channel comes up but the second channel fails. It appears that the MPIP >bundle is getting created, but the second card is trying to give the >second channel a different IP address. The misbehaving NETserver sits in >the "CONNECTING" state until you finally give up on it. What version of netserver code was this? 3.7.24 and before showed "CONNECTING" for the port status when it was really tunneling a connection over to the bundle owner, 3.7.76 (ER release) or thereabouts added a "TUNNELED" status to indicate better what was going on. To really see if the bundling is working, head on over to the netserver which is the bundle owner and do a "show bun" and it'll show you if the second channel got bundled in. >I'm hoping this >is just something I've misconfigured... I'm assuming that since the >bundle came up, the client/server lists are OK and the shared secrets are >OK. Bad assumption? Possibly a bad assumption...You could have the client/server lists bunged up and still have the bundle come up...remember, the bundle is created on the netserver that has the first link...that requires no MPIP communications (well...other than to determine that a bundle doesn't already exist somewhere else, but if that fails, it could go ahead and create the bundle locally...not sure of the behavior there). So...could be client/server lists, could be shared secrets, could actually be getting bundled and the port status is just misleading. >5b) Also, I'm running into a problem with stale bundles hanging around and >piling up. I think our neighbor Jeff Mcadams reported this once with his >NETserver-only setup.... >We have a user with Windows 95, DUN 1.2, a 3com Impact IQ, set for >multilink but only authorized for 64K. With our ARC running as the MPIP >server for our two NETservers (3.7.24), I'm getting this: >tank-arc> list mpip bund >MPIP Bundles >Bundle EndPointDescriminator No. User >Owner Value Type Links Name >206.240.130.10 35303236393630363930 5 39 xxxxxx >where 206.240.130.10 is one of the NETservers. The "No. Links" has been >increasing for the last few days -- basically by one every time he calls. >At the time that "list mpip bund" was entered, he was actually not online >at all. Now he's been unable to log in at all, except on an analog line. Urgh...similar...not exactly what I was seeing. Netserver doesn't have a command to show the links in a bundle, in fact, it doesn't even have a command to show *anything* about what the MPIP server thinks exists...but from the best of my diagnostics, it looks like the MPIP code on the netserver will think the bundle has 0 links in it, but it doesn't delete the bundle. Also, from the sounds of it, your user could still get connected for quite some time with the MPIP server having lost track of the bundle some...so it sounds like the calls were tunnel'ing over to the netserver and the netserver was adding them to a bundle. Mine doesn't do this...the netserver that is supposedly hosting the bundle in my case rejects the tunnel and the call fails. >Rebooting the NETserver card cleared it up (for now?) and his stale >bundles no longer show up. We'll see how things play out this week. Ooh...definitely a bit different from my problem...I have to reboot the MPIP server...rebooting the netserver that supposedly hosts the bundle doesn't do squat for me. :) Fortunately, my work-around is a little easier...cron job to reboot the MPIP server (which is on a dedicated netserver at this point...doesn't take any calls)...doesn't disrupt any calls, and only without MPIP services for about 2 minutes while it reboots. I do this 4 times a day (bleah barf ick periodic reboots to deal with code problems yuk) and that seems frequent enough to clear out the crud in the MPIP server before it causes too many problems for my customers. >I'm really interested in getting the first MPIP problem (5a) fixed up, and >that's probably not an ARC issue. Again, this may not really be a problem...if you're on 3.7.24 or previous, it probably *is* getting tunnelled and the bundle set up and everything...check that out before you try to fix something that ain't broke. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Brian, Its really strange, guess there is something to do with your setup on your hiper arc. if you could give me the access to the card then I can debug the same. Let me know if you want to do this. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Mon, 21 Sep 1998, Brian Gordon wrote: > It still does not work even if adding the user locally. > > I got about twenty users that cannot get on! > > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan > > Sent: Monday, September 21, 1998 5:19 PM > > To: Brian Gordon > > Cc: usr-tc@lists.xmission.com > > Subject: RE: (usr-tc) login user > > > > > > Are these radius users? check your radius server and let me know if you > > are getting any rejects from the server. Also if you could try with a > > local user and let me know. > > > > krish > > > > ----------------------------------------- > > \ T.S.V. Krishnan \ > > \ Network System Engineer \ ( : - : ) > > \ 3Com ............ \ > > ----------------------------------------------/ > > tkrishna@bubba.ae.usr.com > > ----------------------------/ http://interproc.ae.usr.com ----/ > > The Yadda Yadda Search - for simple anwers - > > http://interproc.ae.usr.com/tkb.html > > -------------------------------------------------------------------------\ > > Any Sufficiently advanced bug is indistinguishable for a feature. > > - Rick Kulawiec > > -------------------------------------------------------------------------/ > > > > On Mon, 21 Sep 1998, Brian Gordon wrote: > > > > > Anyone else having problems with WEB TV dialins.??? > > > > > > I upgrade my Hyper Arc's today to 4.1.11 and know no Web TV People can > > > Connect???? > > > > > > > > > Brian Gordon, MCP > > > Westelcom Internet Administrator > > > http://www.westelcom.com > > > 518-566-8376 Voice > > > 518-566-8348 Fax > > > administrator@westelcom.com > > > > > > > -----Original Message----- > > > > From: owner-usr-tc@lists.xmission.com > > > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian > > > > Sent: Monday, September 21, 1998 4:17 PM > > > > To: USRobotics TC Mailing List > > > > Subject: (usr-tc) login user > > > > > > > > > > > > I am trying to setup an entry in RADIUS that just takes a user to a > > > > specific machine on our network, but it fails. Anyone know why? (all > > > > items below are reply attributes, no check attributes are set) > > > > > > > > > > > > download > > > > User-Service-Type = "Login-User", > > > > Login-Service = "Telnet", > > > > Login-Host = "208.206.76.2" > > > > > > > > > > > > --------------------------------------------------------------------- > > > > Source-IP Src-Port Destination-IP Dest-Port Id Packet-Type > > > > --------------------------------------------------------------------- > > > > 208.206.76.35 1645 208.206.76.23 1645 46 > > Access-Request > > > > --------------------------------------------------------------------- > > > > > > > > User-Name : download > > > > User-Password : xxxxxxxxxx > > > > NAS-IP-Address : 208.206.76.35 > > > > NAS-Port : 3 > > > > Acct-Session-Id : 149271 > > > > Interface-Index : 1259 > > > > Service-Type : 1 > > > > Chasis-Call-Slot : 1 > > > > Chasis-Call-Span : 1 > > > > Chasis-Call-Channel : 3 > > > > Calling-Station-Id : 3182132640 > > > > Called-Station-Id : 3182134600 > > > > NAS-Port-Type : 0 > > > > > > > > --------------------------------------------------------------------- > > > > Source-IP Src-Port Destination-IP Dest-Port Id Packet-Type > > > > --------------------------------------------------------------------- > > > > 208.206.76.23 1645 208.206.76.35 1645 46 > > Access-Reject > > > > --------------------------------------------------------------------- > > > > > > > > Reply-Message : Request Denied > > > > > > > > > > > > > > -------------------------------------------------------------------------- > > > > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service > > > > Provider > > > > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > > > > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > > > > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and 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. >

On Tue, 22 Sep 1998, Mike Andrews wrote: > Some observations on ARC 4.1.11: > > 1) The problem with Port-Limit=1 not working is NOT fixed in 4.1.11. > > 2) The problem where a corrupted Radius authentication response packet > crashed my 4.0.30 card *IS* fixed, however. > > This let me finally finish hacking up my Livingston 2.01 Radius server to > send the Max_Sessions VSA, thereby working around the problem above. > I've tested it and people can no longer bring up 128K (or dual analog) > connections on an ARC when I don't want them to. Good enough for me for > now. > > (Since Mike wanted to know, the corrupt packets had, among other problems, > an attribute length of zero... the attribute/value pair basically started > with 0x1a 0x00 followed by lots of garbage. 4.1.11 was very tolerant of > this and other badly mangled packets I generated during my hackery. :-) > > 3) ARC 4.1.11 seems to send Radius accounting packets to ALL available > accounting servers simultaneously. I think it was previously logging to > the secondary only when the primary is down. Take a look at the new show authentication/show radius settings, you can set this up to perform how you like, I'll admit, the default behavior isn't what most would probably prefer. > > 4) Also, our ARC wants to only contact our secondary authentication > server, despite the primary being up. Maybe this is related to the > above... It doesn't seem to want to kick back over to the primary. > "show authentic" indicates this too -- it lists the active server as being > our secondary. This actually caused some problems for us today, because > the passwd database was only copied to the secondary server once a day. > (It's now copied every 30 minutes.) Did the algorithm for selecting a > server change? > You have to read up on those new authentication/accounting attributes, its very much different. Basically you need to setup your RADIUS as "Fall Through" instead of "Round Robin" (default) on the ARC. Also you will want to setup a Primary and a Primary Backup, rather than a Primary and Secondary for accounting, this is what we did. > 5) I'm having some MPIP problems, but I think they are really NETserver > related. Before I even upgraded the ARC, I was (and still am) having the > following problem: > > 5a) When I bring up a multilink connection with a Windows NT machine and > two analog modems, and the two channels land on separate NETservers, one > channel comes up but the second channel fails. It appears that the MPIP > bundle is getting created, but the second card is trying to give the > second channel a different IP address. The misbehaving NETserver sits in > the "CONNECTING" state until you finally give up on it. I'm hoping this > is just something I've misconfigured... I'm assuming that since the > bundle came up, the client/server lists are OK and the shared secrets are > OK. Bad assumption? > > 5b) Also, I'm running into a problem with stale bundles hanging around and > piling up. I think our neighbor Jeff Mcadams reported this once with his > NETserver-only setup.... > We have a user with Windows 95, DUN 1.2, a 3com Impact IQ, set for > multilink but only authorized for 64K. With our ARC running as the MPIP > server for our two NETservers (3.7.24), I'm getting this: > > tank-arc> list mpip bund > > MPIP Bundles > Bundle EndPointDescriminator No. User > Owner Value Type Links Name > 206.240.130.10 35303236393630363930 5 39 xxxxxx > > > > Mike Andrews (MA12) icq 6602506 -------- mandrews@termfrost.org > VP 'n' Systems/Network Administrator --------- mandrews@dcr.net > Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ > "If Barbie is so popular, why do you have to buy her friends?..." > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

> > Urgh...similar...not exactly what I was seeing. Netserver doesn't have > a command to show the links in a bundle, in fact, it doesn't even have a > command to show *anything* about what the MPIP server thinks > exists...but from the best of my diagnostics, it looks like the MPIP > code on the netserver will think the bundle has 0 links in it, but it > doesn't delete the bundle. You can show bundles in the netserver, the exact command escapes me since I haven't used netservers in a long time. > -- > 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. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Is their a command on the ARC to instruct it to send an address hint to the radius client? Brian Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

-----Original Message----- > >> >> Urgh...similar...not exactly what I was seeing. Netserver doesn't have >> a command to show the links in a bundle, in fact, it doesn't even have a >> command to show *anything* about what the MPIP server thinks >> exists...but from the best of my diagnostics, it looks like the MPIP >> code on the netserver will think the bundle has 0 links in it, but it >> doesn't delete the bundle. > >You can show bundles in the netserver, the exact command escapes me since >I haven't used netservers in a long time. > Strangely enough, the command is 'show bundle' :) Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Andrews |Sent: Tuesday, September 22, 1998 1:20 AM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) ARC 4.1.11 impressions (and MPIP questions) | | |Some observations on ARC 4.1.11: | |1) The problem with Port-Limit=1 not working is NOT fixed in 4.1.11. | |2) The problem where a corrupted Radius authentication response packet |crashed my 4.0.30 card *IS* fixed, however. | |This let me finally finish hacking up my Livingston 2.01 Radius server to |send the Max_Sessions VSA, thereby working around the problem above. |I've tested it and people can no longer bring up 128K (or dual analog) |connections on an ARC when I don't want them to. Good enough for me for |now. | |(Since Mike wanted to know, the corrupt packets had, among other problems, |an attribute length of zero... the attribute/value pair basically started |with 0x1a 0x00 followed by lots of garbage. 4.1.11 was very tolerant of |this and other badly mangled packets I generated during my hackery. :-) | |3) ARC 4.1.11 seems to send Radius accounting packets to ALL available |accounting servers simultaneously. I think it was previously logging to |the secondary only when the primary is down. You have configured a secondary accounting server instead of a First Backup. This is a different terminology from all previous releases. If you don't want accounting sent to two servers simultaneously then don't configure a secondary. Use first backup. |4) Also, our ARC wants to only contact our secondary authentication |server, despite the primary being up. Maybe this is related to the |above... It doesn't seem to want to kick back over to the primary. |"show authentic" indicates this too -- it lists the active server as being |our secondary. This actually caused some problems for us today, because |the passwd database was only copied to the secondary server once a day. |(It's now copied every 30 minutes.) Did the algorithm for selecting a |server change? Yes. The algorithm changed. You have two choices: Round Robin and Fall Through: Round Robin: After Authentication is enabled it will send req's to the primary server. If the packet is not answered, two more will be attempted (based on configured timeouts). If after three there is no response, the secondary becomes the main auth server. It will not go back to the primary until it fails , thus round-robin. Fall Though: Here the primary is tried every time. If it does not respond, all configured AUTH servers are tried at once. So if the primary is down, a AUTH_REQ packet will go to 2nd,3rd etc at once in hopes that one of them will respond. The primary is never disabled. -Mike

Thus spake Brian >> Urgh...similar...not exactly what I was seeing. Netserver doesn't have >> a command to show the links in a bundle, in fact, it doesn't even have a >> command to show *anything* about what the MPIP server thinks >> exists...but from the best of my diagnostics, it looks like the MPIP >> code on the netserver will think the bundle has 0 links in it, but it >> doesn't delete the bundle. >You can show bundles in the netserver, the exact command escapes me since >I haven't used netservers in a long time. Right, you can show the bundles (via the "show bundles" command...makes sense) that the netserver is *hosting*...but you can't show what the MPIP *server* thinks about where bundles and links are...ie, you can't get any useful debug information out of the netserver based MPIP *server*. The problem I'm running into is that the MPIP *server* thinks a bundle exists on a netserver, but the bundle doesn't really exist on that netserver....so a show bun on the netserver shows nothing because the bundle doesn't exist, but the MPIP server thinks it does...though I have only deduced this by observing behavior since there's no commands to induce the MPIP server to tell what its view of bundle states is. Incidentally, this would be trivial to do...the MPIP server stores this state as a linked list internally...bundles are a linked list...each bundle then has a linked list of links that are a part of that bundle...would be easy to write some code to traverse that linked list and print out the bundle information that the MPIP server has knowledge of (or *thinks* it has knowledge of)...and this is where my problem comes in....the last link will get removed, so the pointer in the bundle_info will be NULL...which means that the whole bundle should be removed (no links left in the bundle, the bundle ceases to exist), but the bundle_info structure never gets removed from the linked list. Actually, the structure may be called a bif (short for bundle info) in the code, don't remember as its been a couple of months since I looked at it. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

enable authen hint you can also program any ppp message if you want to to say somthing like your ip address is %client_ip and the NAS ip is %server_ip. The %clinet_ip and %server_ip are key words krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Tue, 22 Sep 1998, Brian wrote: > Is their a command on the ARC to instruct it to send an address hint to > the radius client? > > Brian > > > -------------------------------------------------------------------------- > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

| |Is their a command on the ARC to instruct it to send an address hint to |the radius client? | "enable authentication hint_assigned" -M

On Tue, 22 Sep 1998, Tatai SV Krishnan wrote: > enable authen hint > > you can also program any ppp message if you want to to say somthing like > > your ip address is %client_ip and the NAS ip is %server_ip. > Thanks. > > The %clinet_ip and %server_ip are key words > > krish > > ----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ > tkrishna@bubba.ae.usr.com > ----------------------------/ http://interproc.ae.usr.com ----/ > The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html > -------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec > -------------------------------------------------------------------------/ > > On Tue, 22 Sep 1998, Brian wrote: > > > Is their a command on the ARC to instruct it to send an address hint to > > the radius client? > > > > Brian > > > > > > -------------------------------------------------------------------------- > > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Port-Limit and Max-Channels must have two different functions. In the HiperARC 4.1 refernce , Appendix E a listing of RADIUS attibutes shows both are sent for different situations. E-390 shows PPP Framed User call setup for RADIUS. Max Channels is not sent during this call, but Port-Limit is. E-393 is a Multilink PPP session. Max Channels is sent and Port-Limit is not. Does one limit the number of "sessions" and the other the number of "ports" that can be bonded? Or are their functions identical? I realize that their are issues with these two attributes right now, but beyond that I am looking for how things should be once the bugs are worked out, that is, when should Port-Limit be used, and what is its function vs when should Max-Channels be used and what is its function? To my knowledge, port-limit in the past, did not limit sessions, rather it only limited the number of channels that could be bonded. Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Hi all... I was recently requested by our sales rep to outline in email the various issues that IgLou could potentially run up against in a possible migration to a HiPer Arc based platform. These are all basically public issues at this point, so I thought I would forward a copy of the message that I sent to our rep (Tom Goodman) concerning these issues. I also included (as you'll see below) some issues beyond just the HiPer Arc issues that IgLou has with 3Com. As I said, these are all basically public issues, so I thought I would forward a copy to the usr-tc list to allow others to comment on my thoughts here. Thus spake jeffm >Sorry about taking so long to get this to you...been *extremely* busy >around here tuning our network to handle DS-3 speeds. :) Good problem >to have, but very time consuming. :) >Here is the list of potential issues that we might have with the HiPer >Arc equipment, and also some thoughts about what we would see as logical >courses of action. I also included some other, general issues that we >have with 3Com as a whole. >First, the HiPer Arc potential issues... >First, we need to make sure that your active routing protocols are >solid, RIP version 2 at a minimum is needed. OSPF would be nice, but >since OSPF is unlikely to be implemented on the ComOS code (for obvious >reasons) at this point, until we eliminate all of the ComOS based code >from our network, we will need to run RIPv2. Eventually, we would like >to move to OSPF for our routing protocol completely as it simplifies >configuration considerably (no redistribution from RIPv2 into OSPF, and >no external OSPF routes which is desirable). >Second, MPIP must be *solid*. We've had enough problems with MPIP code >on the netservers. We've developed workaround for bugs that are *still* >present in the ComOS based code after having trouble tickets open for >months, and several major version releases of code for netservers. It >would be nice if the netserver could serve as an MPIP server for the >HARC's, but I understand they're not set up to do it and that in a mixed >Netserver/HARC environment that a HARC must be the MPIP server...that's >acceptable, but not really desirable. Again though, the code needs to >be *solid* on both MPIP client and MPIP server side. I've seen some >reports on usr-tc of ongoing MPIP problems with 4.1.11 HARC code. >Third, V.90 support must be solid. I've heard some reports of >difficulties with Rockwell based modems with HiPer DSP's (not strictly a >HiPer Arc issue, but I suspect any upgrade from netserver to HiPer Arc >will also involve HiPer DSP's) >Fourth, we have a rather uncommon method of authentication. Basically, >we're not a PPP only shop, we still support customers using terminal >based (PCPlus for example) logins to our shell servers. We do this >currently by using the radius_prompt settings on the netserver to allow >a 12 second period for PPP to start up, and then use PAP within PPP to >authenticate normal PPP connections. If PPP is not started up, we then >have it set up to automatically telnet (or rlogin since binary mode >telnet was broken in one of the netserver code releases) to our shell >servers which then provides a typical UNIX based login prompt for our >users that are using terminal programs for their service. >Fifth, just solid code in general...this isn't specifically aimed at >HiPer Arc's but has been a general complaint about 3Com code in general. >Every release of code seems to introduce more bugs than it fixes. This >tends to make us very hesitant to update to new versions of code because >we have to work out all new work-arounds for the bugs that are present >in the new code. We currently have work-arounds in place for the code >that we currently use, so we're happy (relatively) with our current >setup...moving to new Netserver code makes us find and work-around all >new bugs...I can only imagine what joy moving to a whole new platform >would give us in this respect. >On another, somewhat related, note...I spoke with you, Tom, about this >earlier, and wanted to mention it again to make sure it was noted to the >right people. :) >I was interested in finding out what the possibilities are for getting >the Pilgrim, HiPerOS code "back-ported" to the netserver platform. >Currently, it seems that 3Com's plan is to completely discontinue the >Netserver platform. It seems to me (and many other individuals that >I've heard comment on this) that the netserver platform, as a hardware >platform, is not really ready for retirement. The hardware is perfectly >capable of providing quite a wide range and high quality service. I >understand that 3Com is loosing access to the ComOS based source due to >licensing issues, but it seems like discontinuing a fine hardware >platform due to a lack of software makes no sense. The Netserver >hardware, with a quality OS, would make a fine access server for at >least 100 ports (12 quads and 2 DSP's...quite a common config for many >folks at this point), without resorting to the more expensive HiPer Arc >platform. With a 486 based processor, the netserver platform will >almost assuredly not be able to support more advanced, CPU-intensive, >capabilities such as VOIP, maybe limited VPN support, etc., but for a >normal dial-up ISP service such as we (and many other 3Com customers) >have, the Netserver hardware platform is *more* than sufficient. >Indeed, we're hesitant to go to the HiPer Arc platform because of the >added cost, with very little (at this point) added value for the new >platform. Maintaining the Netserver as a low-cost alternative to the >high-density HiPer equipment (and quad modems along with it possibly) >would be *extremely* attractive to small, and start-up ISP's and other >small shops that don't need the port density that the HiPer equipment >provides. >Another concern that we have regards support. I understand the >Netserver platform will continue to be supported...at the very least >from a hardware standpoint, although software support will be curtailed >after Dec. for obvious licensing reasons. Some other concerns do exist >in this realm though. >Despite much grumbling, complaining, cajoling, and other efforts on the >part of 3Com customers, technical support recieved from your technical >support line is still pathetic. There are still reports of technicians >demanding to log into the Total control box (either snmp access to the >nmc or telnet access to the netserver) and not providing any support if >that is not allowed, also reports of technicians telling customers to >take certain actions without any explanation to what they're doing or >how this might help the situation. There are also reports of >technicians attempting to change settings that have absolutely nothing >to do with the problem reported. This is unacceptable. >Add to these tech support problems above, the recent reports that I have >gotten that support contracts have now doubled in price, meaning that I >can now get 24/7 hardware and software support, with advanced overnight >replacement, onsite service if needed and great support from the >technical support line, on *all* of my Cisco equipment, for less than it >costs to get software-only, no onsite support, crappy technical support >line, warranty-only nearly one-month turnaround for hardware >replacement, on *one* of our TC chassis'. Another report that I have >received is that 3Com is no longer allowing support contracts to be >purchased for only a subset of the TC chassis' purchased by a customer, >but requires that support be purchased for all chassis' or none at all. >This means we will be spending (at our next contract renewal) for >limited support on our 3Com equipment, well over 20 *times* what we will >be spending for very complete support for our Cisco equipment. I'm >sorry folks, but that's ridiculous, particularly when you consider the >much larger range of services, protocols, and media types that Cisco >equipment supports in comparison to the Total Control equipment. >I look forward to discussing these issues with you in future calls, and >hope that solutions can be found to these problems so we can continue >our relationship with 3Com, and hopefully improve this relationship. >Thanks >-- >Jeff McAdams Email: jeffm@iglou.com >Head Network Administrator Voice: (502) 966-3848 >IgLou Internet Services (800) 436-4456 -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Craig, If you are tyring to generate the accounting report for the calls on the DSP , then you will have to do the following to get a correct report. 1) Highlight the DSP in TCM and go to Fault --> Trap Settings. Select a Template eg Template 1.Select Trap Enables. Set the Traps to Enable log for Incoming calls, incoming Termination etc. Save the DSP settings to NVRAM. You will not have to reset the DSP. 2) Select the Whole DSP Card from TCM ----> Configure ----> Programmed Settings ---> Card Level----> Call statistics. Select Group selection as group1and2and3and4.Minimum Group 3 is required. 3) Highlight your NMC --> Logging Group. type in the IP address of your Primary Accounting server in "Primary log Server IP Address". Set the Log server's UDP port as of the accounting server.Default 1646. Also set the Log group selection to group 2345 . Minimum group 3 is required.Save the settings to NVRAM and reset your NMC. When the NMC comes back up it will display the Event logging Server as Primary. 4) In the Security and accounting server add NMC as a Client with the same UDP port as of NMC.Default 1646. Restart your S/A server. 5)After this any calls will generate a accounting report. Go to your Database manager and select accounting report. In the Chassis/IP field select the IP address of the NMC. When you will do a preview Report on Call Statistics by day you will see the no of incoming calls. Then you can generate the report as you want. regards Sanjay Agarwal. On Fri, 18 Sep 1998, Craig Holland wrote: > Could someone help me figure out why I can't use all the built in accounting > features of the Accounting Server. Specifically, when I do an accounting > report, select a user name, and select "Call statistics by day", it comes > back with #Error all over the form. > > Can anyone help? > > thanks, > craig > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

> > >First, we need to make sure that your active routing protocols are > >solid, RIP version 2 at a minimum is needed. OSPF would be nice, but > >since OSPF is unlikely to be implemented on the ComOS code (for obvious > >reasons) at this point, until we eliminate all of the ComOS based code > >from our network, we will need to run RIPv2. Eventually, we would like > >to move to OSPF for our routing protocol completely as it simplifies > >configuration considerably (no redistribution from RIPv2 into OSPF, and > >no external OSPF routes which is desirable). I have not seen any issues with RIP on the ARC's. > > >Second, MPIP must be *solid*. We've had enough problems with MPIP code > >on the netservers. We've developed workaround for bugs that are *still* > >present in the ComOS based code after having trouble tickets open for > >months, and several major version releases of code for netservers. It > >would be nice if the netserver could serve as an MPIP server for the > >HARC's, but I understand they're not set up to do it and that in a mixed > >Netserver/HARC environment that a HARC must be the MPIP server...that's > >acceptable, but not really desirable. Again though, the code needs to > >be *solid* on both MPIP client and MPIP server side. I've seen some > >reports on usr-tc of ongoing MPIP problems with 4.1.11 HARC code. I have not seen problems with MPIP but then again I haven't been running it very long. If I have problems with it, it will be posted here. > >replacement, on *one* of our TC chassis'. Another report that I have > >received is that 3Com is no longer allowing support contracts to be > >purchased for only a subset of the TC chassis' purchased by a customer, > >but requires that support be purchased for all chassis' or none at all. > >This means we will be spending (at our next contract renewal) for > >limited support on our 3Com equipment, well over 20 *times* what we will > >be spending for very complete support for our Cisco equipment. I'm > >sorry folks, but that's ridiculous, particularly when you consider the > >much larger range of services, protocols, and media types that Cisco > >equipment supports in comparison to the Total Control equipment. This is what I have seen so far. I am told solutions are in the works. But basically what I have seen is that a contract will not be honored on a chassis, regardless of the fact it was paid for, unless you purchase contracts for ALL your chassis. These contracts aren't cheap for the 3 or so calls I may call in in a year. I agree with the Cisco analogy. The support contracts on ALL our cisco stuff, fasthubs, routers, switches, etc. Is only a fraction of the cost of a single USR TC chassis contract. The tech support at cisco requires them to be of "engineering" level, able to solve your problem in one call, no matter how complex (bgp4 routing, complex NAT setups, route redistribution filters). > > >I look forward to discussing these issues with you in future calls, and > >hope that solutions can be found to these problems so we can continue > >our relationship with 3Com, and hopefully improve this relationship. > > >Thanks > >-- > >Jeff McAdams Email: jeffm@iglou.com > >Head Network Administrator Voice: (502) 966-3848 > >IgLou Internet Services (800) 436-4456 > > -- > 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. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

> > You have configured a secondary accounting server instead of a First Backup. This > is a different terminology from all previous releases. If you don't want > accounting sent to two servers simultaneously then don't configure a secondary. > Use first backup. Once it switches to backup, it seems "stuck" their. Is their a way to tell it to always try the "primary" server first, before trying the "primary backup"? I know you can do this with Authentication, using Fall Through vs Round Robin, but can this same idea be applied to Accounting as well? > > |4) Also, our ARC wants to only contact our secondary authentication > |server, despite the primary being up. Maybe this is related to the > |above... It doesn't seem to want to kick back over to the primary. > |"show authentic" indicates this too -- it lists the active server as being > |our secondary. This actually caused some problems for us today, because > |the passwd database was only copied to the secondary server once a day. > |(It's now copied every 30 minutes.) Did the algorithm for selecting a > |server change? > > Yes. The algorithm changed. You have two choices: Round Robin and Fall Through: > Round Robin: > After Authentication is enabled it will send req's to the primary server. If the > packet is not answered, two more will be attempted (based on configured > timeouts). If after three there is no response, the secondary becomes the main > auth server. It will not go back to the primary until it fails , thus > round-robin. > > Fall Though: > Here the primary is tried every time. If it does not respond, all configured > AUTH servers are tried at once. So if the primary is down, a AUTH_REQ packet will > go to 2nd,3rd etc at once in hopes that one of them will respond. The primary is > never disabled. > > -Mike > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

It works great, however, where do you set the secret on the NMC? Thanks for the info. Richard sagarwal@crash.ae.usr.com wrote: > > Craig, > > If you are tyring to generate the accounting report for the calls on the > DSP , then you will have to do the following to get a correct report. > > 1) Highlight the DSP in TCM and go to Fault --> Trap Settings. Select a > Template > eg Template 1.Select Trap Enables. Set the Traps to Enable log for > Incoming calls, incoming Termination etc. Save the DSP settings to NVRAM. > You will not have to reset the DSP. > > 2) Select the Whole DSP Card from TCM ----> Configure ----> Programmed > Settings ---> Card Level----> Call statistics. Select Group selection as > group1and2and3and4.Minimum Group 3 is required. > > 3) Highlight your NMC --> Logging Group. type in the IP address of your > Primary Accounting server in "Primary log Server IP Address". Set the Log > server's UDP port as of the accounting server.Default 1646. Also set the > Log group selection to group 2345 . Minimum group 3 is required.Save the > settings to NVRAM and reset your NMC. When the NMC comes back up it will > display the Event logging Server as Primary. > > 4) In the Security and accounting server add NMC as a Client with the same > UDP port as of NMC.Default 1646. Restart your S/A server. > > 5)After this any calls will generate a accounting report. Go to your > Database manager and select accounting report. In the Chassis/IP field > select the IP address of the NMC. When you will do a preview Report on > Call Statistics by day you will see the no of incoming calls. Then you can > generate the report as you want. > > regards > > Sanjay Agarwal. > > > > On Fri, 18 Sep 1998, Craig Holland wrote: > > > Could someone help me figure out why I can't use all the built in accounting > > features of the Accounting Server. Specifically, when I do an accounting > > report, select a user name, and select "Call statistics by day", it comes > > back with #Error all over the form. > > > > Can anyone help? > > > > thanks, > > craig

Brian said once upon a time: > >I figured this out. I was setting the attribute with the wrong name. >show remote user < username > and monitor radius both show the filter >information correctly now. > >BTW, Dynamic Filters kick *ss!! Does Radiator's dynamic filtering account for framed-routes as well as the framed-address?

Thus spake Brian >> >First, we need to make sure that your active routing protocols are >> >solid, RIP version 2 at a minimum is needed. OSPF would be nice, but >> >since OSPF is unlikely to be implemented on the ComOS code (for obvious >> >reasons) at this point, until we eliminate all of the ComOS based code >> >from our network, we will need to run RIPv2. Eventually, we would like >> >to move to OSPF for our routing protocol completely as it simplifies >> >configuration considerably (no redistribution from RIPv2 into OSPF, and >> >no external OSPF routes which is desirable). >I have not seen any issues with RIP on the ARC's. OK, that takes care of one issue then. :) We can use RIPv2 and wait until OSPF matures. I had not heard any reports of problems with RIP on HARC's, but I also hadn't heard any reports that it *did* work. :) >I have not seen problems with MPIP but then again I haven't been running >it very long. If I have problems with it, it will be posted here. Well...Tom is talking about getting us one to play with, so I'll throw the MPIP server on it and see if it suffers from the bug we've found in the netserver based MPIP code that I described elsewhere...then maybe I'll try it taking calls and make sure that the MPIP client code is good. :) >This is what I have seen so far. I am told solutions are in the works. >But basically what I have seen is that a contract will not be honored on a >chassis, regardless of the fact it was paid for, unless you purchase >contracts for ALL your chassis. These contracts aren't cheap for the 3 or >so calls I may call in in a year. Hrmm...I'd question whether that's even legal...definitely. If they didn't take the money for the contracts then I wouldn't have as much beef about it, but if they're taking the money for that support contract, they *derned* well better honor it. >I agree with the Cisco analogy. The support contracts on ALL our cisco >stuff, fasthubs, routers, switches, etc. Is only a fraction of the cost >of a single USR TC chassis contract. The tech support at cisco requires >them to be of "engineering" level, able to solve your problem in one call, >no matter how complex (bgp4 routing, complex NAT setups, route >redistribution filters). Well...I've had a few calls with Cisco that weren't answered on a first call, but usually it was a "here, try this possible solution, see what it does and get back to me" with Cisco doing an *excellent* job of getting back to me concerning the issue if I don't get back to them. I just spoke with my co-admin about it...and his comment was that there just is no way to compare Cisco and 3Com...its night and day as far as support goes. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Mike Wronski said once upon a time: >There is a 4.1.x manual. It has all the features. 4.1 is very different from 4.0 >and some features are configured differently from the previous version. Where is it, and is it possible to order printed copies? When I printed the PDF of 4.0, it cost me over $100 to get done with color and bound.

Mike Wronski said once upon a time: >There is a 4.1.x manual. It has all the features. 4.1 is very different from 4.0 >and some features are configured differently from the previous version. Where is it, and is it possible to order printed copies? When I printed the PDF of 4.0, it cost me over $100 to get done with color and bound.

At 10:44 AM 9/22/98 -0500, sagarwal@crash.ae.usr.com wrote: >Craig, > >If you are tyring to generate the accounting report for the calls on the >DSP , then you will have to do the following to get a correct report. > >1) Highlight the DSP in TCM and go to Fault --> Trap Settings. Select a >Template >eg Template 1.Select Trap Enables. Set the Traps to Enable log for >Incoming calls, incoming Termination etc. Save the DSP settings to NVRAM. >You will not have to reset the DSP. Would it make a difference if the traps are set to 'enableall' instead of 'enablelog'? Other than this difference, I followed the steps listed, and still get nothing but #error on reports. Kirk >2) Select the Whole DSP Card from TCM ----> Configure ----> Programmed >Settings ---> Card Level----> Call statistics. Select Group selection as >group1and2and3and4.Minimum Group 3 is required. > >3) Highlight your NMC --> Logging Group. type in the IP address of your >Primary Accounting server in "Primary log Server IP Address". Set the Log >server's UDP port as of the accounting server.Default 1646. Also set the >Log group selection to group 2345 . Minimum group 3 is required.Save the >settings to NVRAM and reset your NMC. When the NMC comes back up it will >display the Event logging Server as Primary. > >4) In the Security and accounting server add NMC as a Client with the same >UDP port as of NMC.Default 1646. Restart your S/A server. > >5)After this any calls will generate a accounting report. Go to your >Database manager and select accounting report. In the Chassis/IP field >select the IP address of the NMC. When you will do a preview Report on >Call Statistics by day you will see the no of incoming calls. Then you can >generate the report as you want. > >regards > >Sanjay Agarwal. Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

Go to NMC console and select configuration. Option 7 is to set Radius secret key. Sanjay On Tue, 22 Sep 1998, Richard Lorbieski wrote: > It works great, however, where do you set the secret on the NMC? > > Thanks for the info. > > Richard > > > sagarwal@crash.ae.usr.com wrote: > > > > Craig, > > > > If you are tyring to generate the accounting report for the calls on the > > DSP , then you will have to do the following to get a correct report. > > > > 1) Highlight the DSP in TCM and go to Fault --> Trap Settings. Select a > > Template > > eg Template 1.Select Trap Enables. Set the Traps to Enable log for > > Incoming calls, incoming Termination etc. Save the DSP settings to NVRAM. > > You will not have to reset the DSP. > > > > 2) Select the Whole DSP Card from TCM ----> Configure ----> Programmed > > Settings ---> Card Level----> Call statistics. Select Group selection as > > group1and2and3and4.Minimum Group 3 is required. > > > > 3) Highlight your NMC --> Logging Group. type in the IP address of your > > Primary Accounting server in "Primary log Server IP Address". Set the Log > > server's UDP port as of the accounting server.Default 1646. Also set the > > Log group selection to group 2345 . Minimum group 3 is required.Save the > > settings to NVRAM and reset your NMC. When the NMC comes back up it will > > display the Event logging Server as Primary. > > > > 4) In the Security and accounting server add NMC as a Client with the same > > UDP port as of NMC.Default 1646. Restart your S/A server. > > > > 5)After this any calls will generate a accounting report. Go to your > > Database manager and select accounting report. In the Chassis/IP field > > select the IP address of the NMC. When you will do a preview Report on > > Call Statistics by day you will see the no of incoming calls. Then you can > > generate the report as you want. > > > > regards > > > > Sanjay Agarwal. > > > > > > > > On Fri, 18 Sep 1998, Craig Holland wrote: > > > > > Could someone help me figure out why I can't use all the built in accounting > > > features of the Accounting Server. Specifically, when I do an accounting > > > report, select a user name, and select "Call statistics by day", it comes > > > back with #Error all over the form. > > > > > > Can anyone help? > > > > > > thanks, > > > craig > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

No enable all should also work and I have tested with that setting also. It works fine. Sanjay On Tue, 22 Sep 1998, K Mitchell wrote: > At 10:44 AM 9/22/98 -0500, sagarwal@crash.ae.usr.com wrote: > >Craig, > > > >If you are tyring to generate the accounting report for the calls on the > >DSP , then you will have to do the following to get a correct report. > > > >1) Highlight the DSP in TCM and go to Fault --> Trap Settings. Select a > >Template > >eg Template 1.Select Trap Enables. Set the Traps to Enable log for > >Incoming calls, incoming Termination etc. Save the DSP settings to NVRAM. > >You will not have to reset the DSP. > > Would it make a difference if the traps are set to 'enableall' instead of > 'enablelog'? Other than this difference, I followed the steps listed, and > still get nothing but #error on reports. > > Kirk > > >2) Select the Whole DSP Card from TCM ----> Configure ----> Programmed > >Settings ---> Card Level----> Call statistics. Select Group selection as > >group1and2and3and4.Minimum Group 3 is required. > > > >3) Highlight your NMC --> Logging Group. type in the IP address of your > >Primary Accounting server in "Primary log Server IP Address". Set the Log > >server's UDP port as of the accounting server.Default 1646. Also set the > >Log group selection to group 2345 . Minimum group 3 is required.Save the > >settings to NVRAM and reset your NMC. When the NMC comes back up it will > >display the Event logging Server as Primary. > > > >4) In the Security and accounting server add NMC as a Client with the same > >UDP port as of NMC.Default 1646. Restart your S/A server. > > > >5)After this any calls will generate a accounting report. Go to your > >Database manager and select accounting report. In the Chassis/IP field > >select the IP address of the NMC. When you will do a preview Report on > >Call Statistics by day you will see the no of incoming calls. Then you can > >generate the report as you want. > > > >regards > > > >Sanjay Agarwal. > > > Kirk Mitchell-General Manager sysadmin@keyconn.net > Keystone Connect http://www.keyconn.net > Altoona, PA 814-941-5000 We Unlock the World > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Andrews |Sent: Tuesday, September 22, 1998 12:49 PM |To: usr-tc@lists.xmission.com |Subject: RE: (usr-tc) ARC 4.1.11 impressions (and MPIP questions) | | |On Tue, 22 Sep 1998, Mike Wronski wrote: | |> Yes. The algorithm changed. You have two choices: Round Robin and |Fall Through: |> Round Robin: |> After Authentication is enabled it will send req's to the |primary server. If the |> packet is not answered, two more will be attempted (based on configured |> timeouts). If after three there is no response, the secondary becomes the main |> auth server. It will not go back to the primary until it fails , thus |> round-robin. |> |> Fall Though: |> Here the primary is tried every time. If it does not respond, |all configured |> AUTH servers are tried at once. So if the primary is down, a AUTH_REQ |packet will |> go to 2nd,3rd etc at once in hopes that one of them will respond. The |primary is |> never disabled. | |Thanks Mike and Brian, that took care of it. I also got the backup |accounting server reconfigured to be a primary backup instead of a |secondary. Where was this change documented, by the way? | There is a 4.1.x manual. It has all the features. 4.1 is very different from 4.0 and some features are configured differently from the previous version. -M

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Andrews |Sent: Tuesday, September 22, 1998 12:49 PM |To: usr-tc@lists.xmission.com |Subject: RE: (usr-tc) ARC 4.1.11 impressions (and MPIP questions) | | |On Tue, 22 Sep 1998, Mike Wronski wrote: | |> Yes. The algorithm changed. You have two choices: Round Robin and |Fall Through: |> Round Robin: |> After Authentication is enabled it will send req's to the |primary server. If the |> packet is not answered, two more will be attempted (based on configured |> timeouts). If after three there is no response, the secondary becomes the main |> auth server. It will not go back to the primary until it fails , thus |> round-robin. |> |> Fall Though: |> Here the primary is tried every time. If it does not respond, |all configured |> AUTH servers are tried at once. So if the primary is down, a AUTH_REQ |packet will |> go to 2nd,3rd etc at once in hopes that one of them will respond. The |primary is |> never disabled. | |Thanks Mike and Brian, that took care of it. I also got the backup |accounting server reconfigured to be a primary backup instead of a |secondary. Where was this change documented, by the way? | There is a 4.1.x manual. It has all the features. 4.1 is very different from 4.0 and some features are configured differently from the previous version. -M

Kirk , If your settings are they way I sent earlier then if you save and reset your NMC card the "Event Logging server" is going to be filled with either primary or secondary depending on the Accounting server's Ip address entry. "logging server's DNS enable" set to disable should not cause a problem. regards Sanjay Agarwal On Tue, 22 Sep 1998, K Mitchell wrote: > At 12:47 PM 9/22/98 -0500, you wrote: > >No enable all should also work and I have tested with that setting also. > >It works fine. > > [snip] > > 3) Highlight your NMC --> Logging Group. type in the IP address of your > > >Primary Accounting server in "Primary log Server IP Address". Set the Log > > >server's UDP port as of the accounting server.Default 1646. Also set the > > >Log group selection to group 2345 . Minimum group 3 is required.Save the > > >settings to NVRAM and reset your NMC. When the NMC comes back up it will > > >display the Event logging Server as Primary. > > my settings here are as listed, but, below that, the "Logging Server's > Name" is blank and "Logging Server DNS Enable" is set to 'disable'. Does > one or both of these need changed? > > Kirk > Kirk Mitchell-General Manager sysadmin@keyconn.net > Keystone Connect http://www.keyconn.net > Altoona, PA 814-941-5000 We Unlock the World > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Tue, 22 Sep 1998, Mike Wronski wrote: > Yes. The algorithm changed. You have two choices: Round Robin and Fall Through: > Round Robin: > After Authentication is enabled it will send req's to the primary server. If the > packet is not answered, two more will be attempted (based on configured > timeouts). If after three there is no response, the secondary becomes the main > auth server. It will not go back to the primary until it fails , thus > round-robin. > > Fall Though: > Here the primary is tried every time. If it does not respond, all configured > AUTH servers are tried at once. So if the primary is down, a AUTH_REQ packet will > go to 2nd,3rd etc at once in hopes that one of them will respond. The primary is > never disabled. Thanks Mike and Brian, that took care of it. I also got the backup accounting server reconfigured to be a primary backup instead of a secondary. Where was this change documented, by the way? Mike Andrews (MA12) icq 6602506 -------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "If Barbie is so popular, why do you have to buy her friends?..."

At 12:47 PM 9/22/98 -0500, you wrote: >No enable all should also work and I have tested with that setting also. >It works fine. [snip] 3) Highlight your NMC --> Logging Group. type in the IP address of your > >Primary Accounting server in "Primary log Server IP Address". Set the Log > >server's UDP port as of the accounting server.Default 1646. Also set the > >Log group selection to group 2345 . Minimum group 3 is required.Save the > >settings to NVRAM and reset your NMC. When the NMC comes back up it will > >display the Event logging Server as Primary. my settings here are as listed, but, below that, the "Logging Server's Name" is blank and "Logging Server DNS Enable" is set to 'disable'. Does one or both of these need changed? Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

At 12:47 PM 9/22/98 -0500, you wrote: >No enable all should also work and I have tested with that setting also. >It works fine. [snip] 3) Highlight your NMC --> Logging Group. type in the IP address of your > >Primary Accounting server in "Primary log Server IP Address". Set the Log > >server's UDP port as of the accounting server.Default 1646. Also set the > >Log group selection to group 2345 . Minimum group 3 is required.Save the > >settings to NVRAM and reset your NMC. When the NMC comes back up it will > >display the Event logging Server as Primary. my settings here are as listed, but, below that, the "Logging Server's Name" is blank and "Logging Server DNS Enable" is set to 'disable'. Does one or both of these need changed? Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

On Tue, 22 Sep 1998, Pete Ashdown wrote: > Brian said once upon a time: > > > >I figured this out. I was setting the attribute with the wrong name. > >show remote user < username > and monitor radius both show the filter > >information correctly now. > > > >BTW, Dynamic Filters kick *ss!! > > Does Radiator's dynamic filtering account for framed-routes as well as the > framed-address? Well yes, you would just have to build your filter accordingly, you can insert the customers Framed-Netmask, and other information into the filter, so as to build it dynamically. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

OK, here's a specific instance of the first MPIP problem I'm having. I just made a MLPPP call with two analog modems, from an NT Workstation, into our pool. One channel landed on an ARC, one channel on a NETserver. The ARC side came up first, then the NETserver side just stuck in the "CONNECTING" state with a different IP address. The ARC, running 4.1.11, is the MPIP server. The NETservers, running 3.7.24, are MPIP clients. netserver1> show global [munch] RADIUS Server: 206.240.130.2 Port: 1645 Version: 1 Alt. RADIUS Server: 206.240.130.4 Port: 1645 Version: 1 Accounting Server: 206.240.130.2 Port: 1646 Version: 1 Alt. Acct. Server: 206.240.130.4 Port: 1646 Version: 1 NTP Time Server: 206.240.130.2 Alt. Time Server: 0.0.0.0 MPIP Server: 206.240.130.16 Port: 5912 MPIP Server: 0.0.0.0 Port: 5912 MPIP Server: 0.0.0.0 Port: 5912 MPIP Server: 0.0.0.0 Port: 5912 PPTP IP Address: 0.0.0.0 [munch] 206.240.130.16 is the ARC, which has: arc1> show mpip settings MPIP Server State ON MPIP Client State ON MPIP UDP Port 5912 arc1> list mpip clients MPIP Clients Client Type 206.240.130.10 NETSERVER 206.240.130.12 NETSERVER 206.240.130.16 HIPER arc1> list mpip servers MPIP Servers IP Address UDP Port Priority 206.240.130.16 5912 1 Just now when I tried to dial in the first time, both channels landed on the ARC and all was well. The next time, the ARC authenticated the first one, then two seconds later the NETserver authenticated the second one. Then it got stuck. Relevant output: netserver1> show session S48 mandrews - Netwrk In CONNECTING - 0 netserver1> show s48 ----------------------- Current Status - Port S48 --------------------------- Status: CONNECTING Input: 572 Parity Errors: 0 Output: 276 Framing Errors: 0 Pending: 0 Overrun Errors: 0 Active Configuration Default Configuration -------------------- --------------------- Port Type: Netwrk Login/Netwrk (Dial In) (Security) Device Service: MPIP Tunnel Bundle Owner: 206.240.130.16 Modem Stat: READY ACTIVE Databits: 8 8 Stopbits: 1 1 Parity: none none Flow Control: None None* Modem Control: on on HDLC Framing: PPP in modem PPP in modem SLIP Framing: SLIP in NETServer SLIP in NETServer Remote Host: 199.77.100.1 0.0.0.0 Netmask: 255.255.255.255 0.0.0.0 Interface: ptp48 (PPP,Listen,Compr (SLIP,Quiet) Mtu: 1500 596 Async Map: L:00000000 R:00000000 00000000 Pkt Filters: In:dialup.in Out:dialup.out -- Press Return for More -- netserver1> show bundle Total Bundles: 0 Total Links: 0 On the ARC side: arc1> list mpip bundle MPIP Bundles Bundle EndPointDescriminator No. User Owner Value Type Links Name 206.240.130.16 AE4D8A50500211D2B1C0 1 2 mandrews arc1> list conn [munch] slot:2/mod:17 mandrews DIALIN PPP 22-SEP-1998 18:16:23 [munch] So it looks like the MPIP server (the ARC) sees a two-channel bundle, but the MPIP client (the NETserver) isn't seeing the bundle there at all. The IP address the NT does get is the ARC address. The NETserver has 199.77.100.1 for the IP address of that channel, which is out of the NETserver's pool, not the ARC's. I've just gone through and changed all the shared secrets so that they're all the same across the board. (I do *not* need quotes around them, right?) Does that make my problem any easier to understand, or are you now as confused as I am? ;-) Mike Andrews (MA12) icq 6602506 -------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "If Barbie is so popular, why do you have to buy her friends?..." On Tue, 22 Sep 1998, Jeff Mcadams wrote: > >5a) When I bring up a multilink connection with a Windows NT machine and > >two analog modems, and the two channels land on separate NETservers, one > >channel comes up but the second channel fails. It appears that the MPIP > >bundle is getting created, but the second card is trying to give the > >second channel a different IP address. The misbehaving NETserver sits in > >the "CONNECTING" state until you finally give up on it.

Thus spake Mike Andrews >OK, here's a specific instance of the first MPIP problem I'm having. I >just made a MLPPP call with two analog modems, from an NT Workstation, >into our pool. One channel landed on an ARC, one channel on a NETserver. >The ARC side came up first, then the NETserver side just stuck in the >"CONNECTING" state with a different IP address. I think you're seeing a problem where there is none. :) >The ARC, running 4.1.11, is the MPIP server. The NETservers, running >3.7.24, are MPIP clients. ^^^^^^ 3.7.24 shows MPIP tunneled links as being in the "CONNECTING" state. They are tunneled and the MP bundle is working, just the state on the port is misleading. >netserver1> show session >S48 mandrews - Netwrk In CONNECTING - 0 >netserver1> show s48 >----------------------- Current Status - Port S48 --------------------------- > Status: CONNECTING > Input: 572 Parity Errors: 0 > Output: 276 Framing Errors: 0 > Pending: 0 Overrun Errors: 0 Notice the Input and Output counters...pretty high for a stuck call...I bet they're incrementing too. :) > Active Configuration Default Configuration > -------------------- --------------------- > Port Type: Netwrk Login/Netwrk (Dial In) (Security) >Device Service: MPIP Tunnel > Bundle Owner: 206.240.130.16 ^^^^^^^^^^^ Looks like it did see the tunnel connection... >netserver1> show bundle >Total Bundles: 0 Total Links: 0 This only shows bundles that are hosted on the netserver...since the first link of this bundle landed on the Arc, the bundle is hosted on the ARC...the netserver will therefore show nothing in show bundle, which is what you see here. >On the ARC side: >arc1> list mpip bundle >MPIP Bundles >Bundle EndPointDescriminator No. User >Owner Value Type Links Name >206.240.130.16 AE4D8A50500211D2B1C0 1 2 mandrews ^ Shows two links...I really think you're not having any problems here...just getting confused by the port state on the netserver. >So it looks like the MPIP server (the ARC) sees a two-channel bundle, but >the MPIP client (the NETserver) isn't seeing the bundle there at all. Nope, and it won't because the netserver isn't hosting the bundle, the Arc is... >The IP address the NT does get is the ARC address. Which is correct as PPP is running on the Arc. >The NETserver has >199.77.100.1 for the IP address of that channel, which is out of the >NETserver's pool, not the ARC's. Which is almost assuredly not used. >I've just gone through and changed all the shared secrets so that they're >all the same across the board. (I do *not* need quotes around them, >right?) That is correct...might check your syslog to make sure, but I suspect the tunnel is being made correctly...I'm pretty sure your shared secrets are not a problem as the MPIP server is seeing the second link of the tunnel. >Does that make my problem any easier to understand, or are you now as >confused as I am? ;-) Nope...like I said...you're just seeing a problem where there is none...or well...not one anywhere near as serious as it seems on first inspection. Watch the input and output counters on the port on the netserver...I bet they'll increase in correlation to the PPP traffic on the MP link to the NT box... Again, in 3.7.24, the state of a MPIP tunneled link (ie, a link that is connected to an MP bundle that was started on a different system) will show as "CONNECTING." There is nothing broken here...a 3.7.something or other ER release added the "TUNNELED" port status for more clarification, but it seems your connection is working correctly here. >Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ Hey...I'm not sure I want to help you.... :) We may come down there and compete with you eventually. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Tue, 22 Sep 1998, Jeff Mcadams wrote: > Thus spake Mike Andrews > >OK, here's a specific instance of the first MPIP problem I'm having. I > >just made a MLPPP call with two analog modems, from an NT Workstation, > >into our pool. One channel landed on an ARC, one channel on a NETserver. > >The ARC side came up first, then the NETserver side just stuck in the > >"CONNECTING" state with a different IP address. [munch] > 3.7.24 shows MPIP tunneled links as being in the "CONNECTING" state. > They are tunneled and the MP bundle is working, just the state on the > port is misleading. [munch] > Shows two links...I really think you're not having any problems > here...just getting confused by the port state on the netserver. OK. This actually makes some sense. I was getting a little confused by the output. Both modems do seem to be transmitting/receiving packets... But.... There is one problem still (that I stupidly forgot to mention before). When all this is happening, NT gets stuck at the "connecting, bundling additional lines" dialog box and never closes it off. When this happens, the link is up, but with SEVERE packet loss (over 50%), which leads me to believe something is still sick. That doesn't happen when both channels land on the same chassis, of course... > >Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ > > Hey...I'm not sure I want to help you.... :) We may come down there > and compete with you eventually. :) Heh. Well, we are local to Louisville... :)

Thus spake Mike Andrews >There is one problem still (that I stupidly forgot to mention before). >When all this is happening, NT gets stuck at the "connecting, bundling >additional lines" dialog box and never closes it off. When this happens, >the link is up, but with SEVERE packet loss (over 50%), which leads me to >believe something is still sick. That doesn't happen when both channels >land on the same chassis, of course... Ick...that is bad...best thing I could say would be...get an MP log from the NT box and see what it's telling you...they're supposed to have some fairly decent log info there. >Heh. Well, we are local to Louisville... :) Really? I didn't know that...you have a pop up here or just extended calling area or something? -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Chuckle... Good to know I'm not the only one. If your running the Windows version, it could be 3 things. 1) There is no data for your search criteria. 2) Your trying to pull NMC stats when you want N/S stats 3) You have an old dictnary.dat and radserv.scp that doesn't match the SNMP(?) names your version of Netserver is running. Go to options, and turn on all the debugging features to look at the data passing back and forth. You'll probably see lots of errors about unknown values. Steve >Could someone help me figure out why I can't use all the built in accounting >features of the Accounting Server. Specifically, when I do an accounting >report, select a user name, and select "Call statistics by day", it comes >back with #Error all over the form. > >Can anyone help? > >thanks, >craig > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >

FYI for everyone... Here's a little script that works on all our TC chassis's (both NSC and HARC). For those who want to use it to count users for MRTG, it's easy to put a shell over it, count what you need, then output the totals to MRTG. I'll be doing that later today for myself. First, a sample filter, then the expect script... (Your mileage may vary. Void where prohibited. Employees and their family members are not eligible. Don't buy the farm. :) --- tc-finger --- #!/bin/sh # Usage: tc-finger (nsc/harc addr) (nsc/harc addr) ... searchfor="(ESTABLISHED|DIALIN PPP)" for i in $* do tc-finger.exp "$i" | egrep "$searchfor" done --- snip snip snip --- --- tc-finger.exp --- #!/usr/local/bin/expect -f # set timeout 7 set login_name "REPLACE WITH YOUR !root or administrator userid" set login_password "REPLACE WITH YOUR !root or administrator password" ############################################################################### # Please avoid making changes below this point. ############################################################################### ############################################################################### # Get the local machine name ############################################################################### if { [ llength $argv ] != 1 } { puts "Usage: $argv0 <machine.ip.name>" exit } set machine "[ lindex $argv 0 ]" ############################################################################### # Since there are many potential places we can exit after the telnet is # started, the function below will force the exit from the telnet session ############################################################################### proc do_exit () { # The character in quotes here is a real control-], not just carat then ']'. send "" expect "telnet> " send "close\r" expect eof exit } ############################################################################### # Here we go... ############################################################################### spawn telnet $machine match_max 1000 expect { timeout { puts "Error starting telnet session to $machine!" exit } "Connected to " } expect { timeout { puts "Error connecting to TC ($machine)!" exit } "login: " } send -- "($login_name)\r" expect { timeout { puts "Error connecting to TC ($machine)!" do_exit } "Password: " } send -- "($login_password)\r" expect { timeout { puts "Error logging on to TC ($machine)!" do_exit } "Command> " { set chass_type "NSC" set prompt_string "Command> " set list_command "show sessions" set more_prompt " Press Return for More -- " } "HiPer>>" { set chass_type "ARC" set prompt_string "HiPer>>" set list_command "list connections" set more_prompt "More--" } } send -- "$list_command\r" set done 0 set count 1 while { $done < 1 } { expect { timeout { puts "Error collecting data ($machine)!" do_exit set done 1 break } "$more_prompt" { send -- "\r" } \ "$prompt_string" { set done 1 } } if { $count > 500 } { set done 1 } } send -- "quit\r" expect { timeout { puts "Error disconnecting from TC ($machine)!" do_exit } eof } --- snip snip snip --- Kevin E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

There is indeed a difference between the two and the HARC is doing this sanely... Port-limit limits the number of ports the user is allowed to have per NAS -- in or out of a bundle??? Max-channels limits the number of channels that can be bound into one MLPPP bundle. --Ricky

Thus spake Ricky Beam >There is indeed a difference between the two and the HARC is doing this >sanely... Port-limit limits the number of ports the user is allowed to >have per NAS -- in or out of a bundle??? Max-channels limits the number of >channels that can be bound into one MLPPP bundle. Then Port-Limit is useless for all but the smallest of shops. Even using HiPer equipment, I would have to have 4 Arc's to support my largest dial-in pool, if Port-Limit is designed to stop duplicate logins, but doesn't work across multiple NAS's, then its useless. So...uh...what happens in this scenario? User is allowed 2 channels in an MP bundle, but only one login at a time. I would assume that would mean: Max-Channels = 2 Port-Limit = 1 So, user dial's in, hits NAS #1 with a single channel with MP. User dials in a second time with or without MP, doesn't matter, hits NAS #2. First dial-in, brings up a second channel which hits NAS #2, should NAS #2 allow that second channel to be connected? Port-Limit would say no, Max-Channels would say yes. There are all sorts of scenarios that I could come up with if Port-Limit and Max-Channels work in this way that would be problematic at best. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Jeff Mcadams was heard to say: >User is allowed 2 channels in an MP bundle, but only one login at a >time. I would assume that would mean: >Max-Channels = 2 >Port-Limit = 1 I played around with it a little... Port-limit is checked first then the max-channels. I'm saying it's perfect, but it's as good as most other things. Port-limit limits the number of ports per NAS. Max-channels limits the number of channels (and by relation ports) that can be within a single bundle. As for "small" shops... 14 * 23 ports is fairly large amount of dialtone in one spot. (AOL/et. al. eats entire switches of dialtone, FWIW.) --Ricky

Has anyone created an advertisment filter for the HiperARC that will bascially block all broadcast type advertisments such as RIP, NetBeui, etc? Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Thus spake Ricky Beam >Jeff Mcadams was heard to say: >>User is allowed 2 channels in an MP bundle, but only one login at a >>time. I would assume that would mean: >>Max-Channels = 2 >>Port-Limit = 1 >I played around with it a little... >Port-limit is checked first then the max-channels. Should be the other way around IMHO. The link is already established and allows the second channel, so it should be allowed. However, at that point, the second dial-in (non-MP) is in violation of the Port-Limit. :/ I just think Port-Limit is inherently broken. >I'm saying it's perfect, but it's as good as most other things. Port-limit ^^^ I assume you wanted a "not" in there :) >limits the number of ports per NAS. Max-channels limits the number of >channels (and by relation ports) that can be within a single bundle. Like I said then...Port-Limit's useless then. >As for "small" shops... 14 * 23 ports is fairly large amount of dialtone >in one spot. (AOL/et. al. eats entire switches of dialtone, FWIW.) You sure about that? I'm relatively sure we have more dial-tone in Louisville than AOL does...and we're both on the same switch. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

-> Thus spake Ricky Beam -> >There is indeed a difference between the two and the HARC is doing this -> >sanely... Port-limit limits the number of ports the user is allowed to -> >have per NAS -- in or out of a bundle??? Max-channels limits the number of -> >channels that can be bound into one MLPPP bundle. -> -> Then Port-Limit is useless for all but the smallest of shops. Even using -> HiPer equipment, I would have to have 4 Arc's to support my largest dial-in -> pool, if Port-Limit is designed to stop duplicate logins, but doesn't work -> across multiple NAS's, then its useless. -> So...uh...what happens in this scenario? -> -> User is allowed 2 channels in an MP bundle, but only one login at a time. I -> would assume that would mean: -> Max-Channels = 2 -> Port-Limit = 1 -> -> So, user dial's in, hits NAS #1 with a single channel with MP. User dials -> in a second time with or without MP, doesn't matter, hits NAS #2. First -> dial-in, brings up a second channel which hits NAS #2, should NAS #2 allow -> that second channel to be connected? Port-Limit would say no, Max-Channels -> would say yes. -> -> There are all sorts of scenarios that I could come up with if Port-Limit and -> Max-Channels work in this way that would be problematic at best. It would seem to me that the authenticating device (i.e. RADIUS) would be left to handle multiple logins across multiple NASs. Max channels would seem to take care of MPIP across NASs. Port limit does seem to be limited to a single chassis scenario. Jeff Binkley ASA Network Computing

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ricky Beam |Sent: Wednesday, September 23, 1998 6:45 AM |To: USR Total Control List |Subject: (usr-tc) Port-Limit and Max-Channels | | |There is indeed a difference between the two and the HARC is doing this |sanely... Port-limit limits the number of ports the user is allowed to |have per NAS -- in or out of a bundle??? Max-channels limits the number of |channels that can be bound into one MLPPP bundle. Port-Limit is defined in the RADIUS RFC and we will be making it work per the RFC. Which means it only applies to bonded channels and will not effect multiple unbound logins. The functionality of the MAX-Channels VSA may change to reflect the unbound case. There are no plans for some kind of multiple chassis aware HARC that can stop multiple logins. This is left up to RADIUS or other methods (SNMP, etc). -M

Ok...here's a thought...little bit of Blue Sky thinking here... I'm going to *try* to trace out how I came around to these thoughts, but I'm not sure I really remember it all... This is not something that would be upon 3Com to do, but would require broadening the scope of RADIUS as a standard I suspect. It seems to me that Port-Limit type of functionality should rightly be implemented in a RADIUS'ish setup. RADIUS is tasked with determining if a user should get access to that dial-in resource, so if a Port-Limit = 1 is set, and its the second dial-in, the RADIUS server returns an OK, but the call is dropped anyway...seems a bit counter-intuitive. OK, so...for RADIUS to be able to keep track of whether it should return a Port-Limit = 1 type of denial, it needs to keep track of state on the NASen. This is something that traditionally RADIUS servers have not done, but more and more are doing it now so this isn't a big stretch. This alone isn't that much of a change from the current idea on how RADIUS works...but there is a wrinkle... There is really nothing (that I'm aware of) that distinguishes a seperate call being established from a second link of an MP bundle being established in the info that's sent to the RADIUS server. So...in a second call in the scenario I had talked about before (Port-Limit = 1;Max-Channels = 2) the RADIUS server isn't going to know whether to deny the call or not. OK...so you say, "send the EDO info to the RADIUS server," and that was my thought as well...but when you start doing that...hey, you've pretty much just integrated your RADIUS server and your MPIP server. My first thought on thinking this was, "ick." But when I thought about it a bit more, it didn't seem like *all* that bad of an idea. RADIUS is involved in setting up the config on a port for a call...MP bundle existence, location, etc. *certainly* influence how the port gets set up to handle the call, so perhaps this information *should* be returned from RADIUS and not worry about having the code to decide whether this call is in an MP bundle or not out of the NASen...simplifies the NASen code tremendously there. *Another* benefit of this is....viola' we automagically have a cross-platform method of indicating where bundles are hosted...its just returned as a, or a set of, RADIUS attribute(s) (depending on the information that would be needed to indicate where the bundle is hosted). The only thing that would be needed after this to enable cross-platform cross-vendor MP bundling, would be a standard way of actually setting up the actual tunnels...that should be fairly trivial to work out (l2tp, pptp, one of these, not sure which is becoming the standard, could be used I would think). Like I said...pretty Blue Sky kinda stuff...but when you really think about it, the MPIP-type of functionality dove-tails fairly nicely with RADIUS's functionality...its *certainly* involved in the authentication and accounting functions when you really get down to it. So...questions to answer at this point: 1) Am I totally out in left field here, or does this actually make some sense? 2) Is there any possibility of actually getting something like this implemented? 3) Where on God's green earth do I need to go with this from here to actually get this implemented (assuming the answer to #2 is "yes")? Discuss please. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Jeff Binkley >It would seem to me that the authenticating device (i.e. RADIUS) would be >left to handle multiple logins across multiple NASs. Max channels would seem >to take care of MPIP across NASs. Port limit does seem to be limited to a >single chassis scenario. Heh...that was my thought too...which means your gonna love my other email that I just sent. :) Regarding possibly future directions for RADIUS. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Jeff Mcadams was heard to say: >>As for "small" shops... 14 * 23 ports is fairly large amount of dialtone >>in one spot. (AOL/et. al. eats entire switches of dialtone, FWIW.) > >You sure about that? I'm relatively sure we have more dial-tone in >Louisville than AOL does...and we're both on the same switch. Heh, yeah. We ordered an additional PRI from GTE (USLEC, who ever..) and we were informed it would be delayed for several weeks because "AOL just bought them all." (So they have tiny swithces???) --Ricky

I was looking too, but no one on the list seems to care lately. -----Original Message----- Cc: usr-tc@xmission.com <usr-tc@xmission.com> >I'm looking for sample lines to use in my 'clients' file for Merit RADIUS >3.6B in conjunction with USR Total Control equipment. Comments and >details appreciated. > >Please e-mail responses if possible. > >Thanks, > > >Craig Thompson >---------------------------------------------------------------------- >WingNET Internet Services, >P.O. Box 3000 // Cleveland, TN 37320-3000 >423-559-LINK (v) 423-559-5444 (f) >http://www.wingnet.net >---------------------------------------------------------------------- > >Thought for the day: > Mary had a little RAM, only about a meg or so. > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Thus spake Ricky Beam >Jeff Mcadams was heard to say: >>>As for "small" shops... 14 * 23 ports is fairly large amount of dialtone >>>in one spot. (AOL/et. al. eats entire switches of dialtone, FWIW.) >> >>You sure about that? I'm relatively sure we have more dial-tone in >>Louisville than AOL does...and we're both on the same switch. >Heh, yeah. We ordered an additional PRI from GTE (USLEC, who ever..) and >we were informed it would be delayed for several weeks because "AOL just >bought them all." (So they have tiny swithces???) Well...ok...the switch may have been nearly full already and they just got the last of the available? I've done that with GTE before too...got the last available PRI's... -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Jeff Mcadams was heard to say: >Ok...here's a thought...little bit of Blue Sky thinking here... Should duck for cover? >NASen. This is something that traditionally RADIUS servers have not >done, but more and more are doing it now so this isn't a big stretch. It is if you expect it to work CORRECTLY... he's an example for ya'. (And this is happening as we speak.) You get the accounting stop and then the accounting start... if you track based on the accounting data (which I do, as the authentication requests is even worse way) they you end up with things out-o-sync. >This alone isn't that much of a change from the current idea on how >RADIUS works...but there is a wrinkle... Yes, RADIUS is UDP based and as such not entirely stable. >deny the call or not. OK...so you say, "send the EDO info to the RADIUS >server," and that was my thought as well...but when you start doing >that...hey, you've pretty much just integrated your RADIUS server and >your MPIP server. Not really... the EDO is basically a password or other form of authentication token. But it's not much of a leap to MPIP... >So...questions to answer at this point: >1) Am I totally out in left field here, or does this actually make >some sense? Not entirely, but you are a bit left of center. >2) Is there any possibility of actually getting something like this >implemented? Yes. >3) Where on God's green earth do I need to go with this from here to >actually get this implemented (assuming the answer to #2 is "yes")? NetServer, HiperARC, RADIUS, and MPIP source code. While I have the later two, the former will be an enormous amount of work. --Ricky

>I'm looking for sample lines to use in my 'clients' file for Merit RADIUS >3.6B in conjunction with USR Total Control equipment. Comments and >details appreciated. > >Please e-mail responses if possible. > We use: server.domain secret type=USR:NAS for all of our TC chassis... Dave Martin Netcetera, Inc. dpm@netcetera.com "Infinity Welcomes Careful Drivers"

Thus spake Ricky Beam >Jeff Mcadams was heard to say: >>Ok...here's a thought...little bit of Blue Sky thinking here... >Should duck for cover? Heh...Nah...just wanting to get thoughts out there...can't hurt, right? >>NASen. This is something that traditionally RADIUS servers have not >>done, but more and more are doing it now so this isn't a big stretch. >It is if you expect it to work CORRECTLY... he's an example for ya'. >(And this is happening as we speak.) You get the accounting stop and then >the accounting start... if you track based on the accounting data (which >I do, as the authentication requests is even worse way) they you end up >with things out-o-sync. Well...RADIUS Acounting packets have an Acct-Session-Id, which means that if the stop comes in before the start, it should be able to be sorted out...it may be in the file in the wrong order, but it should be fairly trivial to figure out from this info that they came in reversed...not a biggie...You also have Acct-Delay-Time which could be used for this determination. >>This alone isn't that much of a change from the current idea on how >>RADIUS works...but there is a wrinkle... >Yes, RADIUS is UDP based and as such not entirely stable. Well, there are certainly packet-getting-lost issues that need to be dealt with, but RADIUS accounting is supposed to do its own reliability (retransmission of packets) so, in theory at least, that can be ignored. >>deny the call or not. OK...so you say, "send the EDO info to the RADIUS >>server," and that was my thought as well...but when you start doing >>that...hey, you've pretty much just integrated your RADIUS server and >>your MPIP server. >Not really... the EDO is basically a password or other form of authentication >token. But it's not much of a leap to MPIP... Yeah, that's why I said "pretty much." MPIP is *basically*, when you distill it down, just a way for a system to keep track of where various EDO/userid's bundles are homed. Some RADIUS servers are already doing this already (although maybe not entirely reliably...USR's doesn't do it well from what I understand...I've heard some reports that others are pretty good at it? dunno for sure). So...what's really needed is something along the lines of the interim RADIUS accounting notifications. ie, the RADIUS/MPIP'ish server needs some way to recover the state information if its lost (ie, RADIUS server gets killed and restarted, NAS reboots, etc.) this also shouldn't be too terribly hard to handle in the RADIUS protocol, and I think there's already a mechanism defined (though rarely, if ever, used) to recover state in a situation like this. >>So...questions to answer at this point: >>1) Am I totally out in left field here, or does this actually make >>some sense? >Not entirely, but you are a bit left of center. I can deal with that. :) >>2) Is there any possibility of actually getting something like this >>implemented? >Yes. That's encouraging. >>3) Where on God's green earth do I need to go with this from here to >>actually get this implemented (assuming the answer to #2 is "yes")? >NetServer, HiperARC, RADIUS, and MPIP source code. While I have the >later two, the former will be an enormous amount of work. Hrmm...what about making it cross-platform? That would require (as I see it) the following things: 1) Standard way for a RADIUS server to recover state of bundle hosting information...is this already in the RADIUS standard or perhaps a mechanism to recover some state that doesn't necessarily cover bundle info? If so, that could be extended to cover this? 2) Standard tunneling method...pptp seems reasonable. 3) RADIUS dictionary entries to define bundle hosting information in a cross-platform manner...should be fairly trivial to define. 4) Obviously, support for all this in various NASen and RADIUS servers to make this more than just an exercise in Blue Sky thinking. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

If someone knows how to allow for 10 logins with 4.1.11, please let me know. foo User-Service-Type = "Framed-User", Framed-Protocol = "PPP", Framed-Address = "255.255.255.254", Framed-Netmask = "255.255.255.255", Framed-MTU = "1500", Port-Limit = "10", Framed-Routing = "None", Framed-Compression = "Van-Jacobson-TCP-IP", Max-Channels = "10" The above does *not* work. It only allows 2 logins. If someone knows what needs to be done, then please let me know. On 4.0.x all that would be needed is to set Port-Limit to 10, this is not the case here. I have alot of 5 and 10 login customers who need to be able to get on with their full amount. Brian Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Are there any SNMP OID's (either NMC or NETServer) that give the username of someone connected to a port? I've looked everywhere and I can't find 'em. Thanks, Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com

Thus spake Peter D. Mayer >Are there any SNMP OID's (either NMC or NETServer) that give the username of >someone connected to a port? I've looked everywhere and I can't find 'em. No, Netserver only supports MIB-II which doesn't have that information in it. NMC doesn't have access to the Netserver enough to be able to find that out. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Wed, 23 Sep 1998, Brian wrote: > If someone knows how to allow for 10 logins with 4.1.11, please let me > know. > > foo > User-Service-Type = "Framed-User", > Framed-Protocol = "PPP", > Framed-Address = "255.255.255.254", > Framed-Netmask = "255.255.255.255", > Framed-MTU = "1500", > Port-Limit = "10", > Framed-Routing = "None", > Framed-Compression = "Van-Jacobson-TCP-IP", > Max-Channels = "10" This setup is fine. You do not need both port-limit and max-channels. just set the max-channels to 10. krish > > > The above does *not* work. It only allows 2 logins. If someone knows > what needs to be done, then please let me know. On 4.0.x all that would > be needed is to set Port-Limit to 10, this is not the case here. I have > alot of 5 and 10 login customers who need to be able to get on with their > full amount. > > Brian > > -------------------------------------------------------------------------- > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Wed, 23 Sep 1998, Brian wrote: > If someone knows how to allow for 10 logins with 4.1.11, please let me > know. > > foo > User-Service-Type = "Framed-User", > Framed-Protocol = "PPP", > Framed-Address = "255.255.255.254", > Framed-Netmask = "255.255.255.255", > Framed-MTU = "1500", > Port-Limit = "10", > Framed-Routing = "None", > Framed-Compression = "Van-Jacobson-TCP-IP", > Max-Channels = "10" This setup is fine. You do not need both port-limit and max-channels. just set the max-channels to 10. krish > > > The above does *not* work. It only allows 2 logins. If someone knows > what needs to be done, then please let me know. On 4.0.x all that would > be needed is to set Port-Limit to 10, this is not the case here. I have > alot of 5 and 10 login customers who need to be able to get on with their > full amount. > > Brian > > -------------------------------------------------------------------------- > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Once upon a time Ricky Beam shaped the electrons to say... >There is indeed a difference between the two and the HARC is doing this >sanely... Port-limit limits the number of ports the user is allowed to >have per NAS -- in or out of a bundle??? Max-channels limits the number of Per RFC the Port-Limit is supposed to limit the number of channels allowed in ONE MP bundle. It is NOT supposed to control simultaneous logins. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

Once upon a time Ricky Beam shaped the electrons to say... >I'm saying it's perfect, but it's as good as most other things. Port-limit >limits the number of ports per NAS. Max-channels limits the number of >channels (and by relation ports) that can be within a single bundle. 5.42. Port-Limit Description This Attribute sets the maximum number of ports to be provided to the user by the NAS. This Attribute MAY be sent by the server to the client in an Access-Accept packet. It is intended for use in conjunction with Multilink PPP [7] or similar uses. It MAY also be sent by the NAS to the server as a hint that that many ports are desired for use, but the server is not required to honor the hint. Port-Limit was meant to control the number of channels in a bundle, and that is how it works for the other vendors. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

Once upon a time Jeff Mcadams shaped the electrons to say... >1) Standard way for a RADIUS server to recover state of bundle >hosting information...is this already in the RADIUS standard or perhaps >a mechanism to recover some state that doesn't necessarily cover bundle >info? If so, that could be extended to cover this? It is not part of RADIUS - and, IMHO, SHOULD NOT be. RADIUS is not a stateful protocol by design. It is designed to work even if different servers become involved with the same session, as for failover. Coordinating multiple servers and maintaining state is a BITCH - Lucent is doing it with RADIUS ABM using RADIUS, SNMP, and a commercial database backend to handle the shared distributed database problems. It isn't bad if you only run one server - but anyone of any size can't afford to only have one server. Scaling such a thing reliably is NOT a simple task. >2) Standard tunneling method...pptp seems reasonable. YUCK. PPTP is crap - L2TP is better, AND standard. >3) RADIUS dictionary entries to define bundle hosting information in a >cross-platform manner...should be fairly trivial to define. Not going to happen in the RFC - if you didn't know, the RADIUS WG is *closed*. RADIUS is pretty much done. A few drafts are being polished, but new material is too late. Maybe as a VSA. >4) Obviously, support for all this in various NASen and RADIUS servers >to make this more than just an exercise in Blue Sky thinking. And I don't think you'll get this. First off, other vendors don't like MPIP. I tend to thin kthe PM's MCPPP system scales better. PMs haven't had any problems with huge stacks, and it runs with one setting. No backside host needed at all. And it is easy to locate the master for any given bundle from the command line, or PMVision. And every other vendor has their own protocols, none like MPIP. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

Once upon a time Jeff Mcadams shaped the electrons to say... >1) Standard way for a RADIUS server to recover state of bundle >hosting information...is this already in the RADIUS standard or perhaps >a mechanism to recover some state that doesn't necessarily cover bundle >info? If so, that could be extended to cover this? It is not part of RADIUS - and, IMHO, SHOULD NOT be. RADIUS is not a stateful protocol by design. It is designed to work even if different servers become involved with the same session, as for failover. Coordinating multiple servers and maintaining state is a BITCH - Lucent is doing it with RADIUS ABM using RADIUS, SNMP, and a commercial database backend to handle the shared distributed database problems. It isn't bad if you only run one server - but anyone of any size can't afford to only have one server. Scaling such a thing reliably is NOT a simple task. >2) Standard tunneling method...pptp seems reasonable. YUCK. PPTP is crap - L2TP is better, AND standard. >3) RADIUS dictionary entries to define bundle hosting information in a >cross-platform manner...should be fairly trivial to define. Not going to happen in the RFC - if you didn't know, the RADIUS WG is *closed*. RADIUS is pretty much done. A few drafts are being polished, but new material is too late. Maybe as a VSA. >4) Obviously, support for all this in various NASen and RADIUS servers >to make this more than just an exercise in Blue Sky thinking. And I don't think you'll get this. First off, other vendors don't like MPIP. I tend to thin kthe PM's MCPPP system scales better. PMs haven't had any problems with huge stacks, and it runs with one setting. No backside host needed at all. And it is easy to locate the master for any given bundle from the command line, or PMVision. And every other vendor has their own protocols, none like MPIP. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

Once upon a time Jeff Mcadams shaped the electrons to say... >1) Standard way for a RADIUS server to recover state of bundle >hosting information...is this already in the RADIUS standard or perhaps >a mechanism to recover some state that doesn't necessarily cover bundle >info? If so, that could be extended to cover this? It is not part of RADIUS - and, IMHO, SHOULD NOT be. RADIUS is not a stateful protocol by design. It is designed to work even if different servers become involved with the same session, as for failover. Coordinating multiple servers and maintaining state is a BITCH - Lucent is doing it with RADIUS ABM using RADIUS, SNMP, and a commercial database backend to handle the shared distributed database problems. It isn't bad if you only run one server - but anyone of any size can't afford to only have one server. Scaling such a thing reliably is NOT a simple task. >2) Standard tunneling method...pptp seems reasonable. YUCK. PPTP is crap - L2TP is better, AND standard. >3) RADIUS dictionary entries to define bundle hosting information in a >cross-platform manner...should be fairly trivial to define. Not going to happen in the RFC - if you didn't know, the RADIUS WG is *closed*. RADIUS is pretty much done. A few drafts are being polished, but new material is too late. Maybe as a VSA. >4) Obviously, support for all this in various NASen and RADIUS servers >to make this more than just an exercise in Blue Sky thinking. And I don't think you'll get this. First off, other vendors don't like MPIP. I tend to thin kthe PM's MCPPP system scales better. PMs haven't had any problems with huge stacks, and it runs with one setting. No backside host needed at all. And it is easy to locate the master for any given bundle from the command line, or PMVision. And every other vendor has their own protocols, none like MPIP. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

Once upon a time Frank Basso shaped the electrons to say... >I was looking too, but no one on the list seems to care lately. Same here - Can someone please just post the 3Com RADIUS dictionary? It shouldn't take but a moment. Thanks. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

Once upon a time Frank Basso shaped the electrons to say... >I was looking too, but no one on the list seems to care lately. Same here - Can someone please just post the 3Com RADIUS dictionary? It shouldn't take but a moment. Thanks. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

Once upon a time Frank Basso shaped the electrons to say... >I was looking too, but no one on the list seems to care lately. Same here - Can someone please just post the 3Com RADIUS dictionary? It shouldn't take but a moment. Thanks. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

Once upon a time Frank Basso shaped the electrons to say... >I was looking too, but no one on the list seems to care lately. Same here - Can someone please just post the 3Com RADIUS dictionary? It shouldn't take but a moment. Thanks. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

Once upon a time Frank Basso shaped the electrons to say... >I was looking too, but no one on the list seems to care lately. Same here - Can someone please just post the 3Com RADIUS dictionary? It shouldn't take but a moment. Thanks. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

Anybody know if a Netopia 440 v3.1.3 router will interoperate with the Netserver Munich board? Regards, Charles Hill ioNET Network Specialist work: 405.270.7020 cell: 405.833.5477 pager: 405.559.6697 or 4058335477@mobile.att.net email: chill@ionet.net http://www.ionet.net/~chill ICQ: 4923465@pager.mirabilis.com

Once upon a time Jeff Mcadams shaped the electrons to say... >This is not something that would be upon 3Com to do, but would require >broadening the scope of RADIUS as a standard I suspect. Which won't happen at this point. The IETF closed the RADIUS WG as they completed their work. Controlling MPIP like this is *WAY* outside of the scope of RADIUS. RADIUS was never meant to be a resource management protocol. *Perhaps* it could be part of a follow-on protocol, and much work has been done on the Diameter drafts (lead by Pat Clahoun of Sun, late of 3Com), but IMHO I just don't see this as part of a AAA protocol. >It seems to me that Port-Limit type of functionality should rightly be >implemented in a RADIUS'ish setup. RADIUS is tasked with determining if >a user should get access to that dial-in resource, so if a Port-Limit = >1 is set, and its the second dial-in, the RADIUS server returns an OK, >but the call is dropped anyway...seems a bit counter-intuitive. How is it counter-intuitive? I don't se it. They are authenticated - fine. They are authorized to use some level of service - 1 port. If the NAS determines that they will not be able to do what they are authorized - say this is the 2nd port in a bundle - it refuses the link. This is no different from a user trying to login on shell and being authorized for PPP - the NAS should fail them. Or being authorized for telnet and they are trying to start PPP. Or being authorized for inbound service and they are trying to go outbound, etc. RADIUS at the core tell the NAS what the user is permitted to do. It is up to the NAS to determine if that is within the scope of what it can provide. >a Port-Limit = 1 type of denial, it needs to keep track of state on the >NASen. This is something that traditionally RADIUS servers have not >done, but more and more are doing it now so this isn't a big stretch. Step back and really think about this. Think about a multi-NAS, multi-RADIUS server environment. Now consider the fact that RADIUS itself, at the protocol level, contains possible race conditions - theyby being unsuitable by itself to maintain accurate constant state information. Hence servers like Cistron RADIUS, Radiator, and Lucent RADIUS ABM use SNMP to cover those loopholes. (But most NASes, including 3Com, don't have a good OID to use. Lucent has one in their Enterprise MIB that covers this specifically.) Now, the only one of these solutions that handles state AND scales across multiple RADIUS machines is RADIUS ABM. >There is really nothing (that I'm aware of) that distinguishes a >seperate call being established from a second link of an MP bundle being >established in the info that's sent to the RADIUS server. So...in a Nothing. >1;Max-Channels = 2) the RADIUS server isn't going to know whether to >deny the call or not. OK...so you say, "send the EDO info to the RADIUS The RADIUS server shouldn't have to know - that is for the NAS to handle. The NAS is *already* a choke point for this info, since it already has all of the info on the MP bundle. >that...hey, you've pretty much just integrated your RADIUS server and >your MPIP server. Now, how about all the vendors who do multi-chassis and DO NOT NEED a server? >from RADIUS and not worry about having the code to decide whether this >call is in an MP bundle or not out of the NASen...simplifies the NASen Bu the NAS will STILL have to be concerned with this. It has to know to add the call to a bundle or not. Or to tunnel back to some MP server (I think this is the ugliest thing I've heard in a long time. Any NAS that needs this is crap, IMHO.) to handle the bundle. RADIUS could tell it, but since the NAS already knows about this in the call setup, before calling RADIUS, it is NOT really more work for it. >hosted). The only thing that would be needed after this to enable >cross-platform cross-vendor MP bundling, would be a standard way of I will promise you than any attempt to require a backside server to do multichassis MP will be rejected out of hand by vendors who do it well WITHOUT the added server - ie Lucent and Ascend. Remember when Cisco first required a 7000 level router to be a backside MP server for multichassis? Remember how their customers tore them a new asshole over that Now they can do it without a backside server too. >1) Am I totally out in left field here, or does this actually make >some sense? Sorry, I don't think it makes any sense. >2) Is there any possibility of actually getting something like this >implemented? Single vendor? Maybe. Multi-vendor? Surely you jest. If Lucent considered it I'd rip into them for wasting time, they have better things to do. The system they have now works very well, so they'd be better served to work on new features. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

Guys, there is a serious security hole in the 3Com web site that allows people to view communities and passwords of NMC's, NSC's, ARC's, etc. Reportedly the hole is being closed now, however, someone may have your password without your knowlege. Due to the sensitivity of the information, I will not reveal how to bust through the hole. If you figure it out, please do not publish it. If you do find another hole, you're welcome to email me and I'll forward things on to 3Com. You're also welcome to call 3Com directly. Kevin Benton Network Engineer SOTA Technologies E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

> Guys, there is a serious security hole in the 3Com web site that allows > people to view communities and passwords of NMC's, NSC's, ARC's, etc. > Reportedly the hole is being closed now, however, someone may have your > password without your knowlege. Due to the sensitivity of the > information, I will not reveal how to bust through the hole. If you > figure it out, please do not publish it. If you do find another hole, > you're welcome to email me and I'll forward things on to 3Com. You're > also welcome to call 3Com directly. How do they have this information to begin with? Does 3com have some kind of online snmp 'browser' that you can use? If that's all the hole really is, then it likely won't concern a good majority of users here that have their own SNMP management packages already. (or mrtg. >:) -- Gilles Melanson ViaNet Internet Solutions System Administrator 128 Larch St. Suite 301 gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8 "One World, One Web, One Program" - Microsoft Promotional Ad "Ein Reich, Ein Volk, Ein Fuhrer" - Adolf Hitler

Might this be the "bug" that allows me to look at anyone's case if I know the case number? I'd forgotten my case number and just started browsing one day. Lots of techs put !root passwords and r/w snmp strings in the notes field along with the IP addresses attached to the equipment. Another good reason to say "NO" when a level-1 tech asks for such information. If you do let people in, change the password(s)/string(s) first and give that to them, then change back when they are done. Charles On Wed, 23 Sep 1998, Kevin Benton wrote: > Date: Wed, 23 Sep 1998 12:35:24 -0400 (EDT) > From: Kevin Benton <s1kevin@tims.net> > Reply-To: usr-tc@lists.xmission.com > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Caution: Change your read/write passwords and communities today! > > Guys, there is a serious security hole in the 3Com web site that allows > people to view communities and passwords of NMC's, NSC's, ARC's, etc. > Reportedly the hole is being closed now, however, someone may have your > password without your knowlege. Due to the sensitivity of the > information, I will not reveal how to bust through the hole. If you > figure it out, please do not publish it. If you do find another hole, > you're welcome to email me and I'll forward things on to 3Com. You're > also welcome to call 3Com directly. > > Kevin Benton > Network Engineer > SOTA Technologies > > 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. > =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

I'm looking for sample lines to use in my 'clients' file for Merit RADIUS 3.6B in conjunction with USR Total Control equipment. Comments and details appreciated. Please e-mail responses if possible. Thanks, Craig Thompson WingNET Internet Services, P.O. Box 3000 // Cleveland, TN 37320-3000 423-559-LINK (v) 423-559-5444 (f) http://www.wingnet.net Thought for the day: Mary had a little RAM, only about a meg or so.

Kevin Benton was heard to say: >Guys, there is a serious security hole in the 3Com web site that allows >people to view communities and passwords of NMC's, NSC's, ARC's, etc. >Reportedly the hole is being closed now, however, someone may have your >password without your knowlege. Due to the sensitivity of the >information, I will not reveal how to bust through the hole. If you >figure it out, please do not publish it. If you do find another hole, >you're welcome to email me and I'll forward things on to 3Com. You're >also welcome to call 3Com directly. Do tell... what? reading the SRO's? It's hard for them to give out what they are never given. --Ricky

Charles Hill was heard to say: >Anybody know if a Netopia 440 v3.1.3 router will interoperate with the >Netserver Munich board? As far as I know, it does. 3.1 is pretty old code... --Ricky

So was I and got the same response.. NOTHING! ============================================================================== 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, 23 Sep 1998, Frank Basso wrote: > I was looking too, but no one on the list seems to care lately. > -----Original Message----- > From: C Thompson <cthompson@wingnet.net> > To: inet-access@earth.com <inet-access@earth.com> > Cc: usr-tc@xmission.com <usr-tc@xmission.com> > Date: Wednesday, September 23, 1998 10:29 AM > Subject: (usr-tc) Merit RADIUS entries for USR equipment > > > >I'm looking for sample lines to use in my 'clients' file for Merit RADIUS > >3.6B in conjunction with USR Total Control equipment. Comments and > >details appreciated. > > > >Please e-mail responses if possible. > > > >Thanks, > > > > > >Craig Thompson > >---------------------------------------------------------------------- > >WingNET Internet Services, > >P.O. Box 3000 // Cleveland, TN 37320-3000 > >423-559-LINK (v) 423-559-5444 (f) > >http://www.wingnet.net > >---------------------------------------------------------------------- > > > >Thought for the day: > > Mary had a little RAM, only about a meg or so. > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and 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. >

The security problem in the case tracker was closed. It would probably be a good idea for admins to go ahead a change their passwords and read/write communities in case someone obtained passwords which did not belong to them. I stumbled across the security hole quite by accident while working on our in-house admin support system. I am still working with the 3Com people to put finishing touches on things, but as far as security of data goes, it's safe now. The problem was that some engineers put passwords and read/write communities on the case tracker log pages. This information should never be publically viewable. Without better security, a good hacker would have been able to find his way into the database and expose bunches of passwords. Thankfully, no longer. Kevin Benton Network Engineer SOTA Technologies E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

So you can limit concurrent logins with max-channels option? > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan > Sent: Wednesday, September 23, 1998 12:28 PM > To: usr-tc@lists.xmission.com > Cc: USRobotics TC Mailing List > Subject: Re: (usr-tc) multiple logins > > > On Wed, 23 Sep 1998, Brian wrote: > > > If someone knows how to allow for 10 logins with 4.1.11, please let me > > know. > > > > foo > > User-Service-Type = "Framed-User", > > Framed-Protocol = "PPP", > > Framed-Address = "255.255.255.254", > > Framed-Netmask = "255.255.255.255", > > Framed-MTU = "1500", > > Port-Limit = "10", > > Framed-Routing = "None", > > Framed-Compression = "Van-Jacobson-TCP-IP", > > Max-Channels = "10" > > This setup is fine. You do not need both port-limit and max-channels. > just set the max-channels to 10. > > krish > > > > > > > The above does *not* work. It only allows 2 logins. If someone knows > > what needs to be done, then please let me know. On 4.0.x all that would > > be needed is to set Port-Limit to 10, this is not the case here. I have > > alot of 5 and 10 login customers who need to be able to get on > with their > > full amount. > > > > Brian > > > > > -------------------------------------------------------------------------- > > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet > Service Provider > > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and 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. >

Kevin Benton <s1kevin@tims.net> writes: > I am still working > with the 3Com people to put finishing touches on things, but as far as > security of data goes, it's safe now. It depends by what you mean by safe. You may have closed the hole for non-3Com folks, but there are plenty of 3Com folks that presumably have access to that information. > The problem was that some engineers > put passwords and read/write communities on the case tracker log pages. > This information should never be publically viewable. Without better > security, a good hacker would have been able to find his way into the > database and expose bunches of passwords. Thankfully, no longer. Well, I pretty much agree with some other responses that you should _never_ give out any production community strings or passwords to any support organization if, for some reason, they have to get access to your gear. Either change the passwords/strings first or if the device in question supports more than one password use that facility. (I had pushed for multiple NMC community strings at one point for just this purpose among others, but unfortunately it hasn't been done yet). By giving out such information, you are implicitly trusting the _entire_ organization to which you gave it out, since you really have no visibility to how far that information may be available internally. You're also implicitly trusting the organization to ensure security of the information in general (aka this web access), something over which you have no control. So if you do have to give out production passwords for some reason, I'd also suggest treating it (after the work is completed) as a security exposure and changing all passwords. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Kevin Benton <s1kevin@tims.net> writes: > I am still working > with the 3Com people to put finishing touches on things, but as far as > security of data goes, it's safe now. It depends by what you mean by safe. You may have closed the hole for non-3Com folks, but there are plenty of 3Com folks that presumably have access to that information. > The problem was that some engineers > put passwords and read/write communities on the case tracker log pages. > This information should never be publically viewable. Without better > security, a good hacker would have been able to find his way into the > database and expose bunches of passwords. Thankfully, no longer. Well, I pretty much agree with some other responses that you should _never_ give out any production community strings or passwords to any support organization if, for some reason, they have to get access to your gear. Either change the passwords/strings first or if the device in question supports more than one password use that facility. (I had pushed for multiple NMC community strings at one point for just this purpose among others, but unfortunately it hasn't been done yet). By giving out such information, you are implicitly trusting the _entire_ organization to which you gave it out, since you really have no visibility to how far that information may be available internally. You're also implicitly trusting the organization to ensure security of the information in general (aka this web access), something over which you have no control. So if you do have to give out production passwords for some reason, I'd also suggest treating it (after the work is completed) as a security exposure and changing all passwords. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Thus spake MegaZone >Port-Limit was meant to control the number of channels in a bundle, and >that is how it works for the other vendors. Heya MZ, Thanks for the info...I appreciate that...good to know that I am using Port-Limit correctly, but hadn't taken the time to look it up. :) You may just be working through your mailbox and will get to this in time...but I'm curious what your thoughts would be on my possibly off-the-wall thoughts on RADIUS. I've never exactly known you to keep your thoughts on stuff like that private, but I've also always been pretty impressed by your knowledge and clarity of thought re: RADIUS concepts, so I'd appreciate your thoughts on my...uhm...guess you'd call it a proposal. :) Thanks -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake MegaZone >Port-Limit was meant to control the number of channels in a bundle, and >that is how it works for the other vendors. Heya MZ, Thanks for the info...I appreciate that...good to know that I am using Port-Limit correctly, but hadn't taken the time to look it up. :) You may just be working through your mailbox and will get to this in time...but I'm curious what your thoughts would be on my possibly off-the-wall thoughts on RADIUS. I've never exactly known you to keep your thoughts on stuff like that private, but I've also always been pretty impressed by your knowledge and clarity of thought re: RADIUS concepts, so I'd appreciate your thoughts on my...uhm...guess you'd call it a proposal. :) Thanks -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake MegaZone >Port-Limit was meant to control the number of channels in a bundle, and >that is how it works for the other vendors. Heya MZ, Thanks for the info...I appreciate that...good to know that I am using Port-Limit correctly, but hadn't taken the time to look it up. :) You may just be working through your mailbox and will get to this in time...but I'm curious what your thoughts would be on my possibly off-the-wall thoughts on RADIUS. I've never exactly known you to keep your thoughts on stuff like that private, but I've also always been pretty impressed by your knowledge and clarity of thought re: RADIUS concepts, so I'd appreciate your thoughts on my...uhm...guess you'd call it a proposal. :) Thanks -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake MegaZone >Port-Limit was meant to control the number of channels in a bundle, and >that is how it works for the other vendors. Heya MZ, Thanks for the info...I appreciate that...good to know that I am using Port-Limit correctly, but hadn't taken the time to look it up. :) You may just be working through your mailbox and will get to this in time...but I'm curious what your thoughts would be on my possibly off-the-wall thoughts on RADIUS. I've never exactly known you to keep your thoughts on stuff like that private, but I've also always been pretty impressed by your knowledge and clarity of thought re: RADIUS concepts, so I'd appreciate your thoughts on my...uhm...guess you'd call it a proposal. :) Thanks -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

We have quite a number of call rejects on our HDM's for unknown reasons. We have made sure that all cards are on "fixed assignment" and this fixed part of the problem. Is it possible to trace the layer 2 messaging on the D-channel of the PRI in the HDM ? For info : - 2 Chassis - 20 HDM's running codebase 1.2.2 (10 per chassis) - 4 HiperARC's running 4.0.29 (2 per chassis) - 2 NMC's running 5.5.5 (1 per chassis) All channels are E1-PRI fed directly from a Siemens EWSD switch running DSS-100 Euro ISDN I looked on interproc (http://interproc.ae.usr.com/tkb.html) and found one relevant info which is broken :-( (for your info it's the command "trc dbg 30 2" which is not valid, because "trc dbg" level only goes to 28) More info on these "hidden" commands would be nice, Thanks for any info Robert von Bismarck Petrel Communications SA

I am constructing an IP filter for a user. Is 1 REJECT src-addr!=208.214.45.1/255.255.255.240 functionaly equivelent to 1 REJECT src-addr!=208.214.45.0/255.255.255.240 They both "appear" to work, but was just concerned. It would save me alot of time if I can use the IP address/netmask instead of network address/netmask to implement the filter. Brian Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

ARC, yes... NETserver, no. You'll have to use something like pmcom to suck the names off a NETserver. Mike Andrews (MA12) icq 6602506 -------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "If Barbie is so popular, why do you have to buy her friends?..." On Wed, 23 Sep 1998, Peter D. Mayer wrote: > Are there any SNMP OID's (either NMC or NETServer) that give the username of > someone connected to a port? I've looked everywhere and I can't find 'em.

turn off radius auth on the chassis as long as they are all dynamic..... but dont forget to set hte default user to not check for a password -----Original Message----- >EMERGENCY REQUEST > >We were updating our radius software and crashed the system. Is there a way to >let everyone in until we rebuild the system? PLEASE HELP > >Jack Singer >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. >

On Wed, 23 Sep 1998, Tatai SV Krishnan wrote: > On Wed, 23 Sep 1998, Brian wrote: > > > If someone knows how to allow for 10 logins with 4.1.11, please let me > > know. > > > > foo > > User-Service-Type = "Framed-User", > > Framed-Protocol = "PPP", > > Framed-Address = "255.255.255.254", > > Framed-Netmask = "255.255.255.255", > > Framed-MTU = "1500", > > Port-Limit = "10", > > Framed-Routing = "None", > > Framed-Compression = "Van-Jacobson-TCP-IP", > > Max-Channels = "10" > > This setup is fine. You do not need both port-limit and max-channels. > just set the max-channels to 10. The above settings will NOT allow 10 logins, but will choke after 2. This is replicatable with 4.1.11. Getting rid of Port-Limit = 10, and everything works fine. > > krish > > > > > > > The above does *not* work. It only allows 2 logins. If someone knows > > what needs to be done, then please let me know. On 4.0.x all that would > > be needed is to set Port-Limit to 10, this is not the case here. I have > > alot of 5 and 10 login customers who need to be able to get on with their > > full amount. > > > > Brian > > > > -------------------------------------------------------------------------- > > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

On Wed, 23 Sep 1998, Tatai SV Krishnan wrote: > On Wed, 23 Sep 1998, Brian wrote: > > > If someone knows how to allow for 10 logins with 4.1.11, please let me > > know. > > > > foo > > User-Service-Type = "Framed-User", > > Framed-Protocol = "PPP", > > Framed-Address = "255.255.255.254", > > Framed-Netmask = "255.255.255.255", > > Framed-MTU = "1500", > > Port-Limit = "10", > > Framed-Routing = "None", > > Framed-Compression = "Van-Jacobson-TCP-IP", > > Max-Channels = "10" > > This setup is fine. You do not need both port-limit and max-channels. > just set the max-channels to 10. The above settings will NOT allow 10 logins, but will choke after 2. This is replicatable with 4.1.11. Getting rid of Port-Limit = 10, and everything works fine. > > krish > > > > > > > The above does *not* work. It only allows 2 logins. If someone knows > > what needs to be done, then please let me know. On 4.0.x all that would > > be needed is to set Port-Limit to 10, this is not the case here. I have > > alot of 5 and 10 login customers who need to be able to get on with their > > full amount. > > > > Brian > > > > -------------------------------------------------------------------------- > > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Date sent: Wed, 23 Sep 98 14:49:38 EDT Send reply to: usr-tc@lists.xmission.com > Kevin Benton <s1kevin@tims.net> writes: > > I am still working > > with the 3Com people to put finishing touches on things, but as far as > > security of data goes, it's safe now. > > It depends by what you mean by safe. You may have closed the hole for > non-3Com folks, but there are plenty of 3Com folks that presumably > have access to that information. > > > The problem was that some engineers > > put passwords and read/write communities on the case tracker log pages. > > This information should never be publically viewable. Without better > > security, a good hacker would have been able to find his way into the > > database and expose bunches of passwords. Thankfully, no longer. > > Well, I pretty much agree with some other responses that you should > _never_ give out any production community strings or passwords to any > support organization if, for some reason, they have to get access to > your gear. Either change the passwords/strings first or if the device > in question supports more than one password use that facility. (I had > pushed for multiple NMC community strings at one point for just this > purpose among others, but unfortunately it hasn't been done yet). > > By giving out such information, you are implicitly trusting the > _entire_ organization to which you gave it out, since you really have > no visibility to how far that information may be available internally. > You're also implicitly trusting the organization to ensure security of > the information in general (aka this web access), something over which > you have no control. > > So if you do have to give out production passwords for some reason, > I'd also suggest treating it (after the work is completed) as a > security exposure and changing all passwords. It's funny you should mention that. We had a discussion right before I reported the issue about giving passwords and communities out to support people. With rare exception, we had already decided that we will no longer give out our "normal" communities and/or passwords. Great advice, David. --- Internet: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee $50 subject to change without notice.

Thus spake MegaZone >Once upon a time Jeff Mcadams shaped the electrons to say... >>1) Standard way for a RADIUS server to recover state of bundle >>hosting information...is this already in the RADIUS standard or perhaps >>a mechanism to recover some state that doesn't necessarily cover bundle >>info? If so, that could be extended to cover this? >It is not part of RADIUS - and, IMHO, SHOULD NOT be. RADIUS is not a >stateful protocol by design. It is designed to work even if different >servers become involved with the same session, as for failover. >Coordinating multiple servers and maintaining state is a BITCH - Lucent is >doing it with RADIUS ABM using RADIUS, SNMP, and a commercial database >backend to handle the shared distributed database problems. >It isn't bad if you only run one server - but anyone of any size can't afford >to only have one server. Scaling such a thing reliably is NOT a simple task. Indeed, that thought did cross my mind...coordinating state information there would certainly be difficult. >>2) Standard tunneling method...pptp seems reasonable. >YUCK. PPTP is crap - L2TP is better, AND standard. Oh, is l2tp the standard? Wasn't sure what the status was on all that...just recently subscribed to the pppext WG mailing list...so not up to speed on all that yet. >>3) RADIUS dictionary entries to define bundle hosting information in a >>cross-platform manner...should be fairly trivial to define. >Not going to happen in the RFC - if you didn't know, the RADIUS WG is >*closed*. RADIUS is pretty much done. A few drafts are being polished, >but new material is too late. Maybe as a VSA. Ugh...so there's no mechanism for adding more attributes to it? This seems like a collosally bad idea. Dial-in services are not sitting targets, new things are being developed all the time...heck Multi-chassis MP is a fairly new concept that hasn't really been dealt with in RADIUS but perhaps should be. RADIUS concerns dial-in authentication and port configuration and MP and multi-chassis MP is certainly tied up in that. >>4) Obviously, support for all this in various NASen and RADIUS servers >>to make this more than just an exercise in Blue Sky thinking. >And I don't think you'll get this. First off, other vendors don't like >MPIP. I tend to thin kthe PM's MCPPP system scales better. Obvious biases aside. ;) >PMs haven't had >any problems with huge stacks, and it runs with one setting. No backside >host needed at all. Hrmm...since I haven't played with PM stuff in quite some time...how about a general overview on how MCPPP basically functions? Was reading in the pppext WG page about dynamic discovery of bundle heads...they were talking about multicast I believe...which certainly has its benefits. >And it is easy to locate the master for any given >bundle from the command line, or PMVision. And every other vendor has >their own protocols, none like MPIP. Hrmm...ok...I appreciate your thoughts...and that actually sends me off in the direction that the pppext working group is following with what I've seen so far...using multicast for discovery of the bundle head dynamically...no state information needs to be preserved except on the host that actually has the bundle head which...if that state is blown away, the whole bundle is blown away anyway, so...not a biggie there. I guess I was just looking for a direction for cross-platform compatibility for multi-chassis MP and the only experience I had was with MPIP. I'm becoming convinced of the un-wise-ness of the MPIP-type of solution. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Once upon a time Jeff Mcadams shaped the electrons to say... >Hrmm...since I haven't played with PM stuff in quite some time...how >about a general overview on how MCPPP basically functions? Was reading This is off the top of my head, and it has been a while, but I think this is correct: You send the endpoint identifier on al the chassis to be the same thing. The PM will send out a UDP broadcast and other chassis with the same endpoint identifier will answer and they form a community. When a unit establishes a link with MP negotiated it informs the others, then if they get another link with the same identifier they encapsulate the data back to the unit with the first link. Only that unit needs to maintain all the state data for the session. >in the pppext WG page about dynamic discovery of bundle heads...they >were talking about multicast I believe...which certainly has its >benefits. Sounds like a similar system, only multicast instead of the broadcast. I don't like the idea of needing *another* piece of HW to run a state server. I mean, the NASes are expensive enough, and one would think that they could handle at least that much. It isn't, or it SHOULD NOT, be much load at all. Cisco and 3Com are the only two I know of that have a central server - and they both can do it without them. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

EMERGENCY REQUEST We were updating our radius software and crashed the system. Is there a way to let everyone in until we rebuild the system? PLEASE HELP Jack Singer jsinger@i-c.net

Thus spake MegaZone >Once upon a time Jeff Mcadams shaped the electrons to say... >>This is not something that would be upon 3Com to do, but would require >>broadening the scope of RADIUS as a standard I suspect. >Which won't happen at this point. The IETF closed the RADIUS WG as they >completed their work. Controlling MPIP like this is *WAY* outside of the >scope of RADIUS. RADIUS was never meant to be a resource management protocol. Well..I think closing the WG is goofy...maybe move it to an operations type of working group (rwhois like? although that might not be a good example as I understand that one is almost dead from lack of interest) I think its short-sighted to not consider that RADIUS might need mods as new development occur...but that's really a seperate issue. >*Perhaps* it could be part of a follow-on protocol, and much work has been >done on the Diameter drafts (lead by Pat Clahoun of Sun, late of 3Com), but >IMHO I just don't see this as part of a AAA protocol. Haven't heard about this...pointer to information? (If you haven't noticed, I'm rather interested in getting involved in design concepts for these things). >>It seems to me that Port-Limit type of functionality should rightly be >>implemented in a RADIUS'ish setup. RADIUS is tasked with determining if >>a user should get access to that dial-in resource, so if a Port-Limit = >>1 is set, and its the second dial-in, the RADIUS server returns an OK, >>but the call is dropped anyway...seems a bit counter-intuitive. >How is it counter-intuitive? I don't se it. They are authenticated - fine. >They are authorized to use some level of service - 1 port. If the NAS >determines that they will not be able to do what they are authorized - say >this is the 2nd port in a bundle - it refuses the link. >This is no different from a user trying to login on shell and being authorized >for PPP - the NAS should fail them. Or being authorized for telnet and they >are trying to start PPP. Or being authorized for inbound service and they >are trying to go outbound, etc. >RADIUS at the core tell the NAS what the user is permitted to do. It is >up to the NAS to determine if that is within the scope of what it can provide. Hrmm...I don't think the idea of having more complete info in a RADIUS-like (note it doesn't have to be RADIUS, maybe this could be a next generation of the RADIUS concept) server is altogether a bad idea...NASen code could be considerably simpler if more of the intelligence for authentication and port setup were moved to a RADIUS-like setup. I guarentee you it would be easier on us network administrators to deal with that way. It's a *whole* lot easier to get a fix to a most like source code available RADIUS-like server than to get fixes to code in *ANY* (including Livingston now Lucent RABU) NASen vendor code. I guess this is really a different concept of RADIUS-like servers...where RADIUS tells what the user is *permitted* to do, I guess this type of setup that I'm envisioning (and it doesn't have to include MPIP-like functionality...you've convinced me on that point) tells the NASen...setup the port like thus...the main difficulty with this that I see would be that if the user already has PPP started and is authenticating through PAP/CHAP and the RADIUS-like server tells the NAS to do telnet, then the only real recourse is to drop the call. :/ >Step back and really think about this. Think about a multi-NAS, multi-RADIUS >server environment. This, inherently, is not a problem...adds complexity, yes, but it is doable. >Now consider the fact that RADIUS itself, at the >protocol level, contains possible race conditions - theyby being unsuitable >by itself to maintain accurate constant state information. Indeed, this is something that, unfortunately, that I don't know enough about....like I said originally....blue sky. >Hence servers >like Cistron RADIUS, Radiator, and Lucent RADIUS ABM use SNMP to cover those >loopholes. (But most NASes, including 3Com, don't have a good OID to use. >Lucent has one in their Enterprise MIB that covers this specifically.) Hrmm...perhaps a more SNMP-like authentication system...generate an authentication trap, with a SNMP set response. :D Just kidding...does raise some interesting thoughts though. :) >>1;Max-Channels = 2) the RADIUS server isn't going to know whether to >>deny the call or not. OK...so you say, "send the EDO info to the RADIUS >The RADIUS server shouldn't have to know - that is for the NAS to handle. That's the current thought on RADIUS - NAS interaction...like I said though...I'm thinking blue sky here...open to other possibilities for future ways of thinking about it. >The NAS is *already* a choke point for this info, since it already has all >of the info on the MP bundle. Well...sort of. It can be found out, but as much of the traffic on this list shows, MPIP certainly isn't the way to do it, not sure if dynamic discovery is really the way to do it, but it might be. >>that...hey, you've pretty much just integrated your RADIUS server and >>your MPIP server. >Now, how about all the vendors who do multi-chassis and DO NOT NEED a server? Well...lemme fill in on a bit of where I'm coming from.... When I started with IgLou, about 4 years ago, IgLou was running SLIP and PPP on a unix based pppd...using Digiboards for modem connections into a Sparc. This was *extremely* configureable, we could fix just about anything that broke because of source code availability on most stuff. We then moved to having Xyplex equipment (we were on the beta of their RADIUS project), and we gave up some flexibility for performance (ie, not tunnel'ing ppp through telnet), and we gave up quite a bit of ability to fix our own problems...and there were quite a few, and I got pissed at Xyplex for not being able to fix their problems very well when I could have gotten them fixed quite easily if we'd had source code and the stuff was controlled from one of our unix boxes. Then we bought 3 PM-25's to try out, and I subscribed to pm-users and met Megazone there (had to put that in :), and we had some problems that lasted for months and months that Livingston was unable to fix and I got pissed off at Livingston and was still pissed off at Xyplex. Then we bought USRobotics (which then got bought by 3Com as we all know) equipment and netservers and we've had continual problems with USR/3Com equipment and code, and now I'm pissed off at 3Com. I'm quickly running out of vendors to get pissed off at because none of the ones that I've run into can fix their code fast enough for our needs. The last time we were able to provide really reliable service was back when we were running digiboards and unix based pppd's...now...can you blame me for wanting to keep the code on NASen as simple as possible and get as much of the intelligence as possible onto back-end systems where I can get better access to code and fixes? >>from RADIUS and not worry about having the code to decide whether this >>call is in an MP bundle or not out of the NASen...simplifies the NASen >Bu the NAS will STILL have to be concerned with this. In my vision, no...the RADIUS-like server would say, this bundle exists here, tunnel this port to there with these characteristics. The NAS would not have to have any intelligence to find bundle-heads at all. Again, refer back to my previous paragraphs to understand why I would consider this a "Good Thing(tm)." >It has to know to >add the call to a bundle or not. Or to tunnel back to some MP server (I >think this is the ugliest thing I've heard in a long time. Any NAS that >needs this is crap, IMHO.) to handle the bundle. Uhm, 3Com doesn't tunnel back to an MP server, it sends an info request back to an MP server...its taking the RADIUS idea and extending it to MP bundle-head locating...the idea is not without merit, thought it has its problems as well. 3Com only sets up tunnels between the server that takes the call and the server that hosts the bundle head. There is no tunnel to the MPIP server at all. You can't tell me that extending the concept of getting information from a backend is not without merit...I mean, that's what RADIUS is, that's what ChoiceNet is and any of a number of other Internet protocols. >RADIUS could tell it, >but since the NAS already knows about this in the call setup, before calling >RADIUS, it is NOT really more work for it. The NAS doesn't know if the call is part of an already existing bundle before it calls RADIUS....it can't, the userid is part of the equation. >>hosted). The only thing that would be needed after this to enable >>cross-platform cross-vendor MP bundling, would be a standard way of >I will promise you than any attempt to require a backside server to do >multichassis MP will be rejected out of hand by vendors who do it well >WITHOUT the added server - ie Lucent and Ascend. Remember when Cisco >first required a 7000 level router to be a backside MP server for >multichassis? Remember how their customers tore them a new asshole over >that Now they can do it without a backside server too. Actually, I didn't pay a whole lot of attention to what Cisco did in dial-access until very recently as their still implementing functionality that others have had in their systems for quite some time. The idea of having a back-end server is not without merit...again, that's basically the concept of RADIUS. There are benefits to keeping bundle state on backend servers as well...maybe more drawbacks than there are benefits, but there are benefits...one of the big ones IMHO is simplifying NAS vendor code and dependance on NAS vendors to *fix* their code when its broken...move more of the intelligence into the backend servers so *I* can fix it when its broken. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Do I have the option of running an MPIP server on unix (mpipd if it exists)? If so, where can I get the code and is it compatible with HiperARC? In case it matters, I would be attempting this on Linux. Brian Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

If shrevenet has a 1.2gig or there abouts IDE drive, I would like to put it in LUNA and get some software RAID 1 action going. I think with these upgrades there is a 1gig or there abouts drive lying around that would be perfect. RAID 1 on luna would give us the backup we need in case of failure. Brian Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Damn, that message I sent was for our staff here at ShreveNet, and I don't know how I screwed up so bad to send it to this list....my apologies. Brian Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

On Wed, 23 Sep 1998, Brian wrote: > > I am constructing an IP filter for a user. Is > > 1 REJECT src-addr!=208.214.45.1/255.255.255.240 > > functionaly equivelent to > > 1 REJECT src-addr!=208.214.45.0/255.255.255.240 > > They both "appear" to work, but was just concerned. It would save me alot > of time if I can use the IP address/netmask instead of network > address/netmask to implement the filter. > They are not really runctionally equivalent since one allows a single host and the other gives access to the subnet. If you only want allow trafic to one host, why not 1 ACCEPT src-addr = 208.214.45.1 and use the implicit deny to handle all other a cases? If you want to allow access to the whole network then the .0 address should be used with the appropriate netmask. Mike Wronski (mike@coredump.ae.usr.com) ! 3Com Network Systems Engineer / Beta Engineer <!> PGP KEY - http://coredump.ae.usr.com/pgp !

I have a strange rlogin problem. I have netservers and Hyper Arcs in use and they have the same configs. The problem is that when a user logs on and uses the login host which is setup for rlogin the server says "No shell Connection closed by foreign host." This only happens from a Hyperarc. When I dial into Hub that uses a Netserver I get a login prompt immediatly. Has anybody witnesed this also? Chris Havelka Network Engineer InterAccess Co. Chicago Il chavelka@interaccess.com

MegaZone was heard to say: >Once upon a time Frank Basso shaped the electrons to say... >>I was looking too, but no one on the list seems to care lately. > >Same here - Can someone please just post the 3Com RADIUS dictionary? Legally, we cannot as it's part of their RADIUS server package. Bug krish and see if you can get him to dump one out. (It's 17 pages, BTW.) --Ricky

Jack Singer was heard to say: >EMERGENCY REQUEST > >We were updating our radius software and crashed the system. Is there a way to >let everyone in until we rebuild the system? PLEASE HELP Yes... basically all you need is a radius server that answers with an access accept for every thing. (The USR server comes with an over simplified example of this exact thing.) --Ricky

On Wed, 23 Sep 1998, Mike wrote: > On Wed, 23 Sep 1998, Brian wrote: > > > > > I am constructing an IP filter for a user. Is > > > > 1 REJECT src-addr!=208.214.45.1/255.255.255.240 > > > > functionaly equivelent to > > > > 1 REJECT src-addr!=208.214.45.0/255.255.255.240 > > > > They both "appear" to work, but was just concerned. It would save me alot > > of time if I can use the IP address/netmask instead of network > > address/netmask to implement the filter. > > > > They are not really runctionally equivalent since one allows a single host > and the other gives access to the subnet. but does it? A single host would be 208.214.45.1/255.255.255.255? And if you put the filter 1 REJECT src-addr!=208.214.45.1/255.255.255.240 in place on a user on an arc, then all IP's in 208.214.45.0/28 can get out, try it. I am not sure if thats a bug, or the way its suppose to function or maybe the filters just dont work, but look: HiPer>> show remote user signal User Name: signal Service Type: Framed Framed Protocol: PPP Framed IP Address: 208.214.45.1 Framed IP Netmask: 255.255.255.248 Framed Routing: None Framed MTU: 1500 Framed Compression: VJ TCP/IP header Compression Max Channels: 2 Filter Rules : 1 REJECT src-addr!=208.214.45.1/255.255.255.248 This is my subnet at the house. Now you would think only .1 could get out right? no. ALL my machines work just fine. Which is why I am asking if they are "functionally" equivelent, it would seem so. > > > If you only want allow trafic to one host, why not > > 1 ACCEPT src-addr = 208.214.45.1 Because I want to allow traffic to the entire subnet, and I can automate the process by building the filter dynamically off the Framed-IP-Address such as 208.214.45.1. If I have to build the filter dynamically off the network address, that gets a little more tricky since the network address isn't sent in any radius access-request, nor is it stored in a radius users file. > > and use the implicit deny to handle all other a cases? > > If you want to allow access to the whole network then the .0 address > should be used with the appropriate netmask. > but .1 works as well > > > Mike Wronski (mike@coredump.ae.usr.com) ! > 3Com Network Systems Engineer / Beta Engineer <!> > PGP KEY - http://coredump.ae.usr.com/pgp ! > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

> > That's broken, IMHO. That's why you have a netmask, to mask with the > address give to find out the network that is affected. If you want it > to be just the single address, then you use a /32 netmask. > > 208.214.45.0/255.255.255.240 and 208.214.45.1/255.255.255.240 when > masked together give the same network so both entries (IMHO) should act on > the whole block. Jeff, That's what I thought, and that's how its functioning. > -- > 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. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Thus spake MegaZone >>in the pppext WG page about dynamic discovery of bundle heads...they >>were talking about multicast I believe...which certainly has its >>benefits. >Sounds like a similar system, only multicast instead of the broadcast. Yeah, from your description, it sounds *very* similar. Other than the use of UDP v. mcast. I'm getting more and more to like mcast as it means that I can put other stuff on that network if I want and not have to worry about as much broadcast traffic hitting it. Not that bundle head discovery is gonna cause that much, but its the principle of the thing, ya know? :) >I don't like the idea of needing *another* piece of HW to run a state >server. I mean, the NASes are expensive enough, and one would think that >they could handle at least that much. It isn't, or it SHOULD NOT, be much >load at all. Cisco and 3Com are the only two I know of that have a >central server - and they both can do it without them. Yeah, it isn't and shouldn't be much load, you're correct, should be a trivial matter of throwing an mcmpd (multi-chassis mp daemon) on whatever system you've already got running RADIUS, DNS, etc. :) Again, as I mentioned earlier...there are definite drawbacks to a back-end system doing this (state syncronization being the biggest I can think of), but there are benefits to it as well. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Brian >Do I have the option of running an MPIP server on unix (mpipd if it >exists)? >If so, where can I get the code and is it compatible with HiperARC? There is code written...it was *extremely* rough...more than I wanted to tangle with to try to clean up, and it was based on the netserver code, not sure if it would work with the HiperARC. I doubt it will actually. >In case it matters, I would be attempting this on Linux. I didn't see any reason that it wouldn't compile on linux, but didn't actually try it. It does compile on Solaris without *too* much bashing around of the Makefile and stuff. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Mike >On Wed, 23 Sep 1998, Brian wrote: >> I am constructing an IP filter for a user. Is >> >> 1 REJECT src-addr!=208.214.45.1/255.255.255.240 >> >> functionaly equivelent to >> >> 1 REJECT src-addr!=208.214.45.0/255.255.255.240 >> >> They both "appear" to work, but was just concerned. It would save me alot >> of time if I can use the IP address/netmask instead of network >> address/netmask to implement the filter. >They are not really runctionally equivalent since one allows a single host >and the other gives access to the subnet. >If you only want allow trafic to one host, why not >1 ACCEPT src-addr = 208.214.45.1 >and use the implicit deny to handle all other a cases? >If you want to allow access to the whole network then the .0 address >should be used with the appropriate netmask. That's broken, IMHO. That's why you have a netmask, to mask with the address give to find out the network that is affected. If you want it to be just the single address, then you use a /32 netmask. 208.214.45.0/255.255.255.240 and 208.214.45.1/255.255.255.240 when masked together give the same network so both entries (IMHO) should act on the whole block. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Jeff Mcadams was heard to say: >>If so, where can I get the code and is it compatible with HiperARC? > >There is code written...it was *extremely* rough...more than I wanted to >tangle with to try to clean up, and it was based on the netserver code, >not sure if it would work with the HiperARC. I doubt it will actually. It's not "based on" netserver code ... it *is* netserver code (taken directly from the source tree with a main() wrapper strapped on it.) And yes, it is just as much a mess as everything else I've seen out of USR (of course, it is ComOS hacked to work code from the 50's :-)) I doubt it would work with a HiperARC either. It is very byte order dependant. But, that won't stop me from crashing the HiperARC a few times today :-) >>In case it matters, I would be attempting this on Linux. > >I didn't see any reason that it wouldn't compile on linux, but didn't >actually try it. It does compile on Solaris without *too* much bashing >around of the Makefile and stuff. :) Byte order... unless you mean Linux/Sparc. --Ricky

Maybe I'm just paranoid (not as much as some), but I don't allow access to SNMP ports or unauthorized telnet ports through the router. If someone got the !root password, they cannot get to it unless they are already on my network, such as dial-in users. I also cut off access to radius ports and more. Anyone with an ISP should be doing at least some filtering at the router level, even if it's just to stop spoofing in both directions. If anyone wants more info, let me know. Wayne Barber Coastal Telco Services > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Charles Sprickman > Sent: Wednesday, September 23, 1998 12:56 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Caution: Change your read/write passwords and > communities today! > > > Might this be the "bug" that allows me to look at anyone's case if I know > the case number? I'd forgotten my case number and just started browsing > one day. Lots of techs put !root passwords and r/w snmp strings in the > notes field along with the IP addresses attached to the equipment. > > Another good reason to say "NO" when a level-1 tech asks for such > information. If you do let people in, change the password(s)/string(s) > first and give that to them, then change back when they are done. > > Charles > > On Wed, 23 Sep 1998, Kevin Benton wrote: > > > Date: Wed, 23 Sep 1998 12:35:24 -0400 (EDT) > > From: Kevin Benton <s1kevin@tims.net> > > Reply-To: usr-tc@lists.xmission.com > > To: usr-tc@lists.xmission.com > > Subject: (usr-tc) Caution: Change your read/write passwords and > communities today! > > > > Guys, there is a serious security hole in the 3Com web site that allows > > people to view communities and passwords of NMC's, NSC's, ARC's, etc. > > Reportedly the hole is being closed now, however, someone may have your > > password without your knowlege. Due to the sensitivity of the > > information, I will not reveal how to bust through the hole. If you > > figure it out, please do not publish it. If you do find another hole, > > you're welcome to email me and I'll forward things on to 3Com. You're > > also welcome to call 3Com directly. > > > > Kevin Benton > > Network Engineer > > SOTA Technologies > > > > 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. > > > > =-----------------= = > | Charles Sprickman Internet Channel | > | INCH System Administration Team (212)243-5200 | > | spork@inch.com access@inch.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. >

Thus spake Ricky Beam >I doubt it would work with a HiperARC either. It is very byte order >dependant. But, that won't stop me from crashing the HiperARC a few >times today :-) Any chance of getting that cleaned up code from you? I'd love to be able to free up this netserver that I'm using as a dedicated MPIP server and move that function to a Sparc. :) Also would like to see if this thing suffers from the same not deleting the bundle bug (I would assume it would unless you fixed that as well :), but at least if I have cleaned up code I could proly find it myself, or possibly work with you on getting that fixed. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

We have a problem with the NMC's allowing a supernet-mask. When I try and change the netmask to 255.255.252.0 it will not save it to nvram. I have called USR and they cannot shed any light on this matter. What happens is that when we change the netmask back to 255.255.255.0 it works for a few hours and then the NMC drops off our network. I called cisco and the only suggestion they had was to add a static arp entry with the NMC's mac address. This works, but I'm still concerned there will be residual problems running this device on a incorrect netmask. Anyone have any suggestions??? ********************************************************* Jason Watkins jwatkins@iland.net I-Land Internet Services http://www.iland.net Support & Network Operations Center *********************************************************

We're having alot of trouble with users who have HP Win modems. Most are unable to connect. Can someone recomend a init string for the 3com chassis, and disable flex/56K/v.90?

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian |Sent: Thursday, September 24, 1998 7:35 AM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) filter question | | |On Wed, 23 Sep 1998, Mike wrote: | |> On Wed, 23 Sep 1998, Brian wrote: |> |> > |> > I am constructing an IP filter for a user. Is |> > |> > 1 REJECT src-addr!=208.214.45.1/255.255.255.240 |> > |> > functionaly equivelent to |> > |> > 1 REJECT src-addr!=208.214.45.0/255.255.255.240 |> > |> > They both "appear" to work, but was just concerned. It would save me alot |> > of time if I can use the IP address/netmask instead of network |> > address/netmask to implement the filter. |> > |> |> They are not really runctionally equivalent since one allows a single host |> and the other gives access to the subnet. | |but does it? | |A single host would be 208.214.45.1/255.255.255.255? | |And if you put the filter | |1 REJECT src-addr!=208.214.45.1/255.255.255.240 | |in place on a user on an arc, then all IP's in 208.214.45.0/28 can get |out, try it. I am not sure if thats a bug, or the way its suppose to |function or maybe the filters just dont work, but look: | No they are the same based on Jeff's analysis.. I was quick on the trigger when posting.. With the subnet mask applied the addresses are the same and both reflect a network and not a single address. -M

Date sent: Wed, 23 Sep 1998 22:51:42 -0500 () Send reply to: usr-tc@lists.xmission.com > On Wed, 23 Sep 1998, Brian wrote: > > > > > I am constructing an IP filter for a user. Is > > > > 1 REJECT src-addr!=208.214.45.1/255.255.255.240 > > > > functionaly equivelent to > > > > 1 REJECT src-addr!=208.214.45.0/255.255.255.240 > > > > They both "appear" to work, but was just concerned. It would save me alot > > of time if I can use the IP address/netmask instead of network > > address/netmask to implement the filter. > > > > They are not really runctionally equivalent since one allows a single host > and the other gives access to the subnet. Really? My routers don't handle those that way. They automagically translate the .1 to a .0 when I enter them so I know what the real network address is for the netmask I'm using (in the case above). Shouldn't the /26 apply to the entire subnet even though the address given is not the network address of the subnet? Kevin Benton Network Engineer SOTA Technologies --- Internet: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee $50 subject to change without notice.

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ricky Beam |Sent: Thursday, September 24, 1998 7:27 AM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) MPIP Server | | |Jeff Mcadams was heard to say: |>>If so, where can I get the code and is it compatible with HiperARC? |> |>There is code written...it was *extremely* rough...more than I wanted to |>tangle with to try to clean up, and it was based on the netserver code, |>not sure if it would work with the HiperARC. I doubt it will actually. | |It's not "based on" netserver code ... it *is* netserver code (taken |directly from the source tree with a main() wrapper strapped on it.) |And yes, it is just as much a mess as everything else I've seen out |of USR (of course, it is ComOS hacked to work code from the 50's :-)) If you want a strong MPIP server for netservers, Use a stand-alone netserver or one that will have the least load (end of hunt etc). There's alway's HARC but I fear a flaming for making that suggestion. |I doubt it would work with a HiperARC either. It is very byte order |dependant. But, that won't stop me from crashing the HiperARC a few |times today :-) Your right.. It won't work as a server for HARC. The HARC implementation is different from netserver. The HARC must be the MPIP server in a dual environment because it handles Netserver MPIP clients different than HARC clients. -M

Thanks, also found a updated driver from HP - LUCNT518.EXE, which they claim it fixes various ISP's v.90 :-): URL:http://www.hp.com/cposupport/personal_computing/software/lucnt518.exe.cons.html From the page: HP Pavilion PC Lucent Modem Driver Update (V.90) for Windows 95 and Windows 98. This update is for the HP Pavilion 32xx, 63xx, 74xx, 81xx, 82xx, and 83xx Series PC's. This update will install the latest version (5.18 - V.90 Specification) of the Lucent modem driver. After download is complete, double-click filename Lucnt518.exe and the update will load automatically. This update fixes many compatibility problems with various V.90 ISP's. Brian Gordon wrote: > > Use the extra setting -V90=0 > > this disables V.90 ... > > -v90=1 enables it ... > > Under advanced settings for the customer. > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Richard Lorbieski > > Sent: Thursday, September 24, 1998 10:13 AM > > To: usr-tc@lists.xmission.com > > Subject: (usr-tc) HP Win modems > > > > > > We're having alot of trouble with users who have HP Win modems. > > Most are unable to connect. Can someone recomend a init string for the > > 3com chassis, and disable flex/56K/v.90? > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and 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.

> Guys, there is a serious security hole in the 3Com web site that > allows people to view communities and passwords of NMC's, NSC's, > ARC's, etc. Reportedly the hole is being closed now, however, someone > may have your password without your knowlege. Have I missed something? I've never given 3COM any information regarding the IP addresses or SNMP communities, so how is anyone likely to get this information from their web site? Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Use the extra setting -V90=0 this disables V.90 ... -v90=1 enables it ... Under advanced settings for the customer. > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Richard Lorbieski > Sent: Thursday, September 24, 1998 10:13 AM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) HP Win modems > > > We're having alot of trouble with users who have HP Win modems. > Most are unable to connect. Can someone recomend a init string for the > 3com chassis, and disable flex/56K/v.90? > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Thus spake Mike Wronski >If you want a strong MPIP server for netservers, Use a stand-alone netserver or >one that will have the least load (end of hunt etc). This is what I'm doing...but the netserver code for MPIP is still buggy. Ticket # 58316. Feel free to give them some extra thoughts on it...apparently R&D is working on it but won't be able to get to it 'til next week. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

This is not directly related, but can you issue commands directly to the quad modems without having the NIC for them (i.e. through the netserver)? Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com -----Original Message----- >From the capabilities of the quad modems (ATI7), they support >several methods of digital connections (V.110, V.120, PPP ...) >SW release is 5.9.6, the chassis is less than 1 year old.

Thus spake Stauffer Walter >we have TC modem racks with PRI interface and quad modems, >but no netserver and no NMC in them. Our clients need to connect >to devices hooked up on the RS-232 ports of the quad modems ... >Now we need ISDN end-to-end connection, main reason is faster >call setup than analog. However, I have not found out how to set >up this. I have already set the ISDN GW slot to NONE (in the PRI >config menu). Try setting it to "0" instead of none. Also make sure that the pri card sees the quad-modems in the rack as quad I modems. >From the capabilities of the quad modems (ATI7), they support >several methods of digital connections (V.110, V.120, PPP ...) >SW release is 5.9.6, the chassis is less than 1 year old. OK, they are capable of handling ISDN calls at that firmware level, so you just need to make sure the pri card sees the calls, and you might need to set the gw code to "0" instead of none. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Yes there is a MPIP server. No this code is not supported. Some users have it and some do not. It was built for solaris and is not a supported product. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Wed, 23 Sep 1998, Brian wrote: > Do I have the option of running an MPIP server on unix (mpipd if it > exists)? > > If so, where can I get the code and is it compatible with HiperARC? > > In case it matters, I would be attempting this on Linux. > > Brian > > > -------------------------------------------------------------------------- > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Chris, Do you have a ticket open with our support in this regard? krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Wed, 23 Sep 1998, Chris Havelka wrote: > I have a strange rlogin problem. I have netservers and Hyper Arcs in use and > they have the same configs. > > The problem is that when a user logs on and uses the login host which is > setup for rlogin the server says "No shell Connection closed by foreign > host." > > This only happens from a Hyperarc. When I dial into Hub that uses a > Netserver I get a login prompt immediatly. > > Has anybody witnesed this also? > > Chris Havelka > Network Engineer > InterAccess Co. Chicago Il > chavelka@interaccess.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. >

There's code newer than that at www.digitan.com. 5.15 seems to be the minimum version number needed to make these pieces of junk happy... Mike Andrews (MA12) icq 6602506 -------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "If Barbie is so popular, why do you have to buy her friends?..." On Thu, 24 Sep 1998, Richard Lorbieski wrote: > Thanks, > > also found a updated driver from HP - LUCNT518.EXE, > which they claim it fixes various ISP's v.90 :-): > > URL:http://www.hp.com/cposupport/personal_computing/software/lucnt518.exe.cons.html > > >From the page: > > HP Pavilion PC Lucent Modem Driver Update (V.90) for Windows 95 > and Windows 98. This update is for the HP Pavilion 32xx, 63xx, 74xx, > 81xx, 82xx, and 83xx Series PC's. This update will install the latest > version (5.18 - V.90 Specification) of the Lucent modem driver. After > download is complete, double-click filename Lucnt518.exe and the > update will load automatically. This update fixes many compatibility > problems with various V.90 ISP's. > > > Brian Gordon wrote: > > > > Use the extra setting -V90=0 > > > > this disables V.90 ... > > > > -v90=1 enables it ... > > > > Under advanced settings for the customer. > > > > > -----Original Message----- > > > From: owner-usr-tc@lists.xmission.com > > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Richard Lorbieski > > > Sent: Thursday, September 24, 1998 10:13 AM > > > To: usr-tc@lists.xmission.com > > > Subject: (usr-tc) HP Win modems > > > > > > > > > We're having alot of trouble with users who have HP Win modems. > > > Most are unable to connect. Can someone recomend a init string for the > > > 3com chassis, and disable flex/56K/v.90? > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and 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. >

I would love the fix, since I haven't upgraded yet and this is one reason why -----Original Message----- > >We NOW have a fix available for the Web TV issue. You can call into support or >e-mail me directly for the fix. > >This is a software fix and not a configuration issue. > >-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. >

Once upon a time Ricky Beam shaped the electrons to say... >Legally, we cannot as it's part of their RADIUS server package. Bug krish >and see if you can get him to dump one out. (It's 17 pages, BTW.) Ok... Krish, can you share the dictionary file? I mean, it is just a dictionary - we're not asking for a free server or source code or something. Anyone want to send it to me on the grey market? I promise to immediately strip all mention of you from the file when I save it. This is just so stupid - I can go to Lucent or Ascend and grab their dictionaries openly. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

Once upon a time Julio Arruda shaped the electrons to say... > Out of sheer curiosity, I would like to know if there is any > netserver card that runs anything other than the USR ComOS "hw > customized" version (I think the nickname for this other sw would be > Pilgrim OS, right ?) The NetServer TC runs a modified version of Lucent ComOS. That is all. The NetServer MP units are ComOS up to 3.x, and a new OS 4.x+ - I believe that is "Pilgrim". There were, of course, the Cisoc AS51 blades that turned a TC into a Cisco AS5100 - they ran IOS. >And, as a double check, the Netserver "nextgen" is the Hiper ARC, right ? The Hiper ARC has a new OS, which I like to call HiperOS, but I forget if that's correct or not. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

Tatai SV Krishnan was heard to say: >It was built for solaris and is not a supported product. <grin> at first glance, I saw that as "not a supportable product." So, how much of the VTP was changed for the ARC? --Ricky

Tatai SV Krishnan was heard to say: >It was built for solaris and is not a supported product. <grin> at first glance, I saw that as "not a supportable product." So, how much of the VTP was changed for the ARC? --Ricky

Since upgrading to 4.1.11 on the Arcs, our Web-TV customers can no longer dial into us. We have PPP Authenticate set to either with preference set to PAP. Is there anything else that we may be missing in the config which will allow these customers to connect? On a side-note which may or may not be related: we have one customer who in Win95's settings had a check-mark next to require encrypted password. He says that with this set before the upgrade he could logon. However, after the upgrade he could no longer logon. After clearing this checkbox, he could logon again. -- ======================================================= =========== Andrew Aken - President ========= ====== GlobalEyes Communications, Inc. ====== =Southern Illinois' Fastest Connection to the Internet= ========== http://www.GlobalEyes.net ======== =======================================================

Once upon a time Ricky Beam shaped the electrons to say... >>The Hiper ARC has a new OS, which I like to call HiperOS, but I forget if >>that's correct or not. > >Development codenamed Pilgrim... Ok - if this is Pilgrim, what is the code on the NetServer MP units called - the stuff that replaced ComOS? -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

Once upon a time Tatai SV Krishnan shaped the electrons to say... >I do not have a merit radius dictionary file. I do however have a >dictionary for livingston which you can download ( with radius source >that supports vsa ) from > >ftp://interproc.ae.usr.com/pub > >you can get both the dictionary and the radius source. Thanks. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Andrew Aken |Sent: Thursday, September 24, 1998 2:55 PM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) Web-TV & 4.1.11 | | |Since upgrading to 4.1.11 on the Arcs, our Web-TV customers can no |longer dial into us. We have PPP Authenticate set to either with |preference set to PAP. Is there anything else that we may be missing in |the config which will allow these customers to connect? | |On a side-note which may or may not be related: we have one customer who |in Win95's settings had a check-mark next to require encrypted password. |He says that with this set before the upgrade he could logon. However, |after the upgrade he could no longer logon. After clearing this |checkbox, he could logon again. We NOW have a fix available for the Web TV issue. You can call into support or e-mail me directly for the fix. This is a software fix and not a configuration issue. -M

Paraphrase an AOL user: Mee too. Terry Kennedy wrote: > > I would love the fix, since I haven't upgraded yet and this is one reason > why > -----Original Message----- > > > > >We NOW have a fix available for the Web TV issue. You can call into support > or > >e-mail me directly for the fix. > > > >This is a software fix and not a configuration issue. > > > >-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.

On Thu, 24 Sep 1998, Ricky Beam wrote: > >Same here - Can someone please just post the 3Com RADIUS dictionary? > > Legally, we cannot as it's part of their RADIUS server package. Bug krish > and see if you can get him to dump one out. (It's 17 pages, BTW.) Geez, how many attributes do they have? My Livingston Radius dictionary file is maybe 4 pages long. Does all this extra stuff allow you to log connect speeds and such from a Total Control rack? Brian

I took the two sources that were posted here by the helpful 3Com folks (thanks again), cleaned up the formatting a bit and merged in a couple of values that weren't in both. This is the diff if anyone cares: 1a2 > # Updated 6/23/98 81,88c82,87 < # Prompt value should be 1 for echo, 0 for no echo, default 1. < #ATTRIBUTE Prompt 64 integer < ATTRIBUTE Tunnel_Type 64 string < ATTRIBUTE Tunnel_Medium_Type 65 string < ATTRIBUTE Acct_Tunnel_Cli_Endp 66 string < ATTRIBUTE Acct_Tunnel_Ser_Endp 67 string < ATTRIBUTE Acct_Tunnel_Conn_ID 68 string < ATTRIBUTE Tunnel_Password 69 string --- > ATTRIBUTE Tunnel-Type 64 integer > ATTRIBUTE Tunnel-Medium-Type 65 string > ATTRIBUTE Tunnel-Client-Endpoint 66 string > ATTRIBUTE Tunnel-Server-Endpoint 67 string > ATTRIBUTE Acct-Tunnel-Conn-ID 68 string > ATTRIBUTE Tunnel-Password 69 string 96c95 < ATTRIBUTE Connect_Info 77 string --- > ATTRIBUTE Connect-Info 77 string 98c97 < ATTRIBUTE EAP_Message 79 string --- > ATTRIBUTE EAP-Message 79 string 99a99,107 > ATTRIBUTE Tunnel-Private-Group-ID 81 string > ATTRIBUTE Tunnel-Assignment-ID 82 string > ATTRIBUTE Tunnel-Preference 83 integer > ATTRIBUTE ARAP-Challenge-Response 84 string > ATTRIBUTE Acct-Interim-Interval 85 integer > > ## ASCDEND ## > ATTRIBUTE Ascend-Handle-IPX 222 integer > 101,112c109,121 < ATTRIBUTE User_Group_Name 223 string < ATTRIBUTE Dial-In-Sec-Mode 224 integer < ATTRIBUTE Req-Db-Mdm-Sel 225 integer < ATTRIBUTE Req-Db-Login-Valid 226 integer < ATTRIBUTE Dialback_Group_Names 227 string < ATTRIBUTE Dial_In_Call_Rest 228 string < ATTRIBUTE Dial_Out_Call_Rest 229 string < ATTRIBUTE Logins_Before_Blacklist 230 integer < ATTRIBUTE Failed_Logins 231 integer < ATTRIBUTE Allowed_DB_Modems 233 string < ATTRIBUTE Ascend-idle-crap 244 integer < ATTRIBUTE Char-Noecho 250 integer --- > #ATTRIBUTE User-Group-Name 223 string > #ATTRIBUTE Dial-In-Sec-Mode 224 integer > #ATTRIBUTE Req-Db-Mdm-Sel 225 integer > #ATTRIBUTE Req-Db-Login-Valid 226 integer > #ATTRIBUTE Dialback-Group-Names 227 string > #ATTRIBUTE Dial-In-Call-Rest 228 string > #ATTRIBUTE Dial-Out-Call-Rest 229 string > #ATTRIBUTE Logins-Before-Blacklist 230 integer > #ATTRIBUTE Failed-Logins 231 integer > #ATTRIBUTE Allowed-DB-Modems 233 string > #ATTRIBUTE Char-Noecho 250 integer > > 235c244,246 < ATTRIB_NMC MP-EDO-HIPER 0x9841 string --- > #ATTRIB_NMC MP-EDO-HIPER 0x9841 string > #put the "hex" in since some NAS's were sending non-printable characters > ATTRIB_NMC MP-EDO-HIPER 0x9841 hex 256d266 < ATTRIB_NMC USR-Callback-Type 0x986a integer 260,262c270,289 < VALUE Termination-Action Default 0 < VALUE Termination-Action RADIUS-Request 1 < VALUE Termination-Action Manage-Resources 2 --- > > # Tunnel Types > VALUE Tunnel-Type PPTP 1 > VALUE Tunnel-Type L2TP 3 > VALUE Tunnel-Type VTP 5 > > > # Tunnel Medium Types > VALUE Tunnel-Medium-Type IP 1 > VALUE Tunnel-Medium-Type E.164 8 > > # Tunnel Security Types > VALUE Tunnel-Security None 0 > VALUE Tunnel-Security Control-Only 1 > VALUE Tunnel-Security Data-Only 2 > VALUE Tunnel-Security Both-Data-and-Control 3 > > VALUE Termination-Action Default 0 > VALUE Termination-Action RADIUS-Request 1 > VALUE Termination-Action Manage-Resources 2 363,369d389 < VALUE USR-Callback-Type Normal 1 < VALUE USR-Callback-Type ANI 2 < VALUE USR-Callback-Type Static 3 < VALUE USR-Callback-Type Dynamic 4 < < < 464,468c484,488 < VALUE Event-Id DNS-Contact-Lost 85 < VALUE Event-Id NTP-Contact-Lost 86 < VALUE Event-Id NTP-Contact-Restored 87 < VALUE Event-Id IPGW-Link-Up 88 < VALUE Event-Id IPGW-Link-Down 89 --- > VALUE Event-Id DNS-Contact-Lost 85 > VALUE Event-Id NTP-Contact-Lost 86 > VALUE Event-Id NTP-Contact-Restored 87 > VALUE Event-Id IPGW-Link-Up 88 > VALUE Event-Id IPGW-Link-Down 89 470,471c490,491 < VALUE Event-Id In-Connection-Failed 91 < VALUE Event-Id Out-Connection-Failed 92 --- > VALUE Event-Id In-Connection-Failed 91 > VALUE Event-Id Out-Connection-Failed 92 1096,1103c1116,1123 < VALUE Call-Event-Code inCallArrival 29 < VALUE Call-Event-Code outCallArrival 30 < VALUE Call-Event-Code inCallConnect 31 < VALUE Call-Event-Code outCallConnect 32 < < VALUE RMMIE-Status notEnabledInLocalModem 1 < VALUE RMMIE-Status notDetectedInRemoteModem 2 < VALUE RMMIE-Status ok 3 --- > VALUE Call-Event-Code inCallArrival 29 > VALUE Call-Event-Code outCallArrival 30 > VALUE Call-Event-Code inCallConnect 31 > VALUE Call-Event-Code outCallConnect 32 > > VALUE RMMIE-Status notEnabledInLocalModem 1 > VALUE RMMIE-Status notDetectedInRemoteModem 2 > VALUE RMMIE-Status ok 3 1204c1224 < VALUE Compression-Algorithm Ascend 2 --- > VALUE Compression-Algorithm Ascend 2 Ok - this is the dictionary as I cleaned it up - maybe someone will the most current 3Com RADIUS can tell us if all the attributes are here now. # Compiled 4/21/98 Using latest USR/3Com VSA's # Updated 6/23/98 # Cleaned up by MZ 9/24/98 # # # This file contains dictionary translations for parsing # requests and generating responses. All transactions are # composed of Attribute/Value Pairs. The value of each attribute # is specified as one of 4 data types. Valid data types are: # # string - 0-253 octets # ipaddr - 4 octets in network byte order # integer - 32 bit value in big endian order (high byte first) # date - 32 bit value in big endian order - seconds since # 00:00:00 GMT, Jan. 1, 1970 # # Enumerated values are stored in the user file with dictionary # VALUE translations for easy administration. # # Example: # # ATTRIBUTE VALUE # --------------- ----- # Framed-Protocol = PPP # 7 = 1 (integer encoding) # ATTRIBUTE User-Name 1 string ATTRIBUTE Password 2 string ATTRIBUTE CHAP-Password 3 string ATTRIBUTE Client-Id 4 ipaddr ATTRIBUTE Client-Port-Id 5 integer ATTRIBUTE User-Service-Type 6 integer ATTRIBUTE Framed-Protocol 7 integer ATTRIBUTE Framed-Address 8 ipaddr ATTRIBUTE Framed-Netmask 9 ipaddr ATTRIBUTE Framed-Routing 10 integer ATTRIBUTE Framed-Filter-Id 11 string ATTRIBUTE Framed-MTU 12 integer ATTRIBUTE Framed-Compression 13 integer ATTRIBUTE Login-Host 14 ipaddr ATTRIBUTE Login-Service 15 integer ATTRIBUTE Login-TCP-Port 16 integer ATTRIBUTE Old-Password 17 string ATTRIBUTE Port-Message 18 string ATTRIBUTE Dialback-No 19 string ATTRIBUTE Dialback-Name 20 string ATTRIBUTE Expiration 21 date ATTRIBUTE Framed-Route 22 string ATTRIBUTE Framed-IPX-Network 23 ipaddr ATTRIBUTE Challenge-State 24 string ATTRIBUTE Class 25 string ATTRIBUTE Vendor-Specific 26 string ATTRIBUTE Session-Timeout 27 integer ATTRIBUTE Idle-Timeout 28 integer ATTRIBUTE Termination-Action 29 integer ATTRIBUTE Called-Station-Id 30 string ATTRIBUTE Calling-Station-Id 31 string ATTRIBUTE NAS-Identifier 32 string ATTRIBUTE Proxy-State 33 string ATTRIBUTE Login-LAT-Service 34 string ATTRIBUTE Login-LAT-Node 35 string ATTRIBUTE Login-LAT-Group 36 string ATTRIBUTE Framed-AppleTalk-Link 37 integer ATTRIBUTE Framed-AppleTalk-Network 38 integer ATTRIBUTE Framed-AppleTalk-Zone 39 string ATTRIBUTE Acct-Status-Type 40 integer ATTRIBUTE Acct-Delay-Time 41 integer ATTRIBUTE Acct-Input-Octets 42 integer ATTRIBUTE Acct-Output-Octets 43 integer ATTRIBUTE Acct-Session-Id 44 string ATTRIBUTE Acct-Authentic 45 integer ATTRIBUTE Acct-Session-Time 46 integer ATTRIBUTE Acct-Input-Packets 47 integer ATTRIBUTE Acct-Output-Packets 48 integer ATTRIBUTE Acct-Terminate-Cause 49 integer ATTRIBUTE Acct-Multi-Session-Id 50 string ATTRIBUTE Acct-Link-Count 51 integer ATTRIBUTE CHAP-Challenge 60 string ATTRIBUTE NAS-Port-Type 61 integer ATTRIBUTE Port-Limit 62 integer ATTRIBUTE Login-LAT-Port 63 string ATTRIBUTE Tunnel-Type 64 integer ATTRIBUTE Tunnel-Medium-Type 65 string ATTRIBUTE Tunnel-Client-Endpoint 66 string ATTRIBUTE Tunnel-Server-Endpoint 67 string ATTRIBUTE Acct-Tunnel-Conn-ID 68 string ATTRIBUTE Tunnel-Password 69 string ATTRIBUTE ARAP-Password 70 string ATTRIBUTE ARAP-Feature 71 string ATTRIBUTE ARAP-Zone-Access 72 string ATTRIBUTE ARAP-Security 73 string ATTRIBUTE ARAP-Security-Data 74 string ATTRIBUTE Password-Retry 75 integer ATTRIBUTE Prompt 76 integer ATTRIBUTE Connect-Info 77 string ATTRIBUTE Configuration-Token 78 string ATTRIBUTE EAP-Message 79 string ATTRIBUTE Signature 80 string ATTRIBUTE Tunnel-Private-Group-ID 81 string ATTRIBUTE Tunnel-Assignment-ID 82 string ATTRIBUTE Tunnel-Preference 83 integer ATTRIBUTE ARAP-Challenge-Response 84 string ATTRIBUTE Acct-Interim-Interval 85 integer ## ASCDEND ## ATTRIBUTE Ascend-Handle-IPX 222 integer #### Used by the NMC Card #ATTRIBUTE User-Group-Name 223 string #ATTRIBUTE Dial-In-Sec-Mode 224 integer #ATTRIBUTE Req-Db-Mdm-Sel 225 integer #ATTRIBUTE Req-Db-Login-Valid 226 integer #ATTRIBUTE Dialback-Group-Names 227 string #ATTRIBUTE Dial-In-Call-Rest 228 string #ATTRIBUTE Dial-Out-Call-Rest 229 string #ATTRIBUTE Logins-Before-Blacklist 230 integer #ATTRIBUTE Failed-Logins 231 integer #ATTRIBUTE Allowed-DB-Modems 233 string #ATTRIBUTE Ascend-idle-crap 244 integer #ATTRIBUTE Char-Noecho 250 integer # # These are VSA Radius attributes # ATTRIB_NMC RMMIE-Status 0x01cd integer ATTRIB_NMC Simplified-MNP-Levels 0x0099 integer ATTRIB_NMC Connect-Term-Reason 0x009b integer ATTRIB_NMC Back-Channel-Data-Rate 0x007c integer ATTRIB_NMC Fallback-Enabled 0x0070 integer ATTRIB_NMC Equalization-Type 0x006f integer ATTRIB_NMC Modulation-Type 0x006c integer ATTRIB_NMC Failure-to-Connect-Reason 0x0069 integer ATTRIB_NMC Originate-Answer-Mode 0x0068 integer ATTRIB_NMC Sync-Async-Mode 0x0067 integer ATTRIB_NMC Initial-Tx-Link-Data-Rate 0x006a integer ATTRIB_NMC Final-Tx-Link-Data-Rate 0x006b integer ATTRIB_NMC Simplified-V42bis-Usage 0x00c7 integer ATTRIB_NMC Default-DTE-Data-Rate 0x005e integer ATTRIB_NMC Initial-Modulation-Type 0x0923 integer ATTRIB_NMC RMMIE-x2-Status 0x0909 integer ATTRIB_NMC RMMIE-Planned-Disconnect 0x090a integer ATTRIB_NMC RMMIE-Last-Update-Event 0x0901 integer ATTRIB_NMC Event-Id 0xbfbe integer ATTRIB_NMC Initial-Rx-Link-Data-Rate 0xbf2d integer ATTRIB_NMC Final-Rx-Link-Data-Rate 0xbf2c integer ATTRIB_NMC Card-Type 0xbe85 integer ATTRIB_NMC PW-USR-IFilter-IP 0x9000 string ATTRIB_NMC PW-USR-IFilter-IPX 0x9001 string ATTRIB_NMC PW-USR-IFilter-SAP 0x9002 string ATTRIB_NMC PW-USR-OFilter-IP 0x9003 string ATTRIB_NMC PW-USR-OFilter-IPX 0x9004 string ATTRIB_NMC PW-USR-OFilter-SAP 0x9005 string ATTRIB_NMC PW-VPN-ID 0x9006 integer ATTRIB_NMC PW-VPN-Name 0x9007 string ATTRIB_NMC PW-VPN-Neighbor 0x9008 ipaddr ATTRIB_NMC PW-Framed-Routing-V2 0x9009 integer ATTRIB_NMC PW-VPN-Gateway 0x900a string ATTRIB_NMC PW-Tunnel-Authentication 0x900b string ATTRIB_NMC PW-Index 0x900c integer ATTRIB_NMC PW-Cutoff 0x900d string ATTRIB_NMC PW-Packet 0x900e string ATTRIB_NMC Primary-DNS-Server 0x900f ipaddr ATTRIB_NMC Secondary-DNS-Server 0x9010 ipaddr ATTRIB_NMC Primary-NBNS-Server 0x9011 ipaddr ATTRIB_NMC Secondary-NBNS-Server 0x9012 ipaddr ATTRIB_NMC Syslog-Tap 0x9013 integer ATTRIB_NMC Log-Filter-Packet 0x9017 integer ATTRIB_NMC Chassis-Call-Slot 0x9019 integer ATTRIB_NMC Chassis-Call-Span 0x901A integer ATTRIB_NMC Chassis-Call-Channel 0x901B integer ATTRIB_NMC Keypress-Timeout 0x901C integer ATTRIB_NMC Unauthenticated-Time 0x901D integer ATTRIB_NMC VPN-Encryptor 0x901E string ATTRIB_NMC VPN-GW-Location-Id 0x901F string ATTRIB_NMC Re-Chap-Timeout 0x9020 integer ATTRIB_NMC CCP-Algorithm 0x9021 integer ATTRIB_NMC ACCM-Type 0x9022 integer ATTRIB_NMC Connect-Speed 0x9023 integer ATTRIB_NMC Framed-IP-Address-Pool-Name 0x9024 string ATTRIB_NMC MP-EDO 0x9025 string ATTRIB_NMC Local-Framed-IP-Addr 0x9026 ipaddr ATTRIB_NMC Bearer-Capabilities 0x9800 integer ATTRIB_NMC Speed-Of-Connection 0x9801 integer ATTRIB_NMC Max-Channels 0x9802 integer ATTRIB_NMC Channel-Expansion 0x9803 integer ATTRIB_NMC Channel-Decrement 0x9804 integer ATTRIB_NMC Expansion-Algorithm 0x9805 integer ATTRIB_NMC Compression-Algorithm 0x9806 integer ATTRIB_NMC Receive-Acc-Map 0x9807 integer ATTRIB_NMC Transmit-Acc-Map 0x9808 integer ATTRIB_NMC Compression-Reset-Mode 0x980a integer ATTRIB_NMC Min-Compression-Size 0x980b integer ATTRIB_NMC Filter-Zones 0x980e integer ATTRIB_NMC Appletalk 0x980f integer ATTRIB_NMC Bridging 0x9810 integer ATTRIB_NMC Spoofing 0x9811 integer ATTRIB_NMC Host-Type 0x9812 integer ATTRIB_NMC Send-Name 0x9813 string ATTRIB_NMC Send-Password 0x9814 string ATTRIB_NMC Start-Time 0x9815 integer ATTRIB_NMC End-Time 0x9816 integer ATTRIB_NMC Send-Script1 0x9817 string ATTRIB_NMC Reply-Script1 0x9818 string ATTRIB_NMC Send-Script2 0x9819 string ATTRIB_NMC Reply-Script2 0x981a string ATTRIB_NMC Send-Script3 0x981b string ATTRIB_NMC Reply-Script3 0x981c string ATTRIB_NMC Send-Script4 0x981d string ATTRIB_NMC Reply-Script4 0x981e string ATTRIB_NMC Send-Script5 0x981f string ATTRIB_NMC Reply-Script5 0x9820 string ATTRIB_NMC Send-Script6 0x9821 string ATTRIB_NMC Reply-Script6 0x9822 string ATTRIB_NMC Terminal-Type 0x9823 string ATTRIB_NMC Appletalk-Network-Range 0x9824 integer ATTRIB_NMC Local-IP-Address 0x9825 string ATTRIB_NMC Routing-Protocol 0x9826 integer ATTRIB_NMC Modem-Group 0x9827 string ATTRIB_NMC IPX-Routing 0x9828 integer ATTRIB_NMC IPX-WAN 0x9829 integer ATTRIB_NMC IP-RIP-Policies 0x982a integer ATTRIB_NMC IP-RIP-Simple-Auth-Password 0x982b string ATTRIB_NMC IP-RIP-Input-Filter 0x982c string ATTRIB_NMC IP-Call-Input-Filter 0x982d string ATTRIB_NMC IPX-RIP-Input-Filter 0x982e string ATTRIB_NMC IPX-Call-Input-Filter 0x9830 string ATTRIB_NMC AT-Input-Filter 0x9831 string ATTRIB_NMC AT-RTMP-Input-Filter 0x9832 string ATTRIB_NMC AT-Zip-Input-Filter 0x9833 string ATTRIB_NMC AT-Call-Input-Filter 0x9834 string ATTRIB_NMC ET-Bridge-Input-Filter 0x9835 string ATTRIB_NMC IP-RIP-Output-Filter 0x9836 string ATTRIB_NMC IP-Call-Output-Filter 0x9837 string ATTRIB_NMC IPX-RIP-Output-Filter 0x9838 string ATTRIB_NMC IPX-Call-Output-Filter 0x9839 string ATTRIB_NMC AT-Output-Filter 0x983a string ATTRIB_NMC AT-RTMP-Output-Filter 0x983b string ATTRIB_NMC AT-Zip-Output-Filter 0x983c string ATTRIB_NMC AT-Call-Output-Filter 0x983d string ATTRIB_NMC ET-Bridge-Output-Filter 0x983e string ATTRIB_NMC ET-Bridge-Call-Output-Filter 0x983f string ATTRIB_NMC IP-Default-Route-Option 0x9840 integer #ATTRIB_NMC MP-EDO-HIPER 0x9841 string #put the "hex" in since some NAS's were sending non-printable characters ATTRIB_NMC MP-EDO-HIPER 0x9841 hex ATTRIB_NMC Modem-Training-Time 0x9842 integer ATTRIB_NMC Interface-Index 0x9843 integer ATTRIB_NMC Tunnel-Security 0x9844 integer ATTRIB_NMC Port-Tap 0x9845 integer ATTRIB_NMC Port-Tap-Format 0x9846 integer ATTRIB_NMC Port-Tap-Output 0x9847 integer ATTRIB_NMC Port-Tap-Facility 0x9848 integer ATTRIB_NMC Port-Tap-Priority 0x9849 integer ATTRIB_NMC Port-Tap-Address 0x984a ipaddr ATTRIB_NMC MobileIP-Home-Agent-Address 0x984b ipaddr ATTRIB_NMC Tunneled-MLPP 0x984c integer ATTRIB_NMC Multicast-Proxy 0x984d integer ATTRIB_NMC Multicast-Receive 0x984e integer ATTRIB_NMC Multicast-Forwarding 0x9850 integer ATTRIB_NMC IGMP-Query-Interval 0x9851 integer ATTRIB_NMC IGMP-Maximum-Response-Time 0x9852 integer ATTRIB_NMC IGMP-Robustness 0x9853 integer ATTRIB_NMC IGMP-Version 0x9854 integer ATTRIB_NMC MP-MRRU 0x982f integer ATTRIB_NMC USR-Callback-Type 0x986a integer ATTRIB_NMC Request-Type 0xf001 integer # # Integer Translations # # Tunnel Types VALUE Tunnel-Type PPTP 1 VALUE Tunnel-Type L2TP 3 VALUE Tunnel-Type VTP 5 # Tunnel Medium Types VALUE Tunnel-Medium-Type IP 1 VALUE Tunnel-Medium-Type E.164 8 # Tunnel Security Types VALUE Tunnel-Security None 0 VALUE Tunnel-Security Control-Only 1 VALUE Tunnel-Security Data-Only 2 VALUE Tunnel-Security Both-Data-and-Control 3 VALUE Termination-Action Default 0 VALUE Termination-Action RADIUS-Request 1 VALUE Termination-Action Manage-Resources 2 VALUE CCP-Algorithm NONE 1 VALUE CCP-Algorithm Stac 2 VALUE CCP-Algorithm MS 3 VALUE CCP-Algorithm Any 4 VALUE Connect-Speed NONE 1 VALUE Connect-Speed 300-BPS 2 VALUE Connect-Speed 1200-BPS 3 VALUE Connect-Speed 2400-BPS 4 VALUE Connect-Speed 4800-BPS 5 VALUE Connect-Speed 7200-BPS 6 VALUE Connect-Speed 9600-BPS 7 VALUE Connect-Speed 12000-BPS 8 VALUE Connect-Speed 14400-BPS 9 VALUE Connect-Speed 16800-BPS 10 VALUE Connect-Speed 19200-BPS 11 VALUE Connect-Speed 21600-BPS 12 VALUE Connect-Speed 28800-BPS 13 VALUE Connect-Speed 38400-BPS 14 VALUE Connect-Speed 57600-BPS 15 VALUE Connect-Speed 115200-BPS 16 VALUE Connect-Speed 288000-BPS 17 VALUE Connect-Speed 75-1200-BPS 18 VALUE Connect-Speed 1200-75-BPS 19 VALUE Connect-Speed 24000-BPS 20 VALUE Connect-Speed 26400-BPS 21 VALUE Connect-Speed 31200-BPS 22 VALUE Connect-Speed 33600-BPS 23 VALUE Connect-Speed 33333-BPS 24 VALUE Connect-Speed 37333-BPS 25 VALUE Connect-Speed 41333-BPS 26 VALUE Connect-Speed 42666-BPS 27 VALUE Connect-Speed 44000-BPS 28 VALUE Connect-Speed 45333-BPS 29 VALUE Connect-Speed 46666-BPS 30 VALUE Connect-Speed 48000-BPS 31 VALUE Connect-Speed 49333-BPS 32 VALUE Connect-Speed 50666-BPS 33 VALUE Connect-Speed 52000-BPS 34 VALUE Connect-Speed 53333-BPS 35 VALUE Connect-Speed 54666-BPS 36 VALUE Connect-Speed 56000-BPS 37 VALUE Connect-Speed 57333-BPS 38 VALUE Connect-Speed 64000-BPS 39 VALUE Connect-Speed 25333-BPS 40 VALUE Connect-Speed 26666-BPS 41 VALUE Connect-Speed 28000-BPS 42 VALUE Connect-Speed 29333-BPS 43 VALUE Connect-Speed 30666-BPS 44 VALUE Connect-Speed 32000-BPS 45 VALUE Connect-Speed 34666-BPS 46 VALUE Connect-Speed 36000-BPS 47 VALUE Connect-Speed 38666-BPS 48 VALUE Connect-Speed 40000-BPS 49 VALUE Connect-Speed 58666-BPS 50 VALUE Connect-Speed 60000-BPS 51 VALUE Connect-Speed 61333-BPS 52 VALUE Connect-Speed 62666-BPS 53 VALUE User-Service-Type Login-User 1 VALUE User-Service-Type Framed-User 2 VALUE User-Service-Type Dialback-Login-User 3 VALUE User-Service-Type Dialback-Framed-User 4 VALUE User-Service-Type Outbound-User 5 VALUE User-Service-Type Shell-User 6 VALUE User-Service-Type NAS-Prompt 7 VALUE User-Service-Type Authenticate-Only 8 VALUE User-Service-Type Callback-NAS-Prompt 9 VALUE Framed-Protocol PPP 1 VALUE Framed-Protocol SLIP 2 VALUE Framed-Protocol ARAP 3 VALUE Framed-Protocol Gandalf-Link 4 VALUE Framed-Protocol Xylogics 5 VALUE Framed-Protocol PPTP 9 VALUE Framed-Routing None 0 VALUE Framed-Routing Broadcast 1 VALUE Framed-Routing Listen 2 VALUE Framed-Routing Broadcast-Listen 3 VALUE Framed-Compression None 0 VALUE Framed-Compression Van-Jacobsen-TCP-IP 1 VALUE Framed-Compression IPX-Header 2 VALUE Login-Service Telnet 0 VALUE Login-Service Rlogin 1 VALUE Login-Service TCP-Clear 2 VALUE Login-Service PortMaster 3 VALUE Login-Service LAT 4 VALUE Acct-Status-Type Start 1 VALUE Acct-Status-Type Stop 2 VALUE Acct-Status-Type Alive 3 VALUE Acct-Authentic None 0 VALUE Acct-Authentic RADIUS 1 VALUE Acct-Authentic Local 2 VALUE Acct-Terminate-Cause ACCT-TERM-USER-REQUEST 1 VALUE Acct-Terminate-Cause ACCT-TERM-LOST-CARRIER 2 VALUE Acct-Terminate-Cause ACCT-TERM-LOST-SERVICE 3 VALUE Acct-Terminate-Cause ACCT-TERM-IDLE-TIMEOUT 4 VALUE Acct-Terminate-Cause ACCT-TERM-SESSION-TIMEOUT 5 VALUE Acct-Terminate-Cause ACCT-TERM-ADMIN-RESET 6 VALUE Acct-Terminate-Cause ACCT-TERM-ADMIN-REBOOT 7 VALUE Acct-Terminate-Cause ACCT-TERM-PORT-ERROR 8 VALUE Acct-Terminate-Cause ACCT-TERM-NAS-ERROR 9 VALUE Acct-Terminate-Cause ACCT-TERM-NAS-REQUEST 10 VALUE Acct-Terminate-Cause ACCT-TERM-NAS-REBOOT 11 VALUE Acct-Terminate-Cause ACCT-TERM-PORT-UNNEEDED 12 VALUE Acct-Terminate-Cause ACCT-TERM-PORT-PREEMPTED 13 VALUE Acct-Terminate-Cause ACCT-TERM-PORT-SUSPENDED 14 VALUE Acct-Terminate-Cause ACCT-TERM-SERVICE-UNAVAIL 15 VALUE Acct-Terminate-Cause ACCT-TERM-CALLBACK 16 VALUE Acct-Terminate-Cause ACCT-TERM-USER-ERROR 17 VALUE Acct-Terminate-Cause ACCT-TERM-HOST-REQUEST 18 VALUE Event-Id Module-Inserted 6 VALUE Event-Id Module-Removed 7 VALUE Event-Id PSU-Voltage-Alarm 8 VALUE Event-Id PSU-Failed 9 VALUE Event-Id HUB-Temp-Out-of-Range 10 VALUE Event-Id Fan-Failed 11 VALUE Event-Id Watchdog-Timeout 12 VALUE Event-Id Mgmt-Bus-Failure 13 VALUE Event-Id In-Connection-Est 14 VALUE Event-Id Out-Connection-Est 15 VALUE Event-Id In-Connection-Term 16 VALUE Event-Id Out-Connection-Term 17 VALUE Event-Id Connection-Failed 18 VALUE Event-Id Connection-Timeout 19 VALUE Event-Id DTE-Transmit-Idle 20 VALUE Event-Id DTR-True 21 VALUE Event-Id DTR-False 22 VALUE Event-Id Block-Error-at-Threshold 23 VALUE Event-Id Fallbacks-at-Threshold 24 VALUE Event-Id No-Dial-Tone-Detected 25 VALUE Event-Id No-Loop-Current-Detected 26 VALUE Event-Id Yellow-Alarm 27 VALUE Event-Id Red-Alarm 28 VALUE Event-Id Loss-Of-Signal 29 VALUE Event-Id Rcv-Alrm-Ind-Signal 30 VALUE Event-Id Timing-Source-Switch 31 VALUE Event-Id Modem-Reset-by-DTE 32 VALUE Event-Id Modem-Ring-No-Answer 33 VALUE Event-Id DTE-Ring-No-Answer 34 VALUE Event-Id Pkt-Bus-Session-Active 35 VALUE Event-Id Pkt-Bus-Session-Congestion 36 VALUE Event-Id Pkt-Bus-Session-Lost 37 VALUE Event-Id Pkt-Bus-Session-Inactive 38 VALUE Event-Id User-Interface-Reset 39 VALUE Event-Id Gateway-Port-Out-of-Service 40 VALUE Event-Id Gateway-Port-Link-Active 41 VALUE Event-Id Dial-Out-Login-Failure 42 VALUE Event-Id Dial-In-Login-Failure 43 VALUE Event-Id Dial-Out-Restricted-Number 44 VALUE Event-Id Dial-Back-Restricted-Number 45 VALUE Event-Id User-Blacklisted 46 VALUE Event-Id Attempted-Login-Blacklisted 47 VALUE Event-Id Response-Attempt-Limit-Exceeded 48 VALUE Event-Id Login-Attempt-Limit-Exceeded 49 VALUE Event-Id Dial-Out-Call-Duration 50 VALUE Event-Id Dial-In-Call-Duration 51 VALUE Event-Id Pkt-Bus-Session-Err-Status 52 VALUE Event-Id NMC-AutoRespnse-Trap 53 VALUE Event-Id Acct-Server-Contact-Loss 54 VALUE Event-Id Yellow-Alarm-Clear 55 VALUE Event-Id Red-Alarm-Clear 56 VALUE Event-Id Loss-Of-Signal-Clear 57 VALUE Event-Id Rcv-Alrm-Ind-Signal-Clear 58 VALUE Event-Id Incoming-Connection-Established 59 VALUE Event-Id Outgoing-Connection-Established 60 VALUE Event-Id Incoming-Connection-Terminated 61 VALUE Event-Id Outgoing-Connection-Terminated 62 VALUE Event-Id Connection-Attempt-Failure 63 VALUE Event-Id Continuous-CRC-Alarm 64 VALUE Event-Id Continuous-CRC-Alarm-Clear 65 VALUE Event-Id Physical-State-Change 66 VALUE Event-Id Gateway-Network-Failed 71 VALUE Event-Id Gateway-Network-Restored 72 VALUE Event-Id Packet-Bus-Clock-Lost 73 VALUE Event-Id Packet-Bus-Clock-Restored 74 VALUE Event-Id D-Channel-In-Service 75 VALUE Event-Id D-Channel-Out-of-Service 76 VALUE Event-Id DS0s-In-Service 77 VALUE Event-Id DS0s-Out-of-Service 78 VALUE Event-Id T1/T1PRI/E1PRI-Call-Event 79 VALUE Event-Id Psu-Incompatible 80 VALUE Event-Id T1,T1-E1/PRI-Call-Arrive-Event 81 VALUE Event-Id T1,T1-E1/PRI-Call-Connect-Event 82 VALUE Event-Id T1,T1-E1/PRI-Call-Termina-Event 83 VALUE Event-Id T1,T1-E1/PRI-Call-Failed-Event 84 VALUE Event-Id DNS-Contact-Lost 85 VALUE Event-Id NTP-Contact-Lost 86 VALUE Event-Id NTP-Contact-Restored 87 VALUE Event-Id IPGW-Link-Up 88 VALUE Event-Id IPGW-Link-Down 89 VALUE Event-Id NTP-Contact-Degraded 90 VALUE Event-Id In-Connection-Failed 91 VALUE Event-Id Out-Connection-Failed 92 VALUE Event-Id Application-ProcessorReset 93 VALUE Event-Id DSP-Reset 94 VALUE Event-Id Changed-to-Maint-Srvs-State 95 VALUE Event-Id Loop-Back-cleared-on-channel 96 VALUE Event-Id Loop-Back-on-channel 97 VALUE Event-Id Telco-Abnormal-Response 98 VALUE Event-Id DNS-Contact-Restored 99 VALUE Event-Id DNS-Contact-Degraded 100 VALUE Event-Id RADIUS-Accounting-Restored 101 VALUE Event-Id RADIUS-Accounting-Group-Restore 102 VALUE Event-Id RADIUS-Accounting-Group-Degrade 103 VALUE Event-Id RADIUS-Accounting-Group-NonOper 104 VALUE Event-Id T1/T1-E1/PRI-InCall-Fail-Event 119 VALUE Event-Id T1/T1-E1/PRI-OutCall-Fail-Event 120 VALUE Event-Id RMMIE-Retrain-Event 121 VALUE Event-Id RMMIE-Speed-Shift-Event 122 VALUE Card-Type SlotEmpty 1 VALUE Card-Type SlotUnknown 2 VALUE Card-Type NetwMgtCard 3 VALUE Card-Type DualT1NAC 4 VALUE Card-Type DualModemNAC 5 VALUE Card-Type QuadModemNAC 6 VALUE Card-Type TrGatewayNAC 7 VALUE Card-Type X25GatewayNAC 8 VALUE Card-Type DualV34ModemNAC 9 VALUE Card-Type QuadV32DigitalModemNAC 10 VALUE Card-Type QuadV32AnalogModemNAC 11 VALUE Card-Type QuadV32DigAnlModemNAC 12 VALUE Card-Type QuadV34DigModemNAC 13 VALUE Card-Type QuadV34AnlModemNAC 14 VALUE Card-Type QuadV34DigAnlModemNAC 15 VALUE Card-Type SingleT1NAC 16 VALUE Card-Type EthernetGatewayNAC 17 VALUE Card-Type AccessServer 18 VALUE Card-Type 486TrGatewayNAC 19 VALUE Card-Type 486EthernetGatewayNAC 20 VALUE Card-Type DualRS232NAC 22 VALUE Card-Type 486X25GatewayNAC 23 VALUE Card-Type ApplicationServerNAC 25 VALUE Card-Type ISDNGatewayNAC 26 VALUE Card-Type ISDNpriT1NAC 27 VALUE Card-Type ClkedNetMgtCard 28 VALUE Card-Type ModemPoolManagementNAC 29 VALUE Card-Type ModemPoolNetserverNAC 30 VALUE Card-Type ModemPoolV34ModemNAC 31 VALUE Card-Type ModemPoolISDNNAC 32 VALUE Card-Type NTServerNAC 33 VALUE Card-Type QuadV34DigitalG2NAC 34 VALUE Card-Type QuadV34AnalogG2NAC 35 VALUE Card-Type QuadV34DigAnlgG2NAC 36 VALUE Card-Type NETServerFrameRelayNAC 37 VALUE Card-Type NETServerTokenRingNAC 38 VALUE Card-Type X2524ChannelNAC 39 VALUE Card-Type WirelessGatewayNac 42 VALUE Card-Type EnhancedAccessServer 44 VALUE Card-Type EnhancedISDNGatewayNAC 45 VALUE Card-Type DualT1NIC 1001 VALUE Card-Type DualAlogMdmNIC 1002 VALUE Card-Type QuadDgtlMdmNIC 1003 VALUE Card-Type QuadAlogDgtlMdmNIC 1004 VALUE Card-Type TokenRingNIC 1005 VALUE Card-Type SingleT1NIC 1006 VALUE Card-Type EthernetNIC 1007 VALUE Card-Type ShortHaulDualT1NIC 1008 VALUE Card-Type DualAlogMgdIntlMdmNIC 1009 VALUE Card-Type X25NIC 1010 VALUE Card-Type QuadAlogNonMgdMdmNIC 1011 VALUE Card-Type QuadAlogMgdIntlMdmNIC 1012 VALUE Card-Type QuadAlogNonMgdIntlMdmNIC 1013 VALUE Card-Type QuadLsdLiMgdMdmNIC 1014 VALUE Card-Type QuadLsdLiNonMgdMdmNIC 1015 VALUE Card-Type QuadLsdLiMgdIntlMdmNIC 1016 VALUE Card-Type QuadLsdLiNonMgdIntlMdmNIC 1017 VALUE Card-Type HSEthernetWithV35NIC 1018 VALUE Card-Type HSEthernetWithoutV35NIC 1019 VALUE Card-Type DualHighSpeedV35NIC 1020 VALUE Card-Type QuadV35RS232LowSpeedNIC 1021 VALUE Card-Type DualE1NIC 1022 VALUE Card-Type ShortHaulDualE1NIC 1023 VALUE Card-Type BellcoreLongHaulDualT1NIC 1025 VALUE Card-Type BellcoreShrtHaulDualT1NIC 1026 VALUE Card-Type SCSIEdgeServerNIC 1027 VALUE Default-DTE-Data-Rate 110-BPS 1 VALUE Default-DTE-Data-Rate 300-BPS 2 VALUE Default-DTE-Data-Rate 600-BPS 3 VALUE Default-DTE-Data-Rate 1200-BPS 4 VALUE Default-DTE-Data-Rate 2400-BPS 5 VALUE Default-DTE-Data-Rate 4800-BPS 6 VALUE Default-DTE-Data-Rate 7200-BPS 7 VALUE Default-DTE-Data-Rate 9600-BPS 8 VALUE Default-DTE-Data-Rate 12K-BPS 9 VALUE Default-DTE-Data-Rate 14.4K-BPS 10 VALUE Default-DTE-Data-Rate 16.8-BPS 11 VALUE Default-DTE-Data-Rate 19.2K-BPS 12 VALUE Default-DTE-Data-Rate 38.4K-BPS 13 VALUE Default-DTE-Data-Rate 75-BPS 14 VALUE Default-DTE-Data-Rate 450-BPS 15 VALUE Default-DTE-Data-Rate UNKNOWN-BPS 16 VALUE Default-DTE-Data-Rate 57.6K-BPS 17 VALUE Default-DTE-Data-Rate 21.6K-BPS 18 VALUE Default-DTE-Data-Rate 24K-BPS 19 VALUE Default-DTE-Data-Rate 26K-BPS 20 VALUE Default-DTE-Data-Rate 28K-BPS 21 VALUE Default-DTE-Data-Rate 115K-BPS 22 VALUE Initial-Rx-Link-Data-Rate 110-BPS 1 VALUE Initial-Rx-Link-Data-Rate 300-BPS 2 VALUE Initial-Rx-Link-Data-Rate 600-BPS 3 VALUE Initial-Rx-Link-Data-Rate 1200-BPS 4 VALUE Initial-Rx-Link-Data-Rate 2400-XBPS 5 VALUE Initial-Rx-Link-Data-Rate 4800-BPS 6 VALUE Initial-Rx-Link-Data-Rate 7200-BPS 7 VALUE Initial-Rx-Link-Data-Rate 9600-BPS 8 VALUE Initial-Rx-Link-Data-Rate 12K-BPS 9 VALUE Initial-Rx-Link-Data-Rate 14.4K-BPS 10 VALUE Initial-Rx-Link-Data-Rate 16.8-BPS 11 VALUE Initial-Rx-Link-Data-Rate 19.2K-BPS 12 VALUE Initial-Rx-Link-Data-Rate 38.4K-BPS 13 VALUE Initial-Rx-Link-Data-Rate 75-BPS 14 VALUE Initial-Rx-Link-Data-Rate 450-BPS 15 VALUE Initial-Rx-Link-Data-Rate UNKNOWN-BPS 16 VALUE Initial-Rx-Link-Data-Rate 57.6K-BPS 17 VALUE Initial-Rx-Link-Data-Rate 21.6K-BPS 18 VALUE Initial-Rx-Link-Data-Rate 24K-BPS 19 VALUE Initial-Rx-Link-Data-Rate 26K-BPS 20 VALUE Initial-Rx-Link-Data-Rate 28K-BPS 21 VALUE Initial-Rx-Link-Data-Rate 115K-BPS 22 VALUE Initial-Rx-Link-Data-Rate 31K-BPS 23 VALUE Initial-Rx-Link-Data-Rate 33K-BPS 24 VALUE Initial-Rx-Link-Data-Rate 25333-BPS 25 VALUE Initial-Rx-Link-Data-Rate 26666-BPS 26 VALUE Initial-Rx-Link-Data-Rate 28000-BPS 27 VALUE Initial-Rx-Link-Data-Rate 29333-BPS 28 VALUE Initial-Rx-Link-Data-Rate 30666-BPS 29 VALUE Initial-Rx-Link-Data-Rate 32000-BPS 30 VALUE Initial-Rx-Link-Data-Rate 33333-BPS 31 VALUE Initial-Rx-Link-Data-Rate 34666-BPS 32 VALUE Initial-Rx-Link-Data-Rate 36000-BPS 33 VALUE Initial-Rx-Link-Data-Rate 37333-BPS 34 VALUE Initial-Rx-Link-Data-Rate 38666-BPS 35 VALUE Initial-Rx-Link-Data-Rate 40000-BPS 36 VALUE Initial-Rx-Link-Data-Rate 41333-BPS 37 VALUE Initial-Rx-Link-Data-Rate 42666-BPS 38 VALUE Initial-Rx-Link-Data-Rate 44000-BPS 39 VALUE Initial-Rx-Link-Data-Rate 45333-BPS 40 VALUE Initial-Rx-Link-Data-Rate 46666-BPS 41 VALUE Initial-Rx-Link-Data-Rate 48000-BPS 42 VALUE Initial-Rx-Link-Data-Rate 49333-BPS 43 VALUE Initial-Rx-Link-Data-Rate 50666-BPS 44 VALUE Initial-Rx-Link-Data-Rate 52000-BPS 45 VALUE Initial-Rx-Link-Data-Rate 53333-BPS 46 VALUE Initial-Rx-Link-Data-Rate 54666-BPS 47 VALUE Initial-Rx-Link-Data-Rate 56000-BPS 48 VALUE Initial-Rx-Link-Data-Rate 57333-BPS 49 VALUE Initial-Rx-Link-Data-Rate 58666-BPS 50 VALUE Initial-Rx-Link-Data-Rate 60000-BPS 51 VALUE Initial-Rx-Link-Data-Rate 61333-BPS 52 VALUE Initial-Rx-Link-Data-Rate 62666-BPS 53 VALUE Initial-Rx-Link-Data-Rate 64000-BPS 54 VALUE Final-Rx-Link-Data-Rate 110-BPS 1 VALUE Final-Rx-Link-Data-Rate 300-BPS 2 VALUE Final-Rx-Link-Data-Rate 600-BPS 3 VALUE Final-Rx-Link-Data-Rate 1200-BPS 4 VALUE Final-Rx-Link-Data-Rate 2400-BPS 5 VALUE Final-Rx-Link-Data-Rate 4800-BPS 6 VALUE Final-Rx-Link-Data-Rate 7200-BPS 7 VALUE Final-Rx-Link-Data-Rate 9600-BPS 8 VALUE Final-Rx-Link-Data-Rate 12K-BPS 9 VALUE Final-Rx-Link-Data-Rate 14.4K-BPS 10 VALUE Final-Rx-Link-Data-Rate 16.8-BPS 11 VALUE Final-Rx-Link-Data-Rate 19.2K-BPS 12 VALUE Final-Rx-Link-Data-Rate 38.4K-BPS 13 VALUE Final-Rx-Link-Data-Rate 75-BPS 14 VALUE Final-Rx-Link-Data-Rate 450-BPS 15 VALUE Final-Rx-Link-Data-Rate UNKNOWN-BPS 16 VALUE Final-Rx-Link-Data-Rate 57.6K-BPS 17 VALUE Final-Rx-Link-Data-Rate 21.6K-BPS 18 VALUE Final-Rx-Link-Data-Rate 24K-BPS 19 VALUE Final-Rx-Link-Data-Rate 26K-BPS 20 VALUE Final-Rx-Link-Data-Rate 28K-BPS 21 VALUE Final-Rx-Link-Data-Rate 115K-BPS 22 VALUE Final-Rx-Link-Data-Rate 31K-BPS 23 VALUE Final-Rx-Link-Data-Rate 33K-BPS 24 VALUE Final-Rx-Link-Data-Rate 25333-BPS 25 VALUE Final-Rx-Link-Data-Rate 26666-BPS 26 VALUE Final-Rx-Link-Data-Rate 28000-BPS 27 VALUE Final-Rx-Link-Data-Rate 29333-BPS 28 VALUE Final-Rx-Link-Data-Rate 30666-BPS 29 VALUE Final-Rx-Link-Data-Rate 32000-BPS 30 VALUE Final-Rx-Link-Data-Rate 33333-BPS 31 VALUE Final-Rx-Link-Data-Rate 34666-BPS 32 VALUE Final-Rx-Link-Data-Rate 36000-BPS 33 VALUE Final-Rx-Link-Data-Rate 37333-BPS 34 VALUE Final-Rx-Link-Data-Rate 38666-BPS 35 VALUE Final-Rx-Link-Data-Rate 40000-BPS 36 VALUE Final-Rx-Link-Data-Rate 41333-BPS 37 VALUE Final-Rx-Link-Data-Rate 42666-BPS 38 VALUE Final-Rx-Link-Data-Rate 44000-BPS 39 VALUE Final-Rx-Link-Data-Rate 45333-BPS 40 VALUE Final-Rx-Link-Data-Rate 46666-BPS 41 VALUE Final-Rx-Link-Data-Rate 48000-BPS 42 VALUE Final-Rx-Link-Data-Rate 49333-BPS 43 VALUE Final-Rx-Link-Data-Rate 50666-BPS 44 VALUE Final-Rx-Link-Data-Rate 52000-BPS 45 VALUE Final-Rx-Link-Data-Rate 53333-BPS 46 VALUE Final-Rx-Link-Data-Rate 54666-BPS 47 VALUE Final-Rx-Link-Data-Rate 56000-BPS 48 VALUE Final-Rx-Link-Data-Rate 57333-BPS 49 VALUE Final-Rx-Link-Data-Rate 58666-BPS 50 VALUE Final-Rx-Link-Data-Rate 60000-BPS 51 VALUE Final-Rx-Link-Data-Rate 61333-BPS 52 VALUE Final-Rx-Link-Data-Rate 62666-BPS 53 VALUE Final-Rx-Link-Data-Rate 64000-BPS 54 VALUE Initial-Tx-Link-Data-Rate 110-BPS 1 VALUE Initial-Tx-Link-Data-Rate 300-BPS 2 VALUE Initial-Tx-Link-Data-Rate 600-BPS 3 VALUE Initial-Tx-Link-Data-Rate 1200-BPS 4 VALUE Initial-Tx-Link-Data-Rate 2400-BPS 5 VALUE Initial-Tx-Link-Data-Rate 4800-BPS 6 VALUE Initial-Tx-Link-Data-Rate 7200-BPS 7 VALUE Initial-Tx-Link-Data-Rate 9600-BPS 8 VALUE Initial-Tx-Link-Data-Rate 12K-BPS 9 VALUE Initial-Tx-Link-Data-Rate 14.4K-BPS 10 VALUE Initial-Tx-Link-Data-Rate 16.8-BPS 11 VALUE Initial-Tx-Link-Data-Rate 19.2K-BPS 12 VALUE Initial-Tx-Link-Data-Rate 38.4K-BPS 13 VALUE Initial-Tx-Link-Data-Rate 75-BPS 14 VALUE Initial-Tx-Link-Data-Rate 450-BPS 15 VALUE Initial-Tx-Link-Data-Rate UNKNOWN-BPS 16 VALUE Initial-Tx-Link-Data-Rate 57.6K-BPS 17 VALUE Initial-Tx-Link-Data-Rate 21.6K-BPS 18 VALUE Initial-Tx-Link-Data-Rate 24K-BPS 19 VALUE Initial-Tx-Link-Data-Rate 26K-BPS 20 VALUE Initial-Tx-Link-Data-Rate 28K-BPS 21 VALUE Initial-Tx-Link-Data-Rate 115K-BPS 22 VALUE Initial-Tx-Link-Data-Rate 31K-BPS 23 VALUE Initial-Tx-Link-Data-Rate 33K-BPS 24 VALUE Initial-Tx-Link-Data-Rate 25333-BPS 25 VALUE Initial-Tx-Link-Data-Rate 26666-BPS 26 VALUE Initial-Tx-Link-Data-Rate 28000-BPS 27 VALUE Initial-Tx-Link-Data-Rate 29333-BPS 28 VALUE Initial-Tx-Link-Data-Rate 30666-BPS 29 VALUE Initial-Tx-Link-Data-Rate 32000-BPS 30 VALUE Initial-Tx-Link-Data-Rate 33333-BPS 31 VALUE Initial-Tx-Link-Data-Rate 34666-BPS 32 VALUE Initial-Tx-Link-Data-Rate 36000-BPS 33 VALUE Initial-Tx-Link-Data-Rate 37333-BPS 34 VALUE Initial-Tx-Link-Data-Rate 38666-BPS 35 VALUE Initial-Tx-Link-Data-Rate 40000-BPS 36 VALUE Initial-Tx-Link-Data-Rate 41333-BPS 37 VALUE Initial-Tx-Link-Data-Rate 42666-BPS 38 VALUE Initial-Tx-Link-Data-Rate 44000-BPS 39 VALUE Initial-Tx-Link-Data-Rate 45333-BPS 40 VALUE Initial-Tx-Link-Data-Rate 46666-BPS 41 VALUE Initial-Tx-Link-Data-Rate 48000-BPS 42 VALUE Initial-Tx-Link-Data-Rate 49333-BPS 43 VALUE Initial-Tx-Link-Data-Rate 50666-BPS 44 VALUE Initial-Tx-Link-Data-Rate 52000-BPS 45 VALUE Initial-Tx-Link-Data-Rate 53333-BPS 46 VALUE Initial-Tx-Link-Data-Rate 54666-BPS 47 VALUE Initial-Tx-Link-Data-Rate 56000-BPS 48 VALUE Initial-Tx-Link-Data-Rate 57333-BPS 49 VALUE Initial-Tx-Link-Data-Rate 58666-BPS 50 VALUE Initial-Tx-Link-Data-Rate 60000-BPS 51 VALUE Initial-Tx-Link-Data-Rate 61333-BPS 52 VALUE Initial-Tx-Link-Data-Rate 62666-BPS 53 VALUE Initial-Tx-Link-Data-Rate 64000-BPS 54 VALUE Final-Tx-Link-Data-Rate 110-BPS 1 VALUE Final-Tx-Link-Data-Rate 300-BPS 2 VALUE Final-Tx-Link-Data-Rate 600-BPS 3 VALUE Final-Tx-Link-Data-Rate 1200-BPS 4 VALUE Final-Tx-Link-Data-Rate 2400-BPS 5 VALUE Final-Tx-Link-Data-Rate 4800-BPS 6 VALUE Final-Tx-Link-Data-Rate 7200-BPS 7 VALUE Final-Tx-Link-Data-Rate 9600-BPS 8 VALUE Final-Tx-Link-Data-Rate 12K-BPS 9 VALUE Final-Tx-Link-Data-Rate 14.4K-BPS 10 VALUE Final-Tx-Link-Data-Rate 16.8-BPS 11 VALUE Final-Tx-Link-Data-Rate 19.2K-BPS 12 VALUE Final-Tx-Link-Data-Rate 38.4K-BPS 13 VALUE Final-Tx-Link-Data-Rate 75-BPS 14 VALUE Final-Tx-Link-Data-Rate 450-BPS 15 VALUE Final-Tx-Link-Data-Rate UNKNOWN 16 VALUE Final-Tx-Link-Data-Rate 57.6K-BPS 17 VALUE Final-Tx-Link-Data-Rate 21.6K-BPS 18 VALUE Final-Tx-Link-Data-Rate 24K-BPS 19 VALUE Final-Tx-Link-Data-Rate 26K-BPS 20 VALUE Final-Tx-Link-Data-Rate 28K-BPS 21 VALUE Final-Tx-Link-Data-Rate 115K-BPS 22 VALUE Final-Tx-Link-Data-Rate 31K-BPS 23 VALUE Final-Tx-Link-Data-Rate 33K-BPS 24 VALUE Final-Tx-Link-Data-Rate 25333-BPS 25 VALUE Final-Tx-Link-Data-Rate 26666-BPS 26 VALUE Final-Tx-Link-Data-Rate 28000-BPS 27 VALUE Final-Tx-Link-Data-Rate 29333-BPS 28 VALUE Final-Tx-Link-Data-Rate 30666-BPS 29 VALUE Final-Tx-Link-Data-Rate 32000-BPS 30 VALUE Final-Tx-Link-Data-Rate 33333-BPS 31 VALUE Final-Tx-Link-Data-Rate 34666-BPS 32 VALUE Final-Tx-Link-Data-Rate 36000-BPS 33 VALUE Final-Tx-Link-Data-Rate 37333-BPS 34 VALUE Final-Tx-Link-Data-Rate 38666-BPS 35 VALUE Final-Tx-Link-Data-Rate 40000-BPS 36 VALUE Final-Tx-Link-Data-Rate 41333-BPS 37 VALUE Final-Tx-Link-Data-Rate 42666-BPS 38 VALUE Final-Tx-Link-Data-Rate 44000-BPS 39 VALUE Final-Tx-Link-Data-Rate 45333-BPS 40 VALUE Final-Tx-Link-Data-Rate 46666-BPS 41 VALUE Final-Tx-Link-Data-Rate 48000-BPS 42 VALUE Final-Tx-Link-Data-Rate 49333-BPS 43 VALUE Final-Tx-Link-Data-Rate 50666-BPS 44 VALUE Final-Tx-Link-Data-Rate 52000-BPS 45 VALUE Final-Tx-Link-Data-Rate 53333-BPS 46 VALUE Final-Tx-Link-Data-Rate 54666-BPS 47 VALUE Final-Tx-Link-Data-Rate 56000-BPS 48 VALUE Final-Tx-Link-Data-Rate 57333-BPS 49 VALUE Final-Tx-Link-Data-Rate 58666-BPS 50 VALUE Final-Tx-Link-Data-Rate 60000-BPS 51 VALUE Final-Tx-Link-Data-Rate 61333-BPS 52 VALUE Final-Tx-Link-Data-Rate 62666-BPS 53 VALUE Final-Tx-Link-Data-Rate 64000-BPS 54 VALUE Sync-Async-Mode Asynchronous 1 VALUE Sync-Async-Mode Synchronous 2 VALUE Originate-Answer-Mode Originate-in-Originate-Mode 1 VALUE Originate-Answer-Mode Originate-in-Answer-Mode 2 VALUE Originate-Answer-Mode Answer-in-Originate-Mode 3 VALUE Originate-Answer-Mode Answer-in-Answer-Mode 4 VALUE Modulation-Type usRoboticsHST 1 VALUE Modulation-Type ccittV32 2 VALUE Modulation-Type ccittV22bis 3 VALUE Modulation-Type bell103 4 VALUE Modulation-Type ccittV21 5 VALUE Modulation-Type bell212 6 VALUE Modulation-Type ccittV32bis 7 VALUE Modulation-Type ccittV23 8 VALUE Modulation-Type negotiationFailed 9 VALUE Modulation-Type bell208b 10 VALUE Modulation-Type v21FaxClass1 11 VALUE Modulation-Type v27FaxClass1 12 VALUE Modulation-Type v29FaxClass1 13 VALUE Modulation-Type v17FaxClass1 14 VALUE Modulation-Type v21FaxClass2 15 VALUE Modulation-Type v27FaxClass2 16 VALUE Modulation-Type v29FaxClass2 17 VALUE Modulation-Type v17FaxClass2 18 VALUE Modulation-Type v32Terbo 19 VALUE Modulation-Type v34 20 VALUE Modulation-Type vFC 21 VALUE Modulation-Type v34plus 22 VALUE Modulation-Type x2 23 VALUE Modulation-Type v110 24 VALUE Modulation-Type v120 25 VALUE Modulation-Type x75 26 VALUE Modulation-Type ayncSyncPPP 27 VALUE Modulation-Type clearChannel 28 VALUE Modulation-Type x2client 29 VALUE Modulation-Type x2symmetric 30 VALUE Modulation-Type piafs 31 VALUE Modulation-Type v90Analogue 33 VALUE Modulation-Type v90Digital 34 VALUE Modulation-Type v90AllDigital 35 VALUE Initial-Modulation-Type usRoboticsHST 1 VALUE Initial-Modulation-Type ccittV32 2 VALUE Initial-Modulation-Type ccittV22bis 3 VALUE Initial-Modulation-Type bell103 4 VALUE Initial-Modulation-Type ccittV21 5 VALUE Initial-Modulation-Type bell212 6 VALUE Initial-Modulation-Type ccittV32bis 7 VALUE Initial-Modulation-Type ccittV23 8 VALUE Initial-Modulation-Type negotiationFailed 9 VALUE Initial-Modulation-Type bell208b 10 VALUE Initial-Modulation-Type v21FaxClass1 11 VALUE Initial-Modulation-Type v27FaxClass1 12 VALUE Initial-Modulation-Type v29FaxClass1 13 VALUE Initial-Modulation-Type v17FaxClass1 14 VALUE Initial-Modulation-Type v21FaxClass2 15 VALUE Initial-Modulation-Type v27FaxClass2 16 VALUE Initial-Modulation-Type v29FaxClass2 17 VALUE Initial-Modulation-Type v17FaxClass2 18 VALUE Initial-Modulation-Type v32Terbo 19 VALUE Initial-Modulation-Type v34 20 VALUE Initial-Modulation-Type vFC 21 VALUE Initial-Modulation-Type v34plus 22 VALUE Initial-Modulation-Type x2 23 VALUE Initial-Modulation-Type v110 24 VALUE Initial-Modulation-Type v120 25 VALUE Initial-Modulation-Type x75 26 VALUE Initial-Modulation-Type ayncSyncPPP 27 VALUE Initial-Modulation-Type clearChannel 28 VALUE Initial-Modulation-Type x2client 29 VALUE Initial-Modulation-Type x2symmetric 30 VALUE Initial-Modulation-Type piafs 31 VALUE Initial-Modulation-Type v90Analogue 33 VALUE Initial-Modulation-Type v90Digital 34 VALUE Initial-Modulation-Type v90AllDigital 35 VALUE Connect-Term-Reason dtrDrop 1 VALUE Connect-Term-Reason escapeSequence 2 VALUE Connect-Term-Reason athCommand 3 VALUE Connect-Term-Reason carrierLoss 4 VALUE Connect-Term-Reason inactivityTimout 5 VALUE Connect-Term-Reason mnpIncompatible 6 VALUE Connect-Term-Reason undefined 7 VALUE Connect-Term-Reason remotePassword 8 VALUE Connect-Term-Reason linkPassword 9 VALUE Connect-Term-Reason retransmitLimit 10 VALUE Connect-Term-Reason linkDisconnectMsgReceived 11 VALUE Connect-Term-Reason noLoopCurrent 12 VALUE Connect-Term-Reason invalidSpeed 13 VALUE Connect-Term-Reason unableToRetrain 14 VALUE Connect-Term-Reason managementCommand 15 VALUE Connect-Term-Reason noDialTone 16 VALUE Connect-Term-Reason keyAbort 17 VALUE Connect-Term-Reason lineBusy 18 VALUE Connect-Term-Reason noAnswer 19 VALUE Connect-Term-Reason voice 20 VALUE Connect-Term-Reason noAnswerTone 21 VALUE Connect-Term-Reason noCarrier 22 VALUE Connect-Term-Reason undetermined 23 VALUE Connect-Term-Reason v42SabmeTimeout 24 VALUE Connect-Term-Reason v42BreakTimeout 25 VALUE Connect-Term-Reason v42DisconnectCmd 26 VALUE Connect-Term-Reason v42IdExchangeFail 27 VALUE Connect-Term-Reason v42BadSetup 28 VALUE Connect-Term-Reason v42InvalidCodeWord 29 VALUE Connect-Term-Reason v42StringToLong 30 VALUE Connect-Term-Reason v42InvalidCommand 31 VALUE Connect-Term-Reason none 32 VALUE Connect-Term-Reason v32Cleardown 33 VALUE Connect-Term-Reason dialSecurity 34 VALUE Connect-Term-Reason remoteAccessDenied 35 VALUE Connect-Term-Reason loopLoss 36 VALUE Connect-Term-Reason ds0Teardown 37 VALUE Connect-Term-Reason promptNotEnabled 38 VALUE Connect-Term-Reason noPromptingInSync 39 VALUE Connect-Term-Reason nonArqMode 40 VALUE Connect-Term-Reason modeIncompatible 41 VALUE Connect-Term-Reason noPromptInNonARQ 42 VALUE Connect-Term-Reason dialBackLink 43 VALUE Connect-Term-Reason linkAbort 44 VALUE Connect-Term-Reason autopassFailed 45 VALUE Connect-Term-Reason pbGenericError 46 VALUE Connect-Term-Reason pbLinkErrTxPreAck 47 VALUE Connect-Term-Reason pbLinkErrTxTardyACK 48 VALUE Connect-Term-Reason pbTransmitBusTimeout 49 VALUE Connect-Term-Reason pbReceiveBusTimeout 50 VALUE Connect-Term-Reason pbLinkErrTxTAL 51 VALUE Connect-Term-Reason pbLinkErrRxTAL 52 VALUE Connect-Term-Reason pbTransmitMasterTimeout 53 VALUE Connect-Term-Reason pbClockMissing 54 VALUE Connect-Term-Reason pbReceivedLsWhileLinkUp 55 VALUE Connect-Term-Reason pbOutOfSequenceFrame 56 VALUE Connect-Term-Reason pbBadFrame 57 VALUE Connect-Term-Reason pbAckWaitTimeout 58 VALUE Connect-Term-Reason pbReceivedAckSeqErr 59 VALUE Connect-Term-Reason pbReceiveOvrflwRNRFail 60 VALUE Connect-Term-Reason pbReceiveMsgBufOvrflw 61 VALUE Connect-Term-Reason rcvdGatewayDiscCmd 62 VALUE Connect-Term-Reason tokenPassingTimeout 63 VALUE Connect-Term-Reason dspInterruptTimeout 64 VALUE Connect-Term-Reason mnpProtocolViolation 65 VALUE Connect-Term-Reason class2FaxHangupCmd 66 VALUE Connect-Term-Reason hstSpeedSwitchTimeout 67 VALUE Connect-Term-Reason tooManyUnacked 68 VALUE Connect-Term-Reason timerExpired 69 VALUE Connect-Term-Reason t1Glare 70 VALUE Connect-Term-Reason priDialoutRqTimeout 71 VALUE Connect-Term-Reason abortAnlgDstOvrIsdn 72 VALUE Connect-Term-Reason normalUserCallClear 73 VALUE Connect-Term-Reason normalUnspecified 74 VALUE Connect-Term-Reason bearerIncompatibility 75 VALUE Connect-Term-Reason protocolErrorEvent 76 VALUE Connect-Term-Reason abnormalDisconnect 77 VALUE Connect-Term-Reason invalidCauseValue 78 VALUE Failure-to-Connect-Reason dtrDrop 1 VALUE Failure-to-Connect-Reason escapeSequence 2 VALUE Failure-to-Connect-Reason athCommand 3 VALUE Failure-to-Connect-Reason carrierLoss 4 VALUE Failure-to-Connect-Reason inactivityTimout 5 VALUE Failure-to-Connect-Reason mnpIncompatible 6 VALUE Failure-to-Connect-Reason undefined 7 VALUE Failure-to-Connect-Reason remotePassword 8 VALUE Failure-to-Connect-Reason linkPassword 9 VALUE Failure-to-Connect-Reason retransmitLimit 10 VALUE Failure-to-Connect-Reason linkDisconnectMsgRec 11 VALUE Failure-to-Connect-Reason noLoopCurrent 12 VALUE Failure-to-Connect-Reason invalidSpeed 13 VALUE Failure-to-Connect-Reason unableToRetrain 14 VALUE Failure-to-Connect-Reason managementCommand 15 VALUE Failure-to-Connect-Reason noDialTone 16 VALUE Failure-to-Connect-Reason keyAbort 17 VALUE Failure-to-Connect-Reason lineBusy 18 VALUE Failure-to-Connect-Reason noAnswer 19 VALUE Failure-to-Connect-Reason voice 20 VALUE Failure-to-Connect-Reason noAnswerTone 21 VALUE Failure-to-Connect-Reason noCarrier 22 VALUE Failure-to-Connect-Reason undetermined 23 VALUE Failure-to-Connect-Reason v42SabmeTimeout 24 VALUE Failure-to-Connect-Reason v42BreakTimeout 25 VALUE Failure-to-Connect-Reason v42DisconnectCmd 26 VALUE Failure-to-Connect-Reason v42IdExchangeFail 27 VALUE Failure-to-Connect-Reason v42BadSetup 28 VALUE Failure-to-Connect-Reason v42InvalidCodeWord 29 VALUE Failure-to-Connect-Reason v42StringToLong 30 VALUE Failure-to-Connect-Reason v42InvalidCommand 31 VALUE Failure-to-Connect-Reason none 32 VALUE Failure-to-Connect-Reason v32Cleardown 33 VALUE Failure-to-Connect-Reason dialSecurity 34 VALUE Failure-to-Connect-Reason remoteAccessDenied 35 VALUE Failure-to-Connect-Reason loopLoss 36 VALUE Failure-to-Connect-Reason ds0Teardown 37 VALUE Failure-to-Connect-Reason promptNotEnabled 38 VALUE Failure-to-Connect-Reason noPromptingInSync 39 VALUE Failure-to-Connect-Reason nonArqMode 40 VALUE Failure-to-Connect-Reason modeIncompatible 41 VALUE Failure-to-Connect-Reason noPromptInNonARQ 42 VALUE Failure-to-Connect-Reason dialBackLink 43 VALUE Failure-to-Connect-Reason linkAbort 44 VALUE Failure-to-Connect-Reason autopassFailed 45 VALUE Failure-to-Connect-Reason pbGenericError 46 VALUE Failure-to-Connect-Reason pbLinkErrTxPreAck 47 VALUE Failure-to-Connect-Reason pbLinkErrTxTardyACK 48 VALUE Failure-to-Connect-Reason pbTransmitBusTimeout 49 VALUE Failure-to-Connect-Reason pbReceiveBusTimeout 50 VALUE Failure-to-Connect-Reason pbLinkErrTxTAL 51 VALUE Failure-to-Connect-Reason pbLinkErrRxTAL 52 VALUE Failure-to-Connect-Reason pbTransmitMasterTimeout 53 VALUE Failure-to-Connect-Reason pbClockMissing 54 VALUE Failure-to-Connect-Reason pbReceivedLsWhileLinkUp 55 VALUE Failure-to-Connect-Reason pbOutOfSequenceFrame 56 VALUE Failure-to-Connect-Reason pbBadFrame 57 VALUE Failure-to-Connect-Reason pbAckWaitTimeout 58 VALUE Failure-to-Connect-Reason pbReceivedAckSeqErr 59 VALUE Failure-to-Connect-Reason pbReceiveOvrflwRNRFail 60 VALUE Failure-to-Connect-Reason pbReceiveMsgBufOvrflw 61 VALUE Failure-to-Connect-Reason rcvdGatewayDiscCmd 62 VALUE Failure-to-Connect-Reason tokenPassingTimeout 63 VALUE Failure-to-Connect-Reason dspInterruptTimeout 64 VALUE Failure-to-Connect-Reason mnpProtocolViolation 65 VALUE Failure-to-Connect-Reason class2FaxHangupCmd 66 VALUE Failure-to-Connect-Reason hstSpeedSwitchTimeout 67 VALUE Failure-to-Connect-Reason tooManyUnacked 68 VALUE Failure-to-Connect-Reason timerExpired 69 VALUE Failure-to-Connect-Reason t1Glare 70 VALUE Failure-to-Connect-Reason priDialoutRqTimeout 71 VALUE Failure-to-Connect-Reason abortAnlgDstOvrIsdn 72 VALUE Failure-to-Connect-Reason normalUserCallClear 73 VALUE Failure-to-Connect-Reason normalUnspecified 74 VALUE Failure-to-Connect-Reason bearerIncompatibility 75 VALUE Failure-to-Connect-Reason protocolErrorEvent 76 VALUE Failure-to-Connect-Reason abnormalDisconnect 77 VALUE Failure-to-Connect-Reason invalidCauseValue 78 VALUE Simplified-MNP-Levels none 1 VALUE Simplified-MNP-Levels mnpLevel3 2 VALUE Simplified-MNP-Levels mnpLevel4 3 VALUE Simplified-MNP-Levels ccittV42 4 VALUE Simplified-MNP-Levels usRoboticsHST 5 VALUE Simplified-MNP-Levels synchronousNone 6 VALUE Simplified-MNP-Levels mnpLevel2 7 VALUE Simplified-MNP-Levels mnp10 8 VALUE Simplified-MNP-Levels v42Etc 9 VALUE Simplified-MNP-Levels mnp10Ec 10 VALUE Simplified-MNP-Levels lapmEc 11 VALUE Simplified-MNP-Levels v42Etc2 12 VALUE Simplified-MNP-Levels ccittV42SREJ 13 VALUE Simplified-MNP-Levels piafs 14 VALUE Simplified-V42bis-Usage none 1 VALUE Simplified-V42bis-Usage ccittV42bis 2 VALUE Simplified-V42bis-Usage mnpLevel5 3 VALUE Equalization-Type Long 1 VALUE Equalization-Type Short 2 VALUE Fallback-Enabled Disabled 1 VALUE Fallback-Enabled Enabled 2 VALUE Back-Channel-Data-Rate 450BPS 1 VALUE Back-Channel-Data-Rate 300BPS 2 VALUE Back-Channel-Data-Rate None 3 VALUE Device-Connected-To None 1 VALUE Device-Connected-To isdnGateway 2 VALUE Device-Connected-To quadModem 3 VALUE Call-Event-Code notSupported 1 VALUE Call-Event-Code setup 2 VALUE Call-Event-Code usrSetup 3 VALUE Call-Event-Code telcoDisconnect 4 VALUE Call-Event-Code usrDisconnect 5 VALUE Call-Event-Code noFreeModem 6 VALUE Call-Event-Code modemsNotAllowed 7 VALUE Call-Event-Code modemsRejectCall 8 VALUE Call-Event-Code modemSetupTimeout 9 VALUE Call-Event-Code noFreeIGW 10 VALUE Call-Event-Code igwRejectCall 11 VALUE Call-Event-Code igwSetupTimeout 12 VALUE Call-Event-Code noFreeTdmts 13 VALUE Call-Event-Code bcReject 14 VALUE Call-Event-Code ieReject 15 VALUE Call-Event-Code chidReject 16 VALUE Call-Event-Code progReject 17 VALUE Call-Event-Code callingPartyReject 18 VALUE Call-Event-Code calledPartyReject 19 VALUE Call-Event-Code blocked 20 VALUE Call-Event-Code analogBlocked 21 VALUE Call-Event-Code digitalBlocked 22 VALUE Call-Event-Code outOfService 23 VALUE Call-Event-Code busy 24 VALUE Call-Event-Code congestion 25 VALUE Call-Event-Code protocolError 26 VALUE Call-Event-Code noFreeBchannel 27 VALUE Call-Event-Code inOutCallCollision 28 VALUE Call-Event-Code inCallArrival 29 VALUE Call-Event-Code outCallArrival 30 VALUE Call-Event-Code inCallConnect 31 VALUE Call-Event-Code outCallConnect 32 VALUE RMMIE-Status notEnabledInLocalModem 1 VALUE RMMIE-Status notDetectedInRemoteModem 2 VALUE RMMIE-Status ok 3 VALUE RMMIE-x2-Status notOperational 1 VALUE RMMIE-x2-Status operational 2 VALUE RMMIE-x2-Status x2Disabled 3 VALUE RMMIE-x2-Status v8Disabled 4 VALUE RMMIE-x2-Status remote3200Disabled 5 VALUE RMMIE-x2-Status invalidSpeedSetting 6 VALUE RMMIE-x2-Status v8NotDetected 7 VALUE RMMIE-x2-Status x2NotDetected 8 VALUE RMMIE-x2-Status incompatibleVersion 9 VALUE RMMIE-x2-Status incompatibleModes 10 VALUE RMMIE-x2-Status local3200Disabled 11 VALUE RMMIE-x2-Status excessHighFrequencyAtten 12 VALUE RMMIE-x2-Status connectNotSupport3200 13 VALUE RMMIE-x2-Status retrainBeforeConnection 14 VALUE RMMIE-Planned-Disconnect none 1 VALUE RMMIE-Planned-Disconnect dteNotReady 2 VALUE RMMIE-Planned-Disconnect dteInterfaceError 3 VALUE RMMIE-Planned-Disconnect dteRequest 4 VALUE RMMIE-Planned-Disconnect escapeToOnlineCommandMode 5 VALUE RMMIE-Planned-Disconnect athCommand 6 VALUE RMMIE-Planned-Disconnect inactivityTimeout 7 VALUE RMMIE-Planned-Disconnect arqProtocolError 8 VALUE RMMIE-Planned-Disconnect arqProtocolRetransmitLim 9 VALUE RMMIE-Planned-Disconnect invalidComprDataCodeword 10 VALUE RMMIE-Planned-Disconnect invalidComprDataStringLen 11 VALUE RMMIE-Planned-Disconnect invalidComprDataCommand 12 VALUE RMMIE-Last-Update-Event none 1 VALUE RMMIE-Last-Update-Event initialConnection 2 VALUE RMMIE-Last-Update-Event retrain 3 VALUE RMMIE-Last-Update-Event speedShift 4 VALUE RMMIE-Last-Update-Event plannedDisconnect 5 VALUE Request-Type Access-Request 1 VALUE Request-Type Access-Accept 2 VALUE Request-Type Access-Reject 3 VALUE Request-Type Accounting-Request 4 VALUE Request-Type Accounting-Response 5 VALUE Request-Type Access-Password-Change 7 VALUE Request-Type Access-Password-Ack 8 VALUE Request-Type Access-Password-Reject 9 VALUE Request-Type Access-Challenge 11 VALUE Request-Type Status-Server 12 VALUE Request-Type Status-Client 13 VALUE Request-Type Resource-Free-Request 21 VALUE Request-Type Resource-Free-Response 22 VALUE Request-Type Resource-Query-Request 23 VALUE Request-Type Resource-Query-Response 24 VALUE Request-Type Disconnect-User 25 VALUE Request-Type NAS-Reboot-Request 26 VALUE Request-Type NAS-Reboot-Response 27 VALUE Request-Type Tacacs-Message 253 VALUE Request-Type Reserved 255 VALUE Req-Db-Mdm-Sel No 0 VALUE Req-Db-Mdm-Sel Yes 1 VALUE Req-Db-Login-Valid No 0 VALUE Req-Db-Login-Valid Yes 1 VALUE Dial-In-Sec-Mode Pass-Through 0 VALUE Dial-In-Sec-Mode Dialback-Entered 1 VALUE Dial-In-Sec-Mode Dialback-Stored 2 VALUE NAS-Port-Type Async 0 VALUE NAS-Port-Type Sync 1 VALUE NAS-Port-Type ISDN-Sync 2 VALUE NAS-Port-Type ISDN-Async-V-120 3 VALUE NAS-Port-Type ISDN-Async-V-110 4 VALUE NAS-Port-Type Virtual 5 VALUE NAS-Port-Type PIAFS 6 VALUE NAS-Port-Type HDLC-Clear-Channel 7 VALUE NAS-Port-Type X.25 8 VALUE NAS-Port-Type X.75 9 VALUE Prompt No-Echo 0 VALUE Prompt Echo 1 VALUE ARAP-Zone-Access default-zone-only 1 VALUE ARAP-Zone-Access zone-filter-inclusive 2 VALUE ARAP-Zone-Access zone-filter-exclusive 4 VALUE PW-Framed-Routing-V2 Off 0 VALUE PW-Framed-Routing-V2 On 1 VALUE Syslog-Tap Off 0 VALUE Syslog-Tap Raw 1 VALUE Syslog-Tap Framed 2 VALUE Speed-Of-Connection Auto 0 VALUE Speed-Of-Connection 56 1 VALUE Speed-Of-Connection 64 2 VALUE Speed-Of-Connection Voice 3 VALUE Expansion-Algorithm Constant 1 VALUE Expansion-Algorithm Linear 2 VALUE Compression-Algorithm None 0 VALUE Compression-Algorithm Stac 1 VALUE Compression-Algorithm Ascend 2 VALUE Compression-Algorithm Microsoft 3 VALUE Compression-Algorithm Auto 4 VALUE Compression-Reset-Mode Auto 0 VALUE Compression-Reset-Mode Reset-Every-Packet 1 VALUE Compression-Reset-Mode Reset-On-Error 2 VALUE Filter-Zones enabled 1 VALUE Filter-Zones disabled 2 VALUE Bridging enabled 1 VALUE Bridging disabled 2 VALUE Appletalk enabled 1 VALUE Appletalk disabled 2 VALUE Spoofing enabled 1 VALUE Spoofing disabled 2 VALUE Routing-Protocol Rip1 1 VALUE Routing-Protocol Rip2 2 VALUE IPX-Routing none 0 VALUE IPX-Routing send 1 VALUE IPX-Routing listen 2 VALUE IPX-Routing respond 3 VALUE IPX-Routing all 4 VALUE IPX-WAN enabled 1 VALUE IPX-WAN disabled 2 VALUE IP-Default-Route-Option enabled 1 VALUE IP-Default-Route-Option disabled 2 VALUE IP-RIP-Policies SendDefault 0x0 VALUE IP-RIP-Policies SendRoutes 0x2 VALUE IP-RIP-Policies SendSubnets 0x4 VALUE IP-RIP-Policies AcceptDefault 0x8 VALUE IP-RIP-Policies SplitHorizon 0x10 VALUE IP-RIP-Policies PoisonReserve 0x20 VALUE IP-RIP-Policies FlashUpdate 0x40 VALUE IP-RIP-Policies SimpleAuth 0x80 VALUE IP-RIP-Policies V1Send 0x100 VALUE IP-RIP-Policies V1Receive 0x200 VALUE IP-RIP-Policies V2Receive 0x400 VALUE IP-RIP-Policies Silent 0x80000000 VALUE USR-Callback-Type Normal 1 VALUE USR-Callback-Type ANI 2 VALUE USR-Callback-Type Static 3 VALUE USR-Callback-Type Dynamic 4

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ricky Beam |Sent: Thursday, September 24, 1998 4:28 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) Merit RADIUS entries for USR equipment | | |Brian Elfert was heard to say: |>On Thu, 24 Sep 1998, Ricky Beam wrote: |>> >Same here - Can someone please just post the 3Com RADIUS dictionary? |>> |>> Legally, we cannot as it's part of their RADIUS server package. Bug krish |>> and see if you can get him to dump one out. (It's 17 pages, BTW.) |> |>Geez, how many attributes do they have? My Livingston Radius dictionary |>file is maybe 4 pages long. |> |>Does all this extra stuff allow you to log connect speeds and such from a |>Total Control rack? | |The fact that USR has 16bit vendor attribute numbers should be an indicator. |The dictionary contains more than just the actual attributes. | |I don't see why USR has not made this information (as well as SNMP MIBs) |available. FWIW, the pdf docs for the HARC have the attributes listed. We release the MIBS, they are attached to TCM and the HIPER code comes with them. As for the VSA's, they are all in the dictionary supplied with S&A and if you look at my raddebug tool, I have most of them in the dictionary I supply with that. -M

Dear TC users, we have TC modem racks with PRI interface and quad modems, but no netserver and no NMC in them. Our clients need to connect to devices hooked up on the RS-232 ports of the quad modems ... Now we need ISDN end-to-end connection, main reason is faster call setup than analog. However, I have not found out how to set up this. I have already set the ISDN GW slot to NONE (in the PRI config menu). The debug info says something like "no ISDN GW, trying q-mdm", and then "no q-mdm available". From the capabilities of the quad modems (ATI7), they support several methods of digital connections (V.110, V.120, PPP ...) SW release is 5.9.6, the chassis is less than 1 year old. What am I missing ? TIA & best regards, Walter

> > Once upon a time Ricky Beam shaped the electrons to say... > >Legally, we cannot as it's part of their RADIUS server package. Bug krish > >and see if you can get him to dump one out. (It's 17 pages, BTW.) > > Ok... > > Krish, can you share the dictionary file? I mean, it is just a dictionary - > we're not asking for a free server or source code or something. > > Anyone want to send it to me on the grey market? I promise to immediately > strip all mention of you from the file when I save it. > > This is just so stupid - I can go to Lucent or Ascend and grab their > dictionaries openly. > I do not have a merit radius dictionary file. I do however have a dictionary for livingston which you can download ( with radius source that supports vsa ) from ftp://interproc.ae.usr.com/pub you can get both the dictionary and the radius source. I will try to get merit and as soon as I get it I will update the dictionary and let you know regards krish > -MZ > -- > <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. > Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> > "A little nonsense now and then, is relished by the wisest men" 781-788-0130 > <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia! > ==================================================================== > ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. > Three days of clues, news, and views from the industry's best and > brightest. http://www.ispf.com/ for information and registration. > ==================================================================== > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 Elfert was heard to say: >On Thu, 24 Sep 1998, Ricky Beam wrote: >> >Same here - Can someone please just post the 3Com RADIUS dictionary? >> >> Legally, we cannot as it's part of their RADIUS server package. Bug krish >> and see if you can get him to dump one out. (It's 17 pages, BTW.) > >Geez, how many attributes do they have? My Livingston Radius dictionary >file is maybe 4 pages long. > >Does all this extra stuff allow you to log connect speeds and such from a >Total Control rack? The fact that USR has 16bit vendor attribute numbers should be an indicator. The dictionary contains more than just the actual attributes. I don't see why USR has not made this information (as well as SNMP MIBs) available. FWIW, the pdf docs for the HARC have the attributes listed. --Ricky

MegaZone was heard to say: >There were, of course, the Cisoc AS51 blades that turned a TC into a >Cisco AS5100 - they ran IOS. They _run_ IOS. You can still find those things around... >The Hiper ARC has a new OS, which I like to call HiperOS, but I forget if >that's correct or not. Development codenamed Pilgrim... --Ricky

Regards from the other side of the fence :-), Out of sheer curiosity, I would like to know if there is any netserver card that runs anything other than the USR ComOS "hw customized" version (I think the nickname for this other sw would be Pilgrim OS, right ?) And, as a double check, the Netserver "nextgen" is the Hiper ARC, right ? [], <O-O> Julio Arruda Bay Networks - Where Information Flows

Mike Wronski was heard to say: >|I don't see why USR has not made this information (as well as SNMP MIBs) >|available. FWIW, the pdf docs for the HARC have the attributes listed. > >We release the MIBS, they are attached to TCM and the HIPER code comes with them. >As for the VSA's, they are all in the dictionary supplied with S&A and if you >look at my raddebug tool, I have most of them in the dictionary I supply with >that. If you don't have a software support contract (at min.) then you cannot download either TCM or the HIPER code. And the HIPER code is the only code that ships with MIBs. There are some older mibs on totalservice that are available to the public, but all the new stuff is restricted. And the dictionary within SA is part of the server package -- which one my purchase. Restricting code is one thing, but restricting documentation is just wrong. --Ricky

Has anyone... ANYWHERE... Got Merit 3.6B to work with BSDI v3.1 and USR Netserver/HiperArc? We have it compiled; it works when we test it, but when put online it FAILS to authenticate the users??? We are lost on this one. No indications in the debug output that shows a reason or source of failure! Really need someone to help us on this one. Our current radius solution (Livingston1.16) just doesn't give us all the info we require about our connections! Please email privately! THANKS! ============================================================================== 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 ==============================================================================

MegaZone <megazone@megazone.org> writes: > Ok - if this is Pilgrim, what is the code on the NetServer MP units called - > the stuff that replaced ComOS? It's all "Pilgrim", at least as far as internally goes. I don't know if there has ever been an external "name" for the OS and/or if it differs between the platforms. The MP platform was the first to use the pilgrim core code (actually I think it was even in the /8 or /16 first), with the Hiper ARC being the next. "Pilgrim" was/is a core (kernel) system which is then augmented with appropriate drivers for the hardware involved and communication (e.g., packet bus and stuff in the TC) mechanisms for a given product. For what it's worth, that same core was also part of the short-lived LanLinker product, as can be evidenced by the simularity in command interface. I don't actually know how much code remains shared and common among these platforms, but in theory it could still be all kept in a single development tree with conditional compilation per platform. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

At 02:27 PM 9/24/98 -0700, MegaZone wrote... >Once upon a time Julio Arruda shaped the electrons to say... >> Out of sheer curiosity, I would like to know if there is any >> netserver card that runs anything other than the USR ComOS "hw >> customized" version (I think the nickname for this other sw would be >> Pilgrim OS, right ?) > >The NetServer TC runs a modified version of Lucent ComOS. That is all. >The NetServer MP units are ComOS up to 3.x, and a new OS 4.x+ - I believe >that is "Pilgrim". > Sooooo, the Netserver Card that goes into a Total Control chassis is ComOS "ported". The Hiper ARC that can replace the netserver card in a TC chassis, runs HiperOS (maybe it was the Pilgrim OS). The Netserver stand-alone units (the ones you called MP, right), can run today a 3Com OS (another Pilgrim OS). It seems also that versions >= 4.x are Pilgrim OS (a rose, by any other name), and version >= 3 AND < 4 is ComOS family, in any box, right ? [], <O-O> Julio Arruda Bay Networks - Where Information Flows

On Thu, 24 Sep 1998, David Bolen wrote: > MegaZone <megazone@megazone.org> writes: > > > Ok - if this is Pilgrim, what is the code on the NetServer MP units called - > > the stuff that replaced ComOS? > > It's all "Pilgrim", at least as far as internally goes. I don't know > if there has ever been an external "name" for the OS and/or if it > differs between the platforms. > > The MP platform was the first to use the pilgrim core code (actually I > think it was even in the /8 or /16 first), with the Hiper ARC being > the next. "Pilgrim" was/is a core (kernel) system which is then > augmented with appropriate drivers for the hardware involved and > communication (e.g., packet bus and stuff in the TC) mechanisms for a > given product. > > For what it's worth, that same core was also part of the short-lived > LanLinker product, as can be evidenced by the simularity in command > interface. > > I don't actually know how much code remains shared and common among > these platforms, but in theory it could still be all kept in a single > development tree with conditional compilation per platform. The one USR Viper DSP I saw was also running Pilgrim -- I assume it was the i386 version instead of the PPC version. Which begs the question (again) of why Pilgrim can't be ported to the Netserver card in the TC... Mike Andrews (MA12) icq 6602506 -------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "If Barbie is so popular, why do you have to buy her friends?..."

Mike Andrews <mandrews@termfrost.org> writes: > Which begs the question (again) of why Pilgrim can't be ported to the > Netserver card in the TC... It's probably fair to say it has nothing to do with technical issues. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

And the LanLinker boxes (discontinued?) appear to be "Pilgrim" based as well... Charles On Thu, 24 Sep 1998, Julio Arruda wrote: > Date: Thu, 24 Sep 1998 19:02:18 -0300 > From: Julio Arruda <Julio_Arruda@BayNetworks.COM> > Reply-To: usr-tc@lists.xmission.com > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Netserver OS > > At 02:27 PM 9/24/98 -0700, MegaZone wrote... > >Once upon a time Julio Arruda shaped the electrons to say... > >> Out of sheer curiosity, I would like to know if there is any > >> netserver card that runs anything other than the USR ComOS "hw > >> customized" version (I think the nickname for this other sw would be > >> Pilgrim OS, right ?) > > > >The NetServer TC runs a modified version of Lucent ComOS. That is all. > >The NetServer MP units are ComOS up to 3.x, and a new OS 4.x+ - I believe > >that is "Pilgrim". > > > > Sooooo, the Netserver Card that goes into a Total Control chassis is ComOS "ported". > > The Hiper ARC that can replace the netserver card in a TC chassis, runs HiperOS (maybe it was the Pilgrim OS). > > The Netserver stand-alone units (the ones you called MP, right), can run today a 3Com OS (another Pilgrim OS). > > It seems also that versions >= 4.x are Pilgrim OS (a rose, by any other name), and > version >= 3 AND < 4 is ComOS family, in any box, right ? > > [], <O-O> > Julio Arruda > > Bay Networks - Where Information Flows > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

Does anybody knows how to recover from a password lost on a HiperARC ?. I could not find it in the documentation. Regards Jose De Abreu Venezuela & Caribbean NC

Jose_Luis_De_Abreu@3com.com was heard to say: > >Does anybody knows how to recover from a password lost on a HiperARC ?. > >I could not find it in the documentation. Yes... 1) erase configuration 2) setup a management user in RADIUS 3) reset password via SNMP (HARM 1.1.8 will not touch a manage user) 4) guess the password --Ricky

If you have access to the box then you can tftp the quicksetup.cfg file and view it. this will contain the username and passwords. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Thu, 24 Sep 1998 Jose_Luis_De_Abreu@3com.com wrote: > > Does anybody knows how to recover from a password lost on a HiperARC ?. > > I could not find it in the documentation. > > Regards > > Jose De Abreu > Venezuela & Caribbean NC > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Does the arc have a file yet that has the complete config in it? I know about QuickSetup.cfg but that doesnt have your whole comprehensive configuration, does a file exist that contains this information? Or at least a command that will dump this info? Brian Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

On Thu, 24 Sep 1998, Brian wrote: > Does the arc have a file yet that has the complete config in it? I know > about QuickSetup.cfg but that doesnt have your whole comprehensive > configuration, does a file exist that contains this information? Or at > least a command that will dump this info? I doubt it, but you might want to try tftp-ing to it and grabbing everything. I did that on an older version, and was able to glean a little more info about the config. There's some weird stuff in there. The lack of a complete netserver config for backup has got me in the habit of logging my term sessions when I configure these things. script(1) is a cool tool... Charles > > Brian > > > -------------------------------------------------------------------------- > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

On Thu, 24 Sep 1998, Brian wrote: > Does the arc have a file yet that has the complete config in it? I know > about QuickSetup.cfg but that doesnt have your whole comprehensive > configuration, does a file exist that contains this information? Or at > least a command that will dump this info? I doubt it, but you might want to try tftp-ing to it and grabbing everything. I did that on an older version, and was able to glean a little more info about the config. There's some weird stuff in there. The lack of a complete netserver config for backup has got me in the habit of logging my term sessions when I configure these things. script(1) is a cool tool... Charles > > Brian > > > -------------------------------------------------------------------------- > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

Brian was heard to say: >Does the arc have a file yet that has the complete config in it? I know >about QuickSetup.cfg but that doesnt have your whole comprehensive >configuration, does a file exist that contains this information? Or at >least a command that will dump this info? Yes, it's called a bulk configuration file... look in the 4.1.11 documentation. [tty2]dominion:~/[7:02am]:telnet hiperARC Trying 192.168.0.248 Connected to 192.168.0.248 Escape character is '^]'. Interpath Communications, Inc. Hiper Access Router Card :: Engineering Testbed HiperARC login: !root Password: HiperARC>> show bulk_file Bulk Configuration File Name: ConfigBulkFile Bulk Configuration Error: HiperARC>> save configuration SAVE CONFIGURATION Complete HiperARC>> From the bootrom, you can specify a command line arguement: -config ConfigBulkFile --Ricky

Brian was heard to say: >Does the arc have a file yet that has the complete config in it? I know >about QuickSetup.cfg but that doesnt have your whole comprehensive >configuration, does a file exist that contains this information? Or at >least a command that will dump this info? Yes, it's called a bulk configuration file... look in the 4.1.11 documentation. [tty2]dominion:~/[7:02am]:telnet hiperARC Trying 192.168.0.248 Connected to 192.168.0.248 Escape character is '^]'. Interpath Communications, Inc. Hiper Access Router Card :: Engineering Testbed HiperARC login: !root Password: HiperARC>> show bulk_file Bulk Configuration File Name: ConfigBulkFile Bulk Configuration Error: HiperARC>> save configuration SAVE CONFIGURATION Complete HiperARC>> From the bootrom, you can specify a command line arguement: -config ConfigBulkFile --Ricky

On Thu, 24 Sep 1998, Brian wrote: > Does the arc have a file yet that has the complete config in it? I know > about QuickSetup.cfg but that doesnt have your whole comprehensive > configuration, does a file exist that contains this information? Or at > least a command that will dump this info? > > Brian No not at this point of time. However you can save these configurations using HARM. krish > > > -------------------------------------------------------------------------- > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

At 01:34 PM 9/24/98 -0700, you wrote: >I would love the fix, since I haven't upgraded yet and this is one reason >why >-----Original Message----- > >> >>We NOW have a fix available for the Web TV issue. You can call into support >or >>e-mail me directly for the fix. ditto here Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

I've tried several times to put cistron radius to work with HiperARC, but I wasn't able to make it generate accounting logs... Merit radius works fine, but it would be nice if I could put cistron radius to work here. Does anyone know any patch to make it works? (vsa stuff is welcome too...) Regards, Gustavo ______________________________________________________________________ Andre Gustavo de C. Albuquerque gustavo@visualnet.com.br PGP Public Key: http://www.visualnet.com.br/~gustavo/pgpkey.asc

We use Netscape Mail server with Total Control units. Is there anyway to identify a spammer that is online with us at a given time if I have the spam mail that tells me what time of day and IP address? Jack Singer jsinger@i-c.net

> This is not directly related, but can you issue commands directly to the > quad modems without having the NIC for them (i.e. through the netserver)? We have to issue modem commands through the RS-232 ports (i.e. AT...) Regards, Walter x�>"-

> Try setting it to "0" instead of none. Also make sure that the pri card > sees the quad-modems in the rack as quad I modems. Jeff, thank you very much ! Your latter suggestion did the trick, i.e. I had to configure the modems as "i", not as "q" (in the card config menu of the PRI). Btw, NONE seems to be OK for the ISDN-GW (we have indeed none). Best regards, Walter x�>"5

Hello! How one can find the reason of the last HARC reboot, preferably without TCM? Thanks! Yevgeniy Kruglov, email: yk@cifnet.com System Administrator phone: (773)989-0442 CIFNet, Inc. fax: (773)989-8477

On Thu, 24 Sep 1998, MegaZone wrote: > Once upon a time Tatai SV Krishnan shaped the electrons to say... > >I do not have a merit radius dictionary file. I do however have a > >dictionary for livingston which you can download ( with radius source > >that supports vsa ) from > > > >ftp://interproc.ae.usr.com/pub > > > >you can get both the dictionary and the radius source. > > Thanks. > > -MZ You can grab a dictionary and a set of patches for Livingston Radius 2.0.1 to handle USR VSA's from http://www.dcr.net/~mandrews/usrtoys as well. (Now that I have it correctly sending Max_Channels to the ARC...) Mike Andrews (MA12) icq 6602506 -------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "If Barbie is so popular, why do you have to buy her friends?..."

FS: USR Total Control 48 port chassis $6,995 Total Control Hub : 16-slot chassis single 110v ac 70Amp power supply, fan tray, ethernet network management card 12 Quad Digital Modem NAC (48 ports total, 56k v.90) Netserver PRI Dual PRI/T1 - supports analog/ISDN Asking $6,995 for above bundle. All products are used and in excellent condition. Buyer is responsible for shipping. Contact forsale@xmission.com, or call Brian at 801-539-0852, extension 131. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= XMission Internet Access | Save a Tree -- Use Email! 51 E. 400 S, Suite 200 | Salt Lake City, UT 84111 | Hardware & Software Sales: Voice 801.539.0852 | http://www.xmission.com/general/retail.html =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -

FS: USR new HiPer Access Router Card $2,800 USR new HiPer Access Router Card $2,800 http://hiper.3com.com/router_card.html Buyer is responsible for shipping. Contact forsale@xmission.com, or call Brian at 801-539-0852, extension 131. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= XMission Internet Access | Save a Tree -- Use Email! 51 E. 400 S, Suite 200 | Salt Lake City, UT 84111 | Hardware & Software Sales: Voice 801.539.0852 | http://www.xmission.com/general/retail.html =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= t

On Fri, 25 Sep 1998, Jack Singer wrote: > We use Netscape Mail server with Total Control units. Is there anyway to identify a > spammer that is online with us at a given time if I have the spam mail that tells me > what time of day and IP address? Log all RADIUS accounting logs to a database (we use radiator with platypus billing system to do this). Then just query the database with a timestamp and IP and get the username. Brian > > Jack Singer > 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. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

On Fri, 25 Sep 1998, Yevgeniy Kruglov wrote: > Hello! > > How one can find the reason of the last HARC reboot, preferably without TCM? show board crashdump will contain the last of what was going on when it crashed. brian > > Thanks! > > Yevgeniy Kruglov, email: yk@cifnet.com > System Administrator phone: (773)989-0442 > CIFNet, Inc. fax: (773)989-8477 > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

We had one just like that. There has to be a back way into it, but 3com tech support (not usr) will not give that backdoor to you. You have to RMA the product, and they will send you one with default passwords on it. On Fri, 25 Sep 1998, Greg Coffey wrote: > I have a 3Com SS II Switch 1000 and can't remember the login and password > to access it. Is there a backdoor or a way to reset it to a default? I > tried connecting through the serial port on it and still can't get in. > > > > > Thanks, > Greg Coffey, CoffeyNet Voice 307-234-5443 307-234-5446 Fax > ===================================================================== > 142 S. Center St. 3Com v.90 56k $20 in Casper & Douglas > Casper, WY 82601 Local Internet for Casper, Rawlins, Douglas, > http://WWW.COFFEY.COM Wheatland, Pinedale, Lander & Lusk, WY > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

I have a DSP card that has 4 ports that will not answer a call. I have rebooted the HiPer ARC, rebooted the DSP card to no avail....So I switched out the card with a different card, and lo' and behold the problem still exists.. I have also double check my config's and they match all configurations for all the other cards. Could this be a possibly backplane, or something wrong with it's socket?? Any suggestions would be very helpful. ********************************************************* Jason Watkins jwatkins@iland.net I-Land Internet Services http://www.iland.net Support & Network Operations Center *********************************************************

I have a 3Com SS II Switch 1000 and can't remember the login and password to access it. Is there a backdoor or a way to reset it to a default? I tried connecting through the serial port on it and still can't get in. Thanks, Greg Coffey, CoffeyNet Voice 307-234-5443 307-234-5446 Fax ===================================================================== 142 S. Center St. 3Com v.90 56k $20 in Casper & Douglas Casper, WY 82601 Local Internet for Casper, Rawlins, Douglas, http://WWW.COFFEY.COM Wheatland, Pinedale, Lander & Lusk, WY

On Fri, 25 Sep 1998, Jason W wrote: > I have a DSP card that has 4 ports that will not answer a call. I have > rebooted > the HiPer ARC, rebooted the DSP card to no avail....So I switched out the > card > with a different card, and lo' and behold the problem still exists.. I have > also > double check my config's and they match all configurations for all the other > cards. > Could this be a possibly backplane, or something wrong with it's socket?? > Any > suggestions would be very helpful. list interfaces, make sure they are all Up Up Brian > > > ********************************************************* > Jason Watkins jwatkins@iland.net > I-Land Internet Services http://www.iland.net > Support & Network Operations Center > ********************************************************* > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

: I have a DSP card that has 4 ports that will not answer a call. I : have rebooted the HiPer ARC, rebooted the DSP card to no avail....So : I switched out the card with a different card, and lo' and behold the : problem still exists.. I have also double check my config's and they : match all configurations for all the other cards. Could this be a : possibly backplane, or something wrong with it's socket?? Lo, I say unto you, call the telco and report trouble. You'll want to identify precisely which terminals in your hunt group are having trouble (e.g, 9th, 12th, 13th, and 97th).

Here's the setup... One of the users is configured in Radius with a framed address of 209.190.82.127 and a framed netmask of 255.255.255.255. When that users logs into one of three netservers on either 209.190.80 or 209.190.81, the netservers automatically route to him correctly. When that same user dials into the ARC, he can not go anywhere except to the ARC. Anyone have any ideas on this one? 3Com Case #104788. FYI, RIP is turned on at both the local router and the chassis and of course, both ends understand both RIPv1 and RIPv2. When I assign the network interface of the ARC to the same address as it had before but with a /22 netmask, it works except that it will not talk to the 83 class C (which makes sense because it isn't routing 83). If I go back to just a class C, it no longer works any more. Looking at the routing list in the ARC, it does see RIP routes when I have one of the static users log into the lines on the ARC, then call back on one of the sets of lines on the NetServers. Here's my guess: The ARC is not broadcasting the fact that it owns the 82.127 address via RIP, or somehow, that fact is being blocked from making it to the router. I have a feeling that it may be in part because the static IP is not on the same subnet as the ARC. If I had another spare hub/concentrator, I'd be able to test it. I doubt it's the later because of the result when I configure the ARC with a /22 instead of a /24. Now, if only I can prove what the real problem is so I can nail it down toward a solution. Of course, I am no expert on this stuff. I am new enough to ARC's that I can't make definite statements on things like this, but the above is purely a slightly educated guess. We are getting more concentrators in so I will be able to test RIP with a packet sniffer early next week. We're supposed to be going live with this equipment late next week, so hopefully, we'll have it resolved by then. Kevin Benton Network Engineer SOTA Software E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

Kevin Benton was heard to say: > >Here's the setup... > >One of the users is configured in Radius with a framed address of >209.190.82.127 and a framed netmask of 255.255.255.255. When that users >logs into one of three netservers on either 209.190.80 or 209.190.81, the >netservers automatically route to him correctly. When that same user >dials into the ARC, he can not go anywhere except to the ARC. Anyone have >any ideas on this one? 3Com Case #104788. The ARC is not sending the route or what it's sending isn't being processed by the rest of the network. RIPv2 can be sent via multicast. Look in the v4.1.11 documentation -- the 'set ip network <blah> routing_protocol ... rip_policies_update [...]' (pp. 11-261 - 11-263 of the 7/98 docs) >FYI, RIP is turned on at both the local router and the chassis and of >course, both ends understand both RIPv1 and RIPv2. When I assign the See also: "Send Compatibility" -- enabled == broadcast, disabled == multicast. FWIW, my eth:1 ... HiperARC>> show ip network IP-interpath SHOW IP NETWORK IP-interpath SETTINGS: Interface: eth:1 Network Address: 199.72.1.251/C Frame Type: ETHERNET_II Status: ENABLED Reconfigure Needed: FALSE Mask: 255.255.255.0 Station: 199.72.1.251 Broadcast Algorithm: IETF Max Reassembly Size: 3464 IP Routing Protocol: RIPV2 IP Routing Metric: 1 RIP Interface Export Metric: 0 IP RIP Routing Policies: SEND_ROUTES SPLIT_HORIZON FLASH_UPDATE RIPV2_RECEIVE IP RIP Authentication Key: HiperARC>> show ip routing IP ROUTER SETTINGS IP Router Administrative Status: ENABLED IP Static Remote Routes: ENABLED IP LAN Host Address: 199.72.1.251 IP Autonomous System Number 1 IP Max Table Size: 3864 IP Max Metric Entries: 512 IP RIP ENABLED IP Number RIP Interfaces: 1 IP Number RIP Neighbors: 0 IP RIP Flags: METRICS SEND_REQUEST (You will note, I'm sending routes via multicast.) --Ricky

On Fri, 25 Sep 1998, Kevin Benton wrote: > Here's the setup... > > One of the users is configured in Radius with a framed address of > 209.190.82.127 and a framed netmask of 255.255.255.255. When that users > logs into one of three netservers on either 209.190.80 or 209.190.81, the > netservers automatically route to him correctly. When that same user > dials into the ARC, he can not go anywhere except to the ARC. Anyone have > any ideas on this one? 3Com Case #104788. > > FYI, RIP is turned on at both the local router and the chassis and of > course, both ends understand both RIPv1 and RIPv2. When I assign the > network interface of the ARC to the same address as it had before but with > a /22 netmask, it works except that it will not talk to the 83 class C > (which makes sense because it isn't routing 83). If I go back to just a > class C, it no longer works any more. Looking at the routing list in the > ARC, it does see RIP routes when I have one of the static users log into > the lines on the ARC, then call back on one of the sets of lines on the > NetServers. > > Here's my guess: The ARC is not broadcasting the fact that it owns the > 82.127 address via RIP, or somehow, that fact is being blocked from > making it to the router. I have a feeling that it may be in part because > the static IP is not on the same subnet as the ARC. If I had another spare > hub/concentrator, I'd be able to test it. I doubt it's the later because Do you have RIP enabled on the router to talk to the same network the ARC is on? post the IP of the arc, and and your RIP config on your router. > of the result when I configure the ARC with a /22 instead of a /24. Now, > if only I can prove what the real problem is so I can nail it down toward > a solution. Of course, I am no expert on this stuff. I am new enough to > ARC's that I can't make definite statements on things like this, but the > above is purely a slightly educated guess. We are getting more I don't think its much of an arc, problem, we do rip with: disable ip network ip set ip network ip routing_protocol ripv2 set ip network ip rip_policies_update no_ripv1_receive set ip network ip rip_policies_update no_send_compat enable ip network ip on the arc, the arc lies on 208.206.76 network. then on our Cisco, we have: ! router rip version 2 timers basic 30 30 2 60 300 passive-interface Serial0/0.1 passive-interface Serial1/0.1 network 208.206.76.0 no auto-summary ! and all works well. > concentrators in so I will be able to test RIP with a packet sniffer early > next week. We're supposed to be going live with this equipment late next > week, so hopefully, we'll have it resolved by then. To test rip, on any Cisco just do: term monitor debug ip rip > > Kevin Benton > Network Engineer > SOTA Software > > 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. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

You can get some information from syslog. You can also do a show board crash and send it to us and we can find out the reason for the same. regards krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Fri, 25 Sep 1998, Yevgeniy Kruglov wrote: > Hello! > > How one can find the reason of the last HARC reboot, preferably without TCM? > > Thanks! > > Yevgeniy Kruglov, email: yk@cifnet.com > System Administrator phone: (773)989-0442 > CIFNet, Inc. fax: (773)989-8477 > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

You're right Jeff I had forgotten about that. That backdoor that was posted to bugtraq was after we had the problem with our LinkSwitch. We've since switched on to Cisco Catalyst switches. At 11:29 PM 9/25/98 -0400, you wrote: >Thus spake Eric Forcey >>We had one just like that. > >>There has to be a back way into it, but 3com tech support (not usr) will >>not give that backdoor to you. You have to RMA the product, and they will >>send you one with default passwords on it. > >>On Fri, 25 Sep 1998, Greg Coffey wrote: >>> I have a 3Com SS II Switch 1000 and can't remember the login and password >>> to access it. Is there a backdoor or a way to reset it to a default? I >>> tried connecting through the serial port on it and still can't get in. > >Go back into back issues of BUGTRAQ. The "debug" (higher access than >admin apparently) passwords are available in past BUGTRAQ postings >(www.netspace.org for info...should be there somewhere). 3Com got >roasted on this as much for their response to these revelations of >back-doors as to having them there in the first place. :) Check it >out...its almost humourous actually. >-- >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. >

> It works great, however, where do you set the secret on the NMC? > You may directly access NMC NIC consloe port to set the secret. Then in S/A server add NMC client, you will find where to set accordingly secret. The two secret must be same. > Thanks for the info. > > Richard > > > sagarwal@crash.ae.usr.com wrote: > > > > Craig, > > > > If you are tyring to generate the accounting report for the calls on the > > DSP , then you will have to do the following to get a correct report. > > > > 1) Highlight the DSP in TCM and go to Fault --> Trap Settings. Select a > > Template > > eg Template 1.Select Trap Enables. Set the Traps to Enable log for > > Incoming calls, incoming Termination etc. Save the DSP settings to NVRAM. > > You will not have to reset the DSP. Do I need select NMC card and do--save chassis to NVRAM? > > > > 2) Select the Whole DSP Card from TCM ----> Configure ----> Programmed > > Settings ---> Card Level----> Call statistics. Select Group selection as > > group1and2and3and4.Minimum Group 3 is required. > > > > 3) Highlight your NMC --> Logging Group. type in the IP address of your > > Primary Accounting server in "Primary log Server IP Address". Set the Log > > server's UDP port as of the accounting server.Default 1646. Also set the > > Log group selection to group 2345 . Minimum group 3 is required.Save the > > settings to NVRAM and reset your NMC. When the NMC comes back up it will > > display the Event logging Server as Primary. > > > > 4) In the Security and accounting server add NMC as a Client with the same > > UDP port as of NMC.Default 1646. Restart your S/A server. > > > > 5)After this any calls will generate a accounting report. Go to your > > Database manager and select accounting report. In the Chassis/IP field > > select the IP address of the NMC. When you will do a preview Report on > > Call Statistics by day you will see the no of incoming calls. Then you can > > generate the report as you want. > > > > regards > > > > Sanjay Agarwal. > > > > > > > > On Fri, 18 Sep 1998, Craig Holland wrote: > > > > > Could someone help me figure out why I can't use all the built in accounting > > > features of the Accounting Server. Specifically, when I do an accounting > > > report, select a user name, and select "Call statistics by day", it comes > > > back with #Error all over the form. > > > > > > Can anyone help? > > > > > > thanks, > > > craig > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. ________________________________________________ ��ӭ��ʹ�ù����Ӵ���ѵ�������http://www.163.net

Thus spake Eric Forcey >We had one just like that. >There has to be a back way into it, but 3com tech support (not usr) will >not give that backdoor to you. You have to RMA the product, and they will >send you one with default passwords on it. >On Fri, 25 Sep 1998, Greg Coffey wrote: >> I have a 3Com SS II Switch 1000 and can't remember the login and password >> to access it. Is there a backdoor or a way to reset it to a default? I >> tried connecting through the serial port on it and still can't get in. Go back into back issues of BUGTRAQ. The "debug" (higher access than admin apparently) passwords are available in past BUGTRAQ postings (www.netspace.org for info...should be there somewhere). 3Com got roasted on this as much for their response to these revelations of back-doors as to having them there in the first place. :) Check it out...its almost humourous actually. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On one of my HDM's, the 80% led (eighth one up on the bar graph), is not lighting anymore. Has anyone had any of these LED's go out? Is their a fix? Is it possible its not burnt out and can be something else? I did a hardware reset on the card, and it didn't fix it. I was wondering if anyone had any suggestions. Its more of an annoyance than anything else, but nontheless I'd like it to work :) Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Brian was heard to say: >On one of my HDM's, the 80% led (eighth one up on the bar graph), is not >lighting anymore. Has anyone had any of these LED's go out? Is their a >fix? Is it possible its not burnt out and can be something else? > >I did a hardware reset on the card, and it didn't fix it. I was wondering >if anyone had any suggestions. Its more of an annoyance than anything >else, but nontheless I'd like it to work :) Completely out or just one color? (hardware reset will flash all the colors) It's possible that the LED is dead. Of course, the line driver that powers it could also be dead or just a bad connection somewhere. The LED is, of course, not preventing anything working correctly. --Ricky

This was a problem in one version of beta code. Which version of code=20 are you running on the arc? krish =09=09\=09T.S.V. Krishnan \ =09=09 \ Network System Engineer \ ( : - : ) =09=09 \ 3Com ............ \ =09=09----------------------------------------------/ tkrishna@bubba.ae.usr.com =20 ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tk= b.html =09Any Sufficiently advanced bug is indistinguishable for a feature. =09=09=09=09=09=09- Rick Kulawiec On 27 Sep 1998 cntlxh@163.net wrote: > Hi: >=20 > Followed is My question: >=20 > First,I do(I use E1,not T1): >=20 > set interface slot:1/mod:[1-30] filter_access on > show interface slot:1/mod:2 >=20 > I find "filter access" is ON, then I do: >=20 > save all > show interface slot:/mod:2 >=20 > the "filter access" is ON, then I do: >=20 > reboot >=20 > after a while, I do=20 >=20 > sh interface slot:/mod:2 >=20 > the "filter access" is OFF, why? Obviously > after reboot, the configuration have changed. > I need "filter access" is ON always. >=20 >=20 >=20 >=20 >=20 > ________________________________________________ > =BB=B6=D3=AD=C4=FA=CA=B9=D3=C3=B9=E3=D6=DD=CA=D3=B4=B0=C3=E2=B7=D1=B5=E7= =D7=D3=D3=CA=CF=E4http://www.163.net >=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. >=20

We're running a couple of TC's here with some older code on it which does not support the Connect-Info radius attribute (ie, doesn't log connection speeds). I was curious if any of the newer Netserver releases have fixed this problem, or if upgrading would be futile. Thanks in advance... -- Jeff Carneal - Sys Admin - Apex Internet jeff@apex.net http://www.apex.net (502) 442-5363 The opinions expressed above aren't really mine. They belong to someone else who also refuses to take responsibility for them.

Hi: Followed is My question: First,I do(I use E1,not T1): set interface slot:1/mod:[1-30] filter_access on show interface slot:1/mod:2 I find "filter access" is ON, then I do: save all show interface slot:/mod:2 the "filter access" is ON, then I do: reboot after a while, I do sh interface slot:/mod:2 the "filter access" is OFF, why? Obviously after reboot, the configuration have changed. I need "filter access" is ON always. ________________________________________________ ��ӭ��ʹ�ù����Ӵ���ѵ�������http://www.163.net

Once upon a time Jeff Carneal shaped the electrons to say... >We're running a couple of TC's here with some older code on it which does >not support the Connect-Info radius attribute (ie, doesn't log connection >speeds). I was curious if any of the newer Netserver releases have fixed >this problem, or if upgrading would be futile. Thanks in advance... AFAIK 3Com decided not to use the RFC attribute, but has VSAs for speed data. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

On as last minute change, I am going to ISPcon. Hope to meet up with some of you, maybe at the 3com gathering if they have one this time. I will be staying at the Hyatt San Jose. brian Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

See ya there ! -----Original Message----- >On as last minute change, I am going to ISPcon. Hope to meet up with some >of you, maybe at the 3com gathering if they have one this time. I will be >staying at the Hyatt San Jose. > >brian > > >-------------------------------------------------------------------------- >Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider >Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ >signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, >(318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

I didn't see spontaneous reboots (because I never touch the card ownership settings, ever)... but, a LOT of the MPIP problems I was whining about last week were fixed by upgrading from 4.1.11 to 4.1.78 -- the "WebTV Fix" release. With a 4.1.78 ARC running as the MPIP server for itself and two 3.7.24 NETservers, MPIP now works fine if the two channels of a multilink call come up on one of each of the NETservers. (And of course, if both channels end up on the same chassis, things also work.) The two remaining problems I'm having are: 1) If a multilink call is split between a NETserver and an ARC, I still have major throughput problems. The 50% packet loss problem is gone. Uploads from the dialup client work fine. But, downloads from the Internet to the client run at an abysmal 1.5K/sec. Sometimes FTP connections get randomly reset too (probably due to the packet delays). I was using NT to test this, but now I've verified that a Win95 machine with DUN 1.3 does the exact same thing. It only affects the case where a call is split between a NETserver and an ARC -- if it's split between two NETservers, even with the ARC as the MPIP server, this throughput problem does not happen. So it's a hell of a lot better than it was, but not quite 100% yet... 2) I'm still seeing "stale" bundles piling up. It appears to be affecting just two users, which is a bit strange. Both of them are using Windows 95 with DUN 1.2 and 3com Impact IQ's. Both are set to MLPPP at their end, but are only authorized for 64K -- they bring up one-channel MPIP bundles and they don't always get deleted at logout. "list mpip links" shows 11 bundles for one user and 2 bundles for another right now, all to the same NETserver, yet neither of them are currently dialed in. I still suspect this is a NETserver bug, not an ARC bug... Mike Andrews (MA12) icq 6602506 -------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "If Barbie is so popular, why do you have to buy her friends?..." On Mon, 28 Sep 1998, Mark van Wouw wrote: > I still have a problem with MLPPP failing on the HARC after about > a day and a half (depending on load). Beta version 4.1.7 did not > have this problem. 4.1.9 - 4.1.11 do. I have dialog with 3Com > engineers on this, but so far I'm not sure it's even reproducable > for them. It is 100% reproducable for me, but the card has to be on a > chassis taking many calls (ie. in service). Therefore, once the > HARC starts to fail to bring up the second channel I want to fix > the problem for my customers as soon as possible (ie. reboot ). > > Since the above is already being looked at by engineers, I am giving > this mostly for background info (though I would certainly like to hear > if anyone else sees this problem and I can give more info if requested). > > What I wanted to report is spontaneous HARC reboots after changing > slot ownership of HDM cards. Since I wanted to take a HARC > that was failing MLPPP out of production, without rebooting it, > I did the following: > > Put a HARC V.4.1.9 in a production chassis and waited for MLPPP to begin > to fail. I made it owner of the 7 HDMs in the chassis. I also put another > HARC in the chassis (V.4.1.7 which does not have this problem). After > the problem showed up, I tried to change ownership of the HDMs to the > second HARC. First I set HARC V.4.1.9 as "owner no" of the modems. All > the calls dropped fine. Then I set HARC V.4.1.7 as "owner yes" of the > modems. At this point, the first HARC, V.4.1.9, spontaneously rebooted. > > I flashed the HARC to V.4.1.11 to see if this code also fails on MLPPP. > About 30 hours later, it too began failing to authenticate the second > channel, just as with V.4.1.9. I again tried to change ownership of > the production modems over to a different HARC. This time I first > "hung up" the calls. But again this card spontaneously rebooted shortly > after setting the card as "owner no" of the HDMs. > > The NMC is chassis awareness off, so I don't think that's an issue. > Has anyone else seen spontaneous reboots after changing chassis > slot ownership? > > Mark. > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On 28 Sep 1998 cntlxh@163.net wrote: > The version of code is 4.1.78; It is a chinese 3com engineer > provide us such a version. > What wrong with such a version of code?=20 Hmm, Which chines 3com Engineer? I am not sure where he got the code. I= =20 do know that some beta versions had this problem and 4.1.11 did not have=20 this problem. 4.1.78 ( the web TV fix code ) should not have this=20 problem. I am not sure if this is the version of code you are running. =20 I will try out here with the 4.1.78 code. If the problem exists then you=20 will have to wait for the fix. IN the mean time let me know the=20 engineers name. regards krish >=20 > > This was a problem in one version of beta code. Which version of code= =20 > > are you running on the arc? > >=20 > > krish > >=20 > > ----------------------------------------- > > =09=09\=09T.S.V. Krishnan \ > > =09=09 \ Network System Engineer \ ( : - : ) > > =09=09 \ 3Com ............ \ > > =09=09----------------------------------------------/ > > tkrishna@bubba.ae.usr.com =20 > > ----------------------------/ http://interproc.ae.usr.com ----/ > > The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.co= m/tkb.html > > -----------------------------------------------------------------------= --\ > > =09Any Sufficiently advanced bug is indistinguishable for a feature. > > =09=09=09=09=09=09- Rick Kulawiec > > -----------------------------------------------------------------------= --/ > >=20 > > On 27 Sep 1998 cntlxh@163.net wrote: > >=20 > > > Hi: > > >=20 > > > Followed is My question: > > >=20 > > > First,I do(I use E1,not T1): > > >=20 > > > set interface slot:1/mod:[1-30] filter_access on > > > show interface slot:1/mod:2 > > >=20 > > > I find "filter access" is ON, then I do: > > >=20 > > > save all > > > show interface slot:/mod:2 > > >=20 > > > the "filter access" is ON, then I do: > > >=20 > > > reboot > > >=20 > > > after a while, I do=20 > > >=20 > > > sh interface slot:/mod:2 > > >=20 > > > the "filter access" is OFF, why? Obviously > > > after reboot, the configuration have changed. > > > I need "filter access" is ON always. > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > ________________________________________________ > > > =BB=B6=D3=AD=C4=FA=CA=B9=D3=C3=B9=E3=D6=DD=CA=D3=B4=B0=C3=E2=B7=D1=B5= =E7=D7=D3=D3=CA=CF=E4http://www.163.net > > >=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. > > >=20 > >=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. >=20 >=20 >=20 > ________________________________________________ > =BB=B6=D3=AD=C4=FA=CA=B9=D3=C3=B9=E3=D6=DD=CA=D3=B4=B0=C3=E2=B7=D1=B5=E7= =D7=D3=D3=CA=CF=E4http://www.163.net >=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. >=20

what is the ticket number? krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Mon, 28 Sep 1998, Mark van Wouw wrote: > I still have a problem with MLPPP failing on the HARC after about > a day and a half (depending on load). Beta version 4.1.7 did not > have this problem. 4.1.9 - 4.1.11 do. I have dialog with 3Com > engineers on this, but so far I'm not sure it's even reproducable > for them. It is 100% reproducable for me, but the card has to be on a > chassis taking many calls (ie. in service). Therefore, once the > HARC starts to fail to bring up the second channel I want to fix > the problem for my customers as soon as possible (ie. reboot ). > > Since the above is already being looked at by engineers, I am giving > this mostly for background info (though I would certainly like to hear > if anyone else sees this problem and I can give more info if requested). > > What I wanted to report is spontaneous HARC reboots after changing > slot ownership of HDM cards. Since I wanted to take a HARC > that was failing MLPPP out of production, without rebooting it, > I did the following: > > Put a HARC V.4.1.9 in a production chassis and waited for MLPPP to begin > to fail. I made it owner of the 7 HDMs in the chassis. I also put another > HARC in the chassis (V.4.1.7 which does not have this problem). After > the problem showed up, I tried to change ownership of the HDMs to the > second HARC. First I set HARC V.4.1.9 as "owner no" of the modems. All > the calls dropped fine. Then I set HARC V.4.1.7 as "owner yes" of the > modems. At this point, the first HARC, V.4.1.9, spontaneously rebooted. > > I flashed the HARC to V.4.1.11 to see if this code also fails on MLPPP. > About 30 hours later, it too began failing to authenticate the second > channel, just as with V.4.1.9. I again tried to change ownership of > the production modems over to a different HARC. This time I first > "hung up" the calls. But again this card spontaneously rebooted shortly > after setting the card as "owner no" of the HDMs. > > The NMC is chassis awareness off, so I don't think that's an issue. > Has anyone else seen spontaneous reboots after changing chassis > slot ownership? > > Mark. > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

The version of code is 4.1.78; It is a chinese 3com engineer provide us such a version. What wrong with such a version of code? > This was a problem in one version of beta code. Which version of code > are you running on the arc? > > krish > > ----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ > tkrishna@bubba.ae.usr.com > ----------------------------/ http://interproc.ae.usr.com ----/ > The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html > -------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec > -------------------------------------------------------------------------/ > > On 27 Sep 1998 cntlxh@163.net wrote: > > > Hi: > > > > Followed is My question: > > > > First,I do(I use E1,not T1): > > > > set interface slot:1/mod:[1-30] filter_access on > > show interface slot:1/mod:2 > > > > I find "filter access" is ON, then I do: > > > > save all > > show interface slot:/mod:2 > > > > the "filter access" is ON, then I do: > > > > reboot > > > > after a while, I do > > > > sh interface slot:/mod:2 > > > > the "filter access" is OFF, why? Obviously > > after reboot, the configuration have changed. > > I need "filter access" is ON always. > > > > > > > > > > > > ________________________________________________ > > ��ӭ��ʹ�ù����Ӵ���ѵ�������http://www.163.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. ________________________________________________ ��ӭ��ʹ�ù����Ӵ���ѵ�������http://www.163.net

At 11:31 AM 9/28/98 -0400, you wrote: >where are the archives for this list kept? i am looking for a radius server >that limits duplicate logins and i know we disccussed thsi last week. > > This was from last week - valid I guess?? ftp://ftp.xmission.com/pub/lists/usr-tc/ ***** Top Net InterNet Services ***** Omaha, Nebraska Husker Heaven www.top.net (402) 291-1542 Visit Our BBS at: www.hawgwild.com

At 11:31 AM 9/28/98 -0400, you wrote: >where are the archives for this list kept? i am looking for a radius server >that limits duplicate logins and i know we disccussed thsi last week. > > This as well: RAW: ftp://ftp.xmission.com/pub/lists/usr-tc Searchable: http://usr-tc.datasys.net ***** Top Net InterNet Services ***** Omaha, Nebraska Husker Heaven www.top.net (402) 291-1542 Visit Our BBS at: www.hawgwild.com

where are the archives for this list kept? i am looking for a radius server that limits duplicate logins and i know we disccussed thsi last week. Leon

make sure the line setting is set to message oriented > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of John Powell > Sent: Monday, September 28, 1998 11:18 AM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Quad upgrade to Hyper problems > > > No, there should be nothing special to setup. HiPer cards support all the > same protocols that the PRI cards do. > > I suspect it is a parameter you have set wrong on the HiPer cards. You > will want to compare very closely the settings you have on both. PRIs are > pretty simple, so check things like switch type (DMS, 5E, etc.), line > coding, etc. Things like ANI/DNIS are not likely to cause problems like > this with a PRI, so you can probably not bother with them. > > You should also look at things like error conditions on the spans, look at > perfrormance monitor and see if the call arrives but is rejected for some > reason. If you still have trouble support can walk you through D channel > traces to see if the call is actually presented and any reject > reasons that > may point to the trouble cause. > > Also, what the caller is hearing (busy, ring-no-answer, etc.) > might help ID > the cause. > > Keep digging, it is almost for sure a config issue on the HiPer. I can't > think of anything off-hand that the telco could have messed up if it is > working on your PRI card/quad chassis. > > JP > > > > > > Jack Singer <jsinger@usacars.com> on 09/28/98 01:10:18 PM > > Please respond to usr-tc@lists.xmission.com > > To: usr-tc@lists.xmission.com > cc: cntlxh@163.net (John Powell/MW/US/3Com) > Subject: Re: (usr-tc) Quad upgrade to Hyper problems > > > > > We had 1 quad system and 1 hyper system each with 48 modems. We added 2 > cards to the > hyper system and pluged the PRI's from the quad system in and it will not > recognize > the calls. We plug them back into the quad system and they work > fine. All > 4 hyper > cards are set up the same. > > Is there a configuration I need to tell the phone co? Please help.... > > Jack Singer > 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. >

John, Lately (maybe for some time, I am fairly new to the list) you have been providing excellent support to list members. In my case, e-mail (list) support is almost always enough. If this support is 'official' and likely to continue, then rethinking my decision not to purchase any additional 3Com products may be in order. Is your support official and is it likely to continue? Thank you, Tim Patterson Harborside

How do you turn on caller ID inside TCM for the 2059 Chassis? Thanks. Lee

I still have a problem with MLPPP failing on the HARC after about a day and a half (depending on load). Beta version 4.1.7 did not have this problem. 4.1.9 - 4.1.11 do. I have dialog with 3Com engineers on this, but so far I'm not sure it's even reproducable for them. It is 100% reproducable for me, but the card has to be on a chassis taking many calls (ie. in service). Therefore, once the HARC starts to fail to bring up the second channel I want to fix the problem for my customers as soon as possible (ie. reboot ). Since the above is already being looked at by engineers, I am giving this mostly for background info (though I would certainly like to hear if anyone else sees this problem and I can give more info if requested). What I wanted to report is spontaneous HARC reboots after changing slot ownership of HDM cards. Since I wanted to take a HARC that was failing MLPPP out of production, without rebooting it, I did the following: Put a HARC V.4.1.9 in a production chassis and waited for MLPPP to begin to fail. I made it owner of the 7 HDMs in the chassis. I also put another HARC in the chassis (V.4.1.7 which does not have this problem). After the problem showed up, I tried to change ownership of the HDMs to the second HARC. First I set HARC V.4.1.9 as "owner no" of the modems. All the calls dropped fine. Then I set HARC V.4.1.7 as "owner yes" of the modems. At this point, the first HARC, V.4.1.9, spontaneously rebooted. I flashed the HARC to V.4.1.11 to see if this code also fails on MLPPP. About 30 hours later, it too began failing to authenticate the second channel, just as with V.4.1.9. I again tried to change ownership of the production modems over to a different HARC. This time I first "hung up" the calls. But again this card spontaneously rebooted shortly after setting the card as "owner no" of the HDMs. The NMC is chassis awareness off, so I don't think that's an issue. Has anyone else seen spontaneous reboots after changing chassis slot ownership? Mark.

No, there should be nothing special to setup. HiPer cards support all the same protocols that the PRI cards do. I suspect it is a parameter you have set wrong on the HiPer cards. You will want to compare very closely the settings you have on both. PRIs are pretty simple, so check things like switch type (DMS, 5E, etc.), line coding, etc. Things like ANI/DNIS are not likely to cause problems like this with a PRI, so you can probably not bother with them. You should also look at things like error conditions on the spans, look at perfrormance monitor and see if the call arrives but is rejected for some reason. If you still have trouble support can walk you through D channel traces to see if the call is actually presented and any reject reasons that may point to the trouble cause. Also, what the caller is hearing (busy, ring-no-answer, etc.) might help ID the cause. Keep digging, it is almost for sure a config issue on the HiPer. I can't think of anything off-hand that the telco could have messed up if it is working on your PRI card/quad chassis. JP Jack Singer <jsinger@usacars.com> on 09/28/98 01:10:18 PM Please respond to usr-tc@lists.xmission.com cc: cntlxh@163.net (John Powell/MW/US/3Com) We had 1 quad system and 1 hyper system each with 48 modems. We added 2 cards to the hyper system and pluged the PRI's from the quad system in and it will not recognize the calls. We plug them back into the quad system and they work fine. All 4 hyper cards are set up the same. Is there a configuration I need to tell the phone co? Please help.... Jack Singer 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.

We have USR NetServer cards in some Total Control racks and some Hiper ARC cards. I have been searching, with snmpwalk, everywhere for the idle and total connect time for a current call. I know this can be set VIA radius or in the rack at user login time to terminate a call after a given idle or total connect time, so I know that these units have this information. If they have it I would think we can get it. Please, I have even called the VAR and 3COM on this... Where are the current amount of connect time and idle time via SNMP? If it isn't available, please tell me where I can get the current amount of idle time in any way. Thanks!

Yesterday we had a Hiperarc reboot while running 4.1.9 code. 4.1.11 had been downloaded but our scheduled reboot hadn't been accomplished. After the unscheduled reboot, the Hiperarc came up on 4.1.11 . Last night I attempted to download 4.1.78 via TCM and TFTP. The TFTP session started but stuck on 0% downloaded for over 5 minutes, an unusual condition. I decided to abort the download, fearing something was wrong. After aborting the download I attempted to start it again. It would not start and would timeout saying "Generic error". Also the Hiperarc stayed yellow in TCM. Early this morning I rebooted the Hiperarc and that cleared the yellow condition on TCM but after the reboot the modem_groups entries showed the all modem group with 0 interfaces in it, this was from the CLI and the chassis wasn't taking calls. I went into HARM v1.18 and displayed the modem groups and this triggered the Hiperarc into showing the correct 92 entries in modem_group all and the chassis started taking calls. So now everything is working but I still cannot download 4.1.78 to the Hiperarc via TCM and TFTP. I still get the generic error. The file size is: 2,727,494 . Is this now an NMC problem where I will need to reset the NMC card ? Jeff Binkley ASA Network Computing

We had 1 quad system and 1 hyper system each with 48 modems. We added 2 cards to the hyper system and pluged the PRI's from the quad system in and it will not recognize the calls. We plug them back into the quad system and they work fine. All 4 hyper cards are set up the same. Is there a configuration I need to tell the phone co? Please help.... Jack Singer jsinger@i-c.net

On Mon, 28 Sep 1998, Mike Wronski wrote: > Use this code and type the command "enable ip proxy_arp_all_dialin". This should > fix your problem. Thanks! Your attached version (ne040178-4.dsp) solved that problem right away... What was the problem? Was the old code not proxying for the assigned IP's? Kevin E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

On Mon, 28 Sep 1998, Jeff Binkley wrote: > > > > Yesterday we had a Hiperarc reboot while running 4.1.9 code. 4.1.11 had been > downloaded but our scheduled reboot hadn't been accomplished. After the > unscheduled reboot, the Hiperarc came up on 4.1.11 . Last night I attempted > to download 4.1.78 via TCM and TFTP. The TFTP session started but stuck on 0% > downloaded for over 5 minutes, an unusual condition. I decided to abort the > download, fearing something was wrong. After aborting the download I > attempted to start it again. It would not start and would timeout saying > "Generic error". Also the Hiperarc stayed yellow in TCM. Early this morning > I rebooted the Hiperarc and that cleared the yellow condition on TCM but after The problem is that you did have a TFTP timeout and the tne NMC never recongized the card. The problem would have cleared if you either reboot the hiper arc or the nmc. However in this condition you should be able to download the code again via tcm. This is a nmc/network issue. > > the reboot the modem_groups entries showed the all modem group with 0 > interfaces in it, this was from the CLI and the chassis wasn't taking calls. > I went into HARM v1.18 and displayed the modem groups and this triggered the > Hiperarc into showing the correct 92 entries in modem_group all and the > chassis started taking calls. So now everything is working but I still cannot > download 4.1.78 to the Hiperarc via TCM and TFTP. I still get the generic > error. The file size is: 2,727,494 . Is this now an NMC problem where I will > need to reset the NMC card ? > You can also try downloading the code via tftp directly from the hiper arc or form a tftp client. From the above info it looks like a nmc issue and if you were not able to download the code even via hiper arc/tftpclient then it would be hiper arc issue. krish > Jeff Binkley > ASA Network Computing > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

I agree, we have 7 total control units and a pm3. It is very difficult to get support for the total control units and I am happy that I have found this list. As for the pm3, they give free phone support and I never have a problem 24/7 getting someone to help. Try to find that at 3com. Lets hope 3com decides to support the people that recommend the modems and other hardware to customers...... Jack Singer Tim Patterson wrote: > John, > > Lately (maybe for some time, I am fairly new to the list) you have been > providing excellent support to list members. In my case, e-mail (list) > support is almost always enough. If this support is 'official' and likely > to continue, then rethinking my decision not to purchase any additional > 3Com products may be in order. > > Is your support official and is it likely to continue? > > Thank you, > > Tim Patterson > Harborside > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

At 03:37 PM 9/28/98 -0400, you wrote: >I agree, we have 7 total control units and a pm3. It is very difficult to >get support for the total control units and I am happy that I have found this >list. As for the pm3, they give free phone support and I never have a >problem 24/7 getting someone to help. Try to find that at 3com. Lets hope >3com decides to support the people that recommend the modems and other >hardware to customers...... > Having all three (I guess major) players in house, 3Com/USR - Ascend - and Livingston/Lucent, I'd still rate USR at the bottom. Lucent is nice for support/and mail list support (what can you say about *free*), Ascend's list mail server seems to produce better faster results (again for free) - perhaps cause of more users? Ascends Flat rate cost for repairs, either in warranty or out of warranty Sux... Often, on USR's list mail server, my questions go totally unanswered, unless a brave ISP steps forward to answer off previous experiences. IMO, this is really not a way to run a business, and if USR would cut loose a couple of Tech Support people for the List as a part time operation (at least), it might be helpful. Seems most people on this list are oriented *only* towards HiPer products, yet I'll bet 1,000's of ISP's out there are still using/buying used 2509 type configed units. ***** Top Net InterNet Services ***** Omaha, Nebraska Husker Heaven www.top.net (402) 291-1542 Visit Our BBS at: www.hawgwild.com

> Seems most people >on this list are oriented *only* towards HiPer products, yet I'll bet >1,000's of ISP's out there are still using/buying used 2509 type configed >units. hmmm, interesting observation, not at all correct though. I think your perception is based on the fact that many of the questions on this list over the past months are HiPer related, therefore most of the answers are HiPer related (interesting how that works, eh). Most customers are already quite familiar with the quads/Netservers so don't have as many questions to ask. I am certainly glad to hear you are happy with the quad/netserver platforms, I am certain they will serve you (and the 1000's of other ISPs) well for quite some time. Regards, JP

Thus spake John Powell >> Seems most people >>on this list are oriented *only* towards HiPer products, yet I'll bet >>1,000's of ISP's out there are still using/buying used 2509 type configed >>units. >hmmm, interesting observation, not at all correct though. I think your >perception is based on the fact that many of the questions on this list >over the past months are HiPer related, therefore most of the answers are >HiPer related (interesting how that works, eh). Most customers are already >quite familiar with the quads/Netservers so don't have as many questions to >ask. >I am certainly glad to hear you are happy with the quad/netserver >platforms, I am certain they will serve you (and the 1000's of other ISPs) >well for quite some time. Which further makes me wonder why 3Com seems intent on ditching this platform! I understand the issue of the OS going bye-bye, but it seems that the netserver/quad/dual-pri is an admirable solution for many ISP's rather than the considerably more expensive HiPer cards. I fear 3Com is painting themselves into a corner by not supporting a lower cost solution for smaller houses (small ISP's, small companies), but instead forcing people to buy HiPer equipment, when their needs may not lead that way. Back port Pilgrim to the Netserver and keep selling netserver/quad/dual-pri based systems! -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

TS>> Yesterday we had a Hiperarc reboot while running 4.1.9 code. TS>4.1.11 had been TS>> downloaded but our scheduled reboot hadn't been accomplished. TS>> After the unscheduled reboot, the Hiperarc came up on 4.1.11 . TS>> Last night I attempted to download 4.1.78 via TCM and TFTP. The TS>TFTP session started but stuck on 0% TS>> downloaded for over 5 minutes, an unusual condition. I decided to TS>> abort the download, fearing something was wrong. After aborting TS>> the download I attempted to start it again. It would not start and TS>> would timeout saying "Generic error". Also the Hiperarc stayed TS>yellow in TCM. Early this morning TS>> I rebooted the Hiperarc and that cleared the yellow condition on TS>TCM but after TS>The problem is that you did have a TFTP timeout and the tne NMC never TS>recongized the card. The problem would have cleared if you either TS>reboot the hiper arc or the nmc. However in this condition you TS>should be able to download the code again via tcm. This is a TS>nmc/network issue. TS>> the reboot the modem_groups entries showed the all modem group with TS>> 0 interfaces in it, this was from the CLI and the chassis wasn't TS>> taking calls. I went into HARM v1.18 and displayed the modem groups TS>> and this triggered the Hiperarc into showing the correct 92 entries TS>> in modem_group all and the chassis started taking calls. So now TS>everything is working but I still cannot TS>> download 4.1.78 to the Hiperarc via TCM and TFTP. I still get the TS>> generic error. The file size is: 2,727,494 . Is this now an NMC TS>problem where I will TS>> need to reset the NMC card ? TS>You can also try downloading the code via tftp directly from the TS>hiper arc or form a tftp client. From the above info it looks like TS>a nmc issue and if you were not able to download the code even via TS>hiper arc/tftpclient then it would be hiper arc issue. Krish, Resetting the NMC card did finally fix the problem. I did use a TFTP client to send the file straight to the HiPerArc, prior to rebooting the NMC. This went fine. I was a little concerned what name to give it on the HiPerArc (since TFTP requires a local and remote file name). I left it ne040178.dmf for the remote file name (i.e. on the HiPerArc). After rebooting the NMC, I tried again to TFTP the file to the HiPerArc via the TCM. It got about 35% completed and then failed with a TFTP Access Violation. I tried restarting it and almost immediately got the same error and the Alarm Server gets a Management Bus Failure message on the HiPerArc slot. I am assuming the file I TFTP'd with the TFTP client is still in memory on the HiPerArc and would come online if I rebooted the HiPerArc, since the partial download wouldn't write the file on the HiPerArc. Is the a bad assumption on my part ? Is there any way to see what's been downloaded to the HiPerArc and do any kind of CRC validation on it ? Is any of this a known problem with 4.1.11 ? Up until now the TCM tftp has worked flawlessly. Jeff Binkley ASA Network Computing

>I fear 3Com is >painting themselves into a corner by not supporting a lower cost >solution for smaller houses (small ISP's, small companies), but instead >forcing people to buy HiPer equipment, when their needs may not lead >that way. >Back port Pilgrim to the Netserver and keep selling >netserver/quad/dual-pri based systems! - first, note we will continue to "support" them as far as if you have trouble, we will help, and if we can, provide ERs to resolve bugs. There is also at least one more quad rev in the pipe. The products are not dead, they are just entering their twilight years. - I have not personally done a thorough cost analysis, but clearly the per-port costs are much lower with HiPer equipment. There is a certain number of ports per chassis to achieve that, but it is not outrageous. As the Internet grows, even in smaller communities, the number of customers per-PoP will grow, and even the smaller ISPs needs more ports per PoP. - The proliferation of CLEC based offerings (and RBOC counter-offerings) are increasing and starting to become available outside the big metro areas. As that happens, the number of small disbursed PoPs will decrease and you will find yourself being able to concentrate your ports in so-called mini Super-PoPs (as opposed to having to rent space across your served areas). The benefits of my previous point will then be realized. Let me assure you, this is in the VERY near future, and is already the case in most large and medium population areas. - There is the simple difficulty that we then need to maintain parallel R&D organizations. We would need to spread development, and even manufacturing, costs across the number of units sold. As HiPer becomes more popular, fewer and fewer low density products would be sold and per-port costs would probably need to rise or stay flat, as HiPer costs drop! Us retaining a large development staff for these platforms would be virtual suicide. - The current platforms will not support much more in the way of features. They are quite simply full. - Lastly, but not leastly, you will probably be seeing a large amount of used equipment becoming available as "the big guys" start shifting to HiPer. If HiPer just is not your bag of tricks, you will still be able to get product, and for surplus prices. This is already starting to happen. Believe me, there are several million ports of quads and NSs out there taking up valuable real estate in expensive CO space. Think about it a bit before sending a nasty response to this email (and I am sure I will get a few). As you look at the future of your business's, the logic will make more sense. Also, your options are not as stark as you might imagine. I hope this helps a bit in understanding the logic. I am not the guy making these decisions, and I am quite fond of the quad/NS platform, but the path we are on seems logical to me. Perfect solution, no. Logical, yes. JP

On Tue, 29 Sep 1998, Jeff Binkley wrote: > TS>> Yesterday we had a Hiperarc reboot while running 4.1.9 code. > TS>4.1.11 had been > TS>> downloaded but our scheduled reboot hadn't been accomplished. > TS>> After the unscheduled reboot, the Hiperarc came up on 4.1.11 . > TS>> Last night I attempted to download 4.1.78 via TCM and TFTP. The > TS>TFTP session started but stuck on 0% > TS>> downloaded for over 5 minutes, an unusual condition. I decided to > TS>> abort the download, fearing something was wrong. After aborting > TS>> the download I attempted to start it again. It would not start and > TS>> would timeout saying "Generic error". Also the Hiperarc stayed > TS>yellow in TCM. Early this morning > TS>> I rebooted the Hiperarc and that cleared the yellow condition on > TS>TCM but after > > TS>The problem is that you did have a TFTP timeout and the tne NMC never > TS>recongized the card. The problem would have cleared if you either > TS>reboot the hiper arc or the nmc. However in this condition you > TS>should be able to download the code again via tcm. This is a > TS>nmc/network issue. > > > TS>> the reboot the modem_groups entries showed the all modem group with > TS>> 0 interfaces in it, this was from the CLI and the chassis wasn't > TS>> taking calls. I went into HARM v1.18 and displayed the modem groups > TS>> and this triggered the Hiperarc into showing the correct 92 entries > TS>> in modem_group all and the chassis started taking calls. So now > TS>everything is working but I still cannot > TS>> download 4.1.78 to the Hiperarc via TCM and TFTP. I still get the > TS>> generic error. The file size is: 2,727,494 . Is this now an NMC > TS>problem where I will > TS>> need to reset the NMC card ? > > > TS>You can also try downloading the code via tftp directly from the > TS>hiper arc or form a tftp client. From the above info it looks like > TS>a nmc issue and if you were not able to download the code even via > TS>hiper arc/tftpclient then it would be hiper arc issue. > > Krish, > > Resetting the NMC card did finally fix the problem. I did use a TFTP > client to send the file straight to the HiPerArc, prior to rebooting the > NMC. This went fine. I was a little concerned what name to give it on > the HiPerArc (since TFTP requires a local and remote file name). I left > it ne040178.dmf for the remote file name (i.e. on the HiPerArc). > The should be renamed as netserve.dmf - this will tell the hIper arc that there is a new code in the flash and will boot it in the next reboot. you can either rename it when you start the tftp or rename the same using the command - rename file ne040178.dmf netserve.dmf > After rebooting the NMC, I tried again to TFTP the file to the HiPerArc > via the TCM. It got about 35% completed and then failed with a TFTP > Access Violation. I tried restarting it and almost immediately got the > same error and the Alarm Server gets a Management Bus Failure message on > the HiPerArc slot. Management bus failure here means that the NMC is not able to communicate with the particular card. Do you see any packet bus clock failures also ? > > I am assuming the file I TFTP'd with the TFTP client is still in memory > on the HiPerArc and would come online if I rebooted the HiPerArc, since the > partial download wouldn't write the file on the HiPerArc. Is the a bad > assumption on my part ? Is there any way to see what's been downloaded to the > HiPerArc and do any kind of CRC validation on it ? Is any of this a known > problem with 4.1.11 ? Up until now the TCM tftp has worked flawlessly. > If you tftp a file and if the crc is bad, the hiper arc will not boot that file - It does do some internal checking. So you can tftp a file call it netserver.dmf and if it is not the correct file, the hiper arc will not boot the same. krish > > Jeff Binkley > ASA Network Computing > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Two items come to mind. Fisrt Chassis Awareness... Is it one ?, Second, A= re you using the correct version of the manger ? if not you will have the wr= ong SNMP MIB's -----Original Message----- >Hi, > >After installation of chassis to rack, >it is time to view my chassis use TCM >for window, but strangly, TCM only >display NMC card and two Power module, >other module(HARC,Hiper DSP)'s place >have a big "?" on them. >What's wrong with the chassis? We have >nothing to do with the 'bad' chassis, >only to request 3COM replace the chassis >with a good chassis. >Do you have such a question? >I think perhaps manage bus of the chassis is bad. >How do you think? > > >________________________________________________ >=BB=B6=D3=AD=C4=FA=CA=B9=D3=C3=B9=E3=D6=DD=CA=D3=B4=B0=C3=E2=B7=D1=B5=E7= =D7=D3=D3=CA=CF=E4http://www.163.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. >

BUt the inside rumour from 3COM is that Lucent is buying USR on the 12th of October.... HHHmmmmmm -----Original Message----- >Thus spake Kevin Benton >>I think that 3Com is making a very bad decision >>if they let ComOS go by the wayside in December. > >Unfortunately, that's not a 3Com decision...the licensing agreement from >Livingston, now Lucent RABU, runs out in Dec. 31st and they absolutely >loose access to the ComOS based source...SOL. The only feasible way I >see for 3Com to continue to really support the netserver hardware, >software-wise, would be to back-port Pilgrim, as you mentioned...it >really *NEEDS* to be done. >-- >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. >

Thus spake John Powell >>I fear 3Com is >>painting themselves into a corner by not supporting a lower cost >>solution for smaller houses (small ISP's, small companies), but instead >>forcing people to buy HiPer equipment, when their needs may not lead >>that way. >>Back port Pilgrim to the Netserver and keep selling >>netserver/quad/dual-pri based systems! >- first, note we will continue to "support" them as far as if you have >trouble, we will help, and if we can, provide ERs to resolve bugs. There >is also at least one more quad rev in the pipe. The products are not dead, >they are just entering their twilight years. Right, you all just loose access to the source code on Dec. 31st...given the lack of ability of 3Com to fix bugs even when you *have* the source, I don't hold out much optimism for you all to be able to fix bugs when you *don't* have the source. >- I have not personally done a thorough cost analysis, but clearly the >per-port costs are much lower with HiPer equipment. There is a certain >number of ports per chassis to achieve that, but it is not outrageous. As >the Internet grows, even in smaller communities, the number of customers >per-PoP will grow, and even the smaller ISPs needs more ports per PoP. You seem to be *very* out of touch with ISP's needs. We're constrained from opening up many new POP's because of the startup costs of a new POP. We recently opened up in Nashvile with a single TC chassis...46 ports (dual-pri's), and we haven't even gotten *close* to using that capacity yet. By moving so completely to the HiPer equipment you're pushing more and more small to mid-sized ISP's like us away from your equipment. This is just one more reason for me to consider the Cisco units...they still sell, fully support, and develop, the AS5200 which is the same number of ports as a quad/netserver chassis (smaller form-factor too). I may be forced to consider a migration to the AS5x00 series for new POP's if the continued move to HiPer-based systems is continued. >- The proliferation of CLEC based offerings (and RBOC counter-offerings) >are increasing and starting to become available outside the big metro >areas. As that happens, the number of small disbursed PoPs will decrease >and you will find yourself being able to concentrate your ports in >so-called mini Super-PoPs (as opposed to having to rent space across your >served areas). The benefits of my previous point will then be realized. >Let me assure you, this is in the VERY near future, and is already the case >in most large and medium population areas. Bullshit. You *still* have LATA's and regulations that prevent ICG (for example) from offering Cincinnati dial-tone to us in Louisville. I would love nothing more, but it isn't going to happen...not anytime in the near future. >- There is the simple difficulty that we then need to maintain parallel R&D >organizations. We would need to spread development, and even >manufacturing, costs across the number of units sold. As HiPer becomes >more popular, fewer and fewer low density products would be sold and >per-port costs would probably need to rise or stay flat, as HiPer costs >drop! Us retaining a large development staff for these platforms would be >virtual suicide. Hey, this is your problem, not mine...all I'm saying is that if you abandon the quad/netserver platform, sales to small and mid-sized ISP's are going to move over to Lucent and Cisco who still offer quality support and development on lower-end platforms. >- The current platforms will not support much more in the way of features. >They are quite simply full. Bullshit again. Write better code! The quads and a 486 based netserver should be able to provide *plenty* of features for an ISP. VOIP? probably not, but I don't need that and from what I hear that's not going to be support on the HARC anyway...only the edgeserver pro (spit). So much for me doing VOIP on 3Com gear. There is *no* technical reason that the netserver platform can't continue to provide great quality service to small to mid-sized providers. >- Lastly, but not leastly, you will probably be seeing a large amount of >used equipment becoming available as "the big guys" start shifting to >HiPer. If HiPer just is not your bag of tricks, you will still be able to >get product, and for surplus prices. This is already starting to happen. >Believe me, there are several million ports of quads and NSs out there >taking up valuable real estate in expensive CO space. Great...wonderful support there...small shop? Sorry can't buy from 3Com or a reseller directly, you have to get used equipment that's in who knows what type of shape...wonderful response there. Get real! We have enough problems getting decent support from 3Com as it is, and now we're supposed to get support on *used* equipment?! Ha! >Think about it a bit before sending a nasty response to this email (and I >am sure I will get a few). I thought about it plenty...you're still talking non-sense. >As you look at the future of your business's, >the logic will make more sense. Also, your options are not as stark as you >might imagine. No, my options aren't all that stark, I'm sure Cisco would just *love* to sell me dial-up equipment, as would Lucent RABU. And if I'm forced to go *completely* to HiPer equipment for future purchases from 3Com, that's where I'll probably be forced to go. >I hope this helps a bit in understanding the logic. I am not the guy >making these decisions, and I am quite fond of the quad/NS platform, but >the path we are on seems logical to me. Perfect solution, no. Logical, >yes. Its very logical if you want to loose your whole small to mid-sized ISP market. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Jeff Mcadams was heard to say: >Thus spake John Powell >>- first, note we will continue to "support" them as far as if you have >>trouble, we will help, and if we can, provide ERs to resolve bugs. There >>is also at least one more quad rev in the pipe. The products are not dead, >>they are just entering their twilight years. > >Right, you all just loose access to the source code on Dec. 31st...given >the lack of ability of 3Com to fix bugs even when you *have* the source, >I don't hold out much optimism for you all to be able to fix bugs when >you *don't* have the source. <grin> More true than anyone will ever admit. In the case of the Netserver, USR forced ComOS to run on the hardware at all costs. Nobody knows what all breaks when you change things -- and usually, it breaks shit you didn't even know that it did :-( >>- I have not personally done a thorough cost analysis, but clearly the >>per-port costs are much lower with HiPer equipment. There is a certain >>number of ports per chassis to achieve that, but it is not outrageous. As >>the Internet grows, even in smaller communities, the number of customers >>per-PoP will grow, and even the smaller ISPs needs more ports per PoP. > >You seem to be *very* out of touch with ISP's needs. We're constrained An understatement... look and learn from others in the industry (who's stock is soaring...) Has Lucent/Livingston dropped the PM3 now that they have the PM4? Hell no! VERY VERY few people have the need for such high densities. Interpath, for example, has POPs all across NC & SC. Only four of those POPs have more than one 48port chassis. Until we start concentrating dial-tone (back haul it to "superPOPs"), we will have very little need for hiper hardware (DSP anyway.) And when we do, it will be AS5800 hardware to support VOIP. 3Com needs to have products for both ends of the spectrum. A TC with two DSP's is just a f****** waste of space. >equipment. This is just one more reason for me to consider the Cisco >units...they still sell, fully support, and develop, the AS5200 which >is the same number of ports as a quad/netserver chassis (smaller >form-factor too). I may be forced to consider a migration to the AS5x00 >series for new POP's if the continued move to HiPer-based systems is >continued. If you've never used an AS5x00, then you're in for a ride... Cisco makes damn good routers, but they have a *long* way to go before they have usable dialup hardware. (IOS was never designed for a dialup system -- and it shows.) >>- There is the simple difficulty that we then need to maintain parallel R&D >>organizations. We would need to spread development, and even >>manufacturing, costs across the number of units sold. As HiPer becomes >>more popular, fewer and fewer low density products would be sold and >>per-port costs would probably need to rise or stay flat, as HiPer costs >>drop! Us retaining a large development staff for these platforms would be >>virtual suicide. > >Hey, this is your problem, not mine...all I'm saying is that if you >abandon the quad/netserver platform, sales to small and mid-sized ISP's >are going to move over to Lucent and Cisco who still offer quality >support and development on lower-end platforms. This is, of course, bullshit. Take a lesson from Linux... one source tree that builds on 9 platforms. And the simple fact is, if it costs 10k$ to make and support, then you don't sell it for 2k$. The number of people needed to maintain the code is alot smaller than you think -- look around. Interpath was built and supported by a half dozen people for three years (and then "taken over", but i won't go there.) Maybe 3Com just needs to hire some people who know what the @%@# they are doing ??? >>- The current platforms will not support much more in the way of features. >>They are quite simply full. > >Bullshit again. Write better code! The quads and a 486 based netserver >should be able to provide *plenty* of features for an ISP. VOIP? >probably not, but I don't need that and from what I hear that's not >going to be support on the HARC anyway...only the edgeserver pro (spit). >So much for me doing VOIP on 3Com gear. There is *no* technical reason >that the netserver platform can't continue to provide great quality >service to small to mid-sized providers. And this is absolute BS... a 486dx4-100 has more than enough CPU to handle 96 ports and do everything the HARC does currently. (Maybe not the 100M ethernet as it's not PCI based...) Would you like me to demonstrate what a 386dx40 can do? Go talk to Sam Fousias' group (Haitong Wang specifically) to hear what a capable person can do with your software... >>As you look at the future of your business's, >>the logic will make more sense. Also, your options are not as stark as you >>might imagine. > >No, my options aren't all that stark, I'm sure Cisco would just *love* >to sell me dial-up equipment, as would Lucent RABU. And if I'm forced >to go *completely* to HiPer equipment for future purchases from 3Com, >that's where I'll probably be forced to go. Hmm, what was Cisco's offer for a trade-in? (Yes, they did make an offer! And if it worked properly, we would not be having this discussion.) [Jeff, forget Cisco, go talk to Lucent.] --Ricky

On Tue, 29 Sep 1998, John Powell wrote: > >I fear 3Com is > >painting themselves into a corner by not supporting a lower cost > >solution for smaller houses (small ISP's, small companies), but instead > >forcing people to buy HiPer equipment, when their needs may not lead > >that way. > > >Back port Pilgrim to the Netserver and keep selling > >netserver/quad/dual-pri based systems! > > - first, note we will continue to "support" them as far as if you have > trouble, we will help, and if we can, provide ERs to resolve bugs. There > is also at least one more quad rev in the pipe. The products are not dead, > they are just entering their twilight years. > > - I have not personally done a thorough cost analysis, but clearly the > per-port costs are much lower with HiPer equipment. There is a certain > number of ports per chassis to achieve that, but it is not outrageous. As > the Internet grows, even in smaller communities, the number of customers > per-PoP will grow, and even the smaller ISPs needs more ports per PoP. > > - The proliferation of CLEC based offerings (and RBOC counter-offerings) > are increasing and starting to become available outside the big metro > areas. As that happens, the number of small disbursed PoPs will decrease > and you will find yourself being able to concentrate your ports in > so-called mini Super-PoPs (as opposed to having to rent space across your > served areas). The benefits of my previous point will then be realized. > Let me assure you, this is in the VERY near future, and is already the case > in most large and medium population areas. ... remainder deleted ... John, I think you're missing our point here. As a small ISP with somewhere around 1,000 ports, in 25 areas of Ohio, I can relate very well to what Jeff is saying. We look very heavily at start-up costs of "super-popping" as you put it versus the cost of placing hardware. With the NS/Quad combo, it often makes more sense to place dual leased 56K circuits in to feed a NS/Quad chassis in a town which is small enough that it won't support more than one ISP there. Another possiblity (which we have often used) is to put analog equipment there. If 3Com continues to push the ARC as a required platform, 3Com is going loose chassis sales. We are in a situation where we deal with many different ILEC's, many of which are so small that they don't offer T1 FXing to an area that we could use it from. What choice do we have? I guess we'll start incorporating Cisco equipment to fill the gap. We want to offer 56K dial-up in those areas, however, 3Com is making it cost prohibitive. 3Com seems to think that customers flock to ISP's in small areas. In areas that don't have an ISP, it often takes many months to more than a year to use up an entire T1 for dialup. This is real life. 3Com wants us to spend $9,000+ just for the card which will control the modems. We still have many areas where a single T1 has been installed for more than a year and has not peaked out yet. Let's see - cost per port... TC Chassis, NMC, ARC, DSP or Quads and T1 card versus TC NMC, NSC, DSP or Quads and T1 card versus Cisco 5x00 versus Lucent. You tell me - what makes more sense when going into areas which develop at a snail's pace? This is the very reason we're going into areas with Analog-only equipment (Linux and modems) when we know its growth rate won't justify digital equipment. Is 3Com out of touch with ISP's? Yes. Do they ask us questions which would help them? Rarely. Do they listen to our answers? No. I have stopped answering the support survey calls they've been sending my way. It's a waste of my time. Granted, there are people within 3Com that are probably jumping up and down to help us out. They're not, however, in the positions that can make things happen. Regardless of whether or not the NetServer can do more than what 3Com says it can, it's still a good solution for very small pops which can't be FX'ed cost effectively. I think that 3Com is making a very bad decision if they let ComOS go by the wayside in December. The only way I would see them being able pull that off is if they could successfully back port Pilgrim to the NetServer. Kevin Benton Network Engineer SOTA Technologies E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

Thus spake Kevin Benton >I think that 3Com is making a very bad decision >if they let ComOS go by the wayside in December. Unfortunately, that's not a 3Com decision...the licensing agreement from Livingston, now Lucent RABU, runs out in Dec. 31st and they absolutely loose access to the ComOS based source...SOL. The only feasible way I see for 3Com to continue to really support the netserver hardware, software-wise, would be to back-port Pilgrim, as you mentioned...it really *NEEDS* to be done. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Kevin Benton >I think that 3Com is making a very bad decision >if they let ComOS go by the wayside in December. Unfortunately, that's not a 3Com decision...the licensing agreement from Livingston, now Lucent RABU, runs out in Dec. 31st and they absolutely loose access to the ComOS based source...SOL. The only feasible way I see for 3Com to continue to really support the netserver hardware, software-wise, would be to back-port Pilgrim, as you mentioned...it really *NEEDS* to be done. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Frank Basso >BUt the inside rumour from 3COM is that Lucent is buying USR on the 12th of >October.... HHHmmmmmm Have heard some of that as well...I tend to not make plans like this based on rumours though. :) Personally, I would *love* it if this happened...Livingston/Lucent RABU's code, USR/3Com's hardware and modem code...what a sweet combo! Don't know if it would be the best thing for both companies overall, but for TC owners, at least, it'd be nice. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Frank Basso said once upon a time: >BUt the inside rumour from 3COM is that Lucent is buying USR on the 12th of >October.... HHHmmmmmm This will be interesting (if it happens).

Likewise here. One of the original 4 chassis we bought was bad. The NMC had a red light that would not go away. Everything else worked. We had the chassis replaced and the light went away > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Chris Peltier > Sent: Tuesday, September 29, 1998 2:47 PM > To: 'usr-tc@lists.xmission.com' > Subject: RE: (usr-tc) Bad Hiper 130A chassis? > > > > We had a similar problem and replacing the chassis > fixed it. I thought it was a long shot since there is > not much to fail in a chassis. I was wrong... > > Sincerely, > Chris Peltier > > * email: CPeltier@NetCarrier.com > * voice: 215-257-4917 > * FAX: 215-257-4916 > > > > >---------- > >From: cntlxh@163.net[SMTP:cntlxh@163.net] > >Sent: Tuesday, September 29, 1998 1:16 PM > >To: usr-tc@lists.xmission.com > >Subject: (usr-tc) Bad Hiper 130A chassis? > > > > > >Hi, > > > > > > > >After installation of chassis to rack, > > > >it is time to view my chassis use TCM > > > >for window, but strangly, TCM only > > > >display NMC card and two Power module, > > > >other module(HARC,Hiper DSP)'s place > > > >have a big "?" on them. > > > >What's wrong with the chassis? We have > > > >nothing to do with the 'bad' chassis, > > > >only to request 3COM replace the chassis > > > >with a good chassis. > > > >Do you have such a question? > > > >I think perhaps manage bus of the chassis is bad. > > > >How do you think? > > > > > > > >________________________________________________ > >��ӭ��ʹ�ù����Ӵ���*ѵ�������http://www.163.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. >

[lotsa bla bla deleted] PreScriptum : I am living, working, playing in Europe, so YMMV, partly because a 64k leased circuit here is paid about the price for a T-1 in the USA (no joke...) > >- I have not personally done a thorough cost analysis, but clearly > the > >per-port costs are much lower with HiPer equipment. There is a > certain > >number of ports per chassis to achieve that, but it is not > outrageous. As > >the Internet grows, even in smaller communities, the number of > customers > >per-PoP will grow, and even the smaller ISPs needs more ports per > PoP. > > You seem to be *very* out of touch with ISP's needs. We're > constrained > from opening up many new POP's because of the startup costs of a new > POP. We recently opened up in Nashvile with a single TC chassis...46 > ports (dual-pri's), and we haven't even gotten *close* to using that > capacity yet. By moving so completely to the HiPer equipment you're > pushing more and more small to mid-sized ISP's like us away from your > equipment. This is just one more reason for me to consider the Cisco > units...they still sell, fully support, and develop, the AS5200 which > is the same number of ports as a quad/netserver chassis (smaller > form-factor too). I may be forced to consider a migration to the > AS5x00 > series for new POP's if the continued move to HiPer-based systems is > continued. > Uhh... a recent cost analysis we did in-house brought some very interesting results. Cost of equipment is only 10% of overall costs for managing a growing dial-up basis, the main costs come from manpower (help desk, admin chores, network management) at about 50% (!). The 40% remaining are for buying internet access, marketing, maintenance costs, etc... > >- The proliferation of CLEC based offerings (and RBOC > counter-offerings) > >are increasing and starting to become available outside the big metro > >areas. As that happens, the number of small disbursed PoPs will > decrease > >and you will find yourself being able to concentrate your ports in > >so-called mini Super-PoPs (as opposed to having to rent space across > your > >served areas). The benefits of my previous point will then be > realized. > >Let me assure you, this is in the VERY near future, and is already > the case > >in most large and medium population areas. > > Bullshit. You *still* have LATA's and regulations that prevent ICG > (for > example) from offering Cincinnati dial-tone to us in Louisville. I > would love nothing more, but it isn't going to happen...not anytime in > the near future. > Okay, we just went that step 6 months ago and found out we were actually paying MORE than before, because we our growth rate had augmented so rapidly and we had to invest in several more HiPer boards that weren't on the budget, just to keep customers happy... (OK so we made a few bucks out of those old 2501's gathering dust in the old PoP's, but this won't come anywhere near the price of one single HiperDSP....) [ more stuff on which I have as yet no opinion about deleted ] That's the situation in Switzerland... Robert von Bismarck Petrel Communications SA *** SPAN / SCAN *** Geneva Switzerland <http://www.petrel.ch>

Hi, After installation of chassis to rack, it is time to view my chassis use TCM for window, but strangly, TCM only display NMC card and two Power module, other module(HARC,Hiper DSP)'s place have a big "?" on them. What's wrong with the chassis? We have nothing to do with the 'bad' chassis, only to request 3COM replace the chassis with a good chassis. Do you have such a question? I think perhaps manage bus of the chassis is bad. How do you think? ________________________________________________ ��ӭ��ʹ�ù����Ӵ���ѵ�������http://www.163.net

> On 28 Sep 1998 cntlxh@163.net wrote: > > > The version of code is 4.1.78; It is a chinese 3com engineer > > provide us such a version. > > What wrong with such a version of code? > > Hmm, Which chines 3com Engineer? I am not sure where he got the code. I > do know that some beta versions had this problem and 4.1.11 did not have > this problem. 4.1.78 ( the web TV fix code ) should not have this > problem. I am not sure if this is the version of code you are running. > I will try out here with the 4.1.78 code. If the problem exists then you Tell me if you have confirmed the question. By the way, what's mean of 'web TV fix code'? > will have to wait for the fix. IN the mean time let me know the > engineers name. > His name...sorry, I have forgotten. > > regards > > krish > > > > > > This was a problem in one version of beta code. Which version of code > > > are you running on the arc? > > > > > > krish > > > > > > ----------------------------------------- > > > \ T.S.V. Krishnan \ > > > \ Network System Engineer \ ( : - : ) > > > \ 3Com ............ \ > > > ----------------------------------------------/ > > > tkrishna@bubba.ae.usr.com > > > ----------------------------/ http://interproc.ae.usr.com ----/ > > > The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html > > > -------------------------------------------------------------------------\ > > > Any Sufficiently advanced bug is indistinguishable for a feature. > > > - Rick Kulawiec > > > -------------------------------------------------------------------------/ > > > > > > On 27 Sep 1998 cntlxh@163.net wrote: > > > > > > > Hi: > > > > > > > > Followed is My question: > > > > > > > > First,I do(I use E1,not T1): > > > > > > > > set interface slot:1/mod:[1-30] filter_access on > > > > show interface slot:1/mod:2 > > > > > > > > I find "filter access" is ON, then I do: > > > > > > > > save all > > > > show interface slot:/mod:2 > > > > > > > > the "filter access" is ON, then I do: > > > > > > > > reboot > > > > > > > > after a while, I do > > > > > > > > sh interface slot:/mod:2 > > > > > > > > the "filter access" is OFF, why? Obviously > > > > after reboot, the configuration have changed. > > > > I need "filter access" is ON always. > > > > > > > > > > > > > > > > > > > > > > > > ________________________________________________ > > > > ��ӭ��ʹ�ù����Ӵ���ѵ�������http://www.163.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. > > > > > > > > ________________________________________________ > > ��ӭ��ʹ�ù����Ӵ���ѵ�������http://www.163.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. ________________________________________________ ��ӭ��ʹ�ù����Ӵ���ѵ�������http://www.163.net

Hi, I'm trying to break a few ports out to analog lines on an a/d modem card with the analog nic. The rest of the chassis is working fine (it only has 1 CT1 coming in), but the analog lines just ring and ring. I've set line source to "nic", saved, reset, etc. Netserver shows "ARP". Is there another setting I'm missing? This is TCS 3.1.1 w/NetServer 3.7.73. Thanks, Charles ps- the searchable archive at usr-tc.datasys.net seems to be broken... =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

We had a similar problem and replacing the chassis fixed it. I thought it was a long shot since there is not much to fail in a chassis. I was wrong... Sincerely,=20 Chris Peltier=20 * email: CPeltier@NetCarrier.com * voice: 215-257-4917 * FAX: 215-257-4916 =20 >---------- >From: cntlxh@163.net[SMTP:cntlxh@163.net] >Sent: Tuesday, September 29, 1998 1:16 PM >To: usr-tc@lists.xmission.com >Subject: (usr-tc) Bad Hiper 130A chassis? > > >Hi, > > > >After installation of chassis to rack, > >it is time to view my chassis use TCM=20 > >for window, but strangly, TCM only=20 > >display NMC card and two Power module, > >other module(HARC,Hiper DSP)'s place > >have a big "?" on them. > >What's wrong with the chassis? We have=20 > >nothing to do with the 'bad' chassis, > >only to request 3COM replace the chassis > >with a good chassis. > >Do you have such a question? > >I think perhaps manage bus of the chassis is bad. > >How do you think? > > > >________________________________________________ >=BB=B6=D3=AD=C4=FA=CA=B9=D3=C3=B9=E3=D6=DD=CA=D3=B4=B0=C3=E2*=D1=B5=E7=D7= =D3=D3=CA=CF=E4http://www.163.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. >

We've had to set those ports inactive on the netserver in order for it to change the line interface option. And vice versus, if it's set to nic, it has to be active before it will hold the t1/or PRI setting. > > Hi, > > I'm trying to break a few ports out to analog lines on an a/d modem card > with the analog nic. The rest of the chassis is working fine (it only has > 1 CT1 coming in), but the analog lines just ring and ring. > > I've set line source to "nic", saved, reset, etc. > > Netserver shows "ARP". > > Is there another setting I'm missing? > > This is TCS 3.1.1 w/NetServer 3.7.73. > > Thanks, > > Charles > > ps- the searchable archive at usr-tc.datasys.net seems to be broken... > > =-----------------= = > | Charles Sprickman Internet Channel | > | INCH System Administration Team (212)243-5200 | > | spork@inch.com access@inch.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. >

Thus spake Charles Sprickman >I'm trying to break a few ports out to analog lines on an a/d modem card >with the analog nic. The rest of the chassis is working fine (it only has >1 CT1 coming in), but the analog lines just ring and ring. >I've set line source to "nic", saved, reset, etc. >Netserver shows "ARP". >Is there another setting I'm missing? No settings that I'm aware of...but if you have physical access...pull out the NIC and make sure that it has a (multiple) daughtercards on it...without these daughtercards (and you can see the tracings if you hodl it up to the light) there is no physical interconnect from the rj-11 jack to the rest of the circuitry. Only other thing I could think of would be to make sure you have analog capable modem cards...ie, not the digital only. Although I'm relatively certain I've seen digital only cards take analog calls on them in our hunt-group before we moved to digital connections...better safe than sorry. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

I'm only able to connect about once out of every 4-5 tries with my ThinkPad 385d Win95 using a USR Megahertz 33.6 modem. The times it won't connect, it dials in and starts emitting a squeal before advancing to the authentication stage. I'm dialing into a HiPer chassis running ARC 4.0.30, NMC 5.5.5, DSP 1.0.7 and USR Security & Accounting Server for Radius. Any ideas? TIA, Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

On Wed, 30 Sep 1998, Kevin Benton wrote: > On Tue, 29 Sep 1998, Terry Kennedy wrote: > > > Likewise here. One of the original 4 chassis we bought > > was bad. The NMC had a red light that would not go away. > > Everything else worked. We had the chassis replaced and > > the light went away > > > > > We had a similar problem and replacing the chassis > > > fixed it. I thought it was a long shot since there is > > > not much to fail in a chassis. I was wrong... > > (remainder deleted) > > We too had that problem. It wound up that the fan tray had (count 'em) 6 > fans INOP. Needless to say, the chassis temp went up over spec limit for > the NMC which turned the light red and would occasionally cause flakiness > > (skip) If you enable snmp traps and run a trap daemon to log the trap message you get alerts about things like fan failures. I had a similar problem and the NMC isssued a fan failure trap.

I have heard from a good source that the HiPer Trade Up program's deadline will be extended till September. They are also going to add a promotion for trading quad modem cards in for HiPer DSP's. It should be posted to their site soon..... ********************************************************* Jason Watkins jwatkins@iland.net I-Land Internet Services http://www.iland.net Support & Network Operations Center *********************************************************

Check you etc/hosts file. Put an entry for the hiper arc ip address there. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Wed, 30 Sep 1998, Steve Lalonde wrote: > Hi all > > can somone shed any light on this? > > I have just started setting up my first hyper arc > and all is great except it wont authenticate with my radius > > here is an extract from the merit radius log > > > Wed Sep 30 08:26:10 1998: Received-Authentication: 1/46994 'aic0057' from > warp8.enta.net port 2 $"65628" PPP > Wed Sep 30 08:26:10 1998: insert_attribute: Invalid attribute > Called-Station-Id (30), type 0, vendor 0 > Wed Sep 30 08:26:10 1998: avpair_out: > insert_attribute(Called-Station-Id(30), ..., 16536, 0x0x995c4, 0, 0x2, USR) > returns 0 > Wed Sep 30 08:26:10 1998: send_reply: avpair_out(Called-Station-Id(30), ..., > 16536, USR) for type reject returns 0 > Wed Sep 30 08:26:10 1998: Authentication: 1/46994 'aic0057' from > warp8.enta.net port 2 $"65628" PPP - FAILED Authentication failure -- total > 0, holding 0 > > > i have 2 netserver based tc's and they both work fine > > Ideas anyone > > TIA > > Steve Lalonde > Systems Manager > ENTANET International Ltd > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Hi all can somone shed any light on this? I have just started setting up my first hyper arc and all is great except it wont authenticate with my radius here is an extract from the merit radius log Wed Sep 30 08:26:10 1998: Received-Authentication: 1/46994 'aic0057' from warp8.enta.net port 2 $"65628" PPP Wed Sep 30 08:26:10 1998: insert_attribute: Invalid attribute Called-Station-Id (30), type 0, vendor 0 Wed Sep 30 08:26:10 1998: avpair_out: insert_attribute(Called-Station-Id(30), ..., 16536, 0x0x995c4, 0, 0x2, USR) returns 0 Wed Sep 30 08:26:10 1998: send_reply: avpair_out(Called-Station-Id(30), ..., 16536, USR) for type reject returns 0 Wed Sep 30 08:26:10 1998: Authentication: 1/46994 'aic0057' from warp8.enta.net port 2 $"65628" PPP - FAILED Authentication failure -- total 0, holding 0 i have 2 netserver based tc's and they both work fine Ideas anyone TIA Steve Lalonde Systems Manager ENTANET International Ltd

Can a cht1 card, and the quad modems it talks to, or an HDM, be configured to terminate a PRI that takes calls both from analog modems and ISDN users? Excuse my ignorance, please; I've never worked with ISDN. I've been under the impression that PRI == ISDN calls only, but our BellSouth salespeople told us that they can send analog calls down the B channels. Thanks.

Thus spake Mark R. Lindsey >Can a cht1 card, and the quad modems it talks to, or an HDM, be configured >to terminate a PRI that takes calls both from analog modems and ISDN >users? >Excuse my ignorance, please; I've never worked with ISDN. I've been under >the impression that PRI == ISDN calls only, but our BellSouth salespeople >told us that they can send analog calls down the B channels. Works like a charm. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Tue, 29 Sep 1998, Terry Kennedy wrote: > Likewise here. One of the original 4 chassis we bought > was bad. The NMC had a red light that would not go away. > Everything else worked. We had the chassis replaced and > the light went away > > > We had a similar problem and replacing the chassis > > fixed it. I thought it was a long shot since there is > > not much to fail in a chassis. I was wrong... (remainder deleted) We too had that problem. It wound up that the fan tray had (count 'em) 6 fans INOP. Needless to say, the chassis temp went up over spec limit for the NMC which turned the light red and would occasionally cause flakiness on it. We since instigated a procedure change - every time one of our roving tech's goes on-site to one of our pops, we have them check all the fan trays. We're also taking bottled air out with us occasionally and blowing all the dust off the bottom of the fan trays. It's helped a bunch with reliability. Kevin Benton Network Engineer SOTA Technologies E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

At 04:14 PM 9/27/98 -0700, MegaZone wrote: >Once upon a time Jeff Carneal shaped the electrons to say... >>We're running a couple of TC's here with some older code on it which does >>not support the Connect-Info radius attribute (ie, doesn't log connection >>speeds). I was curious if any of the newer Netserver releases have fixed >>this problem, or if upgrading would be futile. Thanks in advance... > >AFAIK 3Com decided not to use the RFC attribute, but has VSAs for speed >data. > As a customer just pointed out to me, Connect-Info(77) has NOT appeared in an RFC. And they were slightly annoyed to see it emmitted from our system. It has only appeared in a Draft extentions document, which has since expired. However we all expect it to become a standard attribute,... whenever. The real annoying thing about the USR speed attributes is that they are enumerated values. We went with a simple bit rate integer. Dave. >-MZ >-- ><URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. >Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> >"A little nonsense now and then, is relished by the wisest men" 781-788-0130 ><URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia! > ==================================================================== > ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. > Three days of clues, news, and views from the industry's best and > brightest. http://www.ispf.com/ for information and registration. > ==================================================================== > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 Mitton 978-670-8888 Main Consulting Engineer, Nortel 978-916-4570 Direct Carrier Packet Networks, I&SP Group 978-916-4789 FAX Billerica, MA 01821 dmitton@baynetworks.com

Once upon a time Dave Mitton shaped the electrons to say... >As a customer just pointed out to me, Connect-Info(77) has NOT appeared in >an RFC. And they were slightly annoyed to see it emmitted from our system. True - I would have been more accurate to say Draft RFC. Carl is behind in getting the updated drafts out, but Connect-Info is certainly one attribute that will live on. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

send me box with the return address and i'll give you a couple. I've got box's of them. Terry Kennedy 360 452 9755 > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Charles Sprickman > Sent: Wednesday, September 30, 1998 8:06 AM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Analog ports > > > On Tue, 29 Sep 1998, Jeff Mcadams wrote: > > > No settings that I'm aware of...but if you have physical access...pull > > out the NIC and make sure that it has a (multiple) daughtercards on > > it...without these daughtercards (and you can see the tracings if you > > hodl it up to the light) there is no physical interconnect from the > > rj-11 jack to the rest of the circuitry. > > ARGGH! Daughtercards... Where does one get these? What components are > on them? Does anyone have some they'd like to unload? I just need two... > > Thanks, > > Charles > > > > > Only other thing I could think of would be to make sure you have analog > > capable modem cards...ie, not the digital only. Although I'm relatively > > certain I've seen digital only cards take analog calls on them in our > > hunt-group before we moved to digital connections...better safe > than sorry. > > -- > > 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. > > > > =-----------------= = > | Charles Sprickman Internet Channel | > | INCH System Administration Team (212)243-5200 | > | spork@inch.com access@inch.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. >

On Tue, 29 Sep 1998, Jeff Mcadams wrote: > No settings that I'm aware of...but if you have physical access...pull > out the NIC and make sure that it has a (multiple) daughtercards on > it...without these daughtercards (and you can see the tracings if you > hodl it up to the light) there is no physical interconnect from the > rj-11 jack to the rest of the circuitry. ARGGH! Daughtercards... Where does one get these? What components are on them? Does anyone have some they'd like to unload? I just need two... Thanks, Charles > > Only other thing I could think of would be to make sure you have analog > capable modem cards...ie, not the digital only. Although I'm relatively > certain I've seen digital only cards take analog calls on them in our > hunt-group before we moved to digital connections...better safe than sorry. > -- > 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. > =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

Thus spake Charles Sprickman >On Tue, 29 Sep 1998, Jeff Mcadams wrote: >> No settings that I'm aware of...but if you have physical access...pull >> out the NIC and make sure that it has a (multiple) daughtercards on >> it...without these daughtercards (and you can see the tracings if you >> hodl it up to the light) there is no physical interconnect from the >> rj-11 jack to the rest of the circuitry. >ARGGH! Daughtercards... Where does one get these? What components are >on them? Does anyone have some they'd like to unload? I just need two... Heh...wups...we had that happen...sent them back to 3Com for ones with the daughtercards as they were supposed to have them. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Wed, 30 Sep 1998, Jeff Mcadams wrote: > >ARGGH! Daughtercards... Where does one get these? What components are > >on them? Does anyone have some they'd like to unload? I just need two... > > Heh...wups...we had that happen...sent them back to 3Com for ones with > the daughtercards as they were supposed to have them. Well, this chassis was a "gift", so it's unsupported, so if anyone has two of these daughtercards for the analog nics that they'd like to sell, please contact me... Thanks, Charles > -- > 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. > =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

Thus spake Charles Sprickman >On Wed, 30 Sep 1998, Jeff Mcadams wrote: >> >ARGGH! Daughtercards... Where does one get these? What components are >> >on them? Does anyone have some they'd like to unload? I just need two... >> >> Heh...wups...we had that happen...sent them back to 3Com for ones with >> the daughtercards as they were supposed to have them. >Well, this chassis was a "gift", so it's unsupported, so if anyone has >two of these daughtercards for the analog nics that they'd like to sell, >please contact me... Well...ours wasn't replaced on a "warrenty" type of basis, but on a hrmm...these were supposed to have the daughtercard basis, wups, we screwed up...might be worth it getting ahold of 3Com about it...can't hurt (except for the time on hold) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

I'm having a *hell* of a time getting a Sportster 128K ISDN to work correctly with our v.90 HDM's. It seems to talk to our v.90 Quads fine (at least for a single channel call; after playing with it all morning it now can't even bring up a dual-channel call to the same quad chassis...) It's an internal and it's running under NT (which sees it as a network card instead of as a modem), and it doesn't seem to have much in the way of settings I can change at all. What's the correct combination of HDM ISDN settings to make this silly thing work? Right now I have the following: (This is from a Perl script I use to program modem cards. Pretend all the OID's in the first column have "1.3.6.1.4.1.429.1" glued on the front.) I'm also open for recommendations on other ISDN adapters he can get (Motorola? Adtran? Ascend?) that NT is reasonably happy with. "19.1.1.1.2/imdmCcRateAdapV110", "i 2", # 2=enable "19.1.1.1.3/imdmCcFixedNtwkRate", "i 1", # 1=notforced "19.1.1.1.4/imdmCcNetworkRate", "i 1", # 1=56k "19.1.1.1.5/imdmCcBcLinkDly", "i 1", # 1=nodelay "19.1.1.1.6/imdmCcAnlgOvrDig", "i 1", # enable=1 "19.1.1.1.7/imdmCcAsyncPPP", "i 1/i 1", # enable=1 disable=2 "19.1.1.1.8/imdmCcX75", "i 1", # enable=1 "19.1.1.1.9/imdmCcStarV2", "i 1", # 1=auto "19.1.1.1.10/imdmCcStarU1", "i 2", # 2=v120 "19.1.1.1.11/imdmCcStarU2", "i 1", # 1=none "19.1.1.1.12/imdmCcStarU3", "i 2", # 2=analogmodemfax "19.1.1.1.13/imdmCcV120", "i 1", # 1=enable "19.1.1.1.14/imdmCcFrameSize", "i 2048", "19.1.1.1.15/imdmCcWindowSize", "i 2", Mike Andrews (MA12) icq 6602506 -------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "If Barbie is so popular, why do you have to buy her friends?..."

I'm having a *hell* of a time getting a Sportster 128K ISDN to work correctly with our v.90 HDM's. It seems to talk to our v.90 Quads fine (at least for a single channel call; after playing with it all morning it now can't even bring up a dual-channel call to the same quad chassis...) It's an internal and it's running under NT (which sees it as a network card instead of as a modem), and it doesn't seem to have much in the way of settings I can change at all. What's the correct combination of HDM ISDN settings to make this silly thing work? Right now I have the following: (This is from a Perl script I use to program modem cards. Pretend all the OID's in the first column have "1.3.6.1.4.1.429.1" glued on the front.) I'm also open for recommendations on other ISDN adapters he can get (Motorola? Adtran? Ascend?) that NT is reasonably happy with. "19.1.1.1.2/imdmCcRateAdapV110", "i 2", # 2=enable "19.1.1.1.3/imdmCcFixedNtwkRate", "i 1", # 1=notforced "19.1.1.1.4/imdmCcNetworkRate", "i 1", # 1=56k "19.1.1.1.5/imdmCcBcLinkDly", "i 1", # 1=nodelay "19.1.1.1.6/imdmCcAnlgOvrDig", "i 1", # enable=1 "19.1.1.1.7/imdmCcAsyncPPP", "i 1/i 1", # enable=1 disable=2 "19.1.1.1.8/imdmCcX75", "i 1", # enable=1 "19.1.1.1.9/imdmCcStarV2", "i 1", # 1=auto "19.1.1.1.10/imdmCcStarU1", "i 2", # 2=v120 "19.1.1.1.11/imdmCcStarU2", "i 1", # 1=none "19.1.1.1.12/imdmCcStarU3", "i 2", # 2=analogmodemfax "19.1.1.1.13/imdmCcV120", "i 1", # 1=enable "19.1.1.1.14/imdmCcFrameSize", "i 2048", "19.1.1.1.15/imdmCcWindowSize", "i 2", Mike Andrews (MA12) icq 6602506 -------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "If Barbie is so popular, why do you have to buy her friends?..."

Currently, I have a 70A chassis, with an ARC, NMC, and 3 DSPs. I was planning to add another 2 DSP cards to this chassis. Where's the limitation - when do I need a second power supply? What does a second supply give me? Thanks. -- Gilles Melanson ViaNet Internet Solutions System Administrator 128 Larch St. Suite 301 gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8 "One World, One Web, One Program" - Microsoft Promotional Ad "Ein Reich, Ein Volk, Ein Fuhrer" - Adolf Hitler

Currently, I have a 70A chassis, with an ARC, NMC, and 3 DSPs. I was planning to add another 2 DSP cards to this chassis. Where's the limitation - when do I need a second power supply? What does a second supply give me? Thanks. -- Gilles Melanson ViaNet Internet Solutions System Administrator 128 Larch St. Suite 301 gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8 "One World, One Web, One Program" - Microsoft Promotional Ad "Ein Reich, Ein Volk, Ein Fuhrer" - Adolf Hitler

You need to go to the 130A when you have more than 10 cards, also another HiPer ARC is suggested. -Frank -----Original Message----- >Currently, I have a 70A chassis, with an ARC, NMC, and 3 DSPs. >I was planning to add another 2 DSP cards to this chassis. > >Where's the limitation - when do I need a second power supply? >What does a second supply give me? > >Thanks. > >-- >Gilles Melanson ViaNet Internet Solutions >System Administrator 128 Larch St. Suite 301 >gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8 > >"One World, One Web, One Program" >- Microsoft Promotional Ad >"Ein Reich, Ein Volk, Ein Fuhrer" >- Adolf Hitler > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Mike, Just make sure that Sync to Async PPP is enabled on the HDM. The SP128K only supports SyncPPP. Does it fail at verifying user name and password? If it does then run a ppp trace from your NT machine. If it doesn't get that far then use the protocol monitor that comes with the SP128K and capture the Q.931 messages. Vito Mike Andrews <mandrews@termfrost.org> on 09/30/98 10:49:15 AM Please respond to usr-tc@lists.xmission.com cc: (Vito Maselli/MW/US/3Com) I'm having a *hell* of a time getting a Sportster 128K ISDN to work correctly with our v.90 HDM's. It seems to talk to our v.90 Quads fine (at least for a single channel call; after playing with it all morning it now can't even bring up a dual-channel call to the same quad chassis...) It's an internal and it's running under NT (which sees it as a network card instead of as a modem), and it doesn't seem to have much in the way of settings I can change at all. What's the correct combination of HDM ISDN settings to make this silly thing work? Right now I have the following: (This is from a Perl script I use to program modem cards. Pretend all the OID's in the first column have "1.3.6.1.4.1.429.1" glued on the front.) I'm also open for recommendations on other ISDN adapters he can get (Motorola? Adtran? Ascend?) that NT is reasonably happy with. "19.1.1.1.2/imdmCcRateAdapV110", "i 2", # 2=enable "19.1.1.1.3/imdmCcFixedNtwkRate", "i 1", # 1=notforced "19.1.1.1.4/imdmCcNetworkRate", "i 1", # 1=56k "19.1.1.1.5/imdmCcBcLinkDly", "i 1", # 1=nodelay "19.1.1.1.6/imdmCcAnlgOvrDig", "i 1", # enable=1 "19.1.1.1.7/imdmCcAsyncPPP", "i 1/i 1", # enable=1 disable=2 "19.1.1.1.8/imdmCcX75", "i 1", # enable=1 "19.1.1.1.9/imdmCcStarV2", "i 1", # 1=auto "19.1.1.1.10/imdmCcStarU1", "i 2", # 2=v120 "19.1.1.1.11/imdmCcStarU2", "i 1", # 1=none "19.1.1.1.12/imdmCcStarU3", "i 2", # 2=analogmodemfax "19.1.1.1.13/imdmCcV120", "i 1", # 1=enable "19.1.1.1.14/imdmCcFrameSize", "i 2048", "19.1.1.1.15/imdmCcWindowSize", "i 2", Mike Andrews (MA12) icq 6602506 -------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "If Barbie is so popular, why do you have to buy her friends?..." - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Make sure you are using PAP and NO VJ compression. These are bad for the Sportster. -Frank -----Original Message----- >I'm having a *hell* of a time getting a Sportster 128K ISDN to work >correctly with our v.90 HDM's. It seems to talk to our v.90 Quads fine >(at least for a single channel call; after playing with it all morning it >now can't even bring up a dual-channel call to the same quad chassis...) > >It's an internal and it's running under NT (which sees it as a network >card instead of as a modem), and it doesn't seem to have much in the way >of settings I can change at all. > >What's the correct combination of HDM ISDN settings to make this silly >thing work? Right now I have the following: >(This is from a Perl script I use to program modem cards. Pretend all >the OID's in the first column have "1.3.6.1.4.1.429.1" glued on the >front.) > >I'm also open for recommendations on other ISDN adapters he can get >(Motorola? Adtran? Ascend?) that NT is reasonably happy with. > >"19.1.1.1.2/imdmCcRateAdapV110", "i 2", # 2=enable >"19.1.1.1.3/imdmCcFixedNtwkRate", "i 1", # 1=notforced >"19.1.1.1.4/imdmCcNetworkRate", "i 1", # 1=56k >"19.1.1.1.5/imdmCcBcLinkDly", "i 1", # 1=nodelay >"19.1.1.1.6/imdmCcAnlgOvrDig", "i 1", # enable=1 >"19.1.1.1.7/imdmCcAsyncPPP", "i 1/i 1", # enable=1 disable=2 >"19.1.1.1.8/imdmCcX75", "i 1", # enable=1 >"19.1.1.1.9/imdmCcStarV2", "i 1", # 1=auto >"19.1.1.1.10/imdmCcStarU1", "i 2", # 2=v120 >"19.1.1.1.11/imdmCcStarU2", "i 1", # 1=none >"19.1.1.1.12/imdmCcStarU3", "i 2", # 2=analogmodemfax >"19.1.1.1.13/imdmCcV120", "i 1", # 1=enable >"19.1.1.1.14/imdmCcFrameSize", "i 2048", >"19.1.1.1.15/imdmCcWindowSize", "i 2", > > > >Mike Andrews (MA12) icq 6602506 -------- mandrews@termfrost.org >VP 'n' Systems/Network Administrator --------- mandrews@dcr.net >Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ >"If Barbie is so popular, why do you have to buy her friends?..." > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Got about..Hmmmmm I think 90 of those, though ours are cracked to 56k. -Frank -----Original Message----- Cc: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >Cool! I will do that... > >Would you like a rare "For Promotional Use Only - Not for Resale" Courier >from the early-mid 90's in exchange? Already flashed to 33.6... > >Thanks, > >Charles > >On Wed, 30 Sep 1998, Terry Kennedy wrote: > >> Date: Wed, 30 Sep 1998 10:46:47 -0700 >> From: Terry Kennedy <terry@olypen.com> >> Reply-To: usr-tc@lists.xmission.com >> To: usr-tc@lists.xmission.com >> Subject: RE: (usr-tc) Analog ports >> >> send me box with the return address and i'll give you a couple. >> I've got box's of them. >> >> Terry Kennedy >> 360 452 9755 >> >> >> > -----Original Message----- >> > From: owner-usr-tc@lists.xmission.com >> > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Charles Sprickman >> > Sent: Wednesday, September 30, 1998 8:06 AM >> > To: usr-tc@lists.xmission.com >> > Subject: Re: (usr-tc) Analog ports >> > >> > >> > On Tue, 29 Sep 1998, Jeff Mcadams wrote: >> > >> > > No settings that I'm aware of...but if you have physical access...pull >> > > out the NIC and make sure that it has a (multiple) daughtercards on >> > > it...without these daughtercards (and you can see the tracings if you >> > > hodl it up to the light) there is no physical interconnect from the >> > > rj-11 jack to the rest of the circuitry. >> > >> > ARGGH! Daughtercards... Where does one get these? What components are >> > on them? Does anyone have some they'd like to unload? I just need two... >> > >> > Thanks, >> > >> > Charles >> > >> > > >> > > Only other thing I could think of would be to make sure you have analog >> > > capable modem cards...ie, not the digital only. Although I'm relatively >> > > certain I've seen digital only cards take analog calls on them in our >> > > hunt-group before we moved to digital connections...better safe >> > than sorry. >> > > -- >> > > 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. >> > > >> > >> > =-----------------= = >> > | Charles Sprickman Internet Channel | >> > | INCH System Administration Team (212)243-5200 | >> > | spork@inch.com access@inch.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. >> > >=-----------------= = >| Charles Sprickman Internet Channel | >| INCH System Administration Team (212)243-5200 | >| spork@inch.com access@inch.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. >

Have 20 PRI's doing it everyday. -Frank -----Original Message----- >Thus spake Mark R. Lindsey >>Can a cht1 card, and the quad modems it talks to, or an HDM, be configured >>to terminate a PRI that takes calls both from analog modems and ISDN >>users? > >>Excuse my ignorance, please; I've never worked with ISDN. I've been under >>the impression that PRI == ISDN calls only, but our BellSouth salespeople >>told us that they can send analog calls down the B channels. > >Works like a charm. >-- >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. >

Cool! I will do that... Would you like a rare "For Promotional Use Only - Not for Resale" Courier from the early-mid 90's in exchange? Already flashed to 33.6... Thanks, Charles On Wed, 30 Sep 1998, Terry Kennedy wrote: > Date: Wed, 30 Sep 1998 10:46:47 -0700 > From: Terry Kennedy <terry@olypen.com> > Reply-To: usr-tc@lists.xmission.com > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) Analog ports > > send me box with the return address and i'll give you a couple. > I've got box's of them. > > Terry Kennedy > 360 452 9755 > > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Charles Sprickman > > Sent: Wednesday, September 30, 1998 8:06 AM > > To: usr-tc@lists.xmission.com > > Subject: Re: (usr-tc) Analog ports > > > > > > On Tue, 29 Sep 1998, Jeff Mcadams wrote: > > > > > No settings that I'm aware of...but if you have physical access...pull > > > out the NIC and make sure that it has a (multiple) daughtercards on > > > it...without these daughtercards (and you can see the tracings if you > > > hodl it up to the light) there is no physical interconnect from the > > > rj-11 jack to the rest of the circuitry. > > > > ARGGH! Daughtercards... Where does one get these? What components are > > on them? Does anyone have some they'd like to unload? I just need two... > > > > Thanks, > > > > Charles > > > > > > > > Only other thing I could think of would be to make sure you have analog > > > capable modem cards...ie, not the digital only. Although I'm relatively > > > certain I've seen digital only cards take analog calls on them in our > > > hunt-group before we moved to digital connections...better safe > > than sorry. > > > -- > > > 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. > > > > > > > =-----------------= = > > | Charles Sprickman Internet Channel | > > | INCH System Administration Team (212)243-5200 | > > | spork@inch.com access@inch.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. > =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

-----Original Message----- >Once upon a time Dave Mitton shaped the electrons to say... >>As a customer just pointed out to me, Connect-Info(77) has NOT appeared in >>an RFC. And they were slightly annoyed to see it emmitted from our system. > >True - I would have been more accurate to say Draft RFC. Carl is behind >in getting the updated drafts out, but Connect-Info is certainly one >attribute that will live on. > Yeah, now if we could just get some NAS'es to support it :( (Do the HiPerARC's support it?) Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com

I think he said ARC not netserver -----Original Message----- >I have mrtg working on netservers sample bellow > >Has anyone got the oid for the harc? > > >sample code:- > >Options[^]: gauge,absolute >Target[netserver.modems]: >1.3.6.1.2.1.2.1.0&1.3.6.1.2.1.2.1.0:yourpubliccomunity@netserver.com >MaxBytes[netserver.modems]: 30 >Title[netserver.modems]: netserver >PageTop[netserver.modems]: netserver >#Unscaled[netserver.modems]: dwmy >YLegend[netserver.modems]: Modems in use >ShortLegend[netserver.modems]: modems >Legend1[netserver.modems]: Number of modems in use >LegendI[netserver.modems]: &nbsp; in use >LegendO[netserver.modems]: >Directory[netserver.modems]: modems > > >Steve Lalonde >Systems Manager >ENTANET International Ltd > > > > >-----Original Message----- >From: Jamie Orzechowski <mhz@recorder.ca> >To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >Date: 30 September 1998 20:40 >Subject: (usr-tc) MRTG cfg > > >>I was wondering if anyone is using MRTG to graph modem usage via MRTG .. if >>so could somone post sample MRTG cfg files ... thanks! >> >>-------------------------------------------------------------- >>Jamie Orzechowski >>RipNET Internet System Administrator >> >>Tel.: (613)342-3946 ext 293 >>Tel.: (800)267-4434 ext 293 >>Fax.: (613)342-8672 >>Page.: (613)341-0883 >>EMail.: mailto:mhz@recorder.ca >>Web.: http://www.moonchilli.com >> >>There is a $50 Fee for the processing of unsolicited EMail send to this >>address. >>-------------------------------------------------------------- >> >> >>- >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and 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. >

I was wondering if anyone is using MRTG to graph modem usage via MRTG .. if so could somone post sample MRTG cfg files ... thanks! Jamie Orzechowski RipNET Internet System Administrator Tel.: (613)342-3946 ext 293 Tel.: (800)267-4434 ext 293 Fax.: (613)342-8672 Page.: (613)341-0883 EMail.: mailto:mhz@recorder.ca Web.: http://www.moonchilli.com There is a $50 Fee for the processing of unsolicited EMail send to this address.

Thanks for the help. Would I be right to guess that v.90 and X2 work on such lines, too. : Have 20 PRI's doing it everyday. : : >Thus spake Mark R. Lindsey : >>Can a cht1 card, and the quad modems it talks to, or an HDM, be configured : >>to terminate a PRI that takes calls both from analog modems and ISDN : >>users? : > : >>Excuse my ignorance, please; I've never worked with ISDN. I've been under : >>the impression that PRI == ISDN calls only, but our BellSouth salespeople : >>told us that they can send analog calls down the B channels. : > : >Works like a charm.

Thus spake Mark R. Lindsey >Thanks for the help. >Would I be right to guess that v.90 and X2 work on such lines, too. Just hunky-dory. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Hi, How does one go about removing the message that is displayed _before_ the login prompt on HiPerARC via CLI? It seems that v1.1.8 of the HARC software does not allow you to change this. Thanks! -Brian -- # Brian Biggs | Sonic / Sonoma Interconnect # # Sys Admin / Programmer | v707.522.1000 fax707.547.2199 d707.522.1001 # # mailto:bb@sonic.net | http://www.sonic.net mailto:support@sonic.net #

I have been searching, with snmpwalk, everywhere for the idle and total connect time for a current call for Total Control racks with HiperARC or Netserver cards. We have far more Lucent/Livingston PM2 and PM3 units and this information is available in the enterprise mib values for them. That USR/3COM doesn't have this data available will result in our decision to not purchase any more of these units. We use a package to manage modems and times that requires the availability of idle times and total connect times. Note: setting call and idle limits at login time is completly unacceptable when we have a dynamic monitoring tool available. It is completely unacceptable that a device marketed as just as good, if not better, than the other alternatives would lack such a feature. Please, someone prove me wrong! Post the MIB var for IDLE or TOTAL CONNECT TIME for a netserver or hyperarc card in a total control rack or mail me directly. Richard "frustrated with 3com tech support" Stuplich dick@dwave.net

I get the following error when I use this ... like it's trying to change to a directory for some strange reason ... I just replaces the community string with my own communityr string and the address ... cfgmaker will return values so I know the community string is working properly .. any ideas? [root@cc mrtg]# mrtg mrtg.cfg Rateup ERROR: Chdir to /usr/local/etc/httpd/htdocs/mrtg/modems/ failed ... PROBLEM: rateup died from Signal 0 with Exit Value 1 when doing router 'netserver1' If this happens all the time, you should probably investigate the cause. :-) -----Original Message----- >I have mrtg working on netservers sample bellow > >Has anyone got the oid for the harc? > > >sample code:- > >Options[^]: gauge,absolute >Target[netserver.modems]: >1.3.6.1.2.1.2.1.0&1.3.6.1.2.1.2.1.0:yourpubliccomunity@netserver.com >MaxBytes[netserver.modems]: 30 >Title[netserver.modems]: netserver >PageTop[netserver.modems]: netserver >#Unscaled[netserver.modems]: dwmy >YLegend[netserver.modems]: Modems in use >ShortLegend[netserver.modems]: modems >Legend1[netserver.modems]: Number of modems in use >LegendI[netserver.modems]: &nbsp; in use >LegendO[netserver.modems]: >Directory[netserver.modems]: modems > > >Steve Lalonde >Systems Manager >ENTANET International Ltd > > > > >-----Original Message----- >From: Jamie Orzechowski <mhz@recorder.ca> >To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >Date: 30 September 1998 20:40 >Subject: (usr-tc) MRTG cfg > > >>I was wondering if anyone is using MRTG to graph modem usage via MRTG .. if >>so could somone post sample MRTG cfg files ... thanks! >> >>-------------------------------------------------------------- >>Jamie Orzechowski >>RipNET Internet System Administrator >> >>Tel.: (613)342-3946 ext 293 >>Tel.: (800)267-4434 ext 293 >>Fax.: (613)342-8672 >>Page.: (613)341-0883 >>EMail.: mailto:mhz@recorder.ca >>Web.: http://www.moonchilli.com >> >>There is a $50 Fee for the processing of unsolicited EMail send to this >>address. >>-------------------------------------------------------------- >> >> >>- >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and 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. >