December 1998

Subject: (usr-tc) NETserver taplogin feature
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-12-01 16:36:48

Has anyone used the "taplogin" feature on the NETserver I'm trying to use it to write a PPP debugger -- sort of like Livingston's PPP decoder ring, or like the "monitor ppp" command on the ARC. I have it working fine on the ARC. On the NETserver, the first thing I tried was something like "set s16 tap framed". But this only seems to record data AFTER LCP/PAP/IPCP negotiation has finished. (A quick look in the manual says this is how it's supposed to work.) So, to get the PPP negotiation I have to use the global command "set taplogin on". The problem I'm having is that once it starts sending data in packet form, it throws away all outbound packets and only logs incoming. In other words, there are no "TAP FRAMED OUT" lines in this output. So I only see half the conversation. :) Am I missing something here? Dec 1 00:01:46 <4.6> fra1-ns TAP RAW IN(1) S16: 7E FF 7D 23 C0 21 7D 21 7D 21 7D 20 7D 37 7D 22 7D 26 7D 20 7D 2A 7D 20 7D 20 7D 25 7D 26 7D 20 Dec 1 00:01:46 <4.6> fra1-ns TAP RAW IN(2) S16: 74 88 5A 7D 27 7D 22 7D 28 7D 22 7D 2D 7D 23 7D 26 7D 21 A2 7E Dec 1 00:01:47 <4.6> fra1-ns TAP RAW OUT(1) S16: 0D 0A 44 69 67 69 74 61 6C 20 43 72 65 73 63 65 6E 74 2C 20 49 6E 63 20 2D 2D 20 66 72 61 31 2D Dec 1 00:01:47 <4.6> fra1-ns TAP RAW OUT(2) S16: 6E 73 2E 64 63 72 2E 6E 65 74 0D 0A 0D 0A 6C 6F 67 69 6E 3A 20 Dec 1 00:01:49 <4.6> fra1-ns TAP RAW IN(1) S16: 7E FF 7D 23 C0 21 7D 21 7D 22 7D 20 7D 37 7D 22 7D 26 7D 20 7D 2A 7D 20 7D 20 7D 25 7D 26 7D 20 Dec 1 00:01:49 <4.6> fra1-ns TAP RAW IN(2) S16: 74 88 5A 7D 27 7D 22 7D 28 7D 22 7D 2D 7D 23 7D 26 F7 51 7E Dec 1 00:01:49 <4.6> fra1-ns TAP RAW OUT(1) S16: 7E 08 20 08 7D 23 0D 0A 50 50 50 20 73 65 73 73 69 6F 6E 20 66 72 6F 6D 20 28 32 30 36 2E 32 34 Dec 1 00:01:49 <4.6> fra1-ns TAP RAW OUT(2) S16: 30 2E 31 33 30 2E 31 30 29 20 74 6F 20 4E 65 67 6F 74 69 61 74 65 64 20 62 65 67 69 6E 6E 69 6E Dec 1 00:01:49 <4.6> fra1-ns TAP RAW OUT(3) S16: 67 2E 2E 2E 2E Dec 1 00:01:49 <4.6> fra1-ns TAP FRAMED IN(1) S16: FF 03 C0 21 02 01 00 1C 01 04 05 DC 02 06 00 00 00 00 05 06 4C E8 8C 53 07 02 08 02 03 04 C0 23 Dec 1 00:01:52 <4.6> fra1-ns TAP FRAMED IN(1) S16: FF 03 C0 21 01 03 00 17 02 06 00 0A 00 00 05 06 00 74 88 5A 07 02 08 02 0D 03 06 Dec 1 00:01:52 <4.6> fra1-ns TAP FRAMED IN(1) S16: FF 03 C0 21 01 04 00 14 02 06 00 0A 00 00 05 06 00 74 88 5A 07 02 08 02 Dec 1 00:01:52 <4.6> fra1-ns TAP FRAMED IN(1) S16: C0 23 01 01 00 15 08 (username edited out) 07 (password edited out) Dec 1 00:01:52 <4.6> fra1-ns TAP FRAMED IN(1) S16: 80 21 01 01 00 28 02 06 00 2D 0F 01 03 06 00 00 00 00 81 06 00 00 00 00 82 06 00 00 00 00 83 06 Dec 1 00:01:52 <4.6> fra1-ns TAP FRAMED IN(2) S16: 00 00 00 00 84 06 00 00 00 00 Dec 1 00:01:52 <4.6> fra1-ns TAP FRAMED IN(1) S16: 80 FD 01 01 00 0F 12 06 00 00 00 01 11 05 00 01 04 Dec 1 00:01:52 <4.6> fra1-ns TAP FRAMED IN(1) S16: 80 21 02 01 00 10 02 06 00 2D 0F 00 03 06 CE F0 82 0A Dec 1 00:01:52 <4.6> fra1-ns TAP FRAMED IN(1) S16: 80 21 01 02 00 22 02 06 00 2D 0F 01 03 06 00 00 00 00 81 06 00 00 00 00 82 06 00 00 00 00 83 06 Dec 1 00:01:52 <4.6> fra1-ns TAP FRAMED IN(2) S16: 00 00 00 00 Dec 1 00:01:52 <4.6> fra1-ns TAP FRAMED IN(1) S16: 80 FD 02 01 00 09 11 05 00 01 04 Dec 1 00:01:52 <4.6> fra1-ns TAP FRAMED IN(1) S16: 80 21 01 03 00 22 02 06 00 2D 0F 01 03 06 00 00 00 00 81 06 00 00 00 00 82 06 00 00 00 00 83 06 Dec 1 00:01:52 <4.6> fra1-ns TAP FRAMED IN(2) S16: CE F0 82 07 Dec 1 00:01:53 <4.6> fra1-ns TAP FRAMED IN(1) S16: 80 21 01 04 00 1C 02 06 00 2D 0F 01 03 06 00 00 00 00 81 06 00 00 00 00 83 06 CE F0 82 07 Dec 1 00:01:53 <4.6> fra1-ns TAP FRAMED IN(1) S16: 80 21 01 05 00 1C 02 06 00 2D 0F 01 03 06 C7 4D 64 36 81 06 CE F0 82 02 83 06 CE F0 82 07 Dec 1 00:01:55 <4.6> fra1-ns TAP FRAMED IN(1) S16: 80 FD 01 02 00 09 11 05 00 01 04 Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ # view;touch;unzip;finger;mount;mv;mv;mv;yes;mv;yes;mv;yes;umount;sleep

Subject: Re: (usr-tc) HARC is loosing Authentication requests
From: K Mitchell <mitch@keyconn.net>
Date: 1998-12-01 18:03:18

At 09:48 AM 12/1/98 -0600, you wrote: >Hello! > >Ever since we upgraded HARC from 4.0.30 to 4.1.11 and 4.1.72 later, it's >dropping at least 15% of PAP authentication requests. Clients are >getting disconnecteds with "No PAP auth response" message under unix or >os/2 and "Server is not responding" under Windows, nothing ever >beeing sent to neither radius server, and this clients can connect only >after the second or the third dial in attempt. I'm looking to upgrade from 4.0.30 to 4.1.72 myself. Is anybody else seeing this problem or any other issues to be aware of with 4.1.72? Thanks, Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

Subject: Re: (usr-tc) Deleting netserver config?
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-12-01 18:21:20

Jesse Sipprell was heard to say: >Is there a way to completely delete a netserver's configuration (3.8.1)? (aside from the dip switch) 'erase config' (or is it 'erase flash') will commit an empty config to flash. It doesn't erase the net0 setup so you can safely do this remotely to clear out a netserver. --Ricky

Subject: Re: (usr-tc) Deleting netserver config?
From: David Bolen <db3l@ans.net>
Date: 1998-12-01 18:35:18

Ricky Beam <jfbeam@Interpath.net> writes: > 'erase config' (or is it 'erase flash') will commit an empty config to flash. erase flash > It doesn't erase the net0 setup so you can safely do this remotely to clear > out a netserver. Right. And if you have any concern about problems with the prior flash configuration that might have adversely impacted the in-memory configuration of the NETServer, you should probably reboot after issuing the erase command, prior to reconfiguring, to ensure that it has loaded and is running from the fresh flash configuration. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: RE: (usr-tc) Upgrading Network Manager Card 4Meg. ....
From: Mahinder Kumar <mahinderj@ohitelecom.com>
Date: 1998-12-01 18:57:43

Thanks a lot Victor. I could upgrade NMC by following the steps you suggested. Regards,

Subject: (usr-tc) Problem starting up TC.
From: Mathias Herberts <mathias.herberts@ago.fr>
Date: 1998-12-02 08:37:49

Hi, I have recently acquired a Total Control 30 port bundle which includes : TC chassis removable fan tray 1 130A PSU 1 E1/PRI card 8 quad modems 1 HiperARC 1 NMC We hooked up a console on the HiperARC (RS232C port), configured both the terminal and the HiperARC to 19200 8N1 and powered up the chassis. No T2 lines (E1) are hooked on the E1/PRI. The console prints : BOOT PROM 1.15 (built on August 17 12:24:24) Kernel loading ... OK then nothing. The Alrm1 and Alrm2 leds of the E1/PRI are solid red (since no lines are hooked), the Hub Status led of the NMC goes solid red then back to solid green at boot time. Is there anything else to do to start up a TC ? Does the console needs to support some sort of flow control in order to function properly with the HiperARC ? I'd really like to get this baby up and running some time -) Any help would be appreciated, thanks, Mathias Herberts.

Subject: RE: (usr-tc) Deleting netserver config?
From: Sys Mgr - BrunNet <"stainforth, matthew (sys mgr - brunnet)">
Date: 1998-12-02 09:54:09

On Tuesday, December 01, 1998 7:35 PM, David Bolen [SMTP:db3l@ans.net] wrote: > Ricky Beam <jfbeam@Interpath.net> writes: > > > 'erase config' (or is it 'erase flash') will commit an empty config to flash. > > erase flash > > > It doesn't erase the net0 setup so you can safely do this remotely to clear > > out a netserver. > > Right. And if you have any concern about problems with the prior > flash configuration that might have adversely impacted the in-memory > configuration of the NETServer, you should probably reboot after > issuing the erase command, prior to reconfiguring, to ensure that it > has loaded and is running from the fresh flash configuration. Does that clear the !root password? Be Seeing You... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Matthew Stainforth<>Technical Services Manager<>BrunNet Inc.<>(506)450-4562 Don't rush me, sonny. You rush a miracle maker and you get rotten miracles. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Subject: Re: (usr-tc) Debugging PPP on ARC
From: sagarwal@crash.ae.usr.com
Date: 1998-12-02 10:29:55

On ARC the following command is used to debug PPP negotiation problems Hiper> Monitor PPP You will get some options from which you can choose the appropriate one. thanks Sanjay On Wed, 2 Dec 1998, Jesse Sipprell wrote: > What is the process that is typically used to debug PPP problems on the > HiperARC? Since we upgraded one of our POPs from a Netserver, we _seem_ to be > experiencing a large number of "PPP negotiation" problems. The techs have > informed me that often these are fixed by having the client specify DNS > addresses manually, but sometimes the reverse works ("server assigned"). > > Thanks! > > -- > Jesse Sipprell > Technical Operations Director > Evolution Communications, Inc. > 800-496-4736 (ext 106) > > * Finger jss@evcom.net for my PGP Public Key * > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Deleting netserver config?
From: Jesse Sipprell <jss@evcom.net>
Date: 1998-12-02 10:55:07

On Wed, Dec 02, 1998 at 09:54:09AM -0400, Stainforth, Matthew (Sys Mgr - BrunNet) wrote: > On Tuesday, December 01, 1998 7:35 PM, David Bolen [SMTP:db3l@ans.net] > wrote: > > Ricky Beam <jfbeam@Interpath.net> writes: > > > > > 'erase config' (or is it 'erase flash') will commit an empty config to > flash. > > > > erase flash > > > > > It doesn't erase the net0 setup so you can safely do this remotely to > clear > > > out a netserver. > > > > Right. And if you have any concern about problems with the prior > > flash configuration that might have adversely impacted the in-memory > > configuration of the NETServer, you should probably reboot after > > issuing the erase command, prior to reconfiguring, to ensure that it > > has loaded and is running from the fresh flash configuration. > > Does that clear the !root password? Yes. After I received the initial much appreciated response, I used dip switch 5 to erase the config (the chassis was sitting right in front of me). Today, I used the 'erase flash' method to clear a netserver, and it worked quite well (everything except net0 was erased, including !root password). I wish the ARC had a similar configuration erase method that DIDN'T make the box inaccessible remotely. Or does it?? > > Be Seeing You... > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Matthew Stainforth<>Technical Services Manager<>BrunNet Inc.<>(506)450-4562 > Don't rush me, sonny. You rush a miracle maker and you get rotten miracles. > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- Jesse Sipprell Technical Operations Director Evolution Communications, Inc. 800-496-4736 (ext 106) * Finger jss@evcom.net for my PGP Public Key *

Subject: (usr-tc) Question about Norm Miller's script
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-12-02 11:15:21

Norm Miller from 3com was kind enough to post a sample configuration script he uses a few days ago. I looked it over for tips. What does the following line do? set modem_group all connection_type no_prompt message "\b"

Subject: (usr-tc) Debugging PPP on ARC
From: Jesse Sipprell <jss@evcom.net>
Date: 1998-12-02 11:18:38

What is the process that is typically used to debug PPP problems on the HiperARC? Since we upgraded one of our POPs from a Netserver, we _seem_ to be experiencing a large number of "PPP negotiation" problems. The techs have informed me that often these are fixed by having the client specify DNS addresses manually, but sometimes the reverse works ("server assigned"). Thanks! -- Jesse Sipprell Technical Operations Director Evolution Communications, Inc. 800-496-4736 (ext 106) * Finger jss@evcom.net for my PGP Public Key *

Subject: Re: (usr-tc) Debugging PPP on ARC
From: sagarwal@crash.ae.usr.com
Date: 1998-12-02 11:21:07

PPP monitoring for next session will monitor ppp for all the PPP calls coming to ARC. You can monitor PPP for a specific interface or a specific user. This way other calls will not be seen in the debug. Thanks Sanjay On Wed, 2 Dec 1998, Dale Hege wrote: > I was just doing a monitor ppp next session that starts up and it got > stuck on one interface and whouldn't let go. I exited and tried to do any > other ppp monitoring and this one session with IP_DATA flowing in the > middle of everything. It does the ppp monitoring I asked but it also > continues to do the monitoring I canceled. Any ideas? > > Thanks, > > -Dale > > On Wed, 2 Dec 1998 sagarwal@crash.ae.usr.com wrote: > > > Date: Wed, 2 Dec 1998 10:29:55 -0600 (CST) > > From: sagarwal@crash.ae.usr.com > > Reply-To: usr-tc@lists.xmission.com > > To: Jesse Sipprell <jss@evcom.net> > > Cc: usr-tc@lists.xmission.com > > Subject: Re: (usr-tc) Debugging PPP on ARC > > > > On ARC the following command is used to debug PPP negotiation problems > > > > Hiper> Monitor PPP > > > > You will get some options from which you can choose the appropriate one. > > > > thanks > > > > Sanjay > > > > On Wed, 2 Dec 1998, Jesse Sipprell wrote: > > > > > What is the process that is typically used to debug PPP problems on the > > > HiperARC? Since we upgraded one of our POPs from a Netserver, we _seem_ to be > > > experiencing a large number of "PPP negotiation" problems. The techs have > > > informed me that often these are fixed by having the client specify DNS > > > addresses manually, but sometimes the reverse works ("server assigned"). > > > > > > Thanks! > > > > > > -- > > > Jesse Sipprell > > > Technical Operations Director > > > Evolution Communications, Inc. > > > 800-496-4736 (ext 106) > > > > > > * Finger jss@evcom.net for my PGP Public Key * > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Debugging PPP on ARC
From: Dale Hege <fhege@sover.net>
Date: 1998-12-02 11:25:37

We've seen this too. Has there been any word other than try the other setting method? -Dale On Wed, 2 Dec 1998, Jesse Sipprell wrote: > Date: Wed, 2 Dec 1998 11:18:38 -0500 > From: Jesse Sipprell <jss@evcom.net> > Reply-To: usr-tc@lists.xmission.com > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Debugging PPP on ARC > > What is the process that is typically used to debug PPP problems on the > HiperARC? Since we upgraded one of our POPs from a Netserver, we _seem_ to be > experiencing a large number of "PPP negotiation" problems. The techs have > informed me that often these are fixed by having the client specify DNS > addresses manually, but sometimes the reverse works ("server assigned"). > > Thanks! > > -- > Jesse Sipprell > Technical Operations Director > Evolution Communications, Inc. > 800-496-4736 (ext 106) > > * Finger jss@evcom.net for my PGP Public Key * > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Debugging PPP on ARC
From: Dale Hege <fhege@sover.net>
Date: 1998-12-02 12:07:30

I was just doing a monitor ppp next session that starts up and it got stuck on one interface and whouldn't let go. I exited and tried to do any other ppp monitoring and this one session with IP_DATA flowing in the middle of everything. It does the ppp monitoring I asked but it also continues to do the monitoring I canceled. Any ideas? Thanks, -Dale On Wed, 2 Dec 1998 sagarwal@crash.ae.usr.com wrote: > Date: Wed, 2 Dec 1998 10:29:55 -0600 (CST) > From: sagarwal@crash.ae.usr.com > Reply-To: usr-tc@lists.xmission.com > To: Jesse Sipprell <jss@evcom.net> > Cc: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Debugging PPP on ARC > > On ARC the following command is used to debug PPP negotiation problems > > Hiper> Monitor PPP > > You will get some options from which you can choose the appropriate one. > > thanks > > Sanjay > > On Wed, 2 Dec 1998, Jesse Sipprell wrote: > > > What is the process that is typically used to debug PPP problems on the > > HiperARC? Since we upgraded one of our POPs from a Netserver, we _seem_ to be > > experiencing a large number of "PPP negotiation" problems. The techs have > > informed me that often these are fixed by having the client specify DNS > > addresses manually, but sometimes the reverse works ("server assigned"). > > > > Thanks! > > > > -- > > Jesse Sipprell > > Technical Operations Director > > Evolution Communications, Inc. > > 800-496-4736 (ext 106) > > > > * Finger jss@evcom.net for my PGP Public Key * > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Slow-mo MPIP on ARC 4.1.72-7
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-12-02 12:56:38

Someone else posted a report that MPIP between ARCs was slower than a single channel (although it did authenticate and work). I seem to be seeing this as well, now that I've finally upgraded to 4.1.X and turned on MPIP. Is there any sort of fix?

Subject: Re: (usr-tc) Problem starting up TC.
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-02 13:38:55

On Wed, 2 Dec 1998, Mathias Herberts wrote: > Hi, > > I have recently acquired a Total Control 30 port bundle which includes : > > TC chassis > removable fan tray > 1 130A PSU > 1 E1/PRI card > 8 quad modems > 1 HiperARC > 1 NMC > > We hooked up a console on the HiperARC (RS232C port), configured both > the terminal and the HiperARC to 19200 8N1 and powered up the chassis. > No T2 lines (E1) are hooked on the E1/PRI. The console prints : > > BOOT PROM 1.15 (built on August 17 12:24:24) > Kernel loading ... OK > > then nothing. Does the card boot at all or is there red light on the led's of the HiPer arc? Generally what you see here means that your that you need UI Carrier for your terminal program - you can flip the dip switch 5 on the hiper arc to on position and it will work. If it does not boot up then it means that your PC is sending data to the console when it is trying to boot. krish > > The Alrm1 and Alrm2 leds of the E1/PRI are solid red (since no lines are > hooked), > the Hub Status led of the NMC goes solid red then back to solid green at > boot time. > > Is there anything else to do to start up a TC ? Does the console needs > to support some sort of flow control in order to function properly with > the HiperARC ? > > I'd really like to get this baby up and running some time -) > > Any help would be appreciated, > > thanks, > > Mathias Herberts. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) PPP Auth but no Start?
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-12-02 15:02:22

One last question for today. We frequently have problems with people authenticating, but then the RADIUS server never gets a "Start" message for PPP. Now that we've gone to 4.1.72-7, the problem is especially apparent with some ISDN adapters. Here is a normal session: Wed Dec 2 10:13:59 1998: Authentication: 8/94 'onyxgfx' via slc4-tc.xmission.com from slc4-tc.xmission.com port 12 PPP - OK Wed Dec 2 10:13:59 1998: Accounting: 55/98 'onyxgfx' via slc4-tc.xmission.com from slc4-tc.xmission.com port 12 Start - OK Here is an abnormal session, with no "Start": Wed Dec 2 14:59:15 1998: rad_authenticate: 233/154 'klmlaw' at slc2-tc.xmission.com PPP Wed Dec 2 14:59:15 1998: Authentication: 233/154 'klmlaw' via slc2-tc.xmission.com from slc2-tc.xmission.com port 1295 PPP - OK What does the "Start" indicate? Any ideas why it isn't happening?

Subject: Re: (usr-tc) PPP Auth but no Start?
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-12-02 17:12:19

Thus spake Pete Ashdown >We frequently have problems with people authenticating, but then the RADIUS >server never gets a "Start" message for PPP. Now that we've gone to >4.1.72-7, the problem is especially apparent with some ISDN adapters. >Here is a normal session: >Wed Dec 2 10:13:59 1998: Authentication: 8/94 'onyxgfx' via slc4-tc.xmission.com from slc4-tc.xmission.com port 12 PPP - OK >Wed Dec 2 10:13:59 1998: Accounting: 55/98 'onyxgfx' via slc4-tc.xmission.com from slc4-tc.xmission.com port 12 Start - OK >Here is an abnormal session, with no "Start": >Wed Dec 2 14:59:15 1998: rad_authenticate: 233/154 'klmlaw' at slc2-tc.xmission.com PPP >Wed Dec 2 14:59:15 1998: Authentication: 233/154 'klmlaw' via slc2-tc.xmission.com from slc2-tc.xmission.com port 1295 PPP - OK >What does the "Start" indicate? Any ideas why it isn't happening? This is the same symptom, as far as the RADIUS server is concerned, that occurs when we get the MPIP problems that we experience. What happens here is that the user connects, does LCP, and PAP, gets the response back from the RADIUS server, checks the MPIP server, the MPIP server tells it (incorrectly) to set up a tunnel to bundle this link in with a bundle on another system. When the system tries to set up the tunnel, its rejected by the tunnel destination system, so the system just drops the call on the floor. Check your syslog entries to see if you get any vtp syslog messages. That'll really show you a bit better what's going on if this is what you're seeing. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Problem starting up TC.
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-02 17:21:26

That basically means that your box is configured. You can do a delete config and restart it will get you the quick start 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 Dec 1998, Mathias HERBERTS wrote: > > > Generally what you see here means that your that you need UI Carrier for > > your terminal program - you can flip the dip switch 5 on the hiper arc to > > on position and it will work. > > Indeed, I found that while reading old list messages, switching DIP5 > on solved the problem. Thanks for the hint. > > Now strange thing still happen, I do not have quick setup running > after boot up, I end up on the HiPer>> prompt right away. > > The soft version is 4.1.11. > > Mathias. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) Telepath modem running 1.41.017
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-02 18:42:48

I'm still having trouble getting a Telepath modem to reliably connect. Does anyone else have any ideas? Does anyone at 3COM know if this problem will be fixed in the next HiPer DSP code or is this believed to be completely related to the telepath modem? >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Andrews >Sent: Thursday, November 26, 1998 11:59 PM >To: usr-tc@lists.xmission.com >Subject: RE: (usr-tc) Telepath modem running 1.41.017 > > >The last few Telepath user I tried to debug were connecting without v.42 >or MNP 4 error correction -- both to Quads and DSP's. That may be the >real problem -- things often don't work too well when you can't correct >line errors. Disabling v.42 (S15=128) didn't seem to help... it didn't >connect with MNP 4 either. > >I didn't research this too much farther... so there's likely a lot I'm >missing here. I suspect upgrading to v.90 may have helped -- I think they >were x2-only modems. But maybe it'll give you something else to look at? > > >Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org >VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net >Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ ># view;touch;unzip;finger;mount;mv;mv;mv;yes;mv;yes;mv;yes;umount;sleep > >On Wed, 25 Nov 1998, Brian K McIntire wrote: > >> >Just thought I would add that I experienced the same problem with this >> >version of code. Using mon ppp it seemed like it was >experiencing the LCP >> >problem that web TV and imac's had. It did not get up to the >> >authentication stage. I'm still running 4.0.30 on our >production chassis' >> >this being one of the reasons... >> > >> Thanks, that does help. We are seeing exactly the same thing on >ours. The >> user attempts to connect, handshakes and goes no further. Monitor radius >> shows nothing. It just seems to be hanging. I guess I'll call 3COM and >> open a tkt with them. Thought I might have some bad code on >that modem but >> if you are seeing it too then maybe it's a bug with something else. >> >> Thanks again >> >> >Jerry >> > >> >At 10:56 AM 11/25/98 -0600, you wrote: >> >>Does anyone know of issues with this particular modem. I'm >working with a >> >>customer running 1.2.5 on his DSP's and 4.1.72 - 7 on his >HiPer ARC. With >> >>the same user account I can connect 20 times out of 20 with my >> >courier. The >> >>client that has a Telepath connects 1 out of every 3-7 times. >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) Question about Norm Miller's script
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-02 18:56:19

>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Pete Ashdown >Sent: Wednesday, December 02, 1998 12:15 PM >To: usr-tc@lists.xmission.com >Subject: (usr-tc) Question about Norm Miller's script > > >Norm Miller from 3com was kind enough to post a sample configuration script >he uses a few days ago. I looked it over for tips. What does the >following >line do? > >set modem_group all connection_type no_prompt message "\b" I believe with this setting there will be no <Username prompt". I believe the backspace negates the auto line feed. Not sure why you would want to do that but I imagine somebody would have had to ask for 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. >

Subject: RE: (usr-tc) Problem starting up TC.
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-02 19:00:22

Sounds like you have engineering fastboot enabled. Flip dip 3 off. >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mathias HERBERTS >Sent: Wednesday, December 02, 1998 4:33 PM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) Problem starting up TC. > > > > > Generally what you see here means that your that you need UI >Carrier for > > your terminal program - you can flip the dip switch 5 on the >hiper arc to > > on position and it will work. > >Indeed, I found that while reading old list messages, switching DIP5 >on solved the problem. Thanks for the hint. > >Now strange thing still happen, I do not have quick setup running >after boot up, I end up on the HiPer>> prompt right away. > >The soft version is 4.1.11. > >Mathias. > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) PPP Auth but no Start?
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-12-02 19:02:57

Jeff Mcadams said once upon a time: >This is the same symptom, as far as the RADIUS server is concerned, that >occurs when we get the MPIP problems that we experience. What happens >here is that the user connects, does LCP, and PAP, gets the response >back from the RADIUS server, checks the MPIP server, the MPIP server >tells it (incorrectly) to set up a tunnel to bundle this link in with a >bundle on another system. When the system tries to set up the tunnel, >its rejected by the tunnel destination system, so the system just drops >the call on the floor. Check your syslog entries to see if you get any >vtp syslog messages. That'll really show you a bit better what's going >on if this is what you're seeing. So if I shut off the MPIP, things should be OK right? When oh when will they have a MPIP solution that _works_ _every_ _time_? Does 3com have gerbils do their beta testing? MPIP is well over two years old and it still isn't 100%?

Subject: Re: (usr-tc) PPP Auth but no Start?
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-12-02 21:08:27

Thus spake Pete Ashdown >Jeff Mcadams said once upon a time: >>This is the same symptom, as far as the RADIUS server is concerned, that >>occurs when we get the MPIP problems that we experience. What happens >>here is that the user connects, does LCP, and PAP, gets the response >>back from the RADIUS server, checks the MPIP server, the MPIP server >>tells it (incorrectly) to set up a tunnel to bundle this link in with a >>bundle on another system. When the system tries to set up the tunnel, >>its rejected by the tunnel destination system, so the system just drops >>the call on the floor. Check your syslog entries to see if you get any >>vtp syslog messages. That'll really show you a bit better what's going >>on if this is what you're seeing. >So if I shut off the MPIP, things should be OK right? Well, I didn't say *that*. MPIP doing this funkiness is but one of many things that could cause something like this to happen. So I wouldn't be quite so gung-ho to pin the blame on MPIP. It's quite possible that it is what's causing it, but certainly not absolutely the case. >When oh when will >they have a MPIP solution that _works_ _every_ _time_? Does 3com have >gerbils do their beta testing? MPIP is well over two years old and it >still isn't 100%? It took 7 months from the time that I opened the trouble ticket to when they acknowledged that there was a bug in it that needed to be fixed. Apparently, it was a bug in the actual protocol itself, and not just a coding error that has been causing what I'm seeing. Still no fix for the NETServers yet, but its supposed to be on the way. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Problem starting up TC.
From: Mathias HERBERTS <herberts@glop.infini.fr>
Date: 1998-12-02 23:33:23

> Generally what you see here means that your that you need UI Carrier for > your terminal program - you can flip the dip switch 5 on the hiper arc to > on position and it will work. Indeed, I found that while reading old list messages, switching DIP5 on solved the problem. Thanks for the hint. Now strange thing still happen, I do not have quick setup running after boot up, I end up on the HiPer>> prompt right away. The soft version is 4.1.11. Mathias.

Subject: (usr-tc) Packet Filers on NetServer
From: Jamie Dolan <jamie@powernetonline.com>
Date: 1998-12-03 01:14:32

Hi, Is there a way with my netserver to stop my users from being able to use rlogin? Thanks. -- Jamie Dolan 1-888-292-1334 1-920-725-5015 1-920-725-4654 FAX www.powernetonline.com

Subject: (usr-tc) (USR-TC) DEBUGGING PPP ON
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1998-12-03 08:48:00

Jesse, This may or may not be relevant but I was seeing a similar problem, specifically with a Brother Geobook. After working with Krish quite some time, we determined that it worked with the Netserver but not with the HiPerArc. What he determined was the Brother was requesting an invalied LCP packet length and the HiPerArc would reject the request where the Netserver would ignore it. He is working on a version of HiPerArc code which will work similarly to the Netserver. The Brother Geobook has next to no options for PPP. I am hoping we will get the new code by tomorrow. It appeats that the HiPerArc is more picky about PPP/LCP negotiations than the Netserver... Jeff Binkley ASA Network Computing U>What is the process that is typically used to debug PPP problems on U>the HiperARC? Since we upgraded one of our POPs from a Netserver, we U>_seem_ to be experiencing a large number of "PPP negotiation" U>problems. The techs have informed me that often these are fixed by U>having the client specify DNS addresses manually, but sometimes the U>reverse works ("server assigned"). U>Thanks! U>-- U>Jesse Sipprell U>Technical Operations Director U>Evolution Communications, Inc. U>800-496-4736 (ext 106) CMPQwk 1.42 9999

Subject: Re: (usr-tc) Packet Filers on NetServer
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-03 09:15:26

You can setup a filter for every user going to port 513 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, 3 Dec 1998, Jamie Dolan wrote: > Hi, > > Is there a way with my netserver to stop my users from being able to use > rlogin? > > Thanks. > > > -- > Jamie Dolan > 1-888-292-1334 > 1-920-725-5015 > 1-920-725-4654 FAX > www.powernetonline.com > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (no subject)
From: Randy Doran <randydoran@usa.net>
Date: 1998-12-03 10:55:26

Our tech support has reported a fair number of customers having problems getting faster than 28.8/33.6 connection speeds to a TC HiPer chassis with HiPerARC v4.1.11 and HiPerDSP v1.2.5. Of these modems, the majority are Hayes and Motorola. However, some are using USR 56K X2/v.90 WinModems. These WinModem users are able to get fair connection rates on an Ascend Max (36KBps to 48KBps), but are getting no faster than 28.8KBps on our 3Com chassis. Is there a know issue with the USR WinModems or does anybody know of any special configurations for either the chassis or the USR WinModem that might improve these connection rates? Thanks, Randy Doran Circuit Engineer \ Dialup Network Coordinator e.spire Communication's CyberGate Internet Services

Subject: Re: (usr-tc) Re: Slow-mo MPIP on ARC 4.1.72-7
From: Brian Biggs <bb@sonic.net>
Date: 1998-12-03 11:06:10

> >Someone else posted a report that MPIP between ARCs was slower than a > >single channel (although it did authenticate and work). I seem to be > >seeing this as well, now that I've finally upgraded to 4.1.X and turned on > >MPIP. Is there any sort of fix? > > > That was me. I am running 4.1.72-7 and MPIP sessions in any combination > of equipment are having horrible throughput. Multilink connections to > the same chassis on Netservers and HyperARCs are fine though. > > I have had a case open with 3com on this for a good month, but they > have not come up with any answers and for the last few weeks they > haven't even been returning my calls to give status updates. > > Is there anybody else seeing this problem? We have just deployed 3 chassis' set up the same; 1 dual PRI card (3.0.2), 12 Quad cards (5.10.9), 2 DSP cards (1.2.5), 1 ARC (4.1.72-7), & 1 NMC (5.5.5). I've set up one chassis' as the MPIP server and the other two as clients. My question is: do I need to make the server an MPIP client of itself? The docs are not to clear about MPIP configs. And I'll let you know what kind of feedback we get from our clients. 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 #

Subject: (usr-tc) Look at this looniness
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-12-03 11:26:25

Well Jeff, thanks for the idea, but MPIP didn't solve our problems with 4.1.72-7. Look at this syslog output: Dec 3 00:01:46 slc4-tc.xmission.com At 07:01:46, Facility "Auth Facility", Level "COMMON":: remote auth succeeded on slot:2/mod:5 id: 17040366 user: klmlaw Dec 3 00:01:47 slc4-tc.xmission.com At 07:01:47, Facility "Auth Facility", Level "COMMON":: call disconnected on slot:2/mod:5 id: 17040366 user: UNKNOWN duration: 9secs reason: 1 The ARC knows what the user is when they connect, but forgets who they are six seconds later. This is someone with an Ascend Pipeline, where other Ascend Pipelines are connecting fine. When we were on 4.0.30 before, we didn't have these problems. If I don't get a fix in the next couple of hours, I'm going to have to downgrade to 4.0.30, which unfortunately has annoying bugs in other places, but at least people can connect.

Subject: Re: (usr-tc) Re: Slow-mo MPIP on ARC 4.1.72-7
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-12-03 12:10:18

Brian Biggs said once upon a time: >I've set up one chassis' as the MPIP server and the other two as clients. My >question is: do I need to make the server an MPIP client of itself? The docs >are not to clear about MPIP configs. The way you did it on the Netserver was to just configure it as a client to itself. In otherwords, specify it as a client by listing its IP address as you do other clients, then setup its client configuration to use itself as the server.

Subject: Re: (usr-tc) Look at this looniness
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-12-03 12:11:28

Brian said once upon a time: > >On Thu, 3 Dec 1998, Pete Ashdown wrote: > >> Well Jeff, thanks for the idea, but MPIP didn't solve our problems with >> 4.1.72-7. Look at this syslog output: >> >> Dec 3 00:01:46 slc4-tc.xmission.com At 07:01:46, Facility "Auth Facility", Level "COMMON":: remote auth succeeded on slot:2/mod:5 id: 17040366 user: klmlaw >> >> Dec 3 00:01:47 slc4-tc.xmission.com At 07:01:47, Facility "Auth Facility", Level "COMMON":: call disconnected on slot:2/mod:5 id: 17040366 user: UNKNOWN duration: 9secs reason: 1 >> > >So you are only seeing problems with some ascend piplines? What is >special about those piplines that you are having troubles with (code, >model, etc)? According to one customer, he has an identical Pipeline which is configured exactly the same that is connecting with no problems. We haven't been able to find out whether there is a code version difference.

Subject: Re: (usr-tc) Look at this looniness
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-12-03 12:17:51

Tatai SV Krishnan said once upon a time: >First need to know if you are using the HiPer arc as MPIP server for both >NETServer and HiPer arcs. If yes need to know the configuration - >meaning how many HiPerarcs do you have as servers, and also need to know >what version of netserver code you have. There are no Netservers in the mix. I have shut off MPIP completely as per Jeff's suggestion and we're still seeing the problem. >If a call is disconnected before starting ppp meaning less then 20 sec >the arc does now the user it will tell the user as unknow and the >accounting records will show user unauthenticated. Also by default the >NETServer uses pap first so you have to make sure that the MPIP clients >and servers ( hiper arcs ) do support pap first. Again, no netservers in the equation, all ARC. Here's what my ARC PPP config looks like: PPP AUTHENTICATION DIAL_IN Users Authenticate: PAP PPP Authentication Preference: DEFAULT System Transmit Authentication Name: HiPer PPP offloading: ENABLED CCP will be attempted for call type(s): DIGITAL UNCOMPRESSED_ANALOG Primary NBNS Server address: 0.0.0.0 Secondary NBNS Server address: 0.0.0.0 DNS configuration Usage: SYSTEM Primary PPP DNS Server address: 198.60.22.2 Secondary PPP DNS Server address: 198.60.22.22 PPP session start message: Session from (%server_ip) to %client_ip beginning....\n Here's a monitored session for a customer with a problem. It appears to not like the IP address I am sending it, but keep in mind that this worked just fine under 4.0.30. Outgoing PPP Data on interface: slot:2/mod:21 PAP ACK Outgoing PPP Data on interface: slot:2/mod:21 IPCP CFG_REQ COMPR_TYPE 00 2d 0f 00 NEW_ADDRS a6 46 01 29 Incoming PPP Data on interface: slot:2/mod:21 IPCP CFG_REQ NEW_ADDRS c7 68 7c be PRIM DNS 00 00 00 00 PRIM NBNS 00 00 00 00 SEC DNS 00 00 00 00 SEC NBNS 00 00 00 00 Outgoing PPP Data on interface: slot:2/mod:21 IPCP CFG_REJ PRIM NBNS 00 00 00 00 SEC NBNS 00 00 00 00 Incoming PPP Data on interface: slot:2/mod:21 IPCP CFG_REJ COMPR_TYPE 00 2d 0f 00 Outgoing PPP Data on interface: slot:2/mod:21 IPCP CFG_REQ NEW_ADDRS a6 46 01 29 Incoming PPP Data on interface: slot:2/mod:21 IPCP CFG_REQ NEW_ADDRS c7 68 7c be PRIM DNS 00 00 00 00 SEC DNS 00 00 00 00 Outgoing PPP Data on interface: slot:2/mod:21 IPCP CFG_NAK NEW_ADDRS cf 87 80 95 PRIM DNS c6 3c 16 02 SEC DNS c6 3c 16 16 Incoming PPP Data on interface: slot:2/mod:21 IPCP CFG_ACK NEW_ADDRS a6 46 01 29 Incoming PPP Data on interface: slot:2/mod:21 IPCP CFG_REQ NEW_ADDRS c7 68 7c be Outgoing PPP Data on interface: slot:2/mod:21 IPCP CFG_NAK NEW_ADDRS cf 87 80 95 Incoming PPP Data on interface: slot:2/mod:21 IPCP CFG_REQ NEW_ADDRS c7 68 7c be Outgoing PPP Data on interface: slot:2/mod:21 IPCP CFG_NAK NEW_ADDRS cf 87 80 95 Incoming PPP Data on interface: slot:2/mod:21 IPCP CFG_REQ NEW_ADDRS c7 68 7c be Outgoing PPP Data on interface: slot:2/mod:21 IPCP CFG_NAK NEW_ADDRS cf 87 80 95 Incoming PPP Data on interface: slot:2/mod:21 IPCP CFG_REQ NEW_ADDRS c7 68 7c be Outgoing PPP Data on interface: slot:2/mod:21 IPCP CFG_NAK NEW_ADDRS cf 87 80 95 Incoming PPP Data on interface: slot:2/mod:21 IPCP CFG_REQ NEW_ADDRS c7 68 7c be Outgoing PPP Data on interface: slot:2/mod:21 IPCP CFG_REJ NEW_ADDRS cf 87 80 95 Outgoing PPP Data on interface: slot:2/mod:21 LCP TERM_REQ Incoming PPP Data on interface: slot:2/mod:21 IPCP CFG_REQ Incoming PPP Data on interface: slot:2/mod:21 LCP TERM_ACK

Subject: Re: (usr-tc) PRI & CT1
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-12-03 12:28:33

Jason W said once upon a time: >We now have the ability at one of our POP's >to get PRI circuits. Currently we have all CT1's >at that site, but would eventually like to switch >to PRI. My question is, can I mix PRI and CT1 >circuits within the same chassis? We have >some chassis with HiPer ARC, and some >with NETServer cards. Most of our chassis >have Quad modem cards, but we do have >one chassis that has HiPer DSP cards. Any >help would be appreciated. I don't see why not, since the PRI/CT1 specific configuration takes place at the NIC, the Netserver or ARC wouldn't care what you bring the lines in as.

Subject: Re: (usr-tc) (USR-TC) DEBUGGING PPP ON
From: Dale Hege <fhege@sover.net>
Date: 1998-12-03 12:37:47

Will this be a public ER or call for support if you have the problem? I'm getting lots of people complaining of not getting dns numbers assigned and people not getting on at all. -Dale On Thu, 3 Dec 1998, Jeff Binkley wrote: > Date: Thu, 03 Dec 1998 08:48:00 -0500 > From: Jeff Binkley <jeff.binkley@asacomp.com> > Reply-To: usr-tc@lists.xmission.com > To: USR-TC@lists.xmission.com > Subject: (usr-tc) (USR-TC) DEBUGGING PPP ON > > > Jesse, > > This may or may not be relevant but I was seeing a similar problem, > specifically with a Brother Geobook. After working with Krish quite > some time, we determined that it worked with the Netserver but not with > the HiPerArc. What he determined was the Brother was requesting an > invalied LCP packet length and the HiPerArc would reject the request > where the Netserver would ignore it. He is working on a version of > HiPerArc code which will work similarly to the Netserver. The Brother > Geobook has next to no options for PPP. I am hoping we will get the new > code by tomorrow. It appeats that the HiPerArc is more picky about > PPP/LCP negotiations than the Netserver... > > > Jeff Binkley > ASA Network Computing > > > U>What is the process that is typically used to debug PPP problems on > U>the HiperARC? Since we upgraded one of our POPs from a Netserver, we > U>_seem_ to be experiencing a large number of "PPP negotiation" > U>problems. The techs have informed me that often these are fixed by > U>having the client specify DNS addresses manually, but sometimes the > U>reverse works ("server assigned"). > > U>Thanks! > > U>-- > U>Jesse Sipprell > U>Technical Operations Director > U>Evolution Communications, Inc. > U>800-496-4736 (ext 106) > > CMPQwk 1.42 9999 > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Look at this looniness
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-03 12:41:17

On Thu, 3 Dec 1998, Pete Ashdown wrote: > Well Jeff, thanks for the idea, but MPIP didn't solve our problems with > 4.1.72-7. Look at this syslog output: > > Dec 3 00:01:46 slc4-tc.xmission.com At 07:01:46, Facility "Auth Facility", Level "COMMON":: remote auth succeeded on slot:2/mod:5 id: 17040366 user: klmlaw > > Dec 3 00:01:47 slc4-tc.xmission.com At 07:01:47, Facility "Auth Facility", Level "COMMON":: call disconnected on slot:2/mod:5 id: 17040366 user: UNKNOWN duration: 9secs reason: 1 > > The ARC knows what the user is when they connect, but forgets who they are > six seconds later. This is someone with an Ascend Pipeline, where other > Ascend Pipelines are connecting fine. When we were on 4.0.30 before, we > didn't have these problems. First need to know if you are using the HiPer arc as MPIP server for both NETServer and HiPer arcs. If yes need to know the configuration - meaning how many HiPerarcs do you have as servers, and also need to know what version of netserver code you have. If a call is disconnected before starting ppp meaning less then 20 sec the arc does now the user it will tell the user as unknow and the accounting records will show user unauthenticated. Also by default the NETServer uses pap first so you have to make sure that the MPIP clients and servers ( hiper arcs ) do support pap first. Get me this info and we can solve you problem. krish > > If I don't get a fix in the next couple of hours, I'm going to have to > downgrade to 4.0.30, which unfortunately has annoying bugs in other places, > but at least people can connect. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Look at this looniness
From: Brian <signal@shreve.net>
Date: 1998-12-03 12:51:26

On Thu, 3 Dec 1998, Pete Ashdown wrote: > Well Jeff, thanks for the idea, but MPIP didn't solve our problems with > 4.1.72-7. Look at this syslog output: > > Dec 3 00:01:46 slc4-tc.xmission.com At 07:01:46, Facility "Auth Facility", Level "COMMON":: remote auth succeeded on slot:2/mod:5 id: 17040366 user: klmlaw > > Dec 3 00:01:47 slc4-tc.xmission.com At 07:01:47, Facility "Auth Facility", Level "COMMON":: call disconnected on slot:2/mod:5 id: 17040366 user: UNKNOWN duration: 9secs reason: 1 > So you are only seeing problems with some ascend piplines? What is special about those piplines that you are having troubles with (code, model, etc)? Brian > The ARC knows what the user is when they connect, but forgets who they are > six seconds later. This is someone with an Ascend Pipeline, where other > Ascend Pipelines are connecting fine. When we were on 4.0.30 before, we > didn't have these problems. > > If I don't get a fix in the next couple of hours, I'm going to have to > downgrade to 4.0.30, which unfortunately has annoying bugs in other places, > but at least people can connect. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > 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

Subject: (usr-tc) Re: Slow-mo MPIP on ARC 4.1.72-7
From: Mark Lemmert <cto@athenet.net>
Date: 1998-12-03 12:51:35

>Someone else posted a report that MPIP between ARCs was slower than a >single channel (although it did authenticate and work). I seem to be >seeing this as well, now that I've finally upgraded to 4.1.X and turned on >MPIP. Is there any sort of fix? That was me. I am running 4.1.72-7 and MPIP sessions in any combination of equipment are having horrible throughput. Multilink connections to the same chassis on Netservers and HyperARCs are fine though. I have had a case open with 3com on this for a good month, but they have not come up with any answers and for the last few weeks they haven't even been returning my calls to give status updates. Is there anybody else seeing this problem? Mark Lemmert cto@athenet.net Chief Technical Officer (920)954-9799 AthEnet Data Exchange http://www.athenet.net

Subject: Re: (usr-tc) Re: Slow-mo MPIP on ARC 4.1.72-7
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-03 13:13:56

Do you have your ticket number handy? 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, 3 Dec 1998, Mark Lemmert wrote: > >Someone else posted a report that MPIP between ARCs was slower than a > >single channel (although it did authenticate and work). I seem to be > >seeing this as well, now that I've finally upgraded to 4.1.X and turned on > >MPIP. Is there any sort of fix? > > > That was me. I am running 4.1.72-7 and MPIP sessions in any combination > of equipment are having horrible throughput. Multilink connections to > the same chassis on Netservers and HyperARCs are fine though. > > I have had a case open with 3com on this for a good month, but they > have not come up with any answers and for the last few weeks they > haven't even been returning my calls to give status updates. > > Is there anybody else seeing this problem? > > > Mark Lemmert cto@athenet.net > Chief Technical Officer (920)954-9799 > AthEnet Data Exchange http://www.athenet.net > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) PRI & CT1
From: Jason W <jwatkins@iland.net>
Date: 1998-12-03 13:18:09

We now have the ability at one of our POP's to get PRI circuits. Currently we have all CT1's at that site, but would eventually like to switch to PRI. My question is, can I mix PRI and CT1 circuits within the same chassis? We have some chassis with HiPer ARC, and some with NETServer cards. Most of our chassis have Quad modem cards, but we do have one chassis that has HiPer DSP cards. Any help would be appreciated. Thanks. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Jason Watkins jwatkins@iland.net I-Land NOC Tech http://www.iland.net =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Subject: Re: (usr-tc) Re: Slow-mo MPIP on ARC 4.1.72-7
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-03 13:29:10

On Thu, 3 Dec 1998, Brian Biggs wrote: > > >Someone else posted a report that MPIP between ARCs was slower than a > > >single channel (although it did authenticate and work). I seem to be > > >seeing this as well, now that I've finally upgraded to 4.1.X and turned on > > >MPIP. Is there any sort of fix? > > > > > > That was me. I am running 4.1.72-7 and MPIP sessions in any combination > > of equipment are having horrible throughput. Multilink connections to > > the same chassis on Netservers and HyperARCs are fine though. > > > > I have had a case open with 3com on this for a good month, but they > > have not come up with any answers and for the last few weeks they > > haven't even been returning my calls to give status updates. > > > > Is there anybody else seeing this problem? > > We have just deployed 3 chassis' set up the same; 1 dual PRI card (3.0.2), > 12 Quad cards (5.10.9), 2 DSP cards (1.2.5), 1 ARC (4.1.72-7), & 1 NMC > (5.5.5). > > I've set up one chassis' as the MPIP server and the other two as clients. My > question is: do I need to make the server an MPIP client of itself? The docs > are not to clear about MPIP configs. > > And I'll let you know what kind of feedback we get from our clients. Quite the same. You configure One HiPer arc as a server, it can be set as a client also if you want it, else just set it up as server. The other two arc should clients only. On a network of say 7 chassis - you can have one HiPer arc as server and the rest as clients. Do not have more than one server. If you have more than 7 chassis then you can do one of the following 1. You can have one HiPer arc as server and another as back up server. All the others should be clients. Do not have more than two as servers for every 14 chassis. 2. You can have one HiPer arc as server ( the server here will not take any calls ) All the others will be clients. You can have upto 250 clients. krish > > 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 # > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Look at this looniness
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-03 13:39:41

On Thu, 3 Dec 1998, Pete Ashdown wrote: > Tatai SV Krishnan said once upon a time: > > >First need to know if you are using the HiPer arc as MPIP server for both > >NETServer and HiPer arcs. If yes need to know the configuration - > >meaning how many HiPerarcs do you have as servers, and also need to know > >what version of netserver code you have. > > There are no Netservers in the mix. I have shut off MPIP completely as per > Jeff's suggestion and we're still seeing the problem. > > >If a call is disconnected before starting ppp meaning less then 20 sec > >the arc does now the user it will tell the user as unknow and the > >accounting records will show user unauthenticated. Also by default the > >NETServer uses pap first so you have to make sure that the MPIP clients > >and servers ( hiper arcs ) do support pap first. > > Again, no netservers in the equation, all ARC. Here's what my ARC PPP > config looks like: > > PPP AUTHENTICATION > DIAL_IN Users Authenticate: PAP > PPP Authentication Preference: DEFAULT > System Transmit Authentication Name: HiPer > > PPP offloading: ENABLED > > CCP will be attempted for call type(s): DIGITAL > UNCOMPRESSED_ANALOG > > Primary NBNS Server address: 0.0.0.0 > Secondary NBNS Server address: 0.0.0.0 > > DNS configuration Usage: SYSTEM > > Primary PPP DNS Server address: 198.60.22.2 > Secondary PPP DNS Server address: 198.60.22.22 > > PPP session start message: Session from (%server_ip) to %client_ip beginning....\n > This looks fine. > > Here's a monitored session for a customer with a problem. It appears to > not like the IP address I am sending it, but keep in mind that this worked > just fine under 4.0.30. > 4.0.30 - never did MPIP. MPIP support was only in 4.1.x code. I would like to get access to the hiper arc and take some debug if possible. Can I get access? krish > > Outgoing PPP Data on interface: slot:2/mod:21 > PAP ACK > Outgoing PPP Data on interface: slot:2/mod:21 > IPCP CFG_REQ COMPR_TYPE 00 2d 0f 00 > NEW_ADDRS a6 46 01 29 > > Incoming PPP Data on interface: slot:2/mod:21 > IPCP CFG_REQ NEW_ADDRS c7 68 7c be > PRIM DNS 00 00 00 00 > PRIM NBNS 00 00 00 00 > SEC DNS 00 00 00 00 > SEC NBNS 00 00 00 00 > > Outgoing PPP Data on interface: slot:2/mod:21 > IPCP CFG_REJ PRIM NBNS 00 00 00 00 > SEC NBNS 00 00 00 00 > > Incoming PPP Data on interface: slot:2/mod:21 > IPCP CFG_REJ COMPR_TYPE 00 2d 0f 00 > > Outgoing PPP Data on interface: slot:2/mod:21 > IPCP CFG_REQ NEW_ADDRS a6 46 01 29 > > Incoming PPP Data on interface: slot:2/mod:21 > IPCP CFG_REQ NEW_ADDRS c7 68 7c be > PRIM DNS 00 00 00 00 > SEC DNS 00 00 00 00 > > Outgoing PPP Data on interface: slot:2/mod:21 > IPCP CFG_NAK NEW_ADDRS cf 87 80 95 > PRIM DNS c6 3c 16 02 > SEC DNS c6 3c 16 16 > > Incoming PPP Data on interface: slot:2/mod:21 > IPCP CFG_ACK NEW_ADDRS a6 46 01 29 > > Incoming PPP Data on interface: slot:2/mod:21 > IPCP CFG_REQ NEW_ADDRS c7 68 7c be > > Outgoing PPP Data on interface: slot:2/mod:21 > IPCP CFG_NAK NEW_ADDRS cf 87 80 95 > > Incoming PPP Data on interface: slot:2/mod:21 > IPCP CFG_REQ NEW_ADDRS c7 68 7c be > > Outgoing PPP Data on interface: slot:2/mod:21 > IPCP CFG_NAK NEW_ADDRS cf 87 80 95 > > Incoming PPP Data on interface: slot:2/mod:21 > IPCP CFG_REQ NEW_ADDRS c7 68 7c be > > Outgoing PPP Data on interface: slot:2/mod:21 > IPCP CFG_NAK NEW_ADDRS cf 87 80 95 > > Incoming PPP Data on interface: slot:2/mod:21 > IPCP CFG_REQ NEW_ADDRS c7 68 7c be > > Outgoing PPP Data on interface: slot:2/mod:21 > IPCP CFG_NAK NEW_ADDRS cf 87 80 95 > > Incoming PPP Data on interface: slot:2/mod:21 > IPCP CFG_REQ NEW_ADDRS c7 68 7c be > > > Outgoing PPP Data on interface: slot:2/mod:21 > IPCP CFG_REJ NEW_ADDRS cf 87 80 95 > > Outgoing PPP Data on interface: slot:2/mod:21 > LCP TERM_REQ > > Incoming PPP Data on interface: slot:2/mod:21 > IPCP CFG_REQ > Incoming PPP Data on interface: slot:2/mod:21 > LCP TERM_ACK > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Not all modems working
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1998-12-03 14:20:36

I have a chassis with six DSPs and only in two of them I could see all the modems working. I'm already using round-robin. How can I investigate this behavior? - Marcelo

Subject: Re: (usr-tc) Re: Slow-mo MPIP on ARC 4.1.72-7
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-12-03 14:25:26

Thus spake Brian Biggs >I've set up one chassis' as the MPIP server and the other two as clients. My >question is: do I need to make the server an MPIP client of itself? The docs >are not to clear about MPIP configs. Yes, you do need to make it a client of itself. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) Re: Slow-mo MPIP on ARC 4.1.72-7
From: Mark Lemmert <cto@athenet.net>
Date: 1998-12-03 15:18:32

>Quite the same. You configure One HiPer arc as a server, it can be set >as a client also if you want it, else just set it up as server. The >other two arc should clients only. > >On a network of say 7 chassis - you can have one HiPer arc as server and >the rest as clients. Do not have more than one server. > >If you have more than 7 chassis then you can do one of the following > >1. You can have one HiPer arc as server and another as back up server. >All the others should be clients. Do not have more than two as servers >for every 14 chassis. > >2. You can have one HiPer arc as server ( the server here will not take >any calls ) All the others will be clients. You can have upto 250 clients. > >krish Question for you, in one of my POPs I have 8 chassis (1 HyperARC, 7 Netserver) and I only have 1 MPIP server set (the HyperARC), do you think that could be related to the throughput problem I am seeing with MPIP? Second question, why would it be bad to have more than two servers per 14 chassis? Mark Lemmert cto@athenet.net Chief Technical Officer (920)954-9799 AthEnet Data Exchange http://www.athenet.net

Subject: Re: (usr-tc) Re: Slow-mo MPIP on ARC 4.1.72-7
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-03 15:36:00

On Thu, 3 Dec 1998, Mark Lemmert wrote: > >Quite the same. You configure One HiPer arc as a server, it can be set > >as a client also if you want it, else just set it up as server. The > >other two arc should clients only. > > > >On a network of say 7 chassis - you can have one HiPer arc as server and > >the rest as clients. Do not have more than one server. > > > >If you have more than 7 chassis then you can do one of the following > > > >1. You can have one HiPer arc as server and another as back up server. > >All the others should be clients. Do not have more than two as servers > >for every 14 chassis. > > > >2. You can have one HiPer arc as server ( the server here will not take > >any calls ) All the others will be clients. You can have upto 250 clients. > > > >krish > > Question for you, in one of my POPs I have 8 chassis (1 HyperARC, 7 Netserver) > and I only have 1 MPIP server set (the HyperARC), do you think that could be > related to the throughput problem I am seeing with MPIP? > No, the problem here is that the NETServer code in 3.8.1 had added some special type of flags to the deregistration and registration data on MPIP, that is the root cause of the problem. > > Second question, why would it be bad to have more than two servers per 14 > chassis? Yes - what happens is when you have more than one server, the clients starts sending deregistration packets to every server - that results in the main server not receiving the packet and floods the network. krish > > > Mark Lemmert cto@athenet.net > Chief Technical Officer (920)954-9799 > AthEnet Data Exchange http://www.athenet.net > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) TCM/HARM under Linux
From: Brian Biggs <bb@sonic.net>
Date: 1998-12-03 15:57:42

Does it exist? Is there any hope? -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 #

Subject: (usr-tc) Looniness resolved
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-12-03 16:07:32

The problem I had today sourced to misconfigured Ascend Pipelines which were getting away with it under 4.0.30, but not under 4.1.x. Once I isolated the problem with a customer, it was easy to understand. I might also add that Krish is the HiPer God. I wish I could send my support contract money directly to him.

Subject: Re: (usr-tc) PRI & CT1
From: John Rockwell <jrockwel@clarityconnect.com>
Date: 1998-12-03 16:14:11

Yes, both the HiperARCs and the PRI Nac (I'm assuming that you also have a chassis with quadmodems and a netserver card) allow you to configure the switch settings on a per span basis. At 01:18 PM 12/3/98 -0600, you wrote: >We now have the ability at one of our POP's >to get PRI circuits. Currently we have all CT1's >at that site, but would eventually like to switch >to PRI. My question is, can I mix PRI and CT1 >circuits within the same chassis? We have >some chassis with HiPer ARC, and some >with NETServer cards. Most of our chassis >have Quad modem cards, but we do have >one chassis that has HiPer DSP cards. Any >help would be appreciated. > >Thanks. > >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >Jason Watkins jwatkins@iland.net >I-Land NOC Tech http://www.iland.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. > John Rockwell e-mail: jrockwel@clarityconnect.com Network Engineer Clarityconnect, Inc. Ithaca Area: (607)257-8268 Outside Ithaca Area: (888)322-4900 Try us: http://www.clarityconnect.com

Subject: Re: (usr-tc) Re: Slow-mo MPIP on ARC 4.1.72-7
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-12-03 16:23:41

Thus spake Mark Lemmert >Question for you, in one of my POPs I have 8 chassis (1 HyperARC, 7 Netserver) >and I only have 1 MPIP server set (the HyperARC), do you think that could be >related to the throughput problem I am seeing with MPIP? No. MPIP is used only to control the actual process of *finding* which links are where to get them bundled. VTP is the protocol that is actually used to transport the data between chassis to get it to the right NETServer or HARC to get the channels bundled. ie, MPIP being slow might mean it would take some time to get the links bundled together, but once they get bundled, it won't affect the throughput. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Re: Slow-mo MPIP on ARC 4.1.72-7
From: Dale Hege <fhege@sover.net>
Date: 1998-12-03 16:26:22

I've see slow mpip between the netservers and hipers but that was a while ago. I'm not sure if it a problem in the latest code. -Dale On Thu, 3 Dec 1998, Mark Lemmert wrote: > Date: Thu, 3 Dec 1998 15:18:32 -0600 (CST) > From: Mark Lemmert <cto@athenet.net> > Reply-To: usr-tc@lists.xmission.com > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Re: Slow-mo MPIP on ARC 4.1.72-7 > > >Quite the same. You configure One HiPer arc as a server, it can be set > >as a client also if you want it, else just set it up as server. The > >other two arc should clients only. > > > >On a network of say 7 chassis - you can have one HiPer arc as server and > >the rest as clients. Do not have more than one server. > > > >If you have more than 7 chassis then you can do one of the following > > > >1. You can have one HiPer arc as server and another as back up server. > >All the others should be clients. Do not have more than two as servers > >for every 14 chassis. > > > >2. You can have one HiPer arc as server ( the server here will not take > >any calls ) All the others will be clients. You can have upto 250 clients. > > > >krish > > Question for you, in one of my POPs I have 8 chassis (1 HyperARC, 7 Netserver) > and I only have 1 MPIP server set (the HyperARC), do you think that could be > related to the throughput problem I am seeing with MPIP? > > > Second question, why would it be bad to have more than two servers per 14 > chassis? > > > Mark Lemmert cto@athenet.net > Chief Technical Officer (920)954-9799 > AthEnet Data Exchange http://www.athenet.net > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) PRI & CT1
From: Ronald E. Kushner <ron@glis.net>
Date: 1998-12-03 16:33:25

Pete Ashdown wrote: > Jason W said once upon a time: > > >We now have the ability at one of our POP's > >to get PRI circuits. Currently we have all CT1's > >at that site, but would eventually like to switch > >to PRI. My question is, can I mix PRI and CT1 > >circuits within the same chassis? We have > >some chassis with HiPer ARC, and some > >with NETServer cards. Most of our chassis > >have Quad modem cards, but we do have > >one chassis that has HiPer DSP cards. Any > >help would be appreciated. > > I don't see why not, since the PRI/CT1 specific configuration takes place > at the NIC, the Netserver or ARC wouldn't care what you bring the lines in > as. If you have the older Dual T1/PRI cards, both CSU's run the same software code, so you can not mix PRI and CAS on the same card. If you are running HiPer DSP cards, each card can be configured for either CAS or PRI.

Subject: Re: (usr-tc) PRI & CT1
From: Ronald E. Kushner <ron@glis.net>
Date: 1998-12-03 16:33:25

Subject: (usr-tc) USR WinModem slow speeds
From: Randy Doran <randydoran@usa.net>
Date: 1998-12-03 16:36:23

Subject: Re: (usr-tc) (USR-TC) DEBUGGING PPP ON
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1998-12-03 17:25:00

Dale, I don't know. Krish will need to answer this one. He just sent me an E-Mail saying he has the code ready for testing. I'll keep you posted. Jeff -> Will this be a public ER or call for support if you have the problem? I'm -> getting lots of people complaining of not getting dns numbers assigned and -> people not getting on at all. -> -> -Dale -> -> On Thu, 3 Dec 1998, Jeff Binkley wrote: -> -> > Date: Thu, 03 Dec 1998 08:48:00 -0500 -> > From: Jeff Binkley <jeff.binkley@asacomp.com> -> > Reply-To: usr-tc@lists.xmission.com -> > To: USR-TC@lists.xmission.com -> > Subject: (usr-tc) (USR-TC) DEBUGGING PPP ON -> > -> > -> > Jesse, -> > -> > This may or may not be relevant but I was seeing a similar problem, > -> specifically with a Brother Geobook. After working with Krish quite > some -> time, we determined that it worked with the Netserver but not with > the -> HiPerArc. What he determined was the Brother was requesting an > invalied -> LCP packet length and the HiPerArc would reject the request > where the -> Netserver would ignore it. He is working on a version of > HiPerArc code -> which will work similarly to the Netserver. The Brother > Geobook has next -> to no options for PPP. I am hoping we will get the new > code by tomorrow. -> It appeats that the HiPerArc is more picky about > PPP/LCP negotiations than -> the Netserver... -> > -> > -> > Jeff Binkley -> > ASA Network Computing -> > -> >

Subject: Re: (usr-tc) Netserver reboot
From: Clayton Zekelman <clayton@mnsi.net>
Date: 1998-12-03 17:28:05

There is a known problem with certain revisions of Netserver hardware. Take a look at the chip directly above the 486 CPU. If the chip is marked with "FC3" on it, the card is bad, and needs an engineering mod. If its marked FC2, you're fine. This should be a free change, as it is a manufacturing defect. At 03:29 PM 11/25/98 -0500, you wrote: >Hi, >I am new to this list and since web archives don't seem to be up, I will >ask here my question: >I am experiencing self-reboot from my Netserver card (3.8.1) used only for >dialin PPP, from once a day to once a week. Sometimes it hangs, but more >generaly I only see that lights turn red then blinking green.. >It is running with 20MB. I would like to know if someone already met this >kind of problem and if I have a way to be sure that it's an hardware >failure, not sofware (support didn't find anything so they suggest >I replace the card... they are soo helpful.. not! ). > >TIA, >Martin > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 875 Ouellette Avenue Windsor, Ontario N9A 4J6 tel. 519-985-8410 fax. 519-258-3009

Subject: Re: (usr-tc) Netserver reboot
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-12-03 17:51:25

Bob Purdon was heard to say: >So, we had to buy a maintenance contract to get advance replacement. In >the near future I'll invoke that and get the replacements. I say "in >future" because we now have to ring the USA (from Australia) to get >support, and doing so means re-programming our call barring on our PABX to >allow international calls. Umm, what you need is VoIP... <wink> --Ricky

Subject: Re: (usr-tc) Netserver reboot
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-12-03 18:03:34

Thus spake Clayton Zekelman >There is a known problem with certain revisions of Netserver hardware. >Take a look at the >chip directly above the 486 CPU. If the chip is marked with "FC3" on it, >the card is bad, and >needs an engineering mod. If its marked FC2, you're fine. This should be >a free change, as it >is a manufacturing defect. Uhm...this doesn't cause a reboot of the whole NETServer, just a lock up of the ethernet port. And not *all* of the FC3's were bad...but most of them were. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) PRI & CT1
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-12-03 18:10:25

Thus spake John Rockwell > Yes, both the HiperARCs and the PRI Nac (I'm assuming that you also have a >chassis with quadmodems and a netserver card) allow you to configure the >switch settings on a per span basis. Uhm...no...mixing PRI and CT1 on a single dual-pri card is not possible...its not just a matter of differing switch settings, but is, instead, a matter of totally different software being loaded on the card. If you load the pri software, you can't do chan-t1, if you load the chan-t1 software, you can't do pri. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Looniness resolved
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-12-03 18:11:55

Thus spake Pete Ashdown >The problem I had today sourced to misconfigured Ascend Pipelines which >were getting away with it under 4.0.30, but not under 4.1.x. Once I >isolated the problem with a customer, it was easy to understand. >I might also add that Krish is the HiPer God. I wish I could send my >support contract money directly to him. So...uhm...what specifically was misconfigured on the pipes? I'd like to be aware of what's going on so I know what to look for if it ever happens to us (as much as I steer our customers away from ascend products, some of them insist on using them *puke* *gag*). -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Looniness resolved
From: Charles Hill <chill@ionet.net>
Date: 1998-12-03 18:23:52

> What do you recommend instead in terms of small-office, relatively inexpensive > ISDN router hardware? In the past, I've recommended Pipe 130s, because of > their (one model anyway) ability to do both BRI and CT1/Frame Relay (with an > integrated CSU/DSU). I recommend a Cisco 802 or an 804 if you want the POTS ports, which have caller ID, BTW. They run IOS. If you want scaleability, get a 1604 with a WIC slot so you can add a T1 CSU/DSU module later. Farallon or Ascend if you want to scale down from there. Intel 8100 works, too. They don't have near the number/quality of features included in Cisco IOS, however. -CH

Subject: Re: (usr-tc) Looniness resolved
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-03 18:26:00

On Thu, 3 Dec 1998, Jesse Sipprell wrote: > On Thu, Dec 03, 1998 at 06:11:55PM -0500, Jeff Mcadams wrote: > > Thus spake Pete Ashdown > > >The problem I had today sourced to misconfigured Ascend Pipelines which > > >were getting away with it under 4.0.30, but not under 4.1.x. Once I > > >isolated the problem with a customer, it was easy to understand. > > > > >I might also add that Krish is the HiPer God. I wish I could send my > > >support contract money directly to him. > > > > So...uhm...what specifically was misconfigured on the pipes? I'd like > > to be aware of what's going on so I know what to look for if it ever > > happens to us (as much as I steer our customers away from ascend > > products, some of them insist on using them *puke* *gag*). > > What do you recommend instead in terms of small-office, relatively inexpensive > ISDN router hardware? In the past, I've recommended Pipe 130s, because of > their (one model anyway) ability to do both BRI and CT1/Frame Relay (with an > integrated CSU/DSU). 3com lan modem - nothing to beet it for bri. krish > > -- > Jesse Sipprell > Technical Operations Director > Evolution Communications, Inc. > 800-496-4736 (ext 106) > > * Finger jss@evcom.net for my PGP Public Key * > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) PRI & CT1
From: John Rockwell <jrockwel@clarityconnect.com>
Date: 1998-12-03 18:42:57

Ahhh, You're right... The PRI code doesn't provide for the signalling settings that would make a CT1 possible. Hmmm, I can do this on my portmasters and HiperARC, though. Damn this modularized architecture. ;) At 06:10 PM 12/3/98 -0500, you wrote: >Thus spake John Rockwell >> Yes, both the HiperARCs and the PRI Nac (I'm assuming that you also have a >>chassis with quadmodems and a netserver card) allow you to configure the >>switch settings on a per span basis. > >Uhm...no...mixing PRI and CT1 on a single dual-pri card is not >possible...its not just a matter of differing switch settings, but is, >instead, a matter of totally different software being loaded on the >card. If you load the pri software, you can't do chan-t1, if you load >the chan-t1 software, you can't do pri. >-- >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. > John Rockwell e-mail: jrockwel@clarityconnect.com Network Engineer Clarityconnect, Inc. Ithaca Area: (607)257-8268 Outside Ithaca Area: (888)322-4900 Try us: http://www.clarityconnect.com

Subject: Re: (usr-tc) Looniness resolved
From: Dan Hollis <goemon@sasami.anime.net>
Date: 1998-12-03 19:06:46

On Thu, 3 Dec 1998, Jesse Sipprell wrote: > Granted, I love IOS as much as the next routing geek <g>, but last time I > priced a BRI module for the 160x (for my own home use), it was a tad cost > prohibitive. Thats why you buy a used 1004 for $250 instead. Integrated BRI+NT1 router plus it runs real IOS. -Dan

Subject: Re: (usr-tc) Looniness resolved
From: Jesse Sipprell <jss@evcom.net>
Date: 1998-12-03 19:07:50

On Thu, Dec 03, 1998 at 06:11:55PM -0500, Jeff Mcadams wrote: > Thus spake Pete Ashdown > >The problem I had today sourced to misconfigured Ascend Pipelines which > >were getting away with it under 4.0.30, but not under 4.1.x. Once I > >isolated the problem with a customer, it was easy to understand. > > >I might also add that Krish is the HiPer God. I wish I could send my > >support contract money directly to him. > > So...uhm...what specifically was misconfigured on the pipes? I'd like > to be aware of what's going on so I know what to look for if it ever > happens to us (as much as I steer our customers away from ascend > products, some of them insist on using them *puke* *gag*). What do you recommend instead in terms of small-office, relatively inexpensive ISDN router hardware? In the past, I've recommended Pipe 130s, because of their (one model anyway) ability to do both BRI and CT1/Frame Relay (with an integrated CSU/DSU). -- Jesse Sipprell Technical Operations Director Evolution Communications, Inc. 800-496-4736 (ext 106) * Finger jss@evcom.net for my PGP Public Key *

Subject: Re: (usr-tc) Looniness resolved
From: William Behrens <wbehrens@feist.com>
Date: 1998-12-03 19:11:33

We deploy the Lucent OR-U routers at our customer sites (cant beat it for boiler plate, bullet proof connectivity). We are looking at the new Cisco 800 series as a possible replacement (we would like to use all Cisco but the 1000 series is to cost prohibitive and the 700 series was/is junk). William Behrens Director of Network Operations ParaCom Technologies Inc. wbehrens@paracom.com -----Original Message----- >Thus spake Jesse Sipprell >>What do you recommend instead in terms of small-office, relatively inexpensive >>ISDN router hardware? In the past, I've recommended Pipe 130s, because of >>their (one model anyway) ability to do both BRI and CT1/Frame Relay (with an >>integrated CSU/DSU). > >For really inexpensive, we recommend the Netgear routers from Bay...for >higher reliability and more full features, Netopia >routers...incidentally, the Netopia's will also do frac-t1 and stuff I >believe. >-- >Jeff McAdams Email: jeffm@iglou.com >Head Network Administrator Voice: (502) 966-3848 >IgLou Internet Services (800) 436-4456 > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) COMPAQ MODEMS won't connect
From: Brian Gordon <administrator@westelcom.com>
Date: 1998-12-03 19:18:26

There have been several instances recently with new compaq modems having problems are there and resolutions to this. When is new modem coming out for the DSP's? Currently using 1.25 Also we have trouble with: Lucent Zoom And some rockwell. This is getting insane to deal with. Brian Gordon, MCP Network Administrator Westelcom Internet 518-566-8376 Voice 518-566-8348 Fax administrator@westelcom.com http://home.westelcom.com ----- Original Message ----- Sent: Wednesday, November 21, 2018 10:44 AM > >On Fri, 20 Nov 1998, Syed Amiruddin wrote: > >> Hi Everybody, >> Can anyone confirm me, is Year 2000 problem can effect on USR Access >> Servers or not? > >Syed, > >3Com has a comprehensive Y2K site. > >http://www.3com.com/products/yr2000.html > >There is specific info on each TCH component, as well as just about every >3Com product, there. > >Hope that helps. > >JP > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Looniness resolved
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-12-03 19:30:38

Thus spake Jesse Sipprell >What do you recommend instead in terms of small-office, relatively inexpensive >ISDN router hardware? In the past, I've recommended Pipe 130s, because of >their (one model anyway) ability to do both BRI and CT1/Frame Relay (with an >integrated CSU/DSU). For really inexpensive, we recommend the Netgear routers from Bay...for higher reliability and more full features, Netopia routers...incidentally, the Netopia's will also do frac-t1 and stuff I believe. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) TCM/HARM under Linux
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-12-03 19:39:33

Brian Biggs was heard to say: >Does it exist? Is there any hope? Remind me try it under WINE later :-) (heck, it ran winzip95!) --Ricky

Subject: Re: (usr-tc) Looniness resolved
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-12-03 19:41:30

Jesse Sipprell was heard to say: >What do you recommend instead in terms of small-office, relatively inexpensive >ISDN router hardware? In the past, I've recommended Pipe 130s, because of >their (one model anyway) ability to do both BRI and CT1/Frame Relay (with an >integrated CSU/DSU). Netopia... it can do ISDN or Frame -- switching between the two via replacing the interface card (I've turned several BRI ones into T1's) Granted, it doesn't do both at the same time like the 130. --Ricky

Subject: Re: (usr-tc) Looniness resolved
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-12-03 19:46:07

Tatai SV Krishnan was heard to say: >3com lan modem - nothing to beet it for bri. Not a little biased there are ya? <grin> In my experience, the LAN modem is terrible product for anyone who ever hopes to use ANYTHING other than windows. For the brainless people in the world, I'd have to agree, the LAN modem is a good idea. (plug it and pray.) 3com gave me one... I could not get it to handle my simple little /28 network at home (various non-windows things.) I gave it to someone else to play with (all 95 boxen.) Personally, I want a router! Give me something I can control the routes on. (My Cisco-ness is showing :-)) --Ricky

Subject: Re: (usr-tc) Looniness resolved
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-12-03 19:48:01

Charles Hill was heard to say: >works, too. They don't have near the number/quality of features included >in Cisco IOS, however. Very few things have the IOSness...(However, IOS was never designed to run alot of the things Cisco beginning to stick it into... dialup hardware for one.) --Ricky

Subject: Re: (usr-tc) Looniness resolved
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-12-03 19:51:19

Jeff Mcadams was heard to say: >higher reliability and more full features, Netopia >routers...incidentally, the Netopia's will also do frac-t1 and stuff I >believe. Umm, netopia has problems... try putting one on a fairly busy network. I've gotten my netopia to lose telco sync with a few 1000 pps flying PAST it (they had nothing at all to do with the router itself.) That has been about the only problem I've seen with netopia routers for the year(s) Interpath was selling them -- we're using cisco 1604s now (don't ask.) --Ricky

Subject: Re: (usr-tc) Looniness resolved
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-12-03 20:11:24

Thus spake Ricky Beam >Tatai SV Krishnan was heard to say: >>3com lan modem - nothing to beet it for bri. >Not a little biased there are ya? <grin> 'Tis what I thought as well. :) >Personally, I want a router! Give me something I can control the routes on. >(My Cisco-ness is showing :-)) I have people ask me all the time how to get ppp working under Linux...honestly I haven't done it in so long I can't usually tell them. I tell them I do my demand dialing and routing in a dedicated router box like God intended! :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Looniness resolved
From: Jesse Sipprell <jss@evcom.net>
Date: 1998-12-03 21:52:05

On Thu, Dec 03, 1998 at 06:23:52PM -0600, Charles Hill wrote: > > What do you recommend instead in terms of small-office, relatively inexpensive > > ISDN router hardware? In the past, I've recommended Pipe 130s, because of > > their (one model anyway) ability to do both BRI and CT1/Frame Relay (with an > > integrated CSU/DSU). > > I recommend a Cisco 802 or an 804 if you want the POTS ports, which have > caller ID, BTW. They run IOS. > > If you want scaleability, get a 1604 with a WIC slot so you can add a T1 > CSU/DSU module later. Granted, I love IOS as much as the next routing geek <g>, but last time I priced a BRI module for the 160x (for my own home use), it was a tad cost prohibitive. -- Jesse Sipprell Technical Operations Director Evolution Communications, Inc. 800-496-4736 (ext 106) * Finger jss@evcom.net for my PGP Public Key *

Subject: Re: (usr-tc) Looniness resolved
From: Dan Hollis <goemon@sasami.anime.net>
Date: 1998-12-03 23:38:27

On Fri, 4 Dec 1998, William Behrens wrote: > I beleive that $250 is less the IOS. The key word is "used". -Dan

Subject: Re: (usr-tc) COMPAQ MODEMS won't connect
From: Richard Lorbieski <richard@alpha1.net>
Date: 1998-12-04 00:55:24

try adding 2 or 3 commas (,,,) at the end of the phone number. Brian Gordon wrote: > > There have been several instances recently with new compaq modems having > problems are there and resolutions to this. > > When is new modem coming out for the DSP's? Currently using 1.25 > > Also we have trouble with: > > Lucent > Zoom > And some rockwell. > > This is getting insane to deal with. > > Brian Gordon, MCP > Network Administrator > Westelcom Internet > 518-566-8376 Voice > 518-566-8348 Fax > administrator@westelcom.com > http://home.westelcom.com > ----- Original Message ----- > From: John Powell <jp@packet.ae.usr.com> > To: <usr-tc@lists.xmission.com> > Sent: Wednesday, November 21, 2018 10:44 AM > Subject: Re: (usr-tc)Y2K Problem in USR Chassis > > > > >On Fri, 20 Nov 1998, Syed Amiruddin wrote: > > > >> Hi Everybody, > >> Can anyone confirm me, is Year 2000 problem can effect on USR Access > >> Servers or not? > > > >Syed, > > > >3Com has a comprehensive Y2K site. > > > >http://www.3com.com/products/yr2000.html > > > >There is specific info on each TCH component, as well as just about every > >3Com product, there. > > > >Hope that helps. > > > >JP > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Looniness resolved
From: William Behrens <wbehrens@feist.com>
Date: 1998-12-04 01:12:10

I beleive that $250 is less the IOS. William -----Original Message----- >On Thu, 3 Dec 1998, Jesse Sipprell wrote: >> Granted, I love IOS as much as the next routing geek <g>, but last time I >> priced a BRI module for the 160x (for my own home use), it was a tad cost >> prohibitive. > >Thats why you buy a used 1004 for $250 instead. Integrated BRI+NT1 router >plus it runs real IOS. > >-Dan > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) COMPAQ MODEMS won't connect
From: Eric J. Merkel <merkel@defnet.com>
Date: 1998-12-04 01:59:52

On Fri, 4 Dec 1998, Richard Lorbieski wrote: > Date: Fri, 04 Dec 1998 00:55:24 -0600 > From: Richard Lorbieski <richard@alpha1.net> > Reply-To: usr-tc@lists.xmission.com > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) COMPAQ MODEMS won't connect > > try adding 2 or 3 commas (,,,) at the end of the phone number. > Better yet, try the init string +MS=K56,,,,,40000 Eric > Brian Gordon wrote: > > > > There have been several instances recently with new compaq modems having > > problems are there and resolutions to this. > > > > When is new modem coming out for the DSP's? Currently using 1.25 > > > > Also we have trouble with: > > > > Lucent > > Zoom > > And some rockwell. > > > > This is getting insane to deal with. > > > > Brian Gordon, MCP > > Network Administrator > > Westelcom Internet > > 518-566-8376 Voice > > 518-566-8348 Fax > > administrator@westelcom.com > > http://home.westelcom.com > > ----- Original Message ----- > > From: John Powell <jp@packet.ae.usr.com> > > To: <usr-tc@lists.xmission.com> > > Sent: Wednesday, November 21, 2018 10:44 AM > > Subject: Re: (usr-tc)Y2K Problem in USR Chassis > > > > > > > >On Fri, 20 Nov 1998, Syed Amiruddin wrote: > > > > > >> Hi Everybody, > > >> Can anyone confirm me, is Year 2000 problem can effect on USR Access > > >> Servers or not? > > > > > >Syed, > > > > > >3Com has a comprehensive Y2K site. > > > > > >http://www.3com.com/products/yr2000.html > > > > > >There is specific info on each TCH component, as well as just about every > > >3Com product, there. > > > > > >Hope that helps. > > > > > >JP > > > > > > > > >- > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and 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. > ============================================================================= Eric Merkel | URL: www.metalink.net | Local Access in MetaLink Technologies, Inc | EMail: merkel@defnet.com | Defiance, Fulton, 419-782-3472 Ext. 304 | Sales: 1-888-999-8002 | Henry, & Williams Co. =============================================================================

Subject: Re: (usr-tc) COMPAQ MODEMS won't connect
From: Andrew Aken <ajaken@globaleyes.net>
Date: 1998-12-04 02:27:15

Even better yet, if it is Lucent chipset based (you'll need to check on the device driver files installed), upgrade to the latest LT Winmodem code. "Eric J. Merkel" wrote: > > On Fri, 4 Dec 1998, Richard Lorbieski wrote: > > > Date: Fri, 04 Dec 1998 00:55:24 -0600 > > From: Richard Lorbieski <richard@alpha1.net> > > Reply-To: usr-tc@lists.xmission.com > > To: usr-tc@lists.xmission.com > > Subject: Re: (usr-tc) COMPAQ MODEMS won't connect > > > > try adding 2 or 3 commas (,,,) at the end of the phone number. > > > > Better yet, try the init string +MS=K56,,,,,40000 > > Eric > > > > Brian Gordon wrote: > > > > > > There have been several instances recently with new compaq modems having > > > problems are there and resolutions to this. > > > > > > When is new modem coming out for the DSP's? Currently using 1.25 > > > > > > Also we have trouble with: > > > > > > Lucent > > > Zoom > > > And some rockwell. > > > > > > This is getting insane to deal with. > > > -- ======================================================= =========== Andrew Aken - President ========= ====== GlobalEyes Communications, Inc. ====== =Southern Illinois' Fastest Connection to the Internet= ========== http://www.GlobalEyes.net ======== =======================================================

Subject: Re: (usr-tc) Looniness resolved
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-04 07:45:51

On Thu, 3 Dec 1998, Ricky Beam wrote: > Tatai SV Krishnan was heard to say: > >3com lan modem - nothing to beet it for bri. > > Not a little biased there are ya? <grin> No not at all - This is based on my experience. > > In my experience, the LAN modem is terrible product for anyone who ever hopes > to use ANYTHING other than windows. For the brainless people in the world, > I'd have to agree, the LAN modem is a good idea. (plug it and pray.) > Well I have to disagree, Most of your users would love a product that is easy to configure and it takes only 15 min or so. I have several other bri products, like Cisco, ascend, .... ( I do have friends in other companies :-).) I use almost everyone of them. If you feel the Lan modem is a terrible product for anyone one using other than windows - Personally I feel sorry for you. This only says that you do not know the product or have not used it at all. I use it with my local lan at home and trust me I do not run windows. > 3com gave me one... I could not get it to handle my simple little /28 network > at home (various non-windows things.) I gave it to someone else to play > with (all 95 boxen.) > Take a look at it again - you can control routes. You can setup the same not just via web but like any other router - Ever tried to telnet to it? > Personally, I want a router! Give me something I can control the routes on. > (My Cisco-ness is showing :-)) > Cisco is a great product, cisco 1000 series is the one which I used to love a lot - Not any more. I love the lan modem better than the Cisco 1000. Ofcourse, if you want everything to be controlled - the best way to go is to have an ISDN card in your linux box....:-) That I love too. 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. >

Subject: RE: (usr-tc) Looniness resolved
From: William Behrens <wbehrens@feist.com>
Date: 1998-12-04 08:29:58

My mistake...no sleep....didn't read. Sorry. William -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Dan Hollis Sent: Friday, December 04, 1998 1:38 AM On Fri, 4 Dec 1998, William Behrens wrote: > I beleive that $250 is less the IOS. The key word is "used". -Dan - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Looniness resolved
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-12-04 09:03:29

Thus spake Tatai SV Krishnan >Cisco is a great product, cisco 1000 series is the one which I used to >love a lot - Not any more. I love the lan modem better than the Cisco >1000. Ofcourse, if you want everything to be controlled - the best way >to go is to have an ISDN card in your linux box....:-) That I love too. Blah...I worked very hard to get away from an ISDN TA hanging off my linux box...got tired of having to download and configure software to do stuff the "routers" already do. Finally got demand dialing and bandwidth on demand and all that stuff moved *off* my linux box onto a router where God intended things like that to be done. :) Incidentally, I use a NetGear and am pretty happy with it....I have a few beefs with it, but if 3Com's MPIP worked correctly, I wouldn't have nearly the problems with the Netgear as I do now. The main problem I've found with the Netgear is that the ISDN port will "lock up" or something like that...haven't figured out the specifics yet...but it just quits sending data out the ISDN line. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Looniness resolved
From: Brian <signal@shreve.net>
Date: 1998-12-04 09:42:40

On Thu, 3 Dec 1998, Pete Ashdown wrote: > The problem I had today sourced to misconfigured Ascend Pipelines which > were getting away with it under 4.0.30, but not under 4.1.x. Once I > isolated the problem with a customer, it was easy to understand. Can you share the details of the misconfiguration? Just so I know to look their in the future. > > I might also add that Krish is the HiPer God. I wish I could send my > support contract money directly to him. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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

Subject: Re: (usr-tc) Looniness resolved
From: Brian <signal@shreve.net>
Date: 1998-12-04 09:43:53

On Thu, 3 Dec 1998, Jesse Sipprell wrote: > On Thu, Dec 03, 1998 at 06:11:55PM -0500, Jeff Mcadams wrote: > > Thus spake Pete Ashdown > > >The problem I had today sourced to misconfigured Ascend Pipelines which > > >were getting away with it under 4.0.30, but not under 4.1.x. Once I > > >isolated the problem with a customer, it was easy to understand. > > > > >I might also add that Krish is the HiPer God. I wish I could send my > > >support contract money directly to him. > > > > So...uhm...what specifically was misconfigured on the pipes? I'd like > > to be aware of what's going on so I know what to look for if it ever > > happens to us (as much as I steer our customers away from ascend > > products, some of them insist on using them *puke* *gag*). > > What do you recommend instead in terms of small-office, relatively inexpensive > ISDN router hardware? In the past, I've recommended Pipe 130s, because of > their (one model anyway) ability to do both BRI and CT1/Frame Relay (with an > integrated CSU/DSU). Netgear RT328 is a REALLY good ISDN router. Rock solid, $250, has jacks for pots lines, 10bT, nice looking. RT348 is the same thing but has a hub built in for $40 more. > > -- > Jesse Sipprell > Technical Operations Director > Evolution Communications, Inc. > 800-496-4736 (ext 106) > > * Finger jss@evcom.net for my PGP Public Key * > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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

Subject: Re: (usr-tc) Netserver reboot
From: Bob Purdon <bobp@southcom.com.au>
Date: 1998-12-04 09:43:54

> There is a known problem with certain revisions of Netserver hardware. > Take a look at the chip directly above the 486 CPU. If the chip is > marked with "FC3" on it, the card is bad, and needs an engineering > mod. If its marked FC2, you're fine. This should be a free change, > as it is a manufacturing defect. Been there. They wanted to do a 30-day warranty exchange (hurts when you only have 5 chassis, now 6, spread across 3 POP's). So, we had to buy a maintenance contract to get advance replacement. In the near future I'll invoke that and get the replacements. I say "in future" because we now have to ring the USA (from Australia) to get support, and doing so means re-programming our call barring on our PABX to allow international calls. Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Subject: Re: (usr-tc) Netserver reboot
From: Bob Purdon <bobp@southcom.com.au>
Date: 1998-12-04 10:07:32

> >So, we had to buy a maintenance contract to get advance replacement. In > >the near future I'll invoke that and get the replacements. I say "in > >future" because we now have to ring the USA (from Australia) to get > >support, and doing so means re-programming our call barring on our PABX to > >allow international calls. > > Umm, what you need is VoIP... <wink> Agreed :-) Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Subject: RE: (usr-tc) Looniness resolved
From: Robert von Bismarck <rvb@petrel.ch>
Date: 1998-12-04 11:22:50

> -----Original Message----- > From: Jesse Sipprell [SMTP:jss@evcom.net] > Sent: vendredi, 4. d=E9cembre 1998 01:08 > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Looniness resolved >=20 >=20 > What do you recommend instead in terms of small-office, relatively > inexpensive > ISDN router hardware? In the past, I've recommended Pipe 130s, > because of > their (one model anyway) ability to do both BRI and CT1/Frame Relay > (with an > integrated CSU/DSU). >=20 For SOHO's with a BRI, we recommend ZyXel Prestige P100 or P128. They are cheap, and can be configured by our staff in 2 minutes, = they'll connect every time, all the time... just don't ask them to do DHCP on the LAN, it's definitely broken ;-) Robert > --=20 > Jesse Sipprell > Technical Operations Director > Evolution Communications, Inc. > 800-496-4736 (ext 106) >=20 > * Finger jss@evcom.net for my PGP Public Key * >=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.

Subject: Re: (usr-tc) Netserver reboot
From: Clayton Zekelman <clayton@mnsi.net>
Date: 1998-12-04 11:35:23

Well, if the ethernet port is locked, then the whole thing is toast as far as we're concerned. We only have access to the card through ethernet - we don't run serial cables to all 25 of our Netservers. Besides, what good is a Netserver without ethernet? At 06:03 PM 12/3/98 -0500, you wrote: >Thus spake Clayton Zekelman >>There is a known problem with certain revisions of Netserver hardware. >>Take a look at the >>chip directly above the 486 CPU. If the chip is marked with "FC3" on it, >>the card is bad, and >>needs an engineering mod. If its marked FC2, you're fine. This should be >>a free change, as it >>is a manufacturing defect. > >Uhm...this doesn't cause a reboot of the whole NETServer, just a lock up >of the ethernet port. And not *all* of the FC3's were bad...but most of >them were. >-- >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. > --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 875 Ouellette Avenue Windsor, Ontario N9A 4J6 tel. 519-985-8410 fax. 519-258-3009

Subject: Re: (usr-tc) Netserver reboot
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-12-04 12:04:32

Thus spake Clayton Zekelman >Well, if the ethernet port is locked, then the whole thing is toast as far >as we're concerned. We only have access to the card through ethernet - we >don't run serial cables to all 25 of our Netservers. Besides, what good is >a Netserver without ethernet? Agreed. Just pointing out that the FC3 chip (at least generally, apparently not everyone has had the same observations we have) won't cause the NETServer to *reboot*...indeed, I think that would be better...but instead causes the ethernet port to lock up. I'd *rather* have the thing reboot...'cause then at least the thing comes back up and is in service...you may have bumped some people off, but at least your service comes back to normal....with the ethernet ports locking up your service doesn't come back to normal until you get the thing rebooted (the NMC can still reboot the thing so all is not lost for remote management). -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Netserver reboot
From: David Bolen <db3l@ans.net>
Date: 1998-12-04 12:08:36

Clayton Zekelman <clayton@MNSi.Net> writes: > Well, if the ethernet port is locked, then the whole thing is toast as far > as we're concerned. We only have access to the card through ethernet - we > don't run serial cables to all 25 of our Netservers. Besides, what good is > a Netserver without ethernet? Well, some types of failures can still be reset or fixed from the console (e.g., "reset nic"). Also, if you find yourself unable to download to the card via the NMC you can always use the console. And of course, if the configuration gets erased somehow, you won't be able to fix it without console access. We wire all OOB access to all cards that have console ports - it really only gets used in problem cases but in many of those cases it can be the thing that saves you. Although if you've got access to the NMC for management you can also try resetting the slot holding the NETServer to clear a hung condition. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: Re: (usr-tc) HArc Radius Questions...
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-04 12:29:37

On Fri, 4 Dec 1998, Jesse Sipprell wrote: > Can some clued individual offer me some general enlightenment on the way > RADIUS works on the HArc? It doesn't seem intuitive to me, and/or I am not > understanding the HArc's radius methodology. Here is the scoop: > > Specifically: > > (1) As I understand it, the "authentication algorithm" being set to > ROUND_ROBIN, means that an auth request that is not replied to is sent to the > secondary server after a timeout? If set to FALL_THROUGH, the secondary is > only used after the primary has not responded to several requests. What value > controls how many requests this is before rollover to secondary occurs? > Authentication Algorithm Round Robin: Send the packet to the first Primary Radius server if no reply received after timeout Send the packet to the secondary Radius server .... ... Authetication Algorithm Fall through Send the packet to the primary radius server if no reply received after time out Send the packet to both Primary and Secondary Radius server ..... ... > (2) The accounting primary backup server: There is no corresponding > "algorithm" for when the primary backup is switched to? Or is there? Does > the authentication algorithm ROUND_ROBIN/FALL_THROUGH also apply to radius > accounting requests? > Accounting is slightly different. In accounting - If you have a primary and secondary accounting server the HiPer arc by default will send the packets to both primary and secondary. if there is no response from both after timeout, it will send the packet the backup servers for both primary and secondary. It is round robin style here. > (3) What are the differences between NETSERVER/STANDARD attribute styles in > accounting? > There is a attribute called unautheticated time. In netserver this time is equal to the unauthenticated time + the modem training time. In standard - this value is just unauthenticated time - modem training time is not added. hope this helps krish > Thanks! > > PS. Just to set the approriate clue level here, I have a pretty intimate > understanding of the RADIUS protocol, and in fact just finished a custom > RADIUS server that's working quite well with HARCs and Netservers alike. > Unlike others, I am NOT experiencing dropped/missing accounting packets from > the HARC; although I have definitely experienced md5 crypto oddities with > older versions of the netserver software. > > -- > Jesse Sipprell > Technical Operations Director > Evolution Communications, Inc. > 800-496-4736 (ext 106) > > * Finger jss@evcom.net for my PGP Public Key * > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) HArc Radius Questions...
From: Jesse Sipprell <jss@evcom.net>
Date: 1998-12-04 12:37:32

Can some clued individual offer me some general enlightenment on the way RADIUS works on the HArc? It doesn't seem intuitive to me, and/or I am not understanding the HArc's radius methodology. Specifically: (1) As I understand it, the "authentication algorithm" being set to ROUND_ROBIN, means that an auth request that is not replied to is sent to the secondary server after a timeout? If set to FALL_THROUGH, the secondary is only used after the primary has not responded to several requests. What value controls how many requests this is before rollover to secondary occurs? (2) The accounting primary backup server: There is no corresponding "algorithm" for when the primary backup is switched to? Or is there? Does the authentication algorithm ROUND_ROBIN/FALL_THROUGH also apply to radius accounting requests? (3) What are the differences between NETSERVER/STANDARD attribute styles in accounting? Thanks! PS. Just to set the approriate clue level here, I have a pretty intimate understanding of the RADIUS protocol, and in fact just finished a custom RADIUS server that's working quite well with HARCs and Netservers alike. Unlike others, I am NOT experiencing dropped/missing accounting packets from the HARC; although I have definitely experienced md5 crypto oddities with older versions of the netserver software. -- Jesse Sipprell Technical Operations Director Evolution Communications, Inc. 800-496-4736 (ext 106) * Finger jss@evcom.net for my PGP Public Key *

Subject: (usr-tc) HyperARC/Netserver
From: Mark Lemmert <cto@athenet.net>
Date: 1998-12-04 12:47:23

Does anybody know if you can run a HyperARC card and a Netserver card in the same chassis? The reason I would want to do this is because I have T1 lines connected to the WAN serial ports on most of my Netservers and the HyperARCs don't have those ports. My thought in at least a temporary scenerio put a HyperARC card into the Netserver chassis to take over the modem handling etc. but leave the Netserver card in the chassis to handle it's two T1s. Does anybody know if this will work? Mark Lemmert cto@athenet.net Chief Technical Officer (920)954-9799 AthEnet Data Exchange http://www.athenet.net

Subject: Re: (usr-tc) Looniness resolved
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-12-04 12:48:45

Brian said once upon a time: > >On Thu, 3 Dec 1998, Pete Ashdown wrote: > >> The problem I had today sourced to misconfigured Ascend Pipelines which >> were getting away with it under 4.0.30, but not under 4.1.x. Once I >> isolated the problem with a customer, it was easy to understand. > >Can you share the details of the misconfiguration? Just so I know to look >their in the future. The beginning of the tip-off to resolution came when I saw the two sides arguing over IP address with the "monitor ppp" function of the ARC. After talking with the customer, I found that they had no configuration for a legacy WAN subnet (which we use for NT) in the Ascend Pipeline. In the example below, a framed-route would establish subnet X as routed through WAN subnet Y. With 4.0.30, the transaction looked sort of like this: Customer -> Give me address X ARC -> Here's address Y Customer -> Give me address X ARC -> Whatever, use X if you like, I'll still know you're Y, but I'll route X over Y, so things will still work. Under 4.1.x, the two sides get in an argument over X and Y and eventually part ways with a disconnect. The fix was to remove the WAN address Y from our RADIUS configuration, so both sides agree that they are X. Second problem today was with Novell's multi-protocol-router. According to Krish, it improperly NAC's the CCP compression request for STAC. Thus under 4.1.x, it can't get past the initial ISDN negotiation. The solution was to get the customer to stop using ISDN compression in the MPR configuration. At first they denied using it, but when pressed, sure enough, that was it.

Subject: RE: (usr-tc) HArc Radius Questions...
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-04 12:59:23

Subject: (usr-tc) HiPer ARC 4.1.72 - 7
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-04 13:27:41

HiPer ARC 4.1.72 -7 doesn't seem to update its table completely when you move a card from one slot to another. Slot Owner Description Ports Type Console 1 YES 24 Channel High Density Modem 24 DYNAMIC NO 2 YES 24 Channel High Density Modem 24 DYNAMIC NO 3 YES --EMPTY-- 0 STATIC NO 4 YES --EMPTY-- 0 STATIC NO 5 YES --EMPTY-- 0 STATIC NO 6 YES --EMPTY-- 0 STATIC NO 7 YES --EMPTY-- 0 STATIC NO 8 YES --EMPTY-- 0 STATIC NO 9 YES --EMPTY-- 0 STATIC NO 10 YES --EMPTY-- 0 STATIC NO 11 YES --EMPTY-- 0 STATIC NO 12 YES --EMPTY-- 0 STATIC NO 13 YES --EMPTY-- 0 STATIC NO 14 YES --EMPTY-- 0 STATIC NO 15 YES 24 Channel High Density Modem 24 DYNAMIC NO 16 YES HiPer Access Router NAC 0 DYNAMIC NO There is no card in slot 2. It was moved to slot 15. The Hiper ARC immediately brought up all 24 int for slot 15 and brought down all 24 for slot 2 but syill seems to think there is a card in slot 2. Everything has been rebooted except the arc. Can't reboot it now because there are 24 people on line. Has anyone else seen this happen. It's a first for me. I assume it's a bug.

Subject: RE: (usr-tc) HArc Radius Questions...
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-04 13:33:12

>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan >Sent: Friday, December 04, 1998 12:30 PM >To: Jesse Sipprell >Cc: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) HArc Radius Questions... > > >On Fri, 4 Dec 1998, Jesse Sipprell wrote: > >> Can some clued individual offer me some general enlightenment on the way >> RADIUS works on the HArc? It doesn't seem intuitive to me, >and/or I am not >> understanding the HArc's radius methodology. > >Here is the scoop: >> >> Specifically: >> >> (1) As I understand it, the "authentication algorithm" being set to >> ROUND_ROBIN, means that an auth request that is not replied to >is sent to the >> secondary server after a timeout? If set to FALL_THROUGH, the >secondary is >> only used after the primary has not responded to several >requests. What value >> controls how many requests this is before rollover to secondary occurs? >> >Authentication Algorithm Round Robin: >Send the packet to the first Primary Radius server >if no reply received after timeout >Send the packet to the secondary Radius server >.... >... That is definitely not what Monitor RADIUS was showing me when I was watching Authentications. When I was monitoring the authentications I saw all authentication requests go to the second server first, fail and then go to the first primary server. My primary server was down earlier so I assume that is why it was trying second first. May have just been a quirk. > >Authetication Algorithm Fall through > >Send the packet to the primary radius server >if no reply received after time out >Send the packet to both Primary and Secondary Radius server >..... >... > > > >> (2) The accounting primary backup server: There is no corresponding >> "algorithm" for when the primary backup is switched to? Or is >there? Does >> the authentication algorithm ROUND_ROBIN/FALL_THROUGH also apply >to radius >> accounting requests? >> > >Accounting is slightly different. > >In accounting - If you have a primary and secondary accounting server > >the HiPer arc by default will send the packets to both primary and >secondary. >if there is no response from both after timeout, >it will send the packet the backup servers for both primary and secondary. >It is round robin style here. > > >> (3) What are the differences between NETSERVER/STANDARD >attribute styles in >> accounting? >> > >There is a attribute called unautheticated time. In netserver this time >is equal to the unauthenticated time + the modem training time. >In standard - this value is just unauthenticated time - modem training >time is not added. > > >hope this helps > >krish > >> Thanks! >> >> PS. Just to set the approriate clue level here, I have a pretty intimate >> understanding of the RADIUS protocol, and in fact just finished a custom >> RADIUS server that's working quite well with HARCs and Netservers alike. >> Unlike others, I am NOT experiencing dropped/missing accounting >packets from >> the HARC; although I have definitely experienced md5 crypto oddities with >> older versions of the netserver software. >> >> -- >> Jesse Sipprell >> Technical Operations Director >> Evolution Communications, Inc. >> 800-496-4736 (ext 106) >> >> * Finger jss@evcom.net for my PGP Public Key * >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Connection Problem
From: GTI x2 Tech <x2@apollo.gti.net>
Date: 1998-12-04 13:36:38

This has just started happening the last 2 weeks to customers that have been using us for years. I have not upgraded any code, changed any settings, etc. etc. And all the customers Ive talked to havent changed anything either. Anyway they log in, everything goes smoothly untill this: Sending PAP_AUTH_ACK to port S8 of 20 bytes containing: 02 01 00 14 0F 4C 6F 67 69 6E 20 53 75 63 63 65 65 64 65 64 Packet Info: Code: 0x02, ID: 0x01, 20 bytes. Message: Login Succeeded (15 bytes), [0x4C6F67696E20537563636565646564] Sending IPCP_CONFIGURE_REQUEST to port S8 of 10 bytes containing: 01 01 00 0A 03 06 C7 AB 1B 03 Packet Info: Code: 0x01, ID: 0x01, 10 bytes. IP-Address [0x03], length: (6 bytes), [Valid IP*] Received LCP_PROTOCOL_REJECT on port S8 of 12 bytes containing: 08 05 00 10 80 21 01 01 00 0A 03 06 C7 AB 1B 03 Packet Info: Code: 0x08, ID: 0x05, 16 bytes. Rejected Protocol: [0x8021], Internet Protocol Control Protocol 01 01 00 0A 03 06 C7 AB 1B 03 Packet Info: Code: 0x01, ID: 0x01, 10 bytes. IP-Address [0x03], length: (6 bytes), [term server IP*] This is happening to just a handfull of customers, but its a constant problem. It *MIGHT* have to do with IE 5.0?!? My hardware is a USR TC Netserver all with latest code. Any ideas? Thanks, John Harper x2@gti.net

Subject: Re: (usr-tc) HArc Radius Questions...
From: Jesse Sipprell <jss@evcom.net>
Date: 1998-12-04 13:41:54

On Fri, Dec 04, 1998 at 12:59:23PM -0600, Brian K McIntire wrote: > >-----Original Message----- > >From: owner-usr-tc@lists.xmission.com > >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jesse Sipprell > >Sent: Friday, December 04, 1998 11:38 AM > >To: usr-tc@lists.xmission.com > >Subject: (usr-tc) HArc Radius Questions... > > > > > >Can some clued individual offer me some general enlightenment on the way > >RADIUS works on the HArc? It doesn't seem intuitive to me, and/or I am not > >understanding the HArc's radius methodology. > > > >Specifically: > > > >(1) As I understand it, the "authentication algorithm" being set to > >ROUND_ROBIN, means that an auth request that is not replied to is > >sent to the > >secondary server after a timeout? > > No. If set to round_robin the HiPer ARC will send authentication requests > to the first RADIUS server. If the first fails it will send it to the > second. As long as the second stays up it will never send another > authentication request to RADIUS server 1 again. Unless, of course, you > reboot the HARC. Hmmm.. "fails". What does this mean? A certain number of requests are not answered? If so, what controls the number of requests? Is this statistic over a given time period, or a "total number of failures"? Hopefully not a total, because then statistically the value will eventually be reached simply by normal packet loss. I was previously having a problem with the HArc switching over to my secondary server, even though the primary was responding to requests. Krish suggested I change the algorithm to FALL_THROUGH. I have done this, and it does solve the problem but could be problematic in terms of UDP packet loss which may occur if the circuit to the remote POP gets saturated (the HArc is at a POP and the radius servers are on our backbone). > > > If set to FALL_THROUGH, the secondary is > >only used after the primary has not responded to several requests. > > I using monitor RADIUS on an authentication request yesterday. It appears, > when sent to FALL_THROUGH the auth request goes to RADIUS server 1 and > immediately to the second if one does not respond or returns an access > denied. I just took a look at this. I'm seeing slightly different behavior. When an auth request is answered with Access-Reject, the HArc does the Right Thing and does not resend. Perhaps FALL_THROUGH causes the radius client to send to the secondary server only if not answered within a timeout period by the primary? IMO, the _desired_ implementation should act somewhat like ROUND_ROBIN, rolling over to a secondary or tertiary if X number of requests are not responded to within Y timeframe. Then, the radius client should occasionally "probe" the preferred primary server to see if it is responding. Once responding normally, the client can then roll back to the most preferred server. If FALL_THROUGH works as I hypothesized above (which may NOT be a valid assumption), I definitely can see a problem occuring should intermittant network congestion cause a brief period of packet loss. -- Jesse Sipprell Technical Operations Director Evolution Communications, Inc. 800-496-4736 (ext 106) * Finger jss@evcom.net for my PGP Public Key *

Subject: RE: (usr-tc) HArc Radius Questions...
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-04 13:46:16

>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jesse Sipprell >Sent: Friday, December 04, 1998 12:42 PM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) HArc Radius Questions... > > >On Fri, Dec 04, 1998 at 12:59:23PM -0600, Brian K McIntire wrote: >> >-----Original Message----- >> >From: owner-usr-tc@lists.xmission.com >> >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jesse Sipprell >> >Sent: Friday, December 04, 1998 11:38 AM >> >To: usr-tc@lists.xmission.com >> >Subject: (usr-tc) HArc Radius Questions... >> > >> > >> >Can some clued individual offer me some general enlightenment on the way >> >RADIUS works on the HArc? It doesn't seem intuitive to me, >and/or I am not >> >understanding the HArc's radius methodology. >> > >> >Specifically: >> > >> >(1) As I understand it, the "authentication algorithm" being set to >> >ROUND_ROBIN, means that an auth request that is not replied to is >> >sent to the >> >secondary server after a timeout? >> >> No. If set to round_robin the HiPer ARC will send >authentication requests >> to the first RADIUS server. If the first fails it will send it to the >> second. As long as the second stays up it will never send another >> authentication request to RADIUS server 1 again. Unless, of course, you >> reboot the HARC. > >Hmmm.. "fails". What does this mean? A certain number of requests are not >answered? If so, what controls the number of requests? Is this statistic >over a given time period, or a "total number of failures"? Hopefully not a >total, because then statistically the value will eventually be >reached simply >by normal packet loss. I was previously having a problem with the HArc >switching over to my secondary server, even though the primary was >responding >to requests. Krish suggested I change the algorithm to >FALL_THROUGH. I have >done this, and it does solve the problem but could be problematic >in terms of >UDP packet loss which may occur if the circuit to the remote POP gets >saturated (the HArc is at a POP and the radius servers are on our >backbone). > >> >> > If set to FALL_THROUGH, the secondary is >> >only used after the primary has not responded to several requests. >> >> I using monitor RADIUS on an authentication request yesterday. >It appears, >> when sent to FALL_THROUGH the auth request goes to RADIUS server 1 and >> immediately to the second if one does not respond or returns an access >> denied. > >I just took a look at this. I'm seeing slightly different >behavior. When an >auth request is answered with Access-Reject, the HArc does the >Right Thing and >does not resend. The comment I made about sending the authentication request to another server was for a behavior I saw when a customer of mine had the wrong secret set on his Primary. >Perhaps FALL_THROUGH causes the radius client to >send to the >secondary server only if not answered within a timeout period by >the primary? > That has been my observation as well. >IMO, the _desired_ implementation should act somewhat like ROUND_ROBIN, >rolling over to a secondary or tertiary if X number of requests are not >responded to within Y timeframe. Then, the radius client should >occasionally >"probe" the preferred primary server to see if it is responding. Once >responding normally, the client can then roll back to the most preferred >server. > >If FALL_THROUGH works as I hypothesized above (which may NOT be a valid >assumption), I definitely can see a problem occuring should intermittant >network congestion cause a brief period of packet loss. > >-- >Jesse Sipprell >Technical Operations Director >Evolution Communications, Inc. >800-496-4736 (ext 106) > >* Finger jss@evcom.net for my PGP Public Key * > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) HyperARC/Netserver
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-04 13:52:48

You should telnet to the HiPer ARC and type the following: Disable nmc chassis_awareness You will have to statically configure each slot. The following is an example: set chassis slot 1 card_type hdm_24 type static owner yes ports 23 or 24 Telnet to the netserver and set all ports inactive save all and reset all That should be all you have to do. >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mark Lemmert >Sent: Friday, December 04, 1998 12:47 PM >To: usr-tc@lists.xmission.com >Subject: (usr-tc) HyperARC/Netserver > > >Does anybody know if you can run a HyperARC card and a Netserver >card in the same chassis? > >The reason I would want to do this is because I have T1 lines connected >to the WAN serial ports on most of my Netservers and the HyperARCs don't >have those ports. My thought in at least a temporary scenerio put >a HyperARC >card into the Netserver chassis to take over the modem handling >etc. but leave >the Netserver card in the chassis to handle it's two T1s. > >Does anybody know if this will work? > > >Mark Lemmert cto@athenet.net >Chief Technical Officer (920)954-9799 >AthEnet Data Exchange http://www.athenet.net > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) HArc Radius Questions...
From: Jesse Sipprell <jss@evcom.net>
Date: 1998-12-04 13:56:40

On Fri, Dec 04, 1998 at 12:29:37PM -0600, Tatai SV Krishnan wrote: > On Fri, 4 Dec 1998, Jesse Sipprell wrote: > > > Can some clued individual offer me some general enlightenment on the way > > RADIUS works on the HArc? It doesn't seem intuitive to me, and/or I am not > > understanding the HArc's radius methodology. > > Here is the scoop: > > > > Specifically: > > > > (1) As I understand it, the "authentication algorithm" being set to > > ROUND_ROBIN, means that an auth request that is not replied to is sent to the > > secondary server after a timeout? If set to FALL_THROUGH, the secondary is > > only used after the primary has not responded to several requests. What value > > controls how many requests this is before rollover to secondary occurs? > > > Authentication Algorithm Round Robin: > Send the packet to the first Primary Radius server > if no reply received after timeout > Send the packet to the secondary Radius server > .... > ... > > Authetication Algorithm Fall through > > Send the packet to the primary radius server > if no reply received after time out > Send the packet to both Primary and Secondary Radius server > ..... > ... So, if I understand your answer correctly, a *single* "failure to receive response" causes the HArc radius client to switch to either the secondary server or to both servers (depending on round_robin/fall_through)? Thanks! -- Jesse Sipprell Technical Operations Director Evolution Communications, Inc. 800-496-4736 (ext 106) * Finger jss@evcom.net for my PGP Public Key *

Subject: Re: (usr-tc) HyperARC/Netserver
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-12-04 14:03:30

Mark Lemmert was heard to say: >Does anybody know if you can run a HyperARC card and a Netserver >card in the same chassis? > >The reason I would want to do this is because I have T1 lines connected >to the WAN serial ports on most of my Netservers and the HyperARCs don't >have those ports. My thought in at least a temporary scenerio put a HyperARC >card into the Netserver chassis to take over the modem handling etc. but leave >the Netserver card in the chassis to handle it's two T1s. > >Does anybody know if this will work? Yes, you can... HiperARC>> list chassIS Slot Owner Description Ports Type 1 NO Primary Rate T1 NAC 0 DYNAMIC 2 NO Gen. 2 V.34 Digital Modem NAC 4 DYNAMIC 3 NO Gen. 2 V.34 Digital Modem NAC 4 DYNAMIC 4 NO Gen. 2 V.34 Digital Modem NAC 4 DYNAMIC 5 NO Gen. 2 V.34 Digital Modem NAC 4 DYNAMIC 6 NO Gen. 2 V.34 Digital Modem NAC 4 DYNAMIC 7 NO Gen. 2 V.34 Digital Modem NAC 4 DYNAMIC 8 NO Gen. 2 V.34 Digital Modem NAC 4 DYNAMIC 9 NO --EMPTY-- 0 STATIC 10 NO --EMPTY-- 0 STATIC 11 NO --EMPTY-- 0 STATIC 12 NO --EMPTY-- 0 STATIC 13 YES 24 Channel High Density Modem 23 DYNAMIC 14 YES 24 Channel High Density Modem 23 DYNAMIC 15 NO ISDN Primary Direct NAC 0 DYNAMIC 16 NO HiPer Access Router NAC 0 DYNAMIC The NetServer has control over the quads (pri feed) and the hiper has control over the DSPs. --Ricky

Subject: Re: (usr-tc) HyperARC/Netserver
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-04 14:04:48

Yes you can. Make sure that NMC chassis awarness is set to off on the hiper arc. and program you modes static. 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, 4 Dec 1998, Mark Lemmert wrote: > Does anybody know if you can run a HyperARC card and a Netserver > card in the same chassis? > > The reason I would want to do this is because I have T1 lines connected > to the WAN serial ports on most of my Netservers and the HyperARCs don't > have those ports. My thought in at least a temporary scenerio put a HyperARC > card into the Netserver chassis to take over the modem handling etc. but leave > the Netserver card in the chassis to handle it's two T1s. > > Does anybody know if this will work? > > > Mark Lemmert cto@athenet.net > Chief Technical Officer (920)954-9799 > AthEnet Data Exchange http://www.athenet.net > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) COMPAQ MODEMS won't connect
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-12-04 15:33:13

It isn't. Compaq uses Rockwell HCF modems. They're far worse than the LT Winmodems, mostly because there's no firmware update (that we know of) that fixes the problems. At least the LT Winmodems can be made to behave by upgrading them. The Diamond SupraMax appears to be the same thing. They can't seem to connect reliably. We haven't tried every iteration of init strings yet but the comma trick or +ms would probably take care of it. Still, those modems are *evil*. :) Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ # view;touch;unzip;finger;mount;mv;mv;mv;yes;mv;yes;mv;yes;umount;sleep On Fri, 4 Dec 1998, Andrew Aken wrote: > Even better yet, if it is Lucent chipset based (you'll need to check on > the device driver files installed), upgrade to the latest LT Winmodem > code. > > "Eric J. Merkel" wrote: > > > > On Fri, 4 Dec 1998, Richard Lorbieski wrote: > > > > > Date: Fri, 04 Dec 1998 00:55:24 -0600 > > > From: Richard Lorbieski <richard@alpha1.net> > > > Reply-To: usr-tc@lists.xmission.com > > > To: usr-tc@lists.xmission.com > > > Subject: Re: (usr-tc) COMPAQ MODEMS won't connect > > > > > > try adding 2 or 3 commas (,,,) at the end of the phone number. > > > > > > > Better yet, try the init string +MS=K56,,,,,40000 > > > > Eric > > > > > > > Brian Gordon wrote: > > > > > > > > There have been several instances recently with new compaq modems having > > > > problems are there and resolutions to this. > > > > > > > > When is new modem coming out for the DSP's? Currently using 1.25 > > > > > > > > Also we have trouble with: > > > > > > > > Lucent > > > > Zoom > > > > And some rockwell. > > > > > > > > This is getting insane to deal with. > > > > > > -- > ======================================================= > =========== Andrew Aken - President ========= > ====== GlobalEyes Communications, Inc. ====== > =Southern Illinois' Fastest Connection to the Internet= > ========== http://www.GlobalEyes.net ======== > ======================================================= > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) HyperARC/Netserver
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-12-04 16:51:38

Tatai SV Krishnan was heard to say: >Yes you can. Make sure that NMC chassis awarness is set to off on the >hiper arc. and program you modes static. ... >> Does anybody know if you can run a HyperARC card and a Netserver >> card in the same chassis? ... FWIW, my ARC has chassis awareness enabled and it works just fine. (Well you have to staticly define who owns what, but...) --Ricky

Subject: Re: (usr-tc) route on netserver
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-12-04 17:05:31

Matthew Opoka said once upon a time: > >I have to class C's. I have my radius, web, dns, and other servers on. >The other I use for my ppp dialup. >Right now if a user dials in everything has to go thru my router befor it >gets to my radius, DNS, or web servers. >How do I add a static route in my netserver to let it know about the other >class c? I have no routing in my router just static routes. Unless the two C's are contiguous, your PPP connections have to go through the router to reach the other class C. By definition, addresses in the same subnet can reach each other without a router, but subnets require a router to talk to each other. The reason I ask about being contiguous is if so, you could make both of your C's a /23 subnet, although I wouldn't recommend it. It will cause problems when you start to grow.

Subject: Re: (usr-tc) COMPAQ MODEMS won't connect
From: K Mitchell <mitch@keyconn.net>
Date: 1998-12-04 17:29:00

FWIW I have a Compaq Microcom 415 here that I tested and was getting solid 46.6 connects to my Hiper ARC 4.0.30/DSP 1.2.5 Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

Subject: (usr-tc) route on netserver
From: Matthew Opoka <phantom@pemberton.magnolia.net>
Date: 1998-12-04 17:35:33

I have to class C's. I have my radius, web, dns, and other servers on. The other I use for my ppp dialup. Right now if a user dials in everything has to go thru my router befor it gets to my radius, DNS, or web servers. How do I add a static route in my netserver to let it know about the other class c? I have no routing in my router just static routes. Thanks -- Matthew Opoka Systems Admin Mississippi Internet Services, Inc. http://www.magnolia.net Voice: 601.661.0081 Fax: 601.634.1952

Subject: Re: (usr-tc) route on netserver
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-12-04 19:22:32

-----BEGIN PGP SIGNED MESSAGE----- Thus spake Matthew Opoka >I have to class C's. I have my radius, web, dns, and other servers on. >The other I use for my ppp dialup. >Right now if a user dials in everything has to go thru my router befor it >gets to my radius, DNS, or web servers. >How do I add a static route in my netserver to let it know about the other >class c? I have no routing in my router just static routes. If your two "class c's" are contiguous(sp?), or they are a /23 (to use classless notation), then you should just specify everything as a /23 (assuming you have classless capabilities on all your systems), if they aren't contiguous, then you could use a dynamic routing protocol and let the systems find each other that way (not pretty, but it could work), another possibility...some systems will let you specify that a network (/24, or class c in this case) is directly connected without having their own network address on that network...at least I *think* that could work. Might want to play with it and try it out. - -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNmh8xdj85flqqLcBAQFWyQQApnY5hyrT/vJ+7IdG9ZyVcgoiSlcpuvlc 8BacMRh9OLJ3P4PhJE53yhF0N7htVtPayFNGhh+kc7dnnHc9zaCu5UnIntazv39w z8IJZB9Y8fyvysSssnSLRAPQ5OfT8lchWEL2m/xbcCgVphDLu2OI0JoutIiyL6x9 gatSzGhHfWg= =C0SW -----END PGP SIGNATURE-----

Subject: (usr-tc) Security and Anomally
From: Ricky <rickyz@mindspring.com>
Date: 1998-12-04 23:51:25

All, I need any and all suggestions explaining the Security and Accounting = anomally that I am witnessing right now. Let me add that I know next to = nothing on the security and accounting package as a whole, so keep in = mind that's where I'm thinkin' the problem must be. Here goes. <twilight zone tune> Have 3 locations: Hq, Pop1, and Pop2. Hiper bundle at HQ, and Pop1...a Quad/Netserver chassis at Pop2. One Security and Acounting ver. 5.5.4 up and running fine at HQ = authenticating for all three locations. We say hey, let's add a backup server.....so we do. Loaded the same = version of S&A on the machine, copied the radius.mdb file over (ftp'd = it), and put it to the test. Turned off the primary, and watched as only = the netserver could authenticate against it. Turn on Primary, CAN = authenticate, turn off primary , only the Netserver can authenticate? = The usual comes to mind: secrets, ip's/ports in the clients file. All = re-entered in the ARC's, all re-entered in the setup screen shown below. = Now get this: a monitor ppp shows pap auth requests again and again, = with no Naks, or Acks.....and the requests MUST be getting to the = Secondary S&A server because we see the user name we are sending cause = the server to bark: "A packet was dropped because of a prior request. = The NAS will change the packet in about 2 minutes". And get this: we can = ping or trace route either way, back and forth.=20 Where are the auth ack packets going?=20 Why does the Netserver authenticate fine? Is there missing MS NT service pak on the secondary server that would = cause this sort of thing? (just pulled that out of my butt) Why would first line 3Com tell me to upgrade the ARC to 4.1.72-7? = Please, that's ridiculas. This what the setup screen looks like on both severs, so if it is = incorrect (and that's entirely possible), keep in mind the primary = server is identical, and authentication works fine for all three = locations IP PORT SECRET TYPE -- ---- ------ ---- 1645 packard1 Accounting Server 205.216.110.15 1646 NMC 205.216.110.18 1645 packard1 HiPer and Netserver 205.216.110.18 1646 HiPer and Netserver 208.157.60.15 1646 NMC 208.157.60.15 1645 packard1 NetServer 3.x 208.157.60.16 1646 NMC 208.157.60.16 1645 packard1 NMC 208.157.60.18 1645 packard1 NetServer 3.x 208.157.60.18 1646 NetServer 3.x 208.157.60.19 1646 HiPer & NetServer 208.157.60.19 1645 packard1 HiPer & NetServer 1645 NetServer 3.x The kit and ka-boodle following system release 3.1.2 </twilight zone tune> o o =20 \_ _/=20 <(@@)> ----------------000----()----000------------------- THE TRUTH IS OUT THERE 00O O00 =A9

Subject: (usr-tc) Recall: Security and Anomally
From: Ricky <rickyz@mindspring.com>
Date: 1998-12-04 23:52:28

Ricky would like to recall the message, "Security and Anomally".

Subject: (usr-tc) Recall: Security and Anomally
From: Ricky <rickyz@mindspring.com>
Date: 1998-12-04 23:52:53

Ricky would like to recall the message, "Security and Anomally".

Subject: Re: (usr-tc) Security and Anomally
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-12-05 01:24:22

Ricky was heard to say: >Now get this: a monitor ppp shows pap auth requests again and again, = >with no Naks, or Acks.....and the requests MUST be getting to the = Umm... look at 'monitor radius' to see what the problem is. --Ricky

Subject: (usr-tc) MRTG modem useage monitoring
From: K Mitchell <mitch@keyconn.net>
Date: 1998-12-05 02:55:54

I've been unsuccessfully trying to set MRTG up to display modem useage stats from my HiPer ARC. Here's the relevant portion of my mrtg.cgf Can someone point out what I'm doing wrong here? #..................................................................... Target[tch1]: 1.3.6.1.4.1.429.2.19:public@204.171.31.2 MaxBytes[tch1]: 46 Unscaled[tch1]:ymwd Title[tch1]: Total Control Hub #1 PageTop[tch1]: <H1>TCH1 Modem Utilization </H1> YLegend[tch1]:Modem Capacity Options[tch1]:gauge,growright ShortLegend[tch1]:Modems Legend1[tch1]:&nbsp Utilization &nbsp Legend2[tch1]:&nbsp Capacity &nbsp Legend3[tch1]:&nbsp Connections &nbsp Legend4[tch1]:&nbsp Capacity &nbsp LegendI[tch1]:&nbsp Utilization &nbsp LegendO[tch1]:&nbsp Capacity &nbsp #--------------------------------------------------------------- Thanks, Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

Subject: RE: (usr-tc) Security and Anomally
From: Ricky <rickyz@mindspring.com>
Date: 1998-12-05 07:06:45

------ =_NextPart_000_01BE201D.DA337B60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks....I've seen that command before, but we are running 4.0.30 on = the ARC's and mon ppp is the only option that shows up if I do a mon ? Is this a monitor command supported in R&A? Maybe THAT's a good reason = to go ahead to 4.1.72-7? I'll buy that. Thanks for the reply. -----Original Message----- Sent: Saturday, December 05, 1998 1:24 AM Ricky was heard to say: >Now get this: a monitor ppp shows pap auth requests again and again, = =3D >with no Naks, or Acks.....and the requests MUST be getting to the =3D Umm... look at 'monitor radius' to see what the problem is. --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. ------ =_NextPart_000_01BE201D.DA337B60 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IgAMAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYA0AEAAAEAAAAQAAAAAwAAMAIAAAAL AA8OAAAAAAIB/w8BAAAAUQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHVzci10Y0BsaXN0cy54 bWlzc2lvbi5jb20AU01UUAB1c3ItdGNAbGlzdHMueG1pc3Npb24uY29tAAAAAB4AAjABAAAABQAA AFNNVFAAAAAAHgADMAEAAAAaAAAAdXNyLXRjQGxpc3RzLnhtaXNzaW9uLmNvbQAAAAMAFQwBAAAA AwD+DwYAAAAeAAEwAQAAABwAAAAndXNyLXRjQGxpc3RzLnhtaXNzaW9uLmNvbScAAgELMAEAAAAf AAAAU01UUDpVU1ItVENATElTVFMuWE1JU1NJT04uQ09NAAADAAA5AAAAAAsAQDoBAAAAHgD2XwEA AAAaAAAAdXNyLXRjQGxpc3RzLnhtaXNzaW9uLmNvbQAAAAIB918BAAAAUQAAAAAAAACBKx+kvqMQ GZ1uAN0BD1QCAAAAAHVzci10Y0BsaXN0cy54bWlzc2lvbi5jb20AU01UUAB1c3ItdGNAbGlzdHMu eG1pc3Npb24uY29tAAAAAAMA/V8BAAAAAwD/XwAAAAACAfYPAQAAAAQAAAAAAAAC+WgBBIABACMA AABSRTogKHVzci10YykgU2VjdXJpdHkgYW5kIEFub21hbGx5AMgLAQWAAwAOAAAAzgcMAAUABwAG AC0ABgAmAQEggAMADgAAAM4HDAAFAAcAAgAwAAYAJQEBCYABACEAAAA1NTBBRjREN0IyOEJEMjEx ODQxRDQ0NDU1MzU0MDAwMADZBgEDkAYA7AYAACEAAAALAAIAAQAAAAsAIwAAAAAAAwAmAAAAAAAL ACkAAAAAAAMALgAAAAAAAwA2AAAAAABAADkAYGtDukcgvgEeAHAAAQAAACMAAABSRTogKHVzci10 YykgU2VjdXJpdHkgYW5kIEFub21hbGx5AAACAXEAAQAAABYAAAABviBHujLX9ApWi7IR0oQdREVT VAAAAAAeAB4MAQAAAAUAAABTTVRQAAAAAB4AHwwBAAAABwAAAHJpY2t5egAAAwAGEL25OGwDAAcQ 8gIAAB4ACBABAAAAZQAAAFRIQU5LU0lWRVNFRU5USEFUQ09NTUFOREJFRk9SRSxCVVRXRUFSRVJV Tk5JTkc0MDMwT05USEVBUkNTQU5ETU9OUFBQSVNUSEVPTkxZT1BUSU9OVEhBVFNIT1dTVVBJRklE T0EAAAAAAgEJEAEAAADTAwAAzwMAAH0FAABMWkZ14bISNdMACgEKMzYB6CACpAPjCQIAY2gKwHNl dDAeIAcTAoMAUA+WcHJxmjIQln0KgAjIIDsJb5gyNTUCgAqBdWMAUA0LA2MAQQtgbmcxMCQzMwum IFQQIG5rBHMuF2FJJ3ZlIHMQUAnwIHQQIAVABaBtMQOBZCBiARAFsGUsdRkAdQVAdxfQCsAX0HIM dW4DABYQIDQuMDwuMxCAAiAYMRfQQVK8QycEIBjSBGADoHAcgM4gBAAbUwIgbHkbIAUwhmkbMxhh c2hvdwQgAnUcoWYgSSBkb9sZ8BwzPwqiCoBJHNIcwVkfU2l0BbEYlnMeoHAPCREJgBywA6BSJkE/ GQXQYXkZEBbwSEFUMRvSIGdvBHAaMGVhvnMbMh8wI9AZ8BtwYRjwkySRGsAxLgHALTciwL0XoGwD IBmQHWAYQi4fxHsfxBcEIBkxG1MJcAtQec8m9hWwAtERQjE2JwgLMLxsaQ5xCqADYCIgYwVA6i0r 0k8FEGcLgAdABdDhB5BzYWdlK9MnBitkDysxCxMrZAIAaS0xNMY0AUAq8DE4MAFADNBRL3NiIEYD YToMg2KhEIBSaWNrHWBCJDAAbSBbU01UUDrMamYZEDIQQEkCMASQ0wqwGEAubhBgXScFMKCvBmAC MDEHBhB0CHBkIvA1GXBEBZBlBtAEkCAwQjUZcDE5OTg2sDqUMjQQkE0z91RvMQeAdXNyLXRjQCrw ZHN0F1B4bQQBHbEuYxiRM/h1YmorkTEIZag6ICg4xCkGUWMIcWZ0HWAY0kFuA3EmQHm/LX8uiir0 C7Yf0zGUdyRA3iAlAQsgJIIs4HkxAB/T/D5OHmAjwBBgIEM8ACCorxyCHkQKsBygYRmgaCQR7nEK UDlRGfBnC3Eb80YjfRlwPUJ1A/BFYT2QB7BhtxdAGXAFsUExsBdTLhjSwyh0RbVNVVNUGQFDEr8d oBqRJJEbYkc1H8RVGLBlF2EgCQBvaxnwBUAn1SDGciUgaTjAJ0HzCeD/GcAYUhtiK1ECYDYgHLEm +/8r0DGTJwpQtR/EOAEekACA/zrwBPIjESSROMQZcBBQRpJfA6A2IAtwAyAkkSIAwGrXBbAfIARg QDmaIlK1R7N2IlNaOMQiIlIbYgbgZP8dYR7gG2IHgSziJvUwsAWx/wuAGTEAwB2jGzFOQC0AReL3 TfIQYAiBdhqCL0BP4BvkvwbwHCEsxAQgVMJStSIbcHxscFlAS2Us4AeAGfBk/mQJcAQQTPA14B8w PZAFQL84wBfQRbArcQQgImF5CGELWo0SoQBkwAADABAQAAAAAAMAERABAAAAAwCAEP////9AAAcw QANULUcgvgFAAAgwQANULUcgvgELACSACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMAJYAI IAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAmgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUAALcN AAAeACeACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA4LjAAAwAogAggBgAAAAAAwAAA AAAAAEYAAAAAAYUAAAAAAAALACmACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAKoAIIAYA AAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwArgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAe ACyACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgAtgAggBgAAAAAAwAAAAAAA AEYAAAAAN4UAAAEAAAABAAAAAAAAAB4ALoAIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAA AAAAAAAeAD0AAQAAAAUAAABSRTogAAAAAAMADTT9NwAAeKA= ------ =_NextPart_000_01BE201D.DA337B60--

Subject: (usr-tc) NMC Save to NVRAM
From: pferraro@wna-linknet.com
Date: 1998-12-05 09:16:07

Do we need to do a Save to NVRAM on the NMC once we flash it? There reason I ask is that now when the TCm is used and we exit it it ask us to save the profile we say yes, but it asks EVERYTIME!! Will a save to NVRAM correct this or is it a bug? We just flashed NMC on Netserver up to v5.5.5 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 ==============================================================================

Subject: Re: (usr-tc) MRTG modem useage monitoring
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-12-05 09:52:45

I'm using 1.3.6.1.4.1.429.4.2.1.10.0 for the OID... and that works fine, except that if you telnet into the ARC it counts that as a 'modem'. It's pretty close though. Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ # view;touch;unzip;finger;mount;mv;mv;mv;yes;mv;yes;mv;yes;umount;sleep On Sat, 5 Dec 1998, K Mitchell wrote: > I've been unsuccessfully trying to set MRTG up to display modem useage > stats from my HiPer ARC. Here's the relevant portion of my mrtg.cgf Can > someone point out what I'm doing wrong here? > #..................................................................... > > Target[tch1]: 1.3.6.1.4.1.429.2.19:public@204.171.31.2 > MaxBytes[tch1]: 46 > Unscaled[tch1]:ymwd > Title[tch1]: Total Control Hub #1 > PageTop[tch1]: <H1>TCH1 Modem Utilization </H1> > YLegend[tch1]:Modem Capacity > Options[tch1]:gauge,growright > ShortLegend[tch1]:Modems > Legend1[tch1]:&nbsp Utilization &nbsp > Legend2[tch1]:&nbsp Capacity &nbsp > Legend3[tch1]:&nbsp Connections &nbsp > Legend4[tch1]:&nbsp Capacity &nbsp > LegendI[tch1]:&nbsp Utilization &nbsp > LegendO[tch1]:&nbsp Capacity &nbsp

Subject: RE: (usr-tc) NMC Save to NVRAM
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-05 10:34:46

>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of >pferraro@wna-linknet.com >Sent: Saturday, December 05, 1998 8:16 AM >To: Tatai SV Krishnan >Cc: usr-tc@lists.xmission.com >Subject: (usr-tc) NMC Save to NVRAM > > > > Do we need to do a Save to NVRAM on the NMC once we flash it? >There reason I ask is that now when the TCm is used and we exit it it ask >us to save the profile we say yes, but it asks EVERYTIME!! > > Will a save to NVRAM correct this or is it a bug? It's not a bug or somthing you missed. What it is asking you to do is save the image of the chassis. If anything has changed at all, even a modem light, it will ask you to do this. It makes no difference if you save it or not, unless you changed community strings. > We just flashed NMC >on Netserver up to v5.5.5 > > 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 >=================================================================== >=========== > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Is v90 ever going to work?
From: K Mitchell <mitch@keyconn.net>
Date: 1998-12-05 11:14:04

Just upgraded HiPer ARC from 4.0.30 to 4.1.72 and HiPer DSP from 1.0.8 to 1.2.5 last night(HiPer NMC is running 5.5.5). I have a customer with a Gateway Telepath modem(new in July) than can no longer connect. He was connecting consistantly at 46.6 prior to the upgrade and has the most current drivers. The ironic side of this is that I have 2 Gateway Telepath modems here in the office that are a year old and connect fine before and after the upgrade. Is there a fix I'm missing, or should I just scrap v90 alltogether? Thanks, Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

Subject: Re: (usr-tc) MRTG modem useage monitoring
From: K Mitchell <mitch@keyconn.net>
Date: 1998-12-05 12:17:02

At 09:52 AM 12/5/98 -0500, Mike Andrews <mandrews@termfrost.org> wrote: >I'm using 1.3.6.1.4.1.429.4.2.1.10.0 for the OID... and that works fine, >except that if you telnet into the ARC it counts that as a 'modem'. It's >pretty close though. Changed my target string to read; Target[tch1]: 1.3.6.1.4.1.429.4.2.1.10.0:public@204.171.31.2 Still no go :( Do I need to be changing something else also? Thanks, Kirk >> I've been unsuccessfully trying to set MRTG up to display modem useage >> stats from my HiPer ARC. Here's the relevant portion of my mrtg.cgf Can >> someone point out what I'm doing wrong here? >> #..................................................................... >> >> Target[tch1]: 1.3.6.1.4.1.429.2.19:public@204.171.31.2 >> MaxBytes[tch1]: 46 >> Unscaled[tch1]:ymwd >> Title[tch1]: Total Control Hub #1 >> PageTop[tch1]: <H1>TCH1 Modem Utilization </H1> >> YLegend[tch1]:Modem Capacity >> Options[tch1]:gauge,growright >> ShortLegend[tch1]:Modems >> Legend1[tch1]:&nbsp Utilization &nbsp >> Legend2[tch1]:&nbsp Capacity &nbsp >> Legend3[tch1]:&nbsp Connections &nbsp >> Legend4[tch1]:&nbsp Capacity &nbsp >> LegendI[tch1]:&nbsp Utilization &nbsp >> LegendO[tch1]:&nbsp Capacity &nbsp Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

Subject: (usr-tc) Multiple address Pools
From: Russ Miescke <russm@powerweb.net>
Date: 1998-12-05 12:38:50

Can you assign multiple address pools from different class C subnets on a Hiper Arc? If so, does it fill up pool1 for example and then go to pool2? Any help would be appreciated. Russ Miescke Power Web Connect russm@powerweb.net http://www.powerweb.net

Subject: Re: (usr-tc) Multiple address Pools
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-05 13:01:05

If you have two public pools - then the first user will get an address from the first pool and the second will get it from the second pool. The pools are alternated. What you can do is use two private pools and assign users from the private pools - however you need to use vsa attribtutes to assign ip address. 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 Sat, 5 Dec 1998, Russ Miescke wrote: > Can you assign multiple address pools from different class C subnets on a > Hiper Arc? If so, does it fill up pool1 for example and then go to pool2? > Any help would be appreciated. > > > Russ Miescke > Power Web Connect > russm@powerweb.net > http://www.powerweb.net > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) MRTG modem useage monitoring
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-12-05 13:46:17

Here's exactly what I have, minus of course the community name: Target[fra3-arc]: 1.3.6.1.4.1.429.4.2.1.10.0&1.3.6.1.4.1.429.4.2.1.10.0:______@fra3-arc.dcr.net MaxBytes[fra3-arc]: 188 AbsMax[fra3-arc]: 336 Title[fra3-arc]: Number of Busy Modems on 3rd USR Total Control hub only PageTop[fra3-arc]: <h1>Number of Busy Modems on 3rd USR Total Control hub only</h1> Options[fra3-arc]: gauge YLegend[fra3-arc]: Busy Modems ShortLegend[fra3-arc]: Modems Maybe it's having problems because you don't have a pair of OID's... MRTG wants both a transmit and receive OID, generally. Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ # view;touch;unzip;finger;mount;mv;mv;mv;yes;mv;yes;mv;yes;umount;sleep On Sat, 5 Dec 1998, K Mitchell wrote: > At 09:52 AM 12/5/98 -0500, Mike Andrews <mandrews@termfrost.org> wrote: > >I'm using 1.3.6.1.4.1.429.4.2.1.10.0 for the OID... and that works fine, > >except that if you telnet into the ARC it counts that as a 'modem'. It's > >pretty close though. > > Changed my target string to read; > Target[tch1]: 1.3.6.1.4.1.429.4.2.1.10.0:public@204.171.31.2 > > Still no go :( > Do I need to be changing something else also? > > Thanks, > Kirk > > >> I've been unsuccessfully trying to set MRTG up to display modem useage > >> stats from my HiPer ARC. Here's the relevant portion of my mrtg.cgf Can > >> someone point out what I'm doing wrong here? > >> #..................................................................... > >> > >> Target[tch1]: 1.3.6.1.4.1.429.2.19:public@204.171.31.2 > >> MaxBytes[tch1]: 46 > >> Unscaled[tch1]:ymwd > >> Title[tch1]: Total Control Hub #1 > >> PageTop[tch1]: <H1>TCH1 Modem Utilization </H1> > >> YLegend[tch1]:Modem Capacity > >> Options[tch1]:gauge,growright > >> ShortLegend[tch1]:Modems > >> Legend1[tch1]:&nbsp Utilization &nbsp > >> Legend2[tch1]:&nbsp Capacity &nbsp > >> Legend3[tch1]:&nbsp Connections &nbsp > >> Legend4[tch1]:&nbsp Capacity &nbsp > >> LegendI[tch1]:&nbsp Utilization &nbsp > >> LegendO[tch1]:&nbsp Capacity &nbsp > > 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. >

Subject: Re: (usr-tc) MRTG modem useage monitoring
From: K Mitchell <mitch@keyconn.net>
Date: 1998-12-05 14:10:13

At 01:46 PM 12/5/98 -0500, Mike Andrews wrote: >Here's exactly what I have, minus of course the community name: > >Target[fra3-arc]: 1.3.6.1.4.1.429.4.2.1.10.0&1.3.6.1.4.1.429.4.2.1.10.0:______@fra3-arc.dcr.net That's got it! It doesn't appear to be counting my telnet session either :) Thanks a bunch, Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

Subject: Re: (usr-tc) Multiple address Pools
From: Russ Miescke <russm@powerweb.net>
Date: 1998-12-05 14:45:11

I have no problem with the public pool idea, I am just trying to use up some free areas of a class C subnet. The only question remaining is, what if the first pool is 62 numbers and the second is only 30? Russ Miescke Power Web Connect russm@powerweb.net http://www.powerweb.net ----- Original Message ----- Sent: Saturday, December 05, 1998 12:38 PM Can you assign multiple address pools from different class C subnets on a Hiper Arc? If so, does it fill up pool1 for example and then go to pool2? Any help would be appreciated. Russ Miescke Power Web Connect russm@powerweb.net http://www.powerweb.net - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) MRTG modem useage monitoring
From: K Mitchell <mitch@keyconn.net>
Date: 1998-12-05 15:34:00

At 02:10 PM 12/5/98 -0500, I wrote: >At 01:46 PM 12/5/98 -0500, Mike Andrews wrote: >>Here's exactly what I have, minus of course the community name: >> >>Target[fra3-arc]: >1.3.6.1.4.1.429.4.2.1.10.0&1.3.6.1.4.1.429.4.2.1.10.0:______@fra3-arc.dcr.net > >That's got it! It doesn't appear to be counting my telnet session either :) Er...almost. How do I get it to indicate a constant 46 modems available, or poll the DSPs for available modems? Thanks again, Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

Subject: Re: (usr-tc) MRTG modem useage monitoring
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-12-05 15:50:42

I'm confused... "constant 46 modems available"? Try changing MaxBytes? With that OID, you should get a graph of the number of sessions in use on all of the modems managed by that ARC, as long as you set MaxBytes to the number of modems you have. Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ # view;touch;unzip;finger;mount;mv;mv;mv;yes;mv;yes;mv;yes;umount;sleep On Sat, 5 Dec 1998, K Mitchell wrote: > At 02:10 PM 12/5/98 -0500, I wrote: > >At 01:46 PM 12/5/98 -0500, Mike Andrews wrote: > >>Here's exactly what I have, minus of course the community name: > >> > >>Target[fra3-arc]: > >1.3.6.1.4.1.429.4.2.1.10.0&1.3.6.1.4.1.429.4.2.1.10.0:______@fra3-arc.dcr.net > > > >That's got it! It doesn't appear to be counting my telnet session either :) > > Er...almost. How do I get it to indicate a constant 46 modems available, or > poll the DSPs for available modems? > > Thanks again, > Kirk

Subject: Re: (usr-tc) MRTG modem useage monitoring
From: K Mitchell <mitch@keyconn.net>
Date: 1998-12-05 16:00:51

At 03:50 PM 12/5/98 -0500, you wrote: >I'm confused... "constant 46 modems available"? Try changing MaxBytes? >With that OID, you should get a graph of the number of sessions in use on >all of the modems managed by that ARC, as long as you set MaxBytes to the >number of modems you have. Poor phrasing on my part. MaxBytes is set at 46. I want the blue line to show either total capacity(steady 46) or availability(46 minus utilization). Also, it appears that it's only showing my first DSP, not both. Could it not be seeing the 2nd DSP because the chassis sees 24 per DSP and the MaxByte setting of 46 doesn't reach the threshold to see both cards? I know it sounds weird, but I'm out of ideas :( Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

Subject: Re: (usr-tc) Is v90 ever going to work?
From: John Powell <jp@packet.ae.usr.com>
Date: 1998-12-05 17:50:10

On Sat, 5 Dec 1998, K Mitchell wrote: > Just upgraded HiPer ARC from 4.0.30 to 4.1.72 and HiPer DSP from 1.0.8 to > 1.2.5 last night(HiPer NMC is running 5.5.5). I have a customer with a > Gateway Telepath modem(new in July) than can no longer connect. He was > connecting consistantly at 46.6 prior to the upgrade and has the most > current drivers. The ironic side of this is that I have 2 Gateway Telepath > modems here in the office that are a year old and connect fine before and > after the upgrade. > Is there a fix I'm missing, or should I just scrap v90 alltogether? Scrapping it altogether would be a bit extreme. There are far more people helped than hurt with V.90 (by an order of magnitude). What you may want to try is to disable V.90 on that specific client. I believe the Telepath uses the same registers as the Sportster, so S32=66 would disable V.90 but allow x2 to work. Your customer could easily test that in a term program, or can add that string in the additional settings field in MS DUN/modem settings. I'd be interested if that helps. I'd also be interested, if convenient, to get a snapshot of the line conditions for that customer. After making a call in a term program (or +++ out to a command prompt during a call) have them type ATI4 I6 I7 I11 Y11 and capture the results. Regards, JP

Subject: Re: (usr-tc) COMPAQ MODEMS won't connect
From: John Powell <jp@packet.ae.usr.com>
Date: 1998-12-05 18:19:47

On Fri, 4 Dec 1998, Mike Andrews wrote: > It isn't. Compaq uses Rockwell HCF modems. They're far worse than the LT > Winmodems, mostly because there's no firmware update (that we know of) > that fixes the problems. At least the LT Winmodems can be made to behave > by upgrading them. I can't argue with anything you said, but I did want to note that many modems shipped with Compaq's are indeed LT Winmodems. It varies model to model and when you bought it. Unfortunately, it is real hard to tell one from the other. I know the modem in my year old Compaq Presario is an LT, complete with the "coffee stain of Quality" (grin) on the chips. JP

Subject: (usr-tc) Is anyone using Remote Office Gold ?
From: Ralph Helfenberger <rhelfenberger@comlight.ch>
Date: 1998-12-05 19:09:04

Bundled with every TotalControl (HiPer or Netserver) I find a copy of Stamped Remote Office Gold. I'd like to know if anyone is using this software and what the advantage would be to use it (compared to Dial Up Networking from Microsoft)? Ralph

Subject: Re: (usr-tc) Is v90 ever going to work?
From: Dale Pendergrass <adp@cybertours.com>
Date: 1998-12-05 23:59:03

There is a problem with the hyper dsp cards running 1.2.5 especially with disconnects. 1.2.6 which is still in beta which will be available next week that fixes this problem. The modems that are affected are Winmodems and modems with Rockwell chip sets. I hope this helps.. ----- Original Message ----- Sent: Sunday, December 06, 1998 10:52 AM >Gateway uses a cheaper modem in some models called a Telepath=AE 56K Mod= em >Design for the Internet. This is basically an LT Winmodem. I have had >problems with these since upgrading to v.90. I think Gateway is going i= n >the wrong direction here. > > >Russ Miescke >Power Web Connect >russm@powerweb.net >http://www.powerweb.net > >----- Original Message ----- >From: John Powell <jp@packet.ae.usr.com> >To: <usr-tc@lists.xmission.com> >Sent: Saturday, December 05, 1998 5:50 PM >Subject: Re: (usr-tc) Is v90 ever going to work? > > > >On Sat, 5 Dec 1998, K Mitchell wrote: > >> Just upgraded HiPer ARC from 4.0.30 to 4.1.72 and HiPer DSP from 1.0= .8 >to >> 1.2.5 last night(HiPer NMC is running 5.5.5). I have a customer with a >> Gateway Telepath modem(new in July) than can no longer connect. He was >> connecting consistantly at 46.6 prior to the upgrade and has the most >> current drivers. The ironic side of this is that I have 2 Gateway Telepath >> modems here in the office that are a year old and connect fine before = and >> after the upgrade. >> Is there a fix I'm missing, or should I just scrap v90 alltogether? > >Scrapping it altogether would be a bit extreme. There are far more peop= le >helped than hurt with V.90 (by an order of magnitude). > >What you may want to try is to disable V.90 on that specific client. I >believe the Telepath uses the same registers as the Sportster, so S32=3D= 66 >would disable V.90 but allow x2 to work. Your customer could easily tes= t >that in a term program, or can add that string in the additional setting= s >field in MS DUN/modem settings. > >I'd be interested if that helps. I'd also be interested, if convenient, >to get a snapshot of the line conditions for that customer. After makin= g >a call in a term program (or +++ out to a command prompt during a call) >have them type ATI4 I6 I7 I11 Y11 and capture the results. > >Regards, > >JP > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Is v90 ever going to work?
From: Dale Pendergrass <adp@cybertours.com>
Date: 1998-12-06 04:49:30

actually I was talking about 1.2.66 > >On Sat, 5 Dec 1998, Dale Pendergrass wrote: > >> There is a problem with the hyper dsp cards running 1.2.5 especially with >> disconnects. >> 1.2.6 which is still in beta which will be available next week that fixes >> this problem. >> The modems that are affected are >> Winmodems and modems with Rockwell chip sets. >> I hope this helps.. > >Just so expectations are set properly, 1.2.60 (I assume that is what you >are referring to, as there is no 1.2.6) is not intended to fix V.90 issues >with Rockwell. It's primary intention is to fix some issues with T3s and >some reboots in certain situations and lots of cumulative bug fixes from >previous ERs. > >There is an LT Wimodem fix in there though. Nothing for Rockwell >disconnects. We do have some fixes to patch around some Rockwell issues, >but they were intentionally not included in that code as they were causing >other issues with some of the better behaved modems. Work continues on >the Rockwell client issues. > >JP > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Is v90 ever going to work?
From: Russ Miescke <russm@powerweb.net>
Date: 1998-12-06 09:52:25

Gateway uses a cheaper modem in some models called a Telepath� 56K Modem Design for the Internet. This is basically an LT Winmodem. I have had problems with these since upgrading to v.90. I think Gateway is going in the wrong direction here. Russ Miescke Power Web Connect russm@powerweb.net http://www.powerweb.net ----- Original Message ----- Sent: Saturday, December 05, 1998 5:50 PM On Sat, 5 Dec 1998, K Mitchell wrote: > Just upgraded HiPer ARC from 4.0.30 to 4.1.72 and HiPer DSP from 1.0.8 to > 1.2.5 last night(HiPer NMC is running 5.5.5). I have a customer with a > Gateway Telepath modem(new in July) than can no longer connect. He was > connecting consistantly at 46.6 prior to the upgrade and has the most > current drivers. The ironic side of this is that I have 2 Gateway Telepath > modems here in the office that are a year old and connect fine before and > after the upgrade. > Is there a fix I'm missing, or should I just scrap v90 alltogether? Scrapping it altogether would be a bit extreme. There are far more people helped than hurt with V.90 (by an order of magnitude). What you may want to try is to disable V.90 on that specific client. I believe the Telepath uses the same registers as the Sportster, so S32=66 would disable V.90 but allow x2 to work. Your customer could easily test that in a term program, or can add that string in the additional settings field in MS DUN/modem settings. I'd be interested if that helps. I'd also be interested, if convenient, to get a snapshot of the line conditions for that customer. After making a call in a term program (or +++ out to a command prompt during a call) have them type ATI4 I6 I7 I11 Y11 and capture the results. Regards, JP - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Is v90 ever going to work?
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-12-06 12:56:21

Buh? I thought the Gateway Telepaths were basically *Sportster* Winmodems... did they change chipsets? Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ # view;touch;unzip;finger;mount;mv;mv;mv;yes;mv;yes;mv;yes;umount;sleep On Sun, 6 Dec 1998, Russ Miescke wrote: > Gateway uses a cheaper modem in some models called a Telepath=AE 56K Mode= m > Design for the Internet. This is basically an LT Winmodem. I have had > problems with these since upgrading to v.90. I think Gateway is going in > the wrong direction here. >=20 >=20 > Russ Miescke > Power Web Connect > russm@powerweb.net > http://www.powerweb.net >=20 > ----- Original Message ----- > From: John Powell <jp@packet.ae.usr.com> > To: <usr-tc@lists.xmission.com> > Sent: Saturday, December 05, 1998 5:50 PM > Subject: Re: (usr-tc) Is v90 ever going to work? >=20 >=20 >=20 > On Sat, 5 Dec 1998, K Mitchell wrote: >=20 > > Just upgraded HiPer ARC from 4.0.30 to 4.1.72 and HiPer DSP from 1.0.= 8 > to > > 1.2.5 last night(HiPer NMC is running 5.5.5). I have a customer with a > > Gateway Telepath modem(new in July) than can no longer connect. He was > > connecting consistantly at 46.6 prior to the upgrade and has the most > > current drivers. The ironic side of this is that I have 2 Gateway Telep= ath > > modems here in the office that are a year old and connect fine before a= nd > > after the upgrade. > > Is there a fix I'm missing, or should I just scrap v90 alltogether? >=20 > Scrapping it altogether would be a bit extreme. There are far more peopl= e > helped than hurt with V.90 (by an order of magnitude). >=20 > What you may want to try is to disable V.90 on that specific client. I > believe the Telepath uses the same registers as the Sportster, so S32=3D6= 6 > would disable V.90 but allow x2 to work. Your customer could easily test > that in a term program, or can add that string in the additional settings > field in MS DUN/modem settings. >=20 > I'd be interested if that helps. I'd also be interested, if convenient, > to get a snapshot of the line conditions for that customer. After making > a call in a term program (or +++ out to a command prompt during a call) > have them type ATI4 I6 I7 I11 Y11 and capture the results. >=20 > Regards, >=20 > JP >=20 >=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 > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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

Subject: Re: (usr-tc) Is v90 ever going to work?
From: John Powell <jp@packet.ae.usr.com>
Date: 1998-12-06 13:30:41

On Sun, 6 Dec 1998, Mike Andrews wrote: > Buh? I thought the Gateway Telepaths were basically *Sportster* > Winmodems... did they change chipsets? You are correct, their "cheaper ones" are Sportster Winmodems. They also offer a more expensive controller based Sportster as an option. =20 I have seen some line conditions where they drop back to V.34 when V.90 is enabled. You might have better luck if you disable V.90 (s32=3D66) and let x2 take control. Not everyone needs to do this, but if you are having problems it is worth a shot. > On Sun, 6 Dec 1998, Russ Miescke wrote: >=20 > > Gateway uses a cheaper modem in some models called a Telepath=AE 56K Mo= dem > > Design for the Internet. This is basically an LT Winmodem. I have had > > problems with these since upgrading to v.90. I think Gateway is going = in > > the wrong direction here.

Subject: Re: (usr-tc) Is v90 ever going to work?
From: John Powell <jp@packet.ae.usr.com>
Date: 1998-12-06 15:26:20

On Sat, 5 Dec 1998, Dale Pendergrass wrote: > There is a problem with the hyper dsp cards running 1.2.5 especially with > disconnects. > 1.2.6 which is still in beta which will be available next week that fixes > this problem. > The modems that are affected are > Winmodems and modems with Rockwell chip sets. > I hope this helps.. Just so expectations are set properly, 1.2.60 (I assume that is what you are referring to, as there is no 1.2.6) is not intended to fix V.90 issues with Rockwell. It's primary intention is to fix some issues with T3s and some reboots in certain situations and lots of cumulative bug fixes from previous ERs. There is an LT Wimodem fix in there though. Nothing for Rockwell disconnects. We do have some fixes to patch around some Rockwell issues, but they were intentionally not included in that code as they were causing other issues with some of the better behaved modems. Work continues on the Rockwell client issues. JP

Subject: Re: (usr-tc) Is v90 ever going to work?
From: John Powell <jp@packet.ae.usr.com>
Date: 1998-12-06 17:04:19

On Sun, 6 Dec 1998, Dale Pendergrass wrote: > actually I was talking about 1.2.66 Same answer. 1.2.60 is based on 1.2.66 with the T3 change added and one or two other things. No V.90 Rockwell fixes there either. Note, our ER numbering scheme is a bit wierd. The lower the number the more recent it is. ERs start out at x.x.99 and work their way down. 1.2.60 was built on Thursday, 1.2.66 is several weeks old. 1.2.66 was held back from wide distribution due to T1/T3 issues that are now fixed in 1.2.60. Don't get me wrong, if 1.2.60 looks good with the people trying it out, I will recommend going to it. I have high hopes it will pan out. I also believe, matched up with the latest LT code, the LT Winmodem to HiPer V.90 connections will be pretty darn solid (initial testing is showing very good results). Similarly for the later LT controlled based code, code I saw a few weeks ago is greatly improved, and will hopefully be publically available soon (this applies mostly to Hayes and Practical LT based external modems). Rockwell is another story, their recent code is a lot better, but it is still buggy as hell (primarily problems with their speedshifting and retrain functionality, which is what is causing the disconnects). Working around their problems, while maintaining stability for the better behaved modems, has proven to be a serious challenge. Combine that with many of their OEMs being very slow to release new code, and it is not pretty. We are trying to patch around some of these issues, but we are not going to break compliant modems in the process. The bottom line is 1.2.60 is intended to get a bunch of solid and safe fixes available as quickly as possible, and most of them are NOT v.90 related. It appears to be very good code, we'll have a better picture of that by next week as the results roll in from initial field testing. JP

Subject: (usr-tc) Idle time out problems with HARC 4.0.29
From: Eric <elorenzo@mediacity.com>
Date: 1998-12-06 17:05:52

We're running HARC firmware version 4.0.29 because of user connection problems with 4.1.11. Anyway... I used the command: "set user default idle_timeout 1800" so that they get logged out after 30 minutes of idleness. I'm gettin complaints that people are being disconnected shortly after 30 minutes regardless of being active or idle. Has anyone else experienced this? Thanks, Eric elorenzo@mediacity.com

Subject: Re: (usr-tc) Is v90 ever going to work?
From: Charles Sprickman <spork@inch.com>
Date: 1998-12-06 19:23:32

When should we expect a new rev of code for the quads? What are open issues that people are seeing there? Thanks, Charles On Sun, 6 Dec 1998, John Powell wrote: > Date: Sun, 6 Dec 1998 17:04:19 -0600 (CST) > From: John Powell <jp@packet.ae.usr.com> > Reply-To: usr-tc@lists.xmission.com > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Is v90 ever going to work? > > > On Sun, 6 Dec 1998, Dale Pendergrass wrote: > > > actually I was talking about 1.2.66 > > Same answer. 1.2.60 is based on 1.2.66 with the T3 change added and one > or two other things. No V.90 Rockwell fixes there either. Note, our ER > numbering scheme is a bit wierd. The lower the number the more recent it > is. ERs start out at x.x.99 and work their way down. 1.2.60 was built on > Thursday, 1.2.66 is several weeks old. 1.2.66 was held back from wide > distribution due to T1/T3 issues that are now fixed in 1.2.60. > > Don't get me wrong, if 1.2.60 looks good with the people trying it out, I > will recommend going to it. I have high hopes it will pan out. I also > believe, matched up with the latest LT code, the LT Winmodem to HiPer V.90 > connections will be pretty darn solid (initial testing is showing very > good results). Similarly for the later LT controlled based code, code > I saw a few weeks ago is greatly improved, and will hopefully be > publically available soon (this applies mostly to Hayes and Practical LT > based external modems). > > Rockwell is another story, their recent code is a lot better, but it is > still buggy as hell (primarily problems with their speedshifting and > retrain functionality, which is what is causing the disconnects). Working > around their problems, while maintaining stability for the better behaved > modems, has proven to be a serious challenge. Combine that with many of > their OEMs being very slow to release new code, and it is not pretty. We > are trying to patch around some of these issues, but we are not going to > break compliant modems in the process. > > The bottom line is 1.2.60 is intended to get a bunch of solid and safe > fixes available as quickly as possible, and most of them are NOT v.90 > related. It appears to be very good code, we'll have a better picture of > that by next week as the results roll in from initial field testing. > > JP > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 | = =----------------=

Subject: Re: (usr-tc) Is v90 ever going to work?
From: John Powell <jp@packet.ae.usr.com>
Date: 1998-12-06 23:02:15

On Sun, 6 Dec 1998, Charles Sprickman wrote: > When should we expect a new rev of code for the quads? What are open > issues that people are seeing there? There are no ERs planned, it is actually quite clean. There is a pass in beta right now along with the entire TCS 3.5, and that system is expected to release in January. 6.0.3/6.1.3 are in beta now, 6.0.4/6.1.4 will have some last little cleanup details (along with one significant Rockwell patch-around) and will likely be the released rev. JP

Subject: (usr-tc) RE: (USR-TC) IS V90 EVER
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1998-12-07 10:17:00

What about Quads ? I still have a lot of folks with these Winmodems who can't get V.90 connections. Many have been upgrading their firmware which helps somewhat. Jeff Binkley ASA Network Computing U>There is a problem with the hyper dsp cards running 1.2.5 especially U>with disconnects. U>1.2.6 which is still in beta which will be available next week that U>fixes this problem. U>The modems that are affected are U>Winmodems and modems with Rockwell chip sets. U>I hope this helps.. U>----- Original Message ----- U>From: Russ Miescke <russm@powerweb.net> U>To: <usr-tc@lists.xmission.com> U>Sent: Sunday, December 06, 1998 10:52 AM U>Subject: Re: (usr-tc) Is v90 ever going to work? U>>Gateway uses a cheaper modem in some models called a Telepath=AE 56K U>Mod= em U>>Design for the Internet. This is basically an LT Winmodem. I have U>had >problems with these since upgrading to v.90. I think Gateway is U>going i= n U>>the wrong direction here. U>> U>> U>>Russ Miescke U>>Power Web Connect U>>russm@powerweb.net U>>http://www.powerweb.net U>> U>>----- Original Message ----- U>>From: John Powell <jp@packet.ae.usr.com> U>>To: <usr-tc@lists.xmission.com> U>>Sent: Saturday, December 05, 1998 5:50 PM U>>Subject: Re: (usr-tc) Is v90 ever going to work? U>> U>> U>> U>>On Sat, 5 Dec 1998, K Mitchell wrote: U>> U>>> Just upgraded HiPer ARC from 4.0.30 to 4.1.72 and HiPer DSP from U>1.0= ..8 U>>to U>>> 1.2.5 last night(HiPer NMC is running 5.5.5). I have a customer U>>> with a Gateway Telepath modem(new in July) than can no longer U>>> connect. He was connecting consistantly at 46.6 prior to the U>>> upgrade and has the most current drivers. The ironic side of this U>is that I have 2 Gateway Telepath U>>> modems here in the office that are a year old and connect fine U>before = and U>>> after the upgrade. U>>> Is there a fix I'm missing, or should I just scrap v90 U>alltogether? > U>>Scrapping it altogether would be a bit extreme. There are far more U>peop= le U>>helped than hurt with V.90 (by an order of magnitude). U>> U>>What you may want to try is to disable V.90 on that specific client. U>I >believe the Telepath uses the same registers as the Sportster, so U>S32=3D= 66 U>>would disable V.90 but allow x2 to work. Your customer could easily U>tes= t U>>that in a term program, or can add that string in the additional U>setting= s U>>field in MS DUN/modem settings. U>> U>>I'd be interested if that helps. I'd also be interested, if U>convenient, >to get a snapshot of the line conditions for that U>customer. After makin= g U>>a call in a term program (or +++ out to a command prompt during a U>call) >have them type ATI4 I6 I7 I11 Y11 and capture the results. U>> U>>Regards, U>> U>>JP U>> U>> U>> 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. U>> U>> U>> 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. U>> 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. U> CMPQwk 1.42 9999

Subject: (usr-tc) Houston, we have a memory leak
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-12-07 11:25:31

Our first server in line wouldn't allow us to telnet into it this morning. When I got on the console, I found that it had 1K of memory free. Even a hardware reset wouldn't bring it back into action. I had to yank the card and reseat it. I have no idea what the cause could be at this point, but it is definitely a part of 4.1.72-7.

Subject: Re: (usr-tc) Houston, we have a memory leak
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-12-07 11:42:40

Tatai SV Krishnan said once upon a time: >IF its a memory leak - a hardware reset would have got you back without >any problems. You do not need to pull the card out and reset it. From >the console did you reboot it or did you use the nmc way to reset the card? Once I finally got the card back up, I had to rewrite many of its settings. Things like the ip pool configuration and the defaultroute had completely been blown off of it. There were other settings like the command prompt intact. >Do me a favor, Write a script - which would collect this info say every >20 min for about 12 hours, that would tell me what the problem is > > >_debug dump co >_debug dump free >_debug valid mEMORY Roger wilco.

Subject: Re: (usr-tc) Houston, we have a memory leak
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-12-07 12:14:01

Brian said once upon a time: > >On Mon, 7 Dec 1998, Pete Ashdown wrote: > >> Our first server in line wouldn't allow us to telnet into it this morning. >> When I got on the console, I found that it had 1K of memory free. Even a >> hardware reset wouldn't bring it back into action. I had to yank the card >> and reseat it. I have no idea what the cause could be at this point, but >> it is definitely a part of 4.1.72-7. > >great. I had this same problem with 4.1.11, where you can't telnet in >because it has no memory to spawn a telnet or shell. I was told to >upgrade to 4.1.72 to corret the problem with the leak............so you're >saying the leak is in 4.1.72 as well? What I'm saying is that I'm on 4.1.72 and something very bad happened this morning, that looked a whole lot like a memory leak.

Subject: Re: (usr-tc) Houston, we have a memory leak
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-07 12:43:14

On Mon, 7 Dec 1998, Pete Ashdown wrote: > Our first server in line wouldn't allow us to telnet into it this morning. > When I got on the console, I found that it had 1K of memory free. Even a > hardware reset wouldn't bring it back into action. I had to yank the card > and reseat it. I have no idea what the cause could be at this point, but > it is definitely a part of 4.1.72-7. > IF its a memory leak - a hardware reset would have got you back without any problems. You do not need to pull the card out and reset it. From the console did you reboot it or did you use the nmc way to reset the card? Do me a favor, Write a script - which would collect this info say every 20 min for about 12 hours, that would tell me what the problem is _debug dump co _debug dump free _debug valid mEMORY Send this info - will know what is causing the problem. regards krish > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Houston, we have a memory leak
From: Brian <signal@shreve.net>
Date: 1998-12-07 12:57:33

On Mon, 7 Dec 1998, Pete Ashdown wrote: > Our first server in line wouldn't allow us to telnet into it this morning. > When I got on the console, I found that it had 1K of memory free. Even a > hardware reset wouldn't bring it back into action. I had to yank the card > and reseat it. I have no idea what the cause could be at this point, but > it is definitely a part of 4.1.72-7. great. I had this same problem with 4.1.11, where you can't telnet in because it has no memory to spawn a telnet or shell. I was told to upgrade to 4.1.72 to corret the problem with the leak............so you're saying the leak is in 4.1.72 as well? Brian > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) | 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

Subject: (usr-tc) Merit 3.6B
From: Charles Sprickman <spork@inch.com>
Date: 1998-12-07 15:17:42

Hi, In Merit's 3.6B 'clients' file, what are folks using with USR-TC (both Hiper and Netserver) for the 'type' and 'version' fields? Do VSAs work for USR in this release? Any gotchas? Thanks, Charles =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

Subject: (usr-tc) Problems Dialing into TCH with HiperDSP - Please Help!
From: Paul Curnock <paul_curnock@pervasive.co.uk>
Date: 1998-12-07 17:50:08

Please, please, please can someone help me out with this one... I have users experiencing problems when trying to dial in to Total Control Chassis, the chassis contains: 1 x HiperDSP (1.2.5) (PRI) 1 x Edgeserver Pro (Packet bus awareness enabled) 1 x NMC (5.5.5 (I think)) 1 x PSU (I think) When a user dials into the chassis, they receive an operator intercept message from the telco (BT) saying that 'This call is incompatible with this service' and the user is refused connection. If you dial the TCH number directly you also get the message. If you reboot the chassis, then things appear to clear up for around two to three days, then the problems reappear. When the user is experiencing problems, this doesn't mean that no users can gain access as some users are clearly using the dial up without problems(once they log off, they may then experience the problem). It may take users in excess of 1.5 hours to gain access to the system, each time they get the operator intercept message. I have gone through the configuration of the HiperDSP card and all appears to be well (bearing in mind that I am no guru on the TCH). BT say that the lines are ok and functioning correctly(as they would). I have tried replacing the DSP & PRI card with another, but there is no change. I have tried changing the Modem Routing Method within Span 1 to Round Robin, Fixed Assignment and First Available with no joy (I don't think that the Telco has tried it there end?) and I am now at a loss as what to try next. Any suggestions as to what's happening? Paul Curnock This document should only be read by those persons to whom it is addressed and is not intended to be relied upon by any person without subsequent written confirmation of its contents. Accordingly, Pervasive Networks Ltd disclaim all responsibility and accept no liability (including in negligence) for the consequences for any person acting, or refraining from acting, on such information prior to the receipt by those persons of subsequent written confirmation. If you have received this E-mail message in error, please notify us immediately by telephone. Please also destroy and delete the message from your computer. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this E-mail message is strictly prohibited

Subject: (usr-tc) ARC 72-7 release
From: Jamie Orzechowski <mhz@ripnet.com>
Date: 1998-12-07 21:14:21

I am usingthe latest ARC code from totalservice.usr.com and I just noticed the following ... A user dials in via analog and enters any name and/or password and they will get a authorization failed since the users does not exist in radius ... BUT if a user dials in via ISDN and enters garbage for the name/and or password they are accepted and assigned an IP address ... any ideas?

Subject: (usr-tc) How to debug ISDN line?
From: cntlxh@163.net
Date: 1998-12-07 21:53:25

Hi: I found I canot ftp a complete file from remote machine use ISDN line. My ISDN is 2B+D, and I use TA to access Internet. My Remote Access server is Total control hub. I use commond Ptrace to debug my ftp connection. For example: In netserver, I config: add filter test set filter test 1 permit 100.100.100.1/32 100.100.100.3/32 ptrace test Now I can trace ftp packet : In machine(IP:100.100.100.1, win95), I do: ftp 100.100.100.3 ...... I found I canot download a complete file(file size >100K) Through Ptrace debug message, I found the 'segment seq' is always same, no change, I think MAX TCP segment is 64K, am I right? Sorry for my poor English. I only want to know which protocol layer have question? Any suggestion is welcome! Thanks. LXH ________________________________________________ ��ӭ��ʹ�ù��Ӵ��ѵ��http://www.163.net

Subject: (usr-tc) VSA attribute start 0/1
From: Jeff Lynch <jeff@mercury.jorsm.com>
Date: 1998-12-07 23:30:30

On the netservers we had control over whether certain VSAs started counting at 0 or 1 using the set format command: Formatting connect-info message output: This command allows you to specify whether the information sent to RADIUS is 0-based or 1-based. The USR vendor-specific RADIUS attributes affected are; Connect-Speed (0x9023), Modulation-Type (0x006C), Error-Control-Type (0x0099), and Compression-Type (0x00C7). The default is to begin the slot and channel numbering at zero. set format connect-info <0-based | 1-based> We upgraded them all to HiPerARCS but we're seeing mismatches between Modulation-Type and Connect-Speed (possibly others) which could also leave questions about the dictionary.usr from Cistron-Radius we're using. Could be a local problem coz we started hacking some new values and noticed what seemed like inconsistent starting values. What is exactly the behavior with 4.1.72 for default 0/1-ishness for accounting these VSAs. --jeff ========================================================================= Jeffrey A. Lynch JORSM Internet email: jeff@jorsm.com Northwest Indiana's Full-Service Provider Voice: (219)322-2180 927 Sheffield Avenue, Dyer, IN 46311 Autoresponse: info@jorsm.com http://www.jorsm.com

Subject: (usr-tc) Billing...arghhhhhhh
From: Scott Kreuser <scott@nabi.net>
Date: 1998-12-07 23:51:28

Ok, So I've been evaluating billing packages for the past month and still can't find one that meets my individual needs... Maybe I'm just to picky!!! Anyone have any recomendations for a billing package that... 1) Works well with USR or LIVINGSTON RADIUS 2) Set's up UNIX account automatically via script or whatever 3) Does all that other UNIX stuff, change password, etc. 4) Correctly prorates, and bills for the current month on the same invoice. 5) IS EASY TO USE.. Just curious what you fellow TC'ers are using.. Thanks. Scott Nabi Networks, Inc. Austin, Tx. http://www.nabi.net

Subject: Re: (usr-tc) Is v90 ever going to work?
From: Russ Miescke <russm@powerweb.net>
Date: 1998-12-07 23:53:23

Really, I mean LT Winmodems not Sportster Winmodems. My jaw dropped when I saw the modem listed as a Telepath� 56K Modem Design for the Internet and clicked on more info in modem properties to see the LT Winmodem information. This is a brand new Gateway computer received on Friday by my customer. I was really convinced when it connected to our v.90 Quads and heard the tell-tale grinding sounds instead of the USR "boing". I just hope this is not a permanant change for Gateway. Russ Miescke Power Web Connect russm@powerweb.net http://www.powerweb.net ----- Original Message ----- Sent: Sunday, December 06, 1998 1:30 PM On Sun, 6 Dec 1998, Mike Andrews wrote: > Buh? I thought the Gateway Telepaths were basically *Sportster* > Winmodems... did they change chipsets? You are correct, their "cheaper ones" are Sportster Winmodems. They also offer a more expensive controller based Sportster as an option. I have seen some line conditions where they drop back to V.34 when V.90 is enabled. You might have better luck if you disable V.90 (s32=66) and let x2 take control. Not everyone needs to do this, but if you are having problems it is worth a shot. > On Sun, 6 Dec 1998, Russ Miescke wrote: > > > Gateway uses a cheaper modem in some models called a Telepath� 56K Modem > > Design for the Internet. This is basically an LT Winmodem. I have had > > problems with these since upgrading to v.90. I think Gateway is going in > > the wrong direction here. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Is v90 ever going to work?
From: John Powell <jp@packet.ae.usr.com>
Date: 1998-12-08 00:24:31

I stand corrected. News to me. Thanks, JP On Mon, 7 Dec 1998, Russ Miescke wrote: > Really, I mean LT Winmodems not Sportster Winmodems. My jaw dropped when= I > saw the modem listed as a Telepath=AE 56K Modem > Design for the Internet and clicked on more info in modem properties to s= ee > the LT Winmodem information. This is a brand new Gateway computer receiv= ed > on Friday by my customer. I was really convinced when it connected to ou= r > v.90 Quads and heard the tell-tale grinding sounds instead of the USR > "boing". I just hope this is not a permanant change for Gateway. >=20 >=20 > Russ Miescke > Power Web Connect > russm@powerweb.net > http://www.powerweb.net >=20 > ----- Original Message ----- > From: John Powell <jp@packet.ae.usr.com> > To: <usr-tc@lists.xmission.com> > Sent: Sunday, December 06, 1998 1:30 PM > Subject: Re: (usr-tc) Is v90 ever going to work? >=20 >=20 >=20 > On Sun, 6 Dec 1998, Mike Andrews wrote: >=20 > > Buh? I thought the Gateway Telepaths were basically *Sportster* > > Winmodems... did they change chipsets? >=20 > You are correct, their "cheaper ones" are Sportster Winmodems. They also > offer a more expensive controller based Sportster as an option. >=20 > I have seen some line conditions where they drop back to V.34 when V.90 i= s > enabled. You might have better luck if you disable V.90 (s32=3D66) and l= et > x2 take control. Not everyone needs to do this, but if you are having > problems it is worth a shot. >=20 > > On Sun, 6 Dec 1998, Russ Miescke wrote: > > > > > Gateway uses a cheaper modem in some models called a Telepath=AE 56K = Modem > > > Design for the Internet. This is basically an LT Winmodem. I have h= ad > > > problems with these since upgrading to v.90. I think Gateway is goin= g > in > > > the wrong direction here. >=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 > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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

Subject: Re: (usr-tc) Billing...arghhhhhhh
From: Tim Tsai <tim@futuresouth.com>
Date: 1998-12-08 07:52:47

Check out Platypus at http://www.boardtown.com Tim On Mon, Dec 07, 1998 at 11:51:28PM -0600, Scott Kreuser wrote: > Ok, So I've been evaluating billing packages for the past month and still > can't find one that meets my individual needs... Maybe I'm just to picky!!! > > Anyone have any recomendations for a billing package that... > > 1) Works well with USR or LIVINGSTON RADIUS > 2) Set's up UNIX account automatically via script or whatever > 3) Does all that other UNIX stuff, change password, etc. > 4) Correctly prorates, and bills for the current month on the same invoice. > 5) IS EASY TO USE.. > > Just curious what you fellow TC'ers are using.. > > Thanks. Scott > Nabi Networks, Inc. > Austin, Tx. > http://www.nabi.net > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) VSA attribute start 0/1
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-08 08:26:34

On Mon, 7 Dec 1998, Jeff Lynch wrote: > On the netservers we had control over whether certain VSAs started > counting at 0 or 1 using the set format command: > > Formatting connect-info message output: This command allows you to > specify whether the information sent to RADIUS is 0-based or 1-based. > The USR vendor-specific RADIUS attributes affected are; Connect-Speed > (0x9023), Modulation-Type (0x006C), Error-Control-Type (0x0099), and > Compression-Type (0x00C7). The default is to begin the slot and channel > numbering at zero. > > set format connect-info <0-based | 1-based> > > We upgraded them all to HiPerARCS but we're seeing mismatches between > Modulation-Type and Connect-Speed (possibly others) which could also leave > questions about the dictionary.usr from Cistron-Radius we're using. Could > be a local problem coz we started hacking some new values and noticed what > seemed like inconsistent starting values. What is exactly the behavior > with 4.1.72 for default 0/1-ishness for accounting these VSAs. The hiper arc is 1 based. The NETServer was 0 based and in the newer code they added a option to make it 0 or 1 based. krish > > --jeff > > ========================================================================= > Jeffrey A. Lynch JORSM Internet > email: jeff@jorsm.com Northwest Indiana's Full-Service Provider > Voice: (219)322-2180 927 Sheffield Avenue, Dyer, IN 46311 > Autoresponse: info@jorsm.com http://www.jorsm.com > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) Is v90 ever going to work?
From: Richard Gamberg <bbhi@prodigy.net>
Date: 1998-12-08 09:06:46

"Grinding" sounds? The LT modem on v.90 makes what I'd call "blips" during the DIL. Rockwell modems make what I call a "staticy" sound. 3Com does the "boing". So, I wonder if this Gateway modem is really Lucent-based? Or is it a Rockwell soft modem? Or Cirrus (what do they sound like? Anyone have a .w= av or .ra file of a Cirrus handshake?) BTW - RealAudio of 3Com/Lucent/&Rockwell v90 w/ DIL handshakes in on my website at http://808hi.com/56k/r-rnut-x2-3.htm#audio Aloha, Richard -> -----Original Message----- -> From: owner-usr-tc@lists.xmission.com -> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of John Powell -> Sent: Monday, December 07, 1998 8:25 PM -> To: usr-tc@lists.xmission.com -> Subject: Re: (usr-tc) Is v90 ever going to work? -> -> -> I stand corrected. News to me. -> -> Thanks, -> -> JP -> -> On Mon, 7 Dec 1998, Russ Miescke wrote: -> -> > Really, I mean LT Winmodems not Sportster Winmodems. My jaw -> dropped when I -> > saw the modem listed as a Telepath=AE 56K Modem -> > Design for the Internet and clicked on more info in modem -> properties to see -> > the LT Winmodem information. This is a brand new Gateway -> computer received -> > on Friday by my customer. I was really convinced when it -> connected to our -> > v.90 Quads and heard the tell-tale grinding sounds instead of the US= R -> > "boing". I just hope this is not a permanant change for Gateway. -> > -> > -> > Russ Miescke -> > Power Web Connect -> > russm@powerweb.net -> > http://www.powerweb.net -> > -> > ----- Original Message ----- -> > From: John Powell <jp@packet.ae.usr.com> -> > To: <usr-tc@lists.xmission.com> -> > Sent: Sunday, December 06, 1998 1:30 PM -> > Subject: Re: (usr-tc) Is v90 ever going to work? -> > -> > -> > -> > On Sun, 6 Dec 1998, Mike Andrews wrote: -> > -> > > Buh? I thought the Gateway Telepaths were basically *Sportster* -> > > Winmodems... did they change chipsets? -> > -> > You are correct, their "cheaper ones" are Sportster Winmodems. -> They also -> > offer a more expensive controller based Sportster as an option. -> > -> > I have seen some line conditions where they drop back to V.34 -> when V.90 is -> > enabled. You might have better luck if you disable V.90 -> (s32=3D66) and let -> > x2 take control. Not everyone needs to do this, but if you are havi= ng -> > problems it is worth a shot. -> > -> > > On Sun, 6 Dec 1998, Russ Miescke wrote: -> > > -> > > > Gateway uses a cheaper modem in some models called a -> Telepath=AE 56K Modem -> > > > Design for the Internet. This is basically an LT -> Winmodem. I have had -> > > > problems with these since upgrading to v.90. I think -> Gateway is going -> > in -> > > > the wrong direction here. -> > -> > -> > - -> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" -> > with "unsubscribe usr-tc" in the body of the message. -> > For information on digests or retrieving files and old messages sen= d -> > "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 sen= d -> > "help" to the same address. Do not use quotes in your message. -> > -> -> -> - -> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" -> with "unsubscribe usr-tc" in the body of the message. -> For information on digests or retrieving files and old messages send -> "help" to the same address. Do not use quotes in your message. ->

Subject: Re: (usr-tc) Billing...arghhhhhhh
From: Kingsley S. Grant <ksg@recorder.ca>
Date: 1998-12-08 09:17:21

Scott, Check out ISPOne at http://www.internetsupportsystems.com/ it does all of that stuff but it runs on NT so you can get much better reports and it uses Sybase database for speed and strength. King. Scott Kreuser wrote: > Ok, So I've been evaluating billing packages for the past month and still > can't find one that meets my individual needs... Maybe I'm just to picky!!! > > Anyone have any recomendations for a billing package that... > > 1) Works well with USR or LIVINGSTON RADIUS > 2) Set's up UNIX account automatically via script or whatever > 3) Does all that other UNIX stuff, change password, etc. > 4) Correctly prorates, and bills for the current month on the same invoice. > 5) IS EASY TO USE.. > > Just curious what you fellow TC'ers are using.. > > Thanks. Scott > Nabi Networks, Inc. > Austin, Tx. > http://www.nabi.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. -- Kingsley S. Grant RipNET Manager RipNET Internet Services 31 Broad Street Brockville ON, Canada K6V 4T9 (613) 342-3946 work (613) 342-8672 fax (613) 340-1144 Cel (613) 923-2596 Res (613) 341-0882 Pager 1-888-509-6677 E-Mail mailto:ksg@recorder.ca

Subject: Re: (usr-tc) Billing...arghhhhhhh
From: Ronald E. Kushner <ron@glis.net>
Date: 1998-12-08 09:18:54

You know, I looked at Platypus at one time, and the really stupid thing about it is that the software is dead when the company goes out of business. It polls one of the Boardtown servers on the net, and if it can not talk to the server for 60 days, it locks up tight as a drum. You go out of business along with 'em. They tried to tell me if they ever went bankrupt, they would issue new software, but since contracts will be impossiable to enforce after a chapter 7, I wouldn't trust what they tell me. But Platypus does it all. Tim Tsai wrote: > > Check out Platypus at http://www.boardtown.com > > Tim > > On Mon, Dec 07, 1998 at 11:51:28PM -0600, Scott Kreuser wrote: > > Ok, So I've been evaluating billing packages for the past month and still > > can't find one that meets my individual needs... Maybe I'm just to picky!!! > > > > Anyone have any recomendations for a billing package that... > > > > 1) Works well with USR or LIVINGSTON RADIUS > > 2) Set's up UNIX account automatically via script or whatever > > 3) Does all that other UNIX stuff, change password, etc. > > 4) Correctly prorates, and bills for the current month on the same invoice. > > 5) IS EASY TO USE..

Subject: Re: (usr-tc) Is v90 ever going to work?
From: Brian Gordon <administrator@westelcom.com>
Date: 1998-12-08 10:20:10

When is the new modem code coming out, has anyone a clue? Brian Gordon Westelcom Internet home.westelcom.com administrator@westelcom.com ----- Original Message ----- Sent: Tuesday, December 08, 1998 12:53 AM >Really, I mean LT Winmodems not Sportster Winmodems. My jaw dropped when I >saw the modem listed as a Telepath� 56K Modem >Design for the Internet and clicked on more info in modem properties to see >the LT Winmodem information. This is a brand new Gateway computer received >on Friday by my customer. I was really convinced when it connected to our >v.90 Quads and heard the tell-tale grinding sounds instead of the USR >"boing". I just hope this is not a permanant change for Gateway. > > >Russ Miescke >Power Web Connect >russm@powerweb.net >http://www.powerweb.net > >----- Original Message ----- >From: John Powell <jp@packet.ae.usr.com> >To: <usr-tc@lists.xmission.com> >Sent: Sunday, December 06, 1998 1:30 PM >Subject: Re: (usr-tc) Is v90 ever going to work? > > > >On Sun, 6 Dec 1998, Mike Andrews wrote: > >> Buh? I thought the Gateway Telepaths were basically *Sportster* >> Winmodems... did they change chipsets? > >You are correct, their "cheaper ones" are Sportster Winmodems. They also >offer a more expensive controller based Sportster as an option. > >I have seen some line conditions where they drop back to V.34 when V.90 is >enabled. You might have better luck if you disable V.90 (s32=66) and let >x2 take control. Not everyone needs to do this, but if you are having >problems it is worth a shot. > >> On Sun, 6 Dec 1998, Russ Miescke wrote: >> >> > Gateway uses a cheaper modem in some models called a Telepath� 56K Modem >> > Design for the Internet. This is basically an LT Winmodem. I have had >> > problems with these since upgrading to v.90. I think Gateway is going >in >> > the wrong direction here. > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Billing...arghhhhhhh
From: Tim Tsai <tim@futuresouth.com>
Date: 1998-12-08 11:10:59

As far as I know Boardtown will give any customer a permanant key but then you won't be able to change the company info. The other option is a hardware key, then the customer can change anything they like. (No-one likes hardware keys though.) Being both a developer and a consumer of software, I can see both points of view. Tim On Tue, Dec 08, 1998 at 09:18:54AM -0500, Ronald E. Kushner wrote: > You know, I looked at Platypus at one time, and the really stupid thing > about it is that the software is dead when the company goes out of > business. It polls one of the Boardtown servers on the net, and if it > can not talk to the server for 60 days, it locks up tight as a drum. You > go out of business along with 'em. They tried to tell me if they ever > went bankrupt, they would issue new software, but since contracts will > be impossiable to enforce after a chapter 7, I wouldn't trust what they > tell me. > > But Platypus does it all. > > Tim Tsai wrote: > > > > Check out Platypus at http://www.boardtown.com > > > > Tim > > > > On Mon, Dec 07, 1998 at 11:51:28PM -0600, Scott Kreuser wrote: > > > Ok, So I've been evaluating billing packages for the past month and still > > > can't find one that meets my individual needs... Maybe I'm just to picky!!! > > > > > > Anyone have any recomendations for a billing package that... > > > > > > 1) Works well with USR or LIVINGSTON RADIUS > > > 2) Set's up UNIX account automatically via script or whatever > > > 3) Does all that other UNIX stuff, change password, etc. > > > 4) Correctly prorates, and bills for the current month on the same invoice. > > > 5) IS EASY TO USE.. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) Radius
From: Jamie Orzechowski <mhz@ripnet.com>
Date: 1998-12-08 11:15:06

I am using Livingston Radius for accounting v1.6 when a user logs in via a NETServer a radius entry of NAS-PORT = 5 is recorded if the users logs into S5 or NAS-PORT = 6 if they log into S6 now with the HiPER ARC when a user logs in I will get a NAS-PORT = from 1 to 4000+ ... our accounting software is setup so that ports 1-250 in the detail file for this ARC chassis are billable ... but when it reads a NAS-PORT of 3000 it will just discard the record ... any ideas on how to make it report proper ports?

Subject: RE: (usr-tc) Billing...arghhhhhhh
From: dns-admin@netsol.net
Date: 1998-12-08 11:50:42

We bought the platypus eval about a month ago. After much struggle -- hard to find tech support through phone or email. One month later, it turns out they do NOT support TC's S&A server at all. And they refused to refund. Maybe some of you guys had better luck. just my $.02 Liping Chen -- Netsol Internet Service 753 S. Lemon Ave. Walnut, CA91789 liping@netsol.net (909) 869-6455 (909)869-6459 fax > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tim Tsai > Sent: Tuesday, December 08, 1998 9:11 AM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Billing...arghhhhhhh > > > As far as I know Boardtown will give any customer a permanant key but > then you won't be able to change the company info. The other > option is > a hardware key, then the customer can change anything they > like. (No-one > likes hardware keys though.) > > Being both a developer and a consumer of software, I can see > both points > of view. > > Tim > > On Tue, Dec 08, 1998 at 09:18:54AM -0500, Ronald E. Kushner wrote: > > You know, I looked at Platypus at one time, and the really > stupid thing > > about it is that the software is dead when the company goes out of > > business. It polls one of the Boardtown servers on the net, > and if it > > can not talk to the server for 60 days, it locks up tight > as a drum. You > > go out of business along with 'em. They tried to tell me > if they ever > > went bankrupt, they would issue new software, but since > contracts will > > be impossiable to enforce after a chapter 7, I wouldn't > trust what they > > tell me. > > > > But Platypus does it all. > > > > Tim Tsai wrote: > > > > > > Check out Platypus at http://www.boardtown.com > > > > > > Tim > > > > > > On Mon, Dec 07, 1998 at 11:51:28PM -0600, Scott Kreuser wrote: > > > > Ok, So I've been evaluating billing packages for the > past month and still > > > > can't find one that meets my individual needs... Maybe > I'm just to picky!!! > > > > > > > > Anyone have any recomendations for a billing package that... > > > > > > > > 1) Works well with USR or LIVINGSTON RADIUS > > > > 2) Set's up UNIX account automatically via script or whatever > > > > 3) Does all that other UNIX stuff, change password, etc. > > > > 4) Correctly prorates, and bills for the current month > on the same invoice. > > > > 5) IS EASY TO USE.. > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old > messages send > > "help" to the same address. Do not use quotes in your message. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Billing...arghhhhhhh
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-12-08 12:27:34

Scott Kreuser said once upon a time: >Just curious what you fellow TC'ers are using.. We wrote our own billing package. Unfortunately, I still feel that this is the best option for an ISP.

Subject: (usr-tc) 4.1.72-7 memory leak status
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-12-08 12:57:03

I haven't seen the memory leak reappear on any of my equipment. I'm continuing to keep logs of its status every 20 minutes. The other possibility is that my TC's were outside my firewall filters for the weekend (when the memory problem occured). Maybe there is some DoS attack that the TC's aren't hep to.

Subject: Re: (usr-tc) Billing...arghhhhhhh
From: Frank Basso <frank@got.net>
Date: 1998-12-08 13:06:46

http://www.rodopi.com is what we use. -----Original Message----- >Ok, So I've been evaluating billing packages for the past month and still >can't find one that meets my individual needs... Maybe I'm just to picky!!! > >Anyone have any recomendations for a billing package that... > >1) Works well with USR or LIVINGSTON RADIUS >2) Set's up UNIX account automatically via script or whatever >3) Does all that other UNIX stuff, change password, etc. >4) Correctly prorates, and bills for the current month on the same invoice. >5) IS EASY TO USE.. > >Just curious what you fellow TC'ers are using.. > >Thanks. Scott >Nabi Networks, Inc. >Austin, Tx. >http://www.nabi.net > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Billing...arghhhhhhh
From: Thomas Kinnen <tkinnen@livingston.com>
Date: 1998-12-08 13:21:24

Scott Kreuser wrote: > > Ok, So I've been evaluating billing packages for the past month and still > can't find one that meets my individual needs... Maybe I'm just to picky!!! There's Radius ABM: http://www.livingston.com/rabm/ Demo copy is downloadable. Use oracle as a back end. ---- Thomas C Kinnen - <tkinnen@livingston.com> <tkinnen@sobhrach.com> [Test Engineer - Radius ABM] - LUCENT Technologies RABU "All of the opinions stated above are my own and not my employer's, unless they were given to me by my employer"

Subject: RE: (usr-tc) Radius
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-12-08 13:38:44

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jamie Orzechowski |Sent: Tuesday, December 08, 1998 10:15 AM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) Radius | | |I am using Livingston Radius for accounting v1.6 | |when a user logs in via a NETServer a radius entry of NAS-PORT = 5 is |recorded if the users logs into S5 or NAS-PORT = 6 if they log into S6 | |now with the HiPER ARC when a user logs in I will get a NAS-PORT = from 1 to |4000+ ... our accounting software is setup so that ports 1-250 in the detail |file for this ARC chassis are billable ... but when it reads a NAS-PORT of |3000 it will just discard the record ... any ideas on how to make it report |proper ports? It is the "proper" port. The HARC does not have a port system like netserver (ie "S1-SX"). The number you get tells you the Slot and channel the call came in on. -M

Subject: RE: (usr-tc) ARC 72-7 release
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-12-08 13:47:19

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jamie Orzechowski |Sent: Monday, December 07, 1998 8:14 PM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) ARC 72-7 release | | |I am usingthe latest ARC code from totalservice.usr.com and I just noticed |the following ... | |A user dials in via analog and enters any name and/or password and they will |get a authorization failed since the users does not exist in radius ... BUT |if a user dials in via ISDN and enters garbage for the name/and or password |they are accepted and assigned an IP address ... any ideas? | Do you have authentication turned off for digital calls? This is a "switched interface" setting. You can see it with "show interface slot:x/mod:y".. It should have Disable Authentication for call type: NONE -M

Subject: Re: (usr-tc) AMI/D4 Flexpath Cicruit with a TCH
From: Curt Shambeau <curt@execpc.com>
Date: 1998-12-08 14:30:01

> Currently, A call will come into the chassis, the modem will seize > the call, but a handshake is never able to be negotiated. I have tried > various manufacturer's modems. When listening to the handshake with a > handset the tone stays at the initial high frequency tone and never appears > to renegotiate the line speed. If I dial in with HyperTerminal it will I've seen that high pitched whine several times in my dealings with total control equipment. Often, it is related to the initial call setup, which could very well be telco. First thing I would try would be to set the number of DNIS digits different. This is most often when I see this problem. The telco may in fact be sending you 7 digits when you want 0. Why not set all the modems to 4 digits, and have the telco delete 3, send 4. The other time I see this noise is when the modems are set incorrectly on the types of tones... MF or DTMF. Quadruple check with the telco that they are sending you what you have it set for. And even after that, set your modems opposite what they say, and see if it works.... <grin> | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Executive Vice President - Exec-PC, Inc. |

Subject: (usr-tc) AMI/D4 Flexpath Cicruit with a TCH
From: John Rockwell <jrockwel@clarityconnect.com>
Date: 1998-12-08 15:21:55

I am currently trying to get a Total Control chassis to work with a CT1 coming from a Nortel DMS-10 switch provisioned for AMI line coding, D4 framing, wink start, E&M Type II trunk type, and deleting 7 dnis digits. The total control chassis consists of a Netserver card (v3.7.24 code), 12 quad modem cards (v.5.10.9 code), a PRI NAC (v4.2.1 code), power suppplies, etc. I have the PRI NAC configured for: Framing Mode: ds1D4 Line Coding Options: ami Response to Remote Loopback: ignore Jitter Attenuation: attenJitterOnTxmtr Transmitter Attenuation: dB0 Automatic Busy Out: disabled Dial-in Address: dnis Dial-in/Dial-out Trunk Signal Start: wink Acknowledgement Wink: disabled Delay Sending Address Info.: 70 Stuffed Byte Sent to TELCO: 254 Dial-in/Dial-Out Trunk Type: eAndMTypeII Idle Byte Patern: 254 The modems are configured for a T1 tone type of 'dtmf' which is the only change to the modems that has been made (the rest are set to their defaults). Until this change was made the modems would not answer a call. Currently, A call will come into the chassis, the modem will seize the call, but a handshake is never able to be negotiated. I have tried various manufacturer's modems. When listening to the handshake with a handset the tone stays at the initial high frequency tone and never appears to renegotiate the line speed. If I dial in with HyperTerminal it will show a "Connect", no connect rate and shortly thereafter I get a burst of garbage and the modem disconnects. I'm interpreting the lack of a connection rate to mean that the modem is connecting at 300 BPS or below. To me this sounded a lot like a problem with the chassis, but I have another provider's CT1 plugged into the same chassis (provisioned as B8ZS, ESF, immediate start, NoAddress, and E&M Type II coming from an AT&T 5ess switch) and the CT1 works regardless of which span it is plugged into in the chassis. I have also tried numerous modem/DS0 mapping and span swapping combinations, to no avail. The telco. is telling me that they're seeing bit errors (1 and 0 density errors) at their DMS-10 switch. Unfortunately, This is the only "Flexpath" circuit in my network, so I don't have anything to compare to. Our provider claims that they have other "Flexpath" circuits up and running, but they are being plugged into a PBX. I'm suspecting strangeness with the D4 channel bank, but unfortunately it's integrated into the switch which makes troubleshooting a bit more difficult. Currently they're doing a stare and compare between our circuit and the other Flexpath out of that switch, but I'm not holding out a great deal of hope. I have spoken with a plethora of 3com techs. and they have all pointed me back toward the telco. I'm not interested in assessing blame. I'd simply like to make the combination work. Any suggestions, ideas, comments, words of wisdom? John Rockwell e-mail: jrockwel@clarityconnect.com Network Engineer Clarityconnect, Inc. Ithaca Area: (607)257-8268 Outside Ithaca Area: (888)322-4900 Try us: http://www.clarityconnect.com

Subject: Re: (usr-tc) Billing...arghhhhhhh
From: Jamie Dolan <jamie@powernetonline.com>
Date: 1998-12-08 15:24:35

We also use rodopi and we are very happy with it. >http://www.rodopi.com is what we use.

Subject: Re: (usr-tc) AMI/D4 Flexpath Cicruit with a TCH
From: John Rockwell <jrockwel@clarityconnect.com>
Date: 1998-12-08 16:06:35

>> Currently, A call will come into the chassis, the modem will seize >> the call, but a handshake is never able to be negotiated. I have tried >> various manufacturer's modems. When listening to the handshake with a >> handset the tone stays at the initial high frequency tone and never appears >> to renegotiate the line speed. If I dial in with HyperTerminal it will > >I've seen that high pitched whine several times in my dealings with total >control equipment. Often, it is related to the initial call setup, which >could very well be telco. Actually, The tone that I'm hearing sounds similar, if not the same as the initial connect tone for a 56k modem. The tone didn't sound to me to be out of the ordinary. The part that I did find odd is that it never renegotiated to the lower pitched tone indicative of a lower connect rate. >First thing I would try would be to set the number of DNIS digits >different. This is most often when I see this problem. The telco may in >fact be sending you 7 digits when you want 0. Why not set all the modems >to 4 digits, and have the telco delete 3, send 4. We did try a number of dnis combinations, but I'll try a few others. >The other time I see this noise is when the modems are set incorrectly on >the types of tones... MF or DTMF. Quadruple check with the telco that >they are sending you what you have it set for. And even after that, set >your modems opposite what they say, and see if it works.... <grin> Strangely, If I set the T1 tone type on the modems to MfTones, they will not answer calls. At this point, I'm trying to get the telco. to rebuild the circuit from an external D4 channel bank so I can split the DS0s appart and test each one. I'd also like to have them do a stare and compare on the actual translations for this circuit and the other FlexPath out of the same switch. They claim to have done this once before, but one never knows. Thanks for the suggestions. >-------------------------------------------------------------------------- >| 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. John Rockwell e-mail: jrockwel@clarityconnect.com Network Engineer Clarityconnect, Inc. Ithaca Area: (607)257-8268 Outside Ithaca Area: (888)322-4900 Try us: http://www.clarityconnect.com

Subject: (usr-tc) support woes
From: Brian <signal@shreve.net>
Date: 1998-12-08 16:29:27

Just want to relay some support flames........ Like many of you, our support contracts are being held hostage. We purchased contracts this year from source technologies, but they will not be honored by 3Com and are in dispute, since 3Com feels we owe more money for support. Until I get a support contract, I cannot use totalservice. When I was under contract, I downloaded 4.1.11. It has recently come to our attention that 4.1.11 has a nasty memory leak, hence the release of 4.1.72 on total service. So basically what I paid for is broke.......and not just broke in a little way, broke in a way in which it would be crazy for an ISP to use that code in production enviroment knowing the issues, at least in our enviroment. I sent in some warranty registration cards, you know the ones with 90 days support........and I got no response. Has anyone ever gotten anything proactivly back from 3com after sending in those 90day support post cards? I have more but dare not send them in if they aren't going to be honored/responded to. Personally I don't feel I should have to renew my support contract to get the fix for code that I paid for. 3Com needs to credit to your totalservice login what you have paid for, and allow ER releases for that version to be downloaded, instead of treating them like newer code bases which they are not. So I am peeved. I run leaky code, can't get the new code without the support contracts, even though we have paid several thousand for support contracts already this year. I hate the back alley way of people mailing me 4.1.72 just so that I can run 3Com Total Control stable, but that's how it goes......it's sad. So if someone has a copy, you know the email.......and I don't feel guilty because I am working with 3Com to resolve this contract issues, really trying. I have emailed them and am awaiting response, but like I said, I need a fix yesterday. We are the largest ISP in our locality which is made up of 350,000+ people. We were the first to offer x2, and because of that, an unbelievable number of people in this area use 3com modems, hardly any use kflex technology, and alot of that is due to our decision to use 3com equipment. Now the 3com call records will show, that I didn't call support at all last year, not that I can remember, the only time I usually need support is with software bugs/issues, which isn't something you have customers pay for (i.e. if your software is buggy, and becaues of that users call support, that's YOUR problem, not theirs). As far as genuine "how do i do this" support, I don't call them. Anyone elses contracts being held hostage? 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

Subject: Re: (usr-tc) Total Control Sell
From: Frank Basso <frank@got.net>
Date: 1998-12-08 17:21:51

How much ? -----Original Message----- >We are most likely selling our USR product due to software and performance >issues with the USRobotics Software on the modems. > >This is the Equipement that we are getting rid of. > >1 Total Control Chassis 48 ports >1 Total Control Chassis 48 ports >1 Total Control Chassis 48 ports >1 Total Control Chassis 48 ports >1 Total Control Chassis 48 ports >1 Total Control Chassis 48 ports >1 Total Control Chassis 48 ports >1 Total Control Chassis 48 ports >1 Total Control Chassis 48 ports >1 Total Control Chassis 48 ports >1 Total Control Chassis 48 ports >1 Total Control Chassis 48 ports >1 Total Control Chassis 48 ports >1 Total Control Chassis 48 ports >1 Total Control Chassis 48 ports >1 Total Control Chassis 48 ports > 1 Total Control Chassis 48 ports >1 Total Control Chassis 96 ports - 2 Hyper DSP Cards >1 Total Control Chassis 96 ports - 2 Hyper DSP Cards >1 Total Control Chassis 96 ports - 2 Hyper DSP Cards >1 Total Control Chassis 96 ports - 2 Hyper DSP Cards >1 Total Control Chassis 96 ports - 2 Hyper DSP Cards >1 Total Control Chassis 96 ports - 2 Hyper DSP Cards >1 Total Control Chassis 96 ports - 2 Hyper DSP Cards >1 Total Control Chassis 96 ports - 2 Hyper DSP Cards >1 Total Control Chassis 96 ports - 2 Hyper DSP Cards > 1 Total Control Chassis 96 ports - 2 Hyper DSP Cards >1 Total Control Chassis 96 ports - 2 Hyper DSP Cards >1 Total Control Chassis 96 ports - 2 Hyper DSP Cards > 1 Total Control Chassis 96 ports - 2 Hyper DSP Cards > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Total Control Sell
From: dale <adp@cybertours.com>
Date: 1998-12-08 18:10:36

We are most likely selling our USR product due to software and performance issues with the USRobotics Software on the modems. This is the Equipement that we are getting rid of. 1 Total Control Chassis 48 ports 1 Total Control Chassis 48 ports 1 Total Control Chassis 48 ports 1 Total Control Chassis 48 ports 1 Total Control Chassis 48 ports 1 Total Control Chassis 48 ports 1 Total Control Chassis 48 ports 1 Total Control Chassis 48 ports 1 Total Control Chassis 48 ports 1 Total Control Chassis 48 ports 1 Total Control Chassis 48 ports 1 Total Control Chassis 48 ports 1 Total Control Chassis 48 ports 1 Total Control Chassis 48 ports 1 Total Control Chassis 48 ports 1 Total Control Chassis 48 ports 1 Total Control Chassis 48 ports 1 Total Control Chassis 96 ports - 2 Hyper DSP Cards 1 Total Control Chassis 96 ports - 2 Hyper DSP Cards 1 Total Control Chassis 96 ports - 2 Hyper DSP Cards 1 Total Control Chassis 96 ports - 2 Hyper DSP Cards 1 Total Control Chassis 96 ports - 2 Hyper DSP Cards 1 Total Control Chassis 96 ports - 2 Hyper DSP Cards 1 Total Control Chassis 96 ports - 2 Hyper DSP Cards 1 Total Control Chassis 96 ports - 2 Hyper DSP Cards 1 Total Control Chassis 96 ports - 2 Hyper DSP Cards 1 Total Control Chassis 96 ports - 2 Hyper DSP Cards 1 Total Control Chassis 96 ports - 2 Hyper DSP Cards 1 Total Control Chassis 96 ports - 2 Hyper DSP Cards 1 Total Control Chassis 96 ports - 2 Hyper DSP Cards

Subject: Re: (usr-tc) support woes
From: Spork SPORK <spork@inch.com>
Date: 1998-12-08 18:25:48

On Tue, 8 Dec 1998, Brian wrote: > Like many of you, our support contracts are being held hostage. We > purchased contracts this year from source technologies, but they will not > be honored by 3Com and are in dispute, since 3Com feels we owe more money > for support. Brian, I'm not familiar with the "hostage situation"... We are looking to do business with Source, including buying support/software contracts. What's the story with this? Thanks, Charles

Subject: Re: (usr-tc) support woes
From: Spork SPORK <spork@inch.com>
Date: 1998-12-08 18:25:48

Subject: Re: (usr-tc) Is v90 ever going to work?
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1998-12-08 20:57:00

-> When is the new modem code coming out, has anyone a clue? I dunno. I just had a Diamond Supra V.90 which wouldn't connect to Quads without disabling V.90 <sigh>... Most of mine are the same scenario: connect at V.90 speed, see PPP start and then modem never send userid and password, then disconnects. Disable V.90 and everything works fine. Of course this isn't all modems, just primarily LT and Rockwell based ones. Jeff Binkley ASA Network Computing

Subject: Re: (usr-tc) Is v90 ever going to work?
From: Jamie Orzechowski <mhz@ripnet.com>
Date: 1998-12-08 21:26:37

try http://beta.supra.com I coulfn't get a diamond to connect but I flashed their beta code and v.90 worked like without problem. before the flash it would dial and attempt v.90 and then disconnect ... would not even send name and password ... ----- Original Message ----- Sent: Tuesday, December 08, 1998 8:57 PM > >-> When is the new modem code coming out, has anyone a clue? > >I dunno. I just had a Diamond Supra V.90 which wouldn't connect >to Quads without disabling V.90 <sigh>... Most of mine are the >same scenario: connect at V.90 speed, see PPP start and then >modem never send userid and password, then disconnects. Disable >V.90 and everything works fine. Of course this isn't all modems, >just primarily LT and Rockwell based ones. > > >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. >

Subject: RE: (usr-tc) Total Control Sell
From: John Verreault <verreaul@aei.ca>
Date: 1998-12-08 22:50:40

DO you have the bundle part numbers & how much are you asking? John On Tuesday, December 08, 1998 8:22 PM, Frank Basso [SMTP:frank@got.net] wrote: > << File: ATT00000.txt; charset = Windows-1252 >>

Subject: RE: (usr-tc) Total Control Sell
From: John Verreault <verreaul@aei.ca>
Date: 1998-12-08 22:51:19

Do you have the bundle part numbers and how much are you asking John On Tuesday, December 08, 1998 6:11 PM, dale [SMTP:adp@cybertours.com] wrote: > << File: ATT00138.txt; charset = Windows-1252 >>

Subject: Re: (usr-tc) Total Control Sell
From: Ronald E. Kushner <ron@glis.net>
Date: 1998-12-08 23:03:21

How much are you asking for these chassis? dale wrote: > > We are most likely selling our USR product due to software and performance > issues with the USRobotics Software on the modems. > > This is the Equipement that we are getting rid of. > > 1 Total Control Chassis 48 ports > 1 Total Control Chassis 48 ports > 1 Total Control Chassis 48 ports > 1 Total Control Chassis 48 ports > 1 Total Control Chassis 48 ports > 1 Total Control Chassis 48 ports > 1 Total Control Chassis 48 ports > 1 Total Control Chassis 48 ports > 1 Total Control Chassis 48 ports > 1 Total Control Chassis 48 ports > 1 Total Control Chassis 48 ports > 1 Total Control Chassis 48 ports > 1 Total Control Chassis 48 ports > 1 Total Control Chassis 48 ports > 1 Total Control Chassis 48 ports > 1 Total Control Chassis 48 ports > 1 Total Control Chassis 48 ports > 1 Total Control Chassis 96 ports - 2 Hyper DSP Cards > 1 Total Control Chassis 96 ports - 2 Hyper DSP Cards > 1 Total Control Chassis 96 ports - 2 Hyper DSP Cards > 1 Total Control Chassis 96 ports - 2 Hyper DSP Cards > 1 Total Control Chassis 96 ports - 2 Hyper DSP Cards > 1 Total Control Chassis 96 ports - 2 Hyper DSP Cards > 1 Total Control Chassis 96 ports - 2 Hyper DSP Cards > 1 Total Control Chassis 96 ports - 2 Hyper DSP Cards > 1 Total Control Chassis 96 ports - 2 Hyper DSP Cards > 1 Total Control Chassis 96 ports - 2 Hyper DSP Cards > 1 Total Control Chassis 96 ports - 2 Hyper DSP Cards > 1 Total Control Chassis 96 ports - 2 Hyper DSP Cards > 1 Total Control Chassis 96 ports - 2 Hyper DSP Cards > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. --

Subject: Re: (usr-tc) Total Control Sell
From: Brian Gordon <administrator@westelcom.com>
Date: 1998-12-08 23:04:46

For Sale: New Sealed NMC CARD. Best Offer ----- Original Message ----- Sent: Tuesday, December 08, 1998 10:51 PM >Do you have the bundle part numbers and how much are you asking > >John > >On Tuesday, December 08, 1998 6:11 PM, dale [SMTP:adp@cybertours.com] wrote: >> << File: ATT00138.txt; charset = Windows-1252 >> > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) support woes
From: matthews <matthews@brunnet.net>
Date: 1998-12-09 02:15:16

On Tuesday, December 08, 1998 6:29 PM, Brian [SMTP:signal@shreve.net] wrote: > Just want to relay some support flames........ Ok, I've been holding this back for a long time but I can't any longer. Whoever is running the support department needs to dig his head out of his <expletive>. We had a support contract for a period of time and our president eventually received a phone call to tell us that the contract would expire a few months down the road. The phone call was passed to my boss (the general manager) who followed the phone call up (yes, I was present) and got <charming young lady..heh>'s voice mail. My boss got a phone call from that charming young lady one month later (I was present for that too). The charming 3com lady claimed she had never received a call. How she got my boss's name and number, I don't know. Anyhow, after playing phone tag with Charming 3Com Lady for a month, my boss got frustrated and handed it to me. I called Charming 3Com Lady to tell her I'd be interested in considering an additional support contract. She said, that's great but you can probably get a lot better prices from a reseller. Gimme a list of resellers, I said. She didn't have one, she said. But she'd get back to me. Sure. A week later with still no phone call, I called her again and found she had gone on vacation but that I could call Ed. Wonderful, I said. I'll just leave a little nasty-gram on her voice mail. I called Ed and got voice mail as well. I left a message and got a phone call the next day (or the same day, can't remember) saying that he didn't have a list of authorized resellers either but that he DID in fact have a price list for 3Com direct support contract. Wonderful, I said, better than nothing. I did receive a sheepish reply from Charming 3Com Lady the next week explaining that she still didn't have a list of authorized contract resellers but she'd notify me as soon as she did. Charming 3Com Lady called me AGAIN 2 weeks later to notify me that because I hadn't made any initiative to renew my support contract that it would expire within a couple of weeks. I called her back and sharply explained the situation and added that it was because of her sluggishness in letting me know where I could *BUY* the stupid contract that I hadn't renewed it yet. It got extended a couple of weeks. Wow. Our hardware support contract eventually expired. And then one of our NETServer cards went bad. I called support (for which I did have a contract, thank God) and they gave me the diagnosis of a bad NETServer. We're going to pass you to logistics now to get that replaced, they said. Nice. Guess who at logistics they passed me to!?!? My beloved Charming 3Com Lady!! Well now I'm up sh*t creek, I thought. Of course, I had no hardware support contract to fall back on. So I asked Charming 3Com Lady and asked her to step on it so I could get that reseller list. Called Ed and asked him the same thing. No response. By this time I was fuming. So I called the the last person on my list that I could think of. He was a gentleman by the name of Andrew Palmer who was in the area a while back promoting 3Com products at the company I work for. I left him a ripping voice mail telling him what I thought of his company and how logistics ran their operation. The next day my pager started going off. 1-800?? What the hell..hmmm...got back to the office and found that someone from 3Com had called and it was Very Important. Well it was Andrew returning my call, wanting to know the whole story. So I told The Story with all the sordid details and he said he'd look into it and see what we could do. Great. Pretty soon I was put in touch with an engineer (who shall remain nameless by his request) who thought how the way the whole situation was handled was pretty lame (Andrew was in agreement at this point) and decided to do a straight swap right then and there of the NETServer NIC. That didn't solve the technical difficulty, but anyhow, that's not the point. Andrew also suggested I get in touch with Mike Donato from 3Com ISP sales (I think...don't hold me to that). I left a voice mail for Mike who was on vacation at the time and got no direct answer, but, magically, I had support contract resellers calling me left and right. Wonderful. Problem solved. And that's all I had to do to get a support contract vendor. So this what I think of 3Com's logistics department and their support contracts. I agree that we should pay for 24/7 phone support outside of the initial turn-up. But don't give me this crap about needing a support contract for advanced parts replacement outside of the 30 day warranty. Nice warranty, by the way. I have HP servers I paid far less for than these Total Control hubs and get advanced parts replacement with a single phone call. And I don't think I have to tell you what I think about buying a support contract so that I can get updated firmware that fixes bugs in production systems. Charge all you want for new features, I don't care. Don't charge me to fix your own buggy code. (I know, Krish, you'll give us bugfixes...but that didn't help me when I wasn't on this list and it still doesn't help the vast number of TC users who still aren't and don't know about this list). And finally, if you are going to charge for hardware support, don't charge 1/2 the price of a chassis just to speed up the replacement of a part that is (or probably should be) covered under a manufacturer's warranty anyway. One final note. Some of you may remember when there was a bug report released about Cisco IOS version 10.x...had something to do with crashing the router from a remote console session. I placed ONE phone call to the Cisco TAC and was connected with an engineer to help me get updated code FREE OF CHARGE. Not only that, he spent an hour with me on the phone helping me figure out how I could affordably upgrade the routers I had to IOS 11 - buy memory for this router, take simms from that router, move it to that one, where I could buy memory cheaply, etc. Furthermore, I had followup emails from the TAC (and phone calls from him) asking if my situation had been resolved and whether or not I needed help installing the simms and applying the firmware update. None of my routers were covered under warranty. Nor did I have a support contract. I had never placed a call to the Technical Assistance Centre before that day. Take notes, 3Com. *THAT*, my friends, is service. And if any of you 3Com lads know who I'm talking about when I say Charming 3Com Lady at Logistics, give her my warmest regards. > Like many of you, our support contracts are being held hostage. We > purchased contracts this year from source technologies, but they will not > be honored by 3Com and are in dispute, since 3Com feels we owe more money > for support. > > Until I get a support contract, I cannot use totalservice. > > When I was under contract, I downloaded 4.1.11. It has recently come to > our attention that 4.1.11 has a nasty memory leak, hence the release of > 4.1.72 on total service. So basically what I paid for is broke.......and > not just broke in a little way, broke in a way in which it would be crazy > for an ISP to use that code in production enviroment knowing the issues, > at least in our enviroment. > > I sent in some warranty registration cards, you know the ones with 90 days > support........and I got no response. Has anyone ever gotten anything > proactivly back from 3com after sending in those 90day support post cards? > I have more but dare not send them in if they aren't going to be > honored/responded to. > > Personally I don't feel I should have to renew my support contract to get > the fix for code that I paid for. 3Com needs to credit to your > totalservice login what you have paid for, and allow ER releases for that > version to be downloaded, instead of treating them like newer code bases > which they are not. > > So I am peeved. I run leaky code, can't get the new code without the > support contracts, even though we have paid several thousand for support > contracts already this year. I hate the back alley way of people mailing > me 4.1.72 just so that I can run 3Com Total Control stable, but that's how > it goes......it's sad. So if someone has a copy, you know the > email.......and I don't feel guilty because I am working with 3Com to > resolve this contract issues, really trying. I have emailed them and am > awaiting response, but like I said, I need a fix yesterday. > > We are the largest ISP in our locality which is made up of 350,000+ > people. We were the first to offer x2, and because of that, an > unbelievable number of people in this area use 3com modems, hardly any use > kflex technology, and alot of that is due to our decision to use 3com > equipment. > > Now the 3com call records will show, that I didn't call support at all > last year, not that I can remember, the only time I usually need support > is with software bugs/issues, which isn't something you have customers pay > for (i.e. if your software is buggy, and becaues of that users call > support, that's YOUR problem, not theirs). As far as genuine "how do i do > this" support, I don't call them. > > Anyone elses contracts being held hostage? > > 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. Be Seeing You... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Matthew Stainforth<>Technical Services Manager<>BrunNet Inc.<>(506)450-4562 Don't rush me, sonny. You rush a miracle maker and you get rotten miracles. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Subject: Re: (usr-tc) support woes
From: Brian <signal@shreve.net>
Date: 1998-12-09 07:19:28

On Tue, 8 Dec 1998, Spork SPORK wrote: > On Tue, 8 Dec 1998, Brian wrote: > > > Like many of you, our support contracts are being held hostage. We > > purchased contracts this year from source technologies, but they will not > > be honored by 3Com and are in dispute, since 3Com feels we owe more money > > for support. > > Brian, > > I'm not familiar with the "hostage situation"... We are looking to do > business with Source, including buying support/software contracts. What's > the story with this? > Source is a great company don't get me wrong, its not source that is fumbling these deals. If 3Com feels you have more equipment than you have contracts for, then they won't honor any of the contracts you do have, its that simple........so if you buy chassis A, B and C, and you have only a support contract on A or A and B, but not C, then they won't honor it at all, not even on the chassis you bought the contract for. > Thanks, > > Charles > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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

Subject: Re: (usr-tc) support woes
From: Brian <signal@shreve.net>
Date: 1998-12-09 07:19:28

Subject: (usr-tc) syslogging
From: Brian <signal@shreve.net>
Date: 1998-12-09 07:21:41

Question: Do most of you syslog all your calls? if so at what event levels? (default?) How do you handle the data, do you roll it over daily then delete it weekly? database it somehow? 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

Subject: Re: (usr-tc) support woes
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-12-09 08:32:07

Thus spake Brian >On Tue, 8 Dec 1998, Spork SPORK wrote: >> On Tue, 8 Dec 1998, Brian wrote: >> > Like many of you, our support contracts are being held hostage. We >> > purchased contracts this year from source technologies, but they will not >> > be honored by 3Com and are in dispute, since 3Com feels we owe more money >> > for support. >> I'm not familiar with the "hostage situation"... We are looking to do >> business with Source, including buying support/software contracts. What's >> the story with this? >Source is a great company don't get me wrong, its not source that is >fumbling these deals. If 3Com feels you have more equipment than you have >contracts for, then they won't honor any of the contracts you do have, its >that simple........so >if you buy chassis A, B and C, and you have only a support contract on A >or A and B, but not C, then they won't honor it at all, not even on the >chassis you bought the contract for. Man, this *really* sounds like lawsuit time. I've cc:'ed a few extra people on this to try to draw some attention to it. We can't say that we've experienced this, but we are *extremely* concerned, and have discussed the (at the time) rumours that we had heard this was happening with several 3Com folks (conf call). At the time I didn't have any confirmation that this was really happening, so that's why I'm cc:'ing this a bit more as well...to let some of the folks that I talked to on the conf call know about someone that this really is happening to. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) support woes
From: Matthew E. Pearson <mpearson@tiac.net>
Date: 1998-12-09 08:43:34

>if you buy chassis A, B and C, and you have only a support contract on A >or A and B, but not C, then they won't honor it at all, not even on the >chassis you bought the contract for. Correct me if I am wrong.. but... isn't that ummm illegal? They should either A give you your money back on support, or B honor support on the boxes under contract. True every dead card could be in chassis A :) but still.. they build enough slack in their contract prices to cover that. I was told that is why they were so expensive.. It occurs to be 3com can't have it both ways... either A: Charge less because there is no "loss due to contract fraud" because they simply wont honor any contracts without a premise inspection to see how many you actually have. or B: Suck it up and service the boxes at the over inflated rate. We were looking at contracts with 3com and discovered that if we were to be in total compliance (a new 3com site? hehe) we could no only hire two of their senior engineers full time to work for us at more that 3com pays them, but that we could also keep several full chassis around just as spares for parts and we would still save money!!!! 3com seems to have their head up their ass on this one.

Subject: Re: (usr-tc) support woes
From: K Mitchell <mitch@keyconn.net>
Date: 1998-12-09 09:00:50

At 07:19 AM 12/9/98 -0600, Brian wrote: > >Source is a great company don't get me wrong, its not source that is >fumbling these deals. If 3Com feels you have more equipment than you have >contracts for, then they won't honor any of the contracts you do have, its >that simple........so > >if you buy chassis A, B and C, and you have only a support contract on A >or A and B, but not C, then they won't honor it at all, not even on the >chassis you bought the contract for. I agree, Source has been very good to deal with for us. They also included TCM and S&A Server as part of the HiPer chassis bundle I purchased(I strongly feel that 3Com should as well), but I've gotten hell from 3Com people for having both TCM and S&A Server. Source's management assures me that they have an agreement with 3Com that allows them to include the software, but 3Com's support personnel say that they're not aware of any agreement. I'm inclined to believe Source on this one and feel that 3Com's only being pissy about it because they can't collect more money for software that should be included in the first place. Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

Subject: (usr-tc) RE: (USR-TC) IS V90 EVER
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1998-12-09 09:08:00

We worked around it temporarily by disabling V.90 and have them enter +MS=11 in the Extra Settings under the modem properties. This forced them to downspeed to V.34. I'll have them grab the latest code. Thanks, Jeff Binkley ASA Network Computing U>try http://beta.supra.com U>I coulfn't get a diamond to connect but I flashed their beta code and U>v.90 worked like without problem. before the flash it would dial and U>attempt v.90 and then disconnect ... would not even send name and U>password ... U>----- Original Message ----- U>From: Jeff Binkley <jeff.binkley@asacomp.com> U>To: <usr-tc@lists.xmission.com> U>Sent: Tuesday, December 08, 1998 8:57 PM U>Subject: Re: (usr-tc) Is v90 ever going to work? U>> U>>-> When is the new modem code coming out, has anyone a clue? U>> U>>I dunno. I just had a Diamond Supra V.90 which wouldn't connect U>>to Quads without disabling V.90 <sigh>... Most of mine are the U>>same scenario: connect at V.90 speed, see PPP start and then U>>modem never send userid and password, then disconnects. Disable U>>V.90 and everything works fine. Of course this isn't all modems, U>>just primarily LT and Rockwell based ones. U>> U>> U>>Jeff Binkley U>>ASA Network Computing U>> 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. U>> 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. U> CMPQwk 1.42 9999

Subject: RE: (usr-tc) Settings for Ch. T-1 on a HiPerDSP
From: MED, Wipro Systems, Inc <"nair, shibu (med, wipro systems, inc)">
Date: 1998-12-09 09:49:16

Hi My span settings on Hiper DSP card (channelised T1) is shown below, By default the general profile for DSP will be E&M Type II (last line).... And i have changed the DNIS Enable to "No Address" and Signal mod to "Robbed bit" which inturn change th profile from "E&M II" to "Other profile" ... > chdev span span1> display ccrc Span1 Configured Signal Mode is (sigmode): ROBBED BIT Span1 Signal Mode Active is: ROBBED BIT Span1 DNIS Enable is (dnisena): NO ADDRESS Span1 Dial In Out Trunk Start (diotrst): WINK Span1 Dial In Address ACK Wink (daackwnk): ACK WINK DISABLED Span1 Dial Out Address Delay (doadrdly): 70 milliseconds Span1 Dial In Out Trunk Type (dtrnktyp): E&M TYPE II Span1 Configured Switch Type is (swtype): 5ESS Span1 Switch Type Active is: 5ESS Span1 Idle Byte is (idlebyte): 0xFE Span1 Ana Calls Blocked Err Code (ancbec): 58 Span1 Digi Calls Blocked Err Code (dcbec): 58 Span1 No IGWS Avail Err Code (noigwsav): 58 Span1 Chan Blocked Err Code (chanblck): 58 Span1 Block Call Type is (blcaltyp): BLOCK NONE Span1 Tone Type is (tonetype): DTMF TONE Span1 Number Of DTMF Tones is (numdtmft): 4 Span1 Dial Out Select Direction (dseldir): DOWN Span1 Dial Out Next Timeslot (dntslot): 24 Span1 Channelized T1 Profile (cprofile): OTHER PROFILE Hope this will help you.... Regards Shibu ---------- From: Randy Doran[SMTP:RandyDoran@USA.net] Reply To: usr-tc@lists.xmission.com Sent: Wednesday, December 09, 1998 9:26 AM To: usr-tc@lists.xmission.com Subject: (usr-tc) Settings for Ch. T-1 on a HiPerDSP On a HiPerDSP, what do you have to change from the default settings to bring up a Channelized T-1? I have already set the "Signal Mode" to "robbedBit." The circuit appears to be up and all 24 DS0s are "inService". I have verified that the circuit itself works by plugging it into a Dual T-1 card and calls came right in on the Quad modem cards. ----------------------------------------------------- Randy Doran Circuit Engineer \ Dialup Network Coordinator e.spire Communication's CyberGate 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.

Subject: Re: (usr-tc) support woes
From: Brian <signal@shreve.net>
Date: 1998-12-09 10:00:28

On Wed, 9 Dec 1998, Matthew E. Pearson wrote: > > >if you buy chassis A, B and C, and you have only a support contract on A > >or A and B, but not C, then they won't honor it at all, not even on the > >chassis you bought the contract for. > > > > Correct me if I am wrong.. but... isn't that ummm illegal? They should > either A give you your money back on support, or B honor support on the > boxes under contract. True every dead card could be in chassis A :) but > still.. they build enough slack in their contract prices to cover that. I > was told that is why they were so expensive.. It occurs to be 3com can't > have it both ways... either A: Charge less because there is no "loss due to > contract fraud" because they simply wont honor any contracts without a > premise inspection to see how many you actually have. or B: Suck it up and > service the boxes at the over inflated rate. > > We were looking at contracts with 3com and discovered that if we were to be > in total compliance (a new 3com site? hehe) we could no only hire two of > their senior engineers full time to work for us at more that 3com pays them, > but that we could also keep several full chassis around just as spares for > parts and we would still save money!!!! Well, originally 3Com told us we needed to pay $60k per year (remember now we have only 320 modems!) You can imagine how our jaws dropped. They then said they were cutting us a really good deal at $15k per year. > > 3com seems to have their head up their ass on this one. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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

Subject: (usr-tc) syslog->database
From: Brian <signal@shreve.net>
Date: 1998-12-09 10:02:49

Has anyone written anything to take the syslog information from the arc's and format it into an SQL database? 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

Subject: (usr-tc) Settings for Ch. T-1 on a HiPerDSP
From: Randy Doran <randydoran@usa.net>
Date: 1998-12-09 10:26:02

On a HiPerDSP, what do you have to change from the default settings to bring up a Channelized T-1? I have already set the "Signal Mode" to "robbedBit." The circuit appears to be up and all 24 DS0s are "inService". I have verified that the circuit itself works by plugging it into a Dual T-1 card and calls came right in on the Quad modem cards. Randy Doran Circuit Engineer \ Dialup Network Coordinator e.spire Communication's CyberGate Internet Services

Subject: Re: (usr-tc) support woes
From: Brian <signal@shreve.net>
Date: 1998-12-09 10:33:18

On Wed, 9 Dec 1998, Ricky Beam wrote: > Matthew E. Pearson was heard to say: > >>if you buy chassis A, B and C, and you have only a support contract on A > >>or A and B, but not C, then they won't honor it at all, not even on the > >>chassis you bought the contract for. > > > >Correct me if I am wrong.. but... isn't that ummm illegal? They should > > Technically, no. If you have a support contract for one chassis, then you > have access to the firmware for every chassis you have. 3Com has no way of > insuring you are not updating more than the chassis under contract. Well they just have to trust you then. When Microsoft sells you W95 on cd, how do they know you didn't install it on all your machines? This crap is unheard of in this industry, Cisco, Ascend, Bay, none of them hold your contracts hostage. If 3Com had steller support etc, they could probably do this with very little damage, but their support problems were already the worst in the NAS industry. > > Auditing an ISP is nearly impossible -- hardware is scattered over hundreds > of miles. Plus, who's to say the card died in the supported chassis; you > can move cards around :-) exactly, so why does 3Com try to assume how many NAS boxes I have. They are very wrong at what we have, we sold every quad modem chassis we owned, but did they know that? > > Think about it in terms of NT installs. You can buy one CD and install it > on thousands of machines. That's clearly illegal -- trackable, however. > Microsoft is not going to make you buy a license for every computer you own > simply because there are alternatives. 3Com makes you buy a contract for > all or none simply because there is no other way to police it. > > >have it both ways... either A: Charge less because there is no "loss due to > >contract fraud" because they simply wont honor any contracts without a > >premise inspection to see how many you actually have. or B: Suck it up and > >service the boxes at the over inflated rate. > > And how many people will it take to inspect 100 POPs? Tracking who has what > is a nightmare. they just need to suck it up and honor the support contract, its not like they get many phone calls from shrevenet. brian > > --Ricky > > PS: Speaking as an ISP, cards do get moved around. And in some cases, entire > chassises get swaped around. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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

Subject: Re: (usr-tc) VJ Header Compression
From: Frank Basso <frank@okwhatever.com>
Date: 1998-12-09 11:13:06

VJ is supported but the implementation is poor, it will not work with many products, including Farralon, Trancell, Pivotal, and Last but not least 3COM ISDN router products... in my experience. As for the MTU and MRU, this can be set with your radius profiles...... and that is only a suggested setting :) I know a customer can request a different MRU/MTU and the chassis will change it ignoring Radius. -Frank -----Original Message----- > >I was just asked if our Total Control (HiperDSPs) Chassis supported VJ >Header Compression and I don't know the answer. > >Does the TC support VJ Header Compress by default? >Also, can the MTU and MRU be configured in the TC? > >Thanks. > >Alan D. Criado > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) strange modem tones...
From: Frank Basso <frank@okwhatever.com>
Date: 1998-12-09 11:14:02

What do you consider strange ? Screaming Modem ? or ? -----Original Message----- >Recently we've started to get strange modems tones from our chassis'. HDM >cards running 1.2.5 DSP and 4.0.30 ARC. Once we locate the modem that's >making the strange tones, we hardware reset the card and it is fixed. This >seems to be happening nightly, but not to the same DSP cards.... > >Any suggestions? Anyone else seeing (hearing) this? > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) support woes
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-12-09 11:23:16

Matthew E. Pearson was heard to say: >>if you buy chassis A, B and C, and you have only a support contract on A >>or A and B, but not C, then they won't honor it at all, not even on the >>chassis you bought the contract for. > >Correct me if I am wrong.. but... isn't that ummm illegal? They should Technically, no. If you have a support contract for one chassis, then you have access to the firmware for every chassis you have. 3Com has no way of insuring you are not updating more than the chassis under contract. Auditing an ISP is nearly impossible -- hardware is scattered over hundreds of miles. Plus, who's to say the card died in the supported chassis; you can move cards around :-) Think about it in terms of NT installs. You can buy one CD and install it on thousands of machines. That's clearly illegal -- trackable, however. Microsoft is not going to make you buy a license for every computer you own simply because there are alternatives. 3Com makes you buy a contract for all or none simply because there is no other way to police it. >have it both ways... either A: Charge less because there is no "loss due to >contract fraud" because they simply wont honor any contracts without a >premise inspection to see how many you actually have. or B: Suck it up and >service the boxes at the over inflated rate. And how many people will it take to inspect 100 POPs? Tracking who has what is a nightmare. --Ricky PS: Speaking as an ISP, cards do get moved around. And in some cases, entire chassises get swaped around.

Subject: Re: (usr-tc) support woes
From: Brian <signal@shreve.net>
Date: 1998-12-09 11:49:54

> > Man, this *really* sounds like lawsuit time. I've cc:'ed a few extra > people on this to try to draw some attention to it. > > We can't say that we've experienced this, but we are *extremely* > concerned, and have discussed the (at the time) rumours that we had > heard this was happening with several 3Com folks (conf call). At the > time I didn't have any confirmation that this was really happening, so > that's why I'm cc:'ing this a bit more as well...to let some of the > folks that I talked to on the conf call know about someone that this > really is happening to. It's very real. We have paid for legitimate support contracts in 1998 from 3Com. These support contracts were never honored. We never received refunds for the money we spent on the contracts. We feel we are one of 3Com's best customers, we promote their products and defend them on all the lists we can, even with the bad support we receive. We have 14 HDM's, that's it. So thats 336 modems. We are a professional company, who wants to pay good money for good service. > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > 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

Subject: Re: (usr-tc) VJ Header Compression
From: Dan Hollis <goemon@sasami.anime.net>
Date: 1998-12-09 12:53:56

On Wed, 9 Dec 1998, Alan D. Criado wrote: > Hmmm. I have a WebTV customer who just signed on and is having trouble > getting connected with us. The WebTV people said that was neccessary that > VJ Compression be turn on and that the MTU be 1500 and the MRU be 1500 or > higher. With WebTV, vj isnt the problem, MTU is. WebTV's proxy servers are running an ancient buggy version of solaris with completely broken path mtu. I screamed at them about this over a year ago. Set your MTU to 1500 or higher and youll be ok. -Dan

Subject: Re: (usr-tc) support woes
From: Jesse Sipprell <jss@evcom.net>
Date: 1998-12-09 13:07:04

On Wed, Dec 09, 1998 at 11:49:54AM -0600, Brian wrote: > > > > Man, this *really* sounds like lawsuit time. I've cc:'ed a few extra > > people on this to try to draw some attention to it. > > > > We can't say that we've experienced this, but we are *extremely* > > concerned, and have discussed the (at the time) rumours that we had > > heard this was happening with several 3Com folks (conf call). At the > > time I didn't have any confirmation that this was really happening, so > > that's why I'm cc:'ing this a bit more as well...to let some of the > > folks that I talked to on the conf call know about someone that this > > really is happening to. > > It's very real. We have paid for legitimate support contracts in 1998 > from 3Com. These support contracts were never honored. We never received > refunds for the money we spent on the contracts. > > We feel we are one of 3Com's best customers, we promote their products and > defend them on all the lists we can, even with the bad support we receive. > We have 14 HDM's, that's it. So thats 336 modems. We are a professional > company, who wants to pay good money for good service. Heh. Just checked totalservice, and it looks like I am locked out of all the code now, even though I just bought a brand new chassis w/ 4 HDMs, HARC, etc, etc, *AND* a support contract. After reading this conversation, I am NOT looking forward to talking with them. 3com, you are making a VERY VERY serious mistake here. -- Jesse Sipprell Technical Operations Director Evolution Communications, Inc. 800-496-4736 (ext 106) * Finger jss@evcom.net for my PGP Public Key *

Subject: (usr-tc) strange modem tones...
From: Jerry Kalligonis <jerryk@blazenet.net>
Date: 1998-12-09 13:26:42

Recently we've started to get strange modems tones from our chassis'. HDM cards running 1.2.5 DSP and 4.0.30 ARC. Once we locate the modem that's making the strange tones, we hardware reset the card and it is fixed. This seems to be happening nightly, but not to the same DSP cards.... Any suggestions? Anyone else seeing (hearing) this?

Subject: Re: (usr-tc) VJ Header Compression
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-09 13:27:43

On Wed, 9 Dec 1998, Alan D. Criado wrote: > > I was just asked if our Total Control (HiperDSPs) Chassis supported VJ > Header Compression and I don't know the answer. > VJ is not supported on HiperDSP. This is a part of either NETServer or Hiper ARC. On Hiper arc VJ is on by default. On NETServer VJ is off by default. > Does the TC support VJ Header Compress by default? > Also, can the MTU and MRU be configured in the TC? > You can again change VJ and MTU. MTU will take place if you either use chap or if you do a terminal login to ppp krish > Thanks. > > Alan D. Criado > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) support woes
From: Ronald E. Kushner <ron@glis.net>
Date: 1998-12-09 13:28:16

Brian wrote: > > We feel we are one of 3Com's best customers, we promote their products and > defend them on all the lists we can, even with the bad support we receive. > We have 14 HDM's, that's it. So thats 336 modems. We are a professional > company, who wants to pay good money for good service. If that's the case, you're better off just subscribing to software support, and buying a spare HiPer DSP card, a spare HiPer Arc Router, and a spare 130A power supply, and leave them sitting at the POP - if you have a secure location. 3Com's loss is your gain. As long as you have good UPS's, and the equipment is kept below 35 degrees C, you shouldn't see anything happen to the equipment. I have a old Quad bundle, it's over 2 years old, and I've seen it outlast other ISP's at the co-location facility where I have my equipment. Everyone else had quad's going bad all the time... I've not seen one failure. But the others didn't have fan trays, or have those SHIT APC UPS's. I was there one day and saw several APC's catch fire because of a condition Detroit Edison created. Our TrippLite and BEST UPS's never gave up, and all the other ISP's with TrippLite UPS's didn't have a problem either. Some of the equipment on the APC's was fried as well, mostly DSU's and power supplies in RAC equipment. It was scary, one 3000 VA APC UPS from Voyager blew up like a bomb - but luckily none of their Cisco AS5200 equipment was damaged. I figure this power problem was a worse case scenario, and I am making most future plans based on the experience - spare power supplies for all equipment and spare UPS's. -Ron GLISnet, Inc. 810/939.9885

Subject: Re: (usr-tc) support woes
From: Spork SPORK <spork@inch.com>
Date: 1998-12-09 13:33:34

This is so incredibly asinine. I've bought the chassis, but guess what, without a support contract for software, I have a percentage of users that cannot connect. Why should there be a seperate charge to make the equipment fully functional? I'll pay extra for a feature, but not a fix... Even Microsoft makes "service packs" available for free... Haven't these people heard of a site-license? I also guarantee you that some very large customers (howdy David!) are not paying $1300/box for software. Where's the lawyers? C =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------= On Wed, 9 Dec 1998, Jesse Sipprell wrote: > On Wed, Dec 09, 1998 at 11:49:54AM -0600, Brian wrote: > > > > > > Man, this *really* sounds like lawsuit time. I've cc:'ed a few extra > > > people on this to try to draw some attention to it. > > > > > > We can't say that we've experienced this, but we are *extremely* > > > concerned, and have discussed the (at the time) rumours that we had > > > heard this was happening with several 3Com folks (conf call). At the > > > time I didn't have any confirmation that this was really happening, so > > > that's why I'm cc:'ing this a bit more as well...to let some of the > > > folks that I talked to on the conf call know about someone that this > > > really is happening to. > > > > It's very real. We have paid for legitimate support contracts in 1998 > > from 3Com. These support contracts were never honored. We never received > > refunds for the money we spent on the contracts. > > > > We feel we are one of 3Com's best customers, we promote their products and > > defend them on all the lists we can, even with the bad support we receive. > > We have 14 HDM's, that's it. So thats 336 modems. We are a professional > > company, who wants to pay good money for good service. > > Heh. Just checked totalservice, and it looks like I am locked out of all the > code now, even though I just bought a brand new chassis w/ 4 HDMs, HARC, etc, > etc, *AND* a support contract. After reading this conversation, I am NOT > looking forward to talking with them. 3com, you are making a VERY VERY > serious mistake here. > > -- > Jesse Sipprell > Technical Operations Director > Evolution Communications, Inc. > 800-496-4736 (ext 106) > > * Finger jss@evcom.net for my PGP Public Key * > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) VJ Header Compression
From: Alan D. Criado <acriado@elink.net>
Date: 1998-12-09 14:04:46

I was just asked if our Total Control (HiperDSPs) Chassis supported VJ Header Compression and I don't know the answer. Does the TC support VJ Header Compress by default? Also, can the MTU and MRU be configured in the TC? Thanks. Alan D. Criado

Subject: Re: (usr-tc) VJ Header Compression
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-09 14:25:30

On Wed, 9 Dec 1998, Ricky Beam wrote: > Tatai SV Krishnan was heard to say: > >> I was just asked if our Total Control (HiperDSPs) Chassis supported VJ > >> Header Compression and I don't know the answer. > >> > > > >VJ is not supported on HiperDSP. This is a part of either NETServer or > >Hiper ARC. On Hiper arc VJ is on by default. On NETServer VJ is off by > >default. > > Umm, if the DSP card is handling the PPP framing (PPP offloading) then isn't > it going to be doing the VJ compression? I know I started seeing CRC errors > when I loaded 2.0.5 (beta) DSP code. The DSP code was all that changed. > Turning off VJ compression got rid of the errors. Go figure. And Where did you turn VJ off? On the DSP? How - using TCM? 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. >

Subject: Re: (usr-tc) strange modem tones...
From: Curt Shambeau <curt@execpc.com>
Date: 1998-12-09 14:48:53

> Recently we've started to get strange modems tones from our chassis'. HDM > cards running 1.2.5 DSP and 4.0.30 ARC. Once we locate the modem that's > making the strange tones, we hardware reset the card and it is fixed. This > seems to be happening nightly, but not to the same DSP cards.... > > Any suggestions? Anyone else seeing (hearing) this? Call tech support and see if they will give you an ER version of HDM code. I expirenced that problem a lot with older codes, but the newer ER codes seems to have fixed most of it. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Executive Vice President - Exec-PC, Inc. |

Subject: Re: (usr-tc) VJ Header Compression
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-12-09 15:08:30

Tatai SV Krishnan was heard to say: >> I was just asked if our Total Control (HiperDSPs) Chassis supported VJ >> Header Compression and I don't know the answer. >> > >VJ is not supported on HiperDSP. This is a part of either NETServer or >Hiper ARC. On Hiper arc VJ is on by default. On NETServer VJ is off by >default. Umm, if the DSP card is handling the PPP framing (PPP offloading) then isn't it going to be doing the VJ compression? I know I started seeing CRC errors when I loaded 2.0.5 (beta) DSP code. The DSP code was all that changed. Turning off VJ compression got rid of the errors. Go figure. --Ricky

Subject: Re: (usr-tc) VJ Header Compression
From: Alan D. Criado <acriado@elink.net>
Date: 1998-12-09 15:08:40

At 01:27 PM 12/9/98 -0600, Tatai SV Krishnan wrote: >On Wed, 9 Dec 1998, Alan D. Criado wrote: > >> >> I was just asked if our Total Control (HiperDSPs) Chassis supported VJ >> Header Compression and I don't know the answer. >> > >VJ is not supported on HiperDSP. This is a part of either NETServer or >Hiper ARC. On Hiper arc VJ is on by default. On NETServer VJ is off by >default. Ok, my fault. I have HiperArc. >> Does the TC support VJ Header Compress by default? >> Also, can the MTU and MRU be configured in the TC? >> >You can again change VJ and MTU. MTU will take place if you either use >chap or if you do a terminal login to ppp > >krish Hmmm. I have a WebTV customer who just signed on and is having trouble getting connected with us. The WebTV people said that was neccessary that VJ Compression be turn on and that the MTU be 1500 and the MRU be 1500 or higher. I'm just having a problem locating where these parameters can be configured. Thank you. Alan D. Criado

Subject: Re: (usr-tc) VJ Header Compression
From: Ronald E. Kushner <ron@glis.net>
Date: 1998-12-09 15:41:19

"Alan D. Criado" wrote: > > Hmmm. I have a WebTV customer who just signed on and is having trouble > getting connected with us. The WebTV people said that was neccessary that > VJ Compression be turn on and that the MTU be 1500 and the MRU be 1500 or > higher. > > I'm just having a problem locating where these parameters can be configured. > There is a note in the 4.1.72 service release for the HiPer Arc Router: Additional fixes fixed in this release: Problem with WEB TV and Apple Clients - Problems with LCP restart issued by WebTV/Apple causes connection problems.

Subject: Re: (usr-tc) VJ Header Compression
From: Dan Hollis <goemon@sasami.anime.net>
Date: 1998-12-09 15:56:55

On Wed, 9 Dec 1998, Alan D. Criado wrote: > >With WebTV, vj isnt the problem, MTU is. WebTV's proxy servers are running > >an ancient buggy version of solaris with completely broken path mtu. I > >screamed at them about this over a year ago. > >Set your MTU to 1500 or higher and youll be ok. > Sounds good to me Dan. Where is the MTU setting configured? In the radius profile. -Dan

Subject: (usr-tc) pbGenericError on HiPer DSP 1.2.5
From: Simon Ferrett <simonf@ethergate.com>
Date: 1998-12-09 16:20:41

Hi, Recently one of the modems on a HiPer card (1.2.5 ISDN) started reporting a pbGenericError for every call attempt to it.. I'm not sure what the callers were getting, I think a fast-busy. I replaced the front card with another one which reported the same error on the same modem... I moved the front&back to a different chassis and it works fine so it doesn't appear to be the HiPer DSP card. I haven't had a chance to reset the whole chassis yet since it has 13 other HiPer DSP's in it and I dont want to drop them all right now.. perhaps later. Has anyone else experienced this pbGenericError or have a pointer as to what it might be? I'll plug the card back in to its slot (1) in the chassis once I get a chance to reset the whole thing and see if that clears it up. The chassis has an NMC (5.5.5) and 2 ARC (4.0.30) in it.. Regards, --- Simon Ferrett - simonf@ethergate.com

Subject: Re: (usr-tc) VJ Header Compression
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-12-09 16:33:11

Thus spake Frank Basso >VJ is supported but the implementation is poor, it will not work with many >products, including Farralon, Trancell, Pivotal, and Last but not least 3COM >ISDN router products... in my experience. As for the MTU and MRU, this can >be set with your radius profiles...... and that is only a suggested setting >:) I know a customer can request a different MRU/MTU and the chassis will >change it ignoring Radius. Let's think about the PPP setup procedure. MTU is negotiated during LCP, which is the first thing negotiated. RADIUS isn't checked until after PAP has received a userid and password...this is the second phase of PPP negotiation...LCP is already open and the MTU is set. Its conceivable that the NETServer or HARC could send a new LCP Conf-Req after the RADIUS auth-ack is received with the new MTU, but that's going to be problematic as I suspect quite a lot of equipment won't like restarting LCP negotiation at that point (though it is allowed per the spec). -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) VJ Header Compression
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-12-09 16:38:00

Thus spake Ricky Beam >Tatai SV Krishnan was heard to say: >>VJ is not supported on HiperDSP. This is a part of either NETServer or >>Hiper ARC. On Hiper arc VJ is on by default. On NETServer VJ is off by >>default. >Umm, if the DSP card is handling the PPP framing (PPP offloading) then isn't >it going to be doing the VJ compression? Nope. Van Jacobson is TCP header compression (using the OSI model its layer 4), PPP framing is a layer 2 thing. So, the DSP or quad is doing the PPP framing and handing the packet off to the NETServer or Arc, where I suspect more PPP processing still has to be done (I doubt the DSP/quad does *all* the PPP processing), once all the PPP processing has been done, the NETServer/Arc still has to process the IP header before it can even *think* about whether TCP header compression is of any significance. :) >I know I started seeing CRC errors >when I loaded 2.0.5 (beta) DSP code. The DSP code was all that changed. >Turning off VJ compression got rid of the errors. Go figure. There's nothing that's *directly* affecting it, though VJ is gonna change the TCP header, so it will at least indirectly affect the PPP framing and CRC check, so it could be tickling a bug in the PPP framing I guess. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Extending hardware life was "Re: (usr-tc) support woes"
From: John Powell <jp@packet.ae.usr.com>
Date: 1998-12-09 17:05:05

On Wed, 9 Dec 1998, Ronald E. Kushner wrote: .. Lots of good advice snipped.... I might also note that proper grounding is a good thing also. Be sure the chassis, and both PSUs (if you have two) are all properly grounded to spec!! This will not only extend the life of the equipment, it will ensure proper operation (some wierd problems have been traced back to improper grounding). > It was scary, one 3000 VA APC UPS from > Voyager blew up like a bomb - but luckily none of their Cisco AS5200 > equipment was damaged. I figure this power problem was a worse case Now there is a true computer geek speaking. Most people would be concerned that humans were not injured, we just care about the hardware ;) Sorry, couldn't resist a little fun jab there....just kidding. JP

Subject: Re: (usr-tc) strange modem tones...
From: Kingsley S. Grant <ksg@recorder.ca>
Date: 1998-12-09 17:07:31

Jerry, We are getting the same tones here in Brockville. We are putting the fault on the Telco with this one until we get converted to fiber in a few weeks. Somthing to to with Timing Jerry Kalligonis wrote: > Recently we've started to get strange modems tones from our chassis'. HDM > cards running 1.2.5 DSP and 4.0.30 ARC. Once we locate the modem that's > making the strange tones, we hardware reset the card and it is fixed. This > seems to be happening nightly, but not to the same DSP cards.... > > Any suggestions? Anyone else seeing (hearing) this? > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- Kingsley S. Grant RipNET Manager RipNET Internet Services 31 Broad Street Brockville ON, Canada K6V 4T9 (613) 342-3946 work (613) 342-8672 fax (613) 340-1144 Cel (613) 923-2596 Res (613) 341-0882 Pager 1-888-509-6677 E-Mail mailto:ksg@recorder.ca

Subject: Re: (usr-tc) strange modem tones...
From: John Powell <jp@packet.ae.usr.com>
Date: 1998-12-09 17:14:13

On Wed, 9 Dec 1998, Curt Shambeau wrote: > > Recently we've started to get strange modems tones from our chassis'. HDM > > cards running 1.2.5 DSP and 4.0.30 ARC. Once we locate the modem that's > > making the strange tones, we hardware reset the card and it is fixed. This > > seems to be happening nightly, but not to the same DSP cards.... > > > > Any suggestions? Anyone else seeing (hearing) this? > > Call tech support and see if they will give you an ER version of HDM code. > I expirenced that problem a lot with older codes, but the newer ER codes > seems to have fixed most of it. I'll save you the call. If you (or anyone else for that matter) is interested in the latest ER code, 1.2.60, please drop me a personal email. I'll point you to it. It definitely includes fixes for some "wierd tone" problems, as well as many other cumulative fixes. /begin small_print I do want to make clear, it is an ER and therefore has not gone through our full QA process, but all the feedback from the field so far has been positive. Fixes some, but not all, V.90 problems as well as many other issues such as the wierd tone issue. /end small_print JP jp@packet.ae.usr.com

Subject: Re: (usr-tc) strange modem tones...
From: Curt Shambeau <curt@execpc.com>
Date: 1998-12-09 17:21:28

> interested in the latest ER code, 1.2.60, please drop me a personal email. > I'll point you to it. It definitely includes fixes for some "wierd tone" > problems, as well as many other cumulative fixes. > > /begin small_print > I do want to make clear, it is an ER and therefore has not gone through > our full QA process, but all the feedback from the field so far has been > positive. Fixes some, but not all, V.90 problems as well as many other > issues such as the wierd tone issue. > /end small_print And, as long as you are offering, I'll say that I'm running the 1.2.60 code - as of the past couple of days, and it appears to be working great. I'll keep watching it close for the next few days, though.... | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Executive Vice President - Exec-PC, Inc. |

Subject: Re: (usr-tc) VJ Header Compression
From: Dan Hollis <goemon@sasami.anime.net>
Date: 1998-12-09 17:56:58

On Wed, 9 Dec 1998, Jeff Mcadams wrote: > Unless you're auth'ing with a login prompt before you start PPP, that's > too late. MTU is set during LCP, RADIUS information is returned during > PAP...LCP occurs before PAP. You would need to set it on the individual > ports I suspect is the best way to handle it. One wonders why such options as VJ and MTU are in radius at all then... -Dan

Subject: Re: (usr-tc) VJ Header Compression
From: Alan D. Criado <acriado@elink.net>
Date: 1998-12-09 18:46:58

At 12:53 PM 12/9/98 -0800, you wrote: >On Wed, 9 Dec 1998, Alan D. Criado wrote: >> Hmmm. I have a WebTV customer who just signed on and is having trouble >> getting connected with us. The WebTV people said that was neccessary that >> VJ Compression be turn on and that the MTU be 1500 and the MRU be 1500 or >> higher. > >With WebTV, vj isnt the problem, MTU is. WebTV's proxy servers are running >an ancient buggy version of solaris with completely broken path mtu. I >screamed at them about this over a year ago. > >Set your MTU to 1500 or higher and youll be ok. > >-Dan > Sounds good to me Dan. Where is the MTU setting configured? Thank you. Alan D. Criado

Subject: RE: (usr-tc) support woes
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-09 19:06:32

>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jesse Sipprell >Sent: Wednesday, December 09, 1998 12:07 PM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) support woes > > >On Wed, Dec 09, 1998 at 11:49:54AM -0600, Brian wrote: >> > >> > Man, this *really* sounds like lawsuit time. I've cc:'ed a few extra >> > people on this to try to draw some attention to it. >> > >> > We can't say that we've experienced this, but we are *extremely* >> > concerned, and have discussed the (at the time) rumours that we had >> > heard this was happening with several 3Com folks (conf call). At the >> > time I didn't have any confirmation that this was really happening, so >> > that's why I'm cc:'ing this a bit more as well...to let some of the >> > folks that I talked to on the conf call know about someone that this >> > really is happening to. >> >> It's very real. We have paid for legitimate support contracts in 1998 >> from 3Com. These support contracts were never honored. We >never received >> refunds for the money we spent on the contracts. >> >> We feel we are one of 3Com's best customers, we promote their >products and >> defend them on all the lists we can, even with the bad support >we receive. >> We have 14 HDM's, that's it. So thats 336 modems. We are a professional >> company, who wants to pay good money for good service. > >Heh. Just checked totalservice, and it looks like I am locked out >of all the >code now, even though I just bought a brand new chassis w/ 4 HDMs, >HARC, etc, >etc, *AND* a support contract. After reading this conversation, I am NOT >looking forward to talking with them. 3com, you are making a VERY VERY >serious mistake here. You need to go to totalservice and click on product registration and register your new product under your existing login name. Once that is done you will have access for at least 90 days to code upgrades for the chasis you purchased. Use the serial # on the side of the chassis near the power supplies for this. Once you have done that then contact your contract representative at 3COM and fax, if necessary, your proof of purchase of the contract. They will unlock the files for a year instead of 90 days. That's how it works. They don't havee everything set up to automatic yet, but it's getting there. You will need to also fax a receipt for each additional software package you purchased so they can include those files in your access list. Or you can register them one at a time under product registration on TotalService if you have serial #'s. They aren't trying to make this hard, there just isn't a perfect way of doing this yet. > >-- >Jesse Sipprell >Technical Operations Director >Evolution Communications, Inc. >800-496-4736 (ext 106) > >* Finger jss@evcom.net for my PGP Public Key * > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) support woes
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-12-09 19:35:13

Bob Purdon was heard to say: >> Technically, no. If you have a support contract for one chassis, then you >> have access to the firmware for every chassis you have. 3Com has no way of >> insuring you are not updating more than the chassis under contract. > >Unless I'm mistaken, Cisco manage it... Cisco takes your word for it... --Ricky

Subject: RE: (usr-tc) support woes
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-09 19:41:50

>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Bob Purdon >Sent: Wednesday, December 09, 1998 5:02 PM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) support woes > > > >> Technically, no. If you have a support contract for one >chassis, then you >> have access to the firmware for every chassis you have. 3Com >has no way of >> insuring you are not updating more than the chassis under contract. > >Unless I'm mistaken, Cisco manage it... They probably have a way of verifying the serial # of the router remotely. The 3COM chassis has no chip to store the serial # on. There is no way to remotely identify the serial # of the chassis itself. A serious mistake. We were told to verify all contracts, serial #'s, or warranties before providing support. How could we. We never knew what chassis we were working on. Even if we could find a list of serial #'s of cards that are supposed to be on the chassis there was no way to no if certain cards had been replaced by Logistics so it made no difference. I know the former manager of Level 1 at 3COM argued for a chip to be placed on the backplane of the chassis for identification purposes but he did not have enough pull, apparently, to get them to change the chassis design. Most people we talked to at 3COM agreed it would be smart but we never saw a thing come of it. Truth is, 3COM thinks they are getting ripped of by ISP's with dozens of chassis and 1 contract so they are trying to hold everyone accountable. One estimate I heard from the manager of contract admin about 8 months ago was about 50% loss of profit based on how many chassis they believed they were supporting without support contracts. Personally, I would be surprised if the figures were that good. I have seen dozen of very large customers who have only one contract with 3COM call in every single day with new problems, questions, concerns. After verifying with contract admin that there was only one chassis listed under the contract we knew the customer was "stealing" support. Anyway, just my .02 > >> Auditing an ISP is nearly impossible -- hardware is scattered >over hundreds >> of miles. Plus, who's to say the card died in the supported chassis; you >> can move cards around :-) > >When we took out our contract, they made us supply serial numbers of >everything we wanted covered... > >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. >

Subject: Re: (usr-tc) support woes
From: Greg Coffey <greg@coffey.com>
Date: 1998-12-09 19:57:22

Thanks for some words of insight from the other side. Would be nice to hear some feedback from someone currently at 3Com, they remain strangely silent on the topic. We have 3 units and one contract. All have netservers and I don't intend to upgrade to the hyper cards. I think we've accessed tech support maybe 1-2 times a year. Based on that, I think its a ripoff for me and one sweet deal for 3Com. Its like my dialup customers. I make my money off the majority that use the system a couple of hours a week and we never hear from. I have some that abuse the system either by hogging lines or tech support time. I also monitor that and occasionally run off some of the very abusive ones. Maybe 3Com should do the same. I don't like being punished because someone else abuses the system. My experience with 3Com has been usually pretty miserable going through the tech support route. Tough for me to believe that an ISP is calling daily with new problems. I couldn't stand the hold time. Surely, the ISP is on the way out if he is spending that much time with problems/downtime. I have gotten some good results with some direct email with John Powell regarding some issues. I'm glad to see that he has become a regular to the mail list. At 08:51 PM 12/9/98 -0500, you wrote: >Thus spake Brian K McIntire >>Truth is, 3COM thinks they are getting ripped of by ISP's >>with dozens of chassis and 1 contract so they are trying to hold everyone >>accountable. > >Oh, I'm sure this does happen, but if the support contract prices >weren't so *TOTALLY* outrageous, it wouldn't happen *nearly* as much. >-- >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. > > 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

Subject: Re: (usr-tc) support woes
From: Dan Hollis <goemon@sasami.anime.net>
Date: 1998-12-09 20:05:05

On Wed, 9 Dec 1998, Charles Sprickman wrote: > On Wed, 9 Dec 1998, Ricky Beam wrote: > > Bob Purdon was heard to say: > > >Unless I'm mistaken, Cisco manage it... > > Cisco takes your word for it... > And that's why I feel confident recommending their products to people. > Sure, some of the stuff is a bit overpriced, and they've released some > crappy software, but at least I know that if I have an issue for a 2501 > w/no contract but my 7200 is covered I can go grab a version of software > that will fix things without hassling the support people. Cisco emergency bugfix IOS releases are free for customers with or without support contracts (as long as you get the IOS with the same feature set). Theres a reason Cisco is #1. Of course Cisco has been at this a long time and has the battle scars. -Dan

Subject: Re: (usr-tc) VJ Header Compression
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-12-09 20:47:42

Thus spake Dan Hollis >On Wed, 9 Dec 1998, Alan D. Criado wrote: >> >With WebTV, vj isnt the problem, MTU is. WebTV's proxy servers are running >> >an ancient buggy version of solaris with completely broken path mtu. I >> >screamed at them about this over a year ago. >> >Set your MTU to 1500 or higher and youll be ok. >> Sounds good to me Dan. Where is the MTU setting configured? >In the radius profile. Unless you're auth'ing with a login prompt before you start PPP, that's too late. MTU is set during LCP, RADIUS information is returned during PAP...LCP occurs before PAP. You would need to set it on the individual ports I suspect is the best way to handle it. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) support woes
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-12-09 20:51:31

Thus spake Brian K McIntire >Truth is, 3COM thinks they are getting ripped of by ISP's >with dozens of chassis and 1 contract so they are trying to hold everyone >accountable. Oh, I'm sure this does happen, but if the support contract prices weren't so *TOTALLY* outrageous, it wouldn't happen *nearly* as much. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) support woes
From: Allen Marsalis <am@shreve.net>
Date: 1998-12-09 20:56:27

At 07:41 PM 12/9/98 -0600, Brian K McIntire wrote: >Truth is, 3COM thinks they are getting ripped of by ISP's >with dozens of chassis and 1 contract so they are trying to hold everyone >accountable. Now there's a good joke. We lease a chassis and pay an extra $2K for a support contract (with interest).. 9 months later, we are told that we will be given a $500 credit on our next 4 chassis purchases! We may have purchased a support contract, but in effect, we have given 3COM a loan for a year and we are paying the interest! Combine this sort of nonsense with the profits that USR/3COM made off of us on Quake lag.. *and* add in the fact that we just want code to fix memory leaks, etc., and I think it's the ISP's who are getting ripped off. By the time they get around to fixing something, it's usually too late for us, and we have already found another solution or way around it. My latest thought is to cron a job to reset all ARC's at 3am once a week before the memory leak gets critical.. pretty pathetic solution actually.. but probably just as effective as the support contract would have been.. Allen

Subject: RE: (usr-tc) support woes
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-09 21:19:38

>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams >Sent: Wednesday, December 09, 1998 7:52 PM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) support woes > > >Thus spake Brian K McIntire >>Truth is, 3COM thinks they are getting ripped of by ISP's >>with dozens of chassis and 1 contract so they are trying to hold everyone >>accountable. > >Oh, I'm sure this does happen, but if the support contract prices >weren't so *TOTALLY* outrageous, it wouldn't happen *nearly* as much. Of course the other side of the coin is the contracts wouldn't be so high if there wern't so many people "stealing" service. Out of my hands. Oh well >-- >Jeff McAdams Email: jeffm@iglou.com >Head Network Administrator Voice: (502) 966-3848 >IgLou Internet Services (800) 436-4456 > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) VJ Header Compression
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-12-09 21:20:10

Thus spake Dan Hollis >On Wed, 9 Dec 1998, Jeff Mcadams wrote: >> Unless you're auth'ing with a login prompt before you start PPP, that's >> too late. MTU is set during LCP, RADIUS information is returned during >> PAP...LCP occurs before PAP. You would need to set it on the individual >> ports I suspect is the best way to handle it. >One wonders why such options as VJ and MTU are in radius at all then... I would think primarily because of the qualification that I put at the beginning "Unless you're auth'ing with a login prompt before you start PPP," which would allow you to set the MTU in PPP when PPP *is* started. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) support woes
From: Allen Marsalis <am@shreve.net>
Date: 1998-12-09 21:33:48

At 10:00 PM 12/9/98 -0500, Charles Sprickman wrote: >On Wed, 9 Dec 1998, Ricky Beam wrote: > >> Bob Purdon was heard to say: >> >Unless I'm mistaken, Cisco manage it... >> >> Cisco takes your word for it... > >And that's why I feel confident recommending their products to people. >Sure, some of the stuff is a bit overpriced, and they've released some >crappy software, but at least I know that if I have an issue for a 2501 We made both of these purchases approx 24 months ago: Fair Market Price Now 12mos ago 24mos ago Cisco 2501 $1100 $1500 $2300 USR 1706 $5000 $18000 $32000 I think the feeling people have about Cisco and the utility and lifespan of their products is reflected in what people will pay for them. In other words, there are many reasons to provide good support and *sales* is number one.. >w/no contract but my 7200 is covered I can go grab a version of software >that will fix things without hassling the support people. Am I stealing? >Well, I don't go get the super-firewall version if the router came with >IPPlus... And generally if you call them with an emergency, they will >help you, contract or not. They airdropped a new router to one of our >customers recently, even though they had no such contract. Made for a >very happy customer that will buy more of their stuff. It's the hardware >that should generate the $$. know what you mean.. We own a Cisco fasthub that we have had for over a year with no contract ever. We recently noticed a problem that we considered a defect in design and with only one phone call, they shipped us a new unit before we even returned our old unit so we wouldn't be down.. They trusted us. Incidents like this does influence our decision to purchase Cisco with confidence in the future.. They have earned that confidence and it's worth $$$ to them.. I purchase USR/3COM with considerable more reluctance, and only for their modems.. I'll buy a Yugo before _attempting_ to buy another 3COM support contract. I guess the lack of trust on the subject is now mutual.. Allen

Subject: Re: (usr-tc) VJ Header Compression
From: John Powell <jp@packet.ae.usr.com>
Date: 1998-12-09 21:40:48

Actually, the best place to set it is at the client side! As I am sure most of you know better than I do, no one value is best for everyone. A value that is good for downloading lots of JPGs is not all that good for gaming, etc. As ISPs, you obviously would not want the administrative hassle of custom setting this for everyone individually. If I were designing an IP stack I would have radio-buttons right on the popup ID/Password screen that allow you to identify what you plan to be doing that session (gaming, surfing, downloading big files, telnet, etc.) and set optimized values for these parameters based on the selection. Obviously one would need to have a compromise "middle of the road" value as default, but it would be very slick if the user had the option (perhaps in an "advanced" dialog box) on a session by session basis of selecting the values. BTW, don't get me wrong, I do see some value in the ability to suggest a default value from the head-end for some more specialized applications. Just my 2 cents. JP On Wed, 9 Dec 1998, Jeff Mcadams wrote: > Thus spake Dan Hollis > >On Wed, 9 Dec 1998, Jeff Mcadams wrote: > >> Unless you're auth'ing with a login prompt before you start PPP, that's > >> too late. MTU is set during LCP, RADIUS information is returned during > >> PAP...LCP occurs before PAP. You would need to set it on the individual > >> ports I suspect is the best way to handle it. > > >One wonders why such options as VJ and MTU are in radius at all then... > > I would think primarily because of the qualification that I put at the > beginning "Unless you're auth'ing with a login prompt before you start > PPP," which would allow you to set the MTU in PPP when PPP *is* started. > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) dspInterruptTimeout
From: Bob Purdon <bobp@southcom.com.au>
Date: 1998-12-09 21:40:58

Hi All, Anyone know what a 'dspInterruptTimeout' call failure reason means? It was taking calls OK, but now sounds like a strangled fax machine when it answers, and fails EVERY call... If it means foobared hardware then I'll be really pissed, as this'll be 2 out of 4 dead quad cards so far, and this one is a 400 mile round trip away. It refused to take 'nic' or 't1' as the line type (reverted back instantly), refused to accept an 'n:5' on the PRI card, accepted an 'out of service', but then took calls anyway, and generally didn't want to be disabled. In the end I had to abort a flash and reboot the PRI card before it'd sit up and take notice that I didn't want the card used... Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Subject: Re: (usr-tc) support woes
From: Brian <signal@shreve.net>
Date: 1998-12-09 21:45:45

On Thu, 10 Dec 1998, Bob Purdon wrote: > > > Technically, no. If you have a support contract for one chassis, then you > > have access to the firmware for every chassis you have. 3Com has no way of > > insuring you are not updating more than the chassis under contract. > > Unless I'm mistaken, Cisco manage it... nope. Cisco is on the honor system. Once you have a CCO account, you can download all kinds of stuff, not just what your contract covers. > > > Auditing an ISP is nearly impossible -- hardware is scattered over hundreds > > of miles. Plus, who's to say the card died in the supported chassis; you > > can move cards around :-) > > When we took out our contract, they made us supply serial numbers of > everything we wanted covered... > > 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. > 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

Subject: RE: (usr-tc) support woes
From: Brian <signal@shreve.net>
Date: 1998-12-09 21:47:58

> > You need to go to totalservice and click on product registration and > register your new product under your existing login name. Once that is done > you will have access for at least 90 days to code upgrades for the chasis > you purchased. Use the serial # on the side of the chassis near the power > supplies for this. Once you have done that then contact your contract > representative at 3COM and fax, if necessary, your proof of purchase of the > contract. They will unlock the files for a year instead of 90 days. That's > how it works. They don't havee everything set up to automatic yet, but it's > getting there. You will need to also fax a receipt for each additional > software package you purchased so they can include those files in your > access list. Or you can register them one at a time under product > registration on TotalService if you have serial #'s. They aren't trying to > make this hard, there just isn't a perfect way of doing this yet. I will give it a shot. Brian > > > >-- > >Jesse Sipprell > >Technical Operations Director > >Evolution Communications, Inc. > >800-496-4736 (ext 106) > > > >* Finger jss@evcom.net for my PGP Public Key * > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and 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

Subject: Re: (usr-tc) VJ Header Compression
From: Charles Sprickman <spork@inch.com>
Date: 1998-12-09 21:55:43

On Wed, 9 Dec 1998, Dan Hollis wrote: > On Wed, 9 Dec 1998, Jeff Mcadams wrote: > > Unless you're auth'ing with a login prompt before you start PPP, that's > > too late. MTU is set during LCP, RADIUS information is returned during > > PAP...LCP occurs before PAP. You would need to set it on the individual > > ports I suspect is the best way to handle it. > > One wonders why such options as VJ and MTU are in radius at all then... I'm confused. On a Cisco, I have two MTU settings. One is at the interface level, and one is at the IP level. Is there a "PPP MTU" and an "IP MTU"??? I need a book... Charles > > -Dan > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) support woes
From: Brian <signal@shreve.net>
Date: 1998-12-09 21:56:09

On Wed, 9 Dec 1998, Allen Marsalis wrote: > At 10:00 PM 12/9/98 -0500, Charles Sprickman wrote: > >On Wed, 9 Dec 1998, Ricky Beam wrote: > > > >> Bob Purdon was heard to say: > >> >Unless I'm mistaken, Cisco manage it... > >> > >> Cisco takes your word for it... > > > >And that's why I feel confident recommending their products to people. > >Sure, some of the stuff is a bit overpriced, and they've released some > >crappy software, but at least I know that if I have an issue for a 2501 > > We made both of these purchases approx 24 months ago: > > Fair Market Price Now 12mos ago 24mos ago > > Cisco 2501 $1100 $1500 $2300 > USR 1706 $5000 $18000 $32000 let me add some to that: Bugs found/encountered in code during 24months: Cisco 2501 (IOS 11.x) 0 USR 1706 20 (give or take) Crashes Cisco 2501 (IOS 11.x) 0 USR 1706 20 (give or take) Now don't get me wrong, I know the codebase is new comparitivly, and i like the way things are moving in development at 3Com. The engineers/developers seem to really have vision and I feel are doing a great job. My problem is more of a political one, and with contracts. 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

Subject: Re: (usr-tc) support woes
From: Charles Sprickman <spork@inch.com>
Date: 1998-12-09 22:00:21

On Wed, 9 Dec 1998, Ricky Beam wrote: > Bob Purdon was heard to say: > >Unless I'm mistaken, Cisco manage it... > > Cisco takes your word for it... And that's why I feel confident recommending their products to people. Sure, some of the stuff is a bit overpriced, and they've released some crappy software, but at least I know that if I have an issue for a 2501 w/no contract but my 7200 is covered I can go grab a version of software that will fix things without hassling the support people. Am I stealing? Well, I don't go get the super-firewall version if the router came with IPPlus... And generally if you call them with an emergency, they will help you, contract or not. They airdropped a new router to one of our customers recently, even though they had no such contract. Made for a very happy customer that will buy more of their stuff. It's the hardware that should generate the $$. Charles > > --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. >

Subject: Re: (usr-tc) VJ Header Compression
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-12-09 22:18:09

Thus spake Charles Sprickman >On Wed, 9 Dec 1998, Dan Hollis wrote: >> On Wed, 9 Dec 1998, Jeff Mcadams wrote: >> > Unless you're auth'ing with a login prompt before you start PPP, that's >> > too late. MTU is set during LCP, RADIUS information is returned during >> > PAP...LCP occurs before PAP. You would need to set it on the individual >> > ports I suspect is the best way to handle it. >> One wonders why such options as VJ and MTU are in radius at all then... >I'm confused. On a Cisco, I have two MTU settings. One is at the >interface level, and one is at the IP level. Is there a "PPP MTU" and an >"IP MTU"??? I need a book... IP doesn't have an MTU. The MTU is determined by the physical media and layer 2 protocol that is being used. Ethernet, for example has a 1500 MTU. Token-Ring can do...what is it? 4096 at least, maybe more, for its MTU. IP will take advantage of whatever the layer 2 MTU is. Keep in mind though that IP has end-to-end issues to deal with, so if you're routing over a token-ring connection onto an ethernet network, you won't see any of those frames being bigger than 1500...or they won't get to the destination...or they'll get fragmented along the way. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) support woes
From: K Mitchell <mitch@keyconn.net>
Date: 1998-12-09 22:19:43

At 09:19 PM 12/9/98 -0600, Brian K McIntire wrote: >>Oh, I'm sure this does happen, but if the support contract prices >>weren't so *TOTALLY* outrageous, it wouldn't happen *nearly* as much. > >Of course the other side of the coin is the contracts wouldn't be so high if >there wern't so many people "stealing" service. Or maybe if they'd quit putting out such bug-ridden code, they'd get less calls and their support overhead would drop. My 1(one) chassis is 8 months old and has been upgraded 4 or 5 times. Each time something has bit me in the ass. $2k plus a year to talk to idiots hasn't helped. I've only called into 3Com support twice, and I'd classify the knowledge at the other end marginal at best. At $1k per call, I should have a freaking guru at the other end, and a christmas card to boot. I'm also curious as to why 3Com feels that, after paying over $10k for a chassis, I need to pay more for a poorly working RADIUS server to authenticate users into it. From my standpoint, 3Coms' hardware people are doing a top-notch job but, aside from Krish and a few others on this list, the rest of the company is determined to sell me a PM-3 JM2C, YMMV, Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

Subject: Re: (usr-tc) support woes
From: Ronald E. Kushner <ron@glis.net>
Date: 1998-12-09 22:22:48

> >Thus spake Brian K McIntire > >>Truth is, 3COM thinks they are getting ripped of by ISP's > >>with dozens of chassis and 1 contract so they are trying to hold everyone > >>accountable. > > > >Oh, I'm sure this does happen, but if the support contract prices > >weren't so *TOTALLY* outrageous, it wouldn't happen *nearly* as much. > > Of course the other side of the coin is the contracts wouldn't be so high if > there wern't so many people "stealing" service. I think there's the basic conflict between a company who sees the bottom line being damaged, and the Internet/hacker community that believe information/software/whatever wants to be free... I always laugh out loud at DefCon when I hear someone spew some crap like that.. I owned a Total Control bundle for about a year and a half before I had to call for service, and it was when I switched from CAS to PRI, analog calls were not being routed to the modems. I saved $6,000 in contacts, and paid the $200 per incident to find out there was a setting in the quads for where the modems would get their timing from (T1 bus or PRI).. Well worth $200 to find this out. 3Com definitely needs to revamp their contracts, to cover a HiPer chassis fully populated costs far more than what it costs to cover other equipment being sold out there. I have pricing from Bay Networks here on their 5000/5399 product, it's $2,400 for 1 year software, 1 year 24x7 telephone support, NBD hardware replacement on chassis and up to 4 5399 cards(192 modem ports). From what I can tell from this confusing price list from Source, similar coverage on a 3Com chassis lists for $3,161 for "base," and $598 for each additional card - whatever that means. So as I read it if you had a 192 port HiPer chassis it would run you $9141 a year. That's knock your socks off kind of outrageous. But a major corporation would think nothing of spending that kind of money on a support contract. I run my company like a mom & pop business that watches every penny. Don't forget there are 3rd party service companies out there that do it all for much less. If you want the 3Com service, you will pay a premium for it. And here is some food for thought. On the Bay Networks web site, they have the latest software for the RAC 8000 and the RAC 5399 open to the public. Anyone can download the software, unrestricted. No games. -Ron GLISnet, Inc. +1 810/939.9885

Subject: RE: (usr-tc) support woes
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-09 22:41:14

>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Charles Sprickman >Sent: Wednesday, December 09, 1998 9:00 PM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) support woes > > > >On Wed, 9 Dec 1998, Ricky Beam wrote: > >> Bob Purdon was heard to say: >> >Unless I'm mistaken, Cisco manage it... >> >> Cisco takes your word for it... > >And that's why I feel confident recommending their products to people. >Sure, some of the stuff is a bit overpriced, and they've released some >crappy software, but at least I know that if I have an issue for a 2501 >w/no contract but my 7200 is covered I can go grab a version of software >that will fix things without hassling the support people. Am I stealing? >Well, I don't go get the super-firewall version if the router came with >IPPlus... And generally if you call them with an emergency, they will >help you, contract or not. They airdropped a new router to one of our >customers recently, even though they had no such contract. Made for a >very happy customer that will buy more of their stuff. It's the hardware >that should generate the $$. Kind of depends on the market i would think. 3COM has had to compete harder and harder on their hardware prices. Much less margin in it than there used to be. > >Charles > >> >> --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. >

Subject: RE: (usr-tc) support woes
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-09 23:03:41

>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of K Mitchell >Sent: Wednesday, December 09, 1998 9:20 PM >To: usr-tc@lists.xmission.com >Subject: RE: (usr-tc) support woes > > >At 09:19 PM 12/9/98 -0600, Brian K McIntire wrote: >>>Oh, I'm sure this does happen, but if the support contract prices >>>weren't so *TOTALLY* outrageous, it wouldn't happen *nearly* as much. >> >>Of course the other side of the coin is the contracts wouldn't be >so high if >>there wern't so many people "stealing" service. > > Or maybe if they'd quit putting out such bug-ridden code, they'd get less >calls and their support overhead would drop. My 1(one) chassis is 8 months >old and has been upgraded 4 or 5 times. Each time something has bit me in >the ass. $2k plus a year to talk to idiots hasn't helped. Hold on. They aren't all bad. There has been a lot of turbulence since 3COM bought USR. There have been a lot of changes with more to come. They have added a tremendous number of people to the front lines. I know for a fact they are working to make sure they are all trained better. You should at least take in to consideration 3COM's efforts to make things better. >into 3Com support twice, and I'd classify the knowledge at the other end >marginal at best. At $1k per call, I should have a freaking guru at the >other end, and a christmas card to boot. I'm also curious as to why 3Com >feels that, after paying over $10k for a chassis, I need to pay more for a >poorly working RADIUS server to authenticate users into it. This is a marketing complaint. 3COM does not have the margin they used to in the hardware to constantly revamp and add features to all software for free. Like any other company they need to make sure each piece of the puzzle is making money. Yes, the HiPer ARC and HiPer DSP's have had a lot of problems. They have also added a lot of features to an otherwise antiquated product line. No one rights perfect code. They have a lot to contend with. Once they get the code running smoothly I believe we will see the software as steady as Ciscos's. Or at least close. That's my .02 anyway > From my standpoint, 3Coms' hardware people are doing a top-notch job but, >aside from Krish and a few others on this list, the rest of the company is >determined to sell me a PM-3 > >JM2C, YMMV, >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. >

Subject: RE: (usr-tc) support woes
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-09 23:14:12

>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Dan Hollis >Sent: Wednesday, December 09, 1998 10:05 PM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) support woes > > >On Wed, 9 Dec 1998, Charles Sprickman wrote: >> On Wed, 9 Dec 1998, Ricky Beam wrote: >> > Bob Purdon was heard to say: >> > >Unless I'm mistaken, Cisco manage it... >> > Cisco takes your word for it... >> And that's why I feel confident recommending their products to people. >> Sure, some of the stuff is a bit overpriced, and they've released some >> crappy software, but at least I know that if I have an issue for a 2501 >> w/no contract but my 7200 is covered I can go grab a version of software >> that will fix things without hassling the support people. If I'm not mistaken ins't that what Krish and John have been helping you with on this list? Making ER code available to all that need it. Am I wrong? Besides, as we all know the code is new on the products most of us are concerned about. 3COM needs to understand how and why it is failing for many of us; to learn more quickly how to make it better for all of us. Blindly posting fixes does not allow for that kind of interaction. Another .02. I'm at .06 or .08 now. :0 > >Cisco emergency bugfix IOS releases are free for customers with or without >support contracts (as long as you get the IOS with the same feature set). > >Theres a reason Cisco is #1. Of course Cisco has been at this a long time >and has the battle scars. > >-Dan > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) support woes
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-12-09 23:20:02

On Wed, 9 Dec 1998, Brian wrote: > let me add some to that: > > Bugs found/encountered in code during 24months: > > Cisco 2501 (IOS 11.x) 0 > USR 1706 20 (give or take) There was a pretty bad security hole (or two?) in IOS 11.something a few months ago... just to be totally fair. :) The one I remember involved someone being able to telnet to the router and get the command history for the last console user without actually logging into the router. There's also a really obnoxious and obscure problem with IP tunneling, MTU sizes, and MTU path discovery on any IOS 11.x rev. The REAL problem is that a lot of sites are stupidly blocking ALL ICMP at their routers now (out of fear of DoS attacks). This causes MTU Path Discovery to break very very very badly. If you access such a paranoid site from a client whose MTU is set to anything under about 1480, the connection will open, and then 'hang' because your client's request for the server to fragment the packet down to the client's MTU size never gets to it, because the request is ICMP based... (So if you have any problems with your users getting "stuck" browsing certain web sites, check their MTU. And if you're blocking all ICMP at your router... don't!!) Anyway... on Cisco IOS 11.x, if you run a tunneled IP-over-IP connection, the effective MTU on the tunneled link drops to about 1460, because the tunneling adds about that much overhead. It also honors the "don't fragment" bit set in the packet being tunneled. The net result is that even with the MTU set to 1500 on both ends, connections to one of these paranoid sites hang through a tunneled link like this. My upstream at home (not my ISP; I live a long distance call from it) was tunneling IP between two 2501's to work around some Ascend Max braindamage and we were scratching our heads for 3 weeks until we finally got tcpdump out and found this. It had been working fine until he upgraded from IOS 10.3 to IOS 11.1. On IOS 10.3, you can set the MTU on the tunnel to 1540 to work around this problem. On 11.x, you can't. He got a bug ID assigned to it... don't know if 12.0 fixed it. Now don't get me wrong, I'm not real thrilled about all the 3com bugs I've had to work around either (and I'm about to post another in a second)... just felt like playing devil's advocate tonight. ;-) Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ # view;touch;unzip;finger;mount;mv;mv;mv;yes;mv;yes;mv;yes;umount;sleep

Subject: (usr-tc) Comparative review of Cisco AS5300
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1998-12-09 23:20:29

Howdy, all. I'd just like to present a brief comparative review of my experience with another NAS product, the Cisco AS5300. Almost all of my experience with remote-access equipment has been with Total Control hubs. If there are others out there like me, this information might be useful. Our reasons for exploring beyond the wonderful, magical world of 3Com NASsen are many. Cisco is offering trade in credit toward their line of Universal Access Servers, and have given us >$150/port for a chassis with quad modems, an HDM, and a Netserver. My experience ~~~~~~~~~~~~~~ We received our AS5300 and immediately started reading. It's a mighty beast, with an R-4700 CPU, 64 megabytes of memory, 12 megabytes of flash, and three cards. One of the cards provides four T1 controllers that can be setup for any type of channelized T1 or PRI. The other two cards provide the modem modules; each modem module is mounted on a SIMM-type socket, and can terminate four calls. None of the cards are hot-swappable; I don't like that. I understand that ours was a typical AS5300, providing one 10Base-T ethernet port and one 100Base-TX ethernet port. It runs Cisco's standard routing operating system, IOS, which can be upgraded. In our case, we have four E&M Type II FGB T1s terminated on it. Here's how it seems to work: when a call comes in, the CSM (call switching module, I believe) routes the call to a particular modem. Through the interactive IOS command-line interface, extensive statistics on modem performance history are available, as well as information about current calls, and the status of modems still in use. Everything about the unit, AFAIK, can be managed through the one interface. (One of the bad characteristics of the TC unit, as far as we were concerned, was that there were so many different ways to manage stuff. TCM is one of those ways, but it certainly doesn't do everything.) The unit ships with extensive documentation on a cdrom, but I've much enjoyed the documentation available in printed form from Cisco Press, including the book Cisco IOS Dial Solutions (A *major*, *extreme*, *incredibly huge* annoyance about the Total Control equipment was the lack of thorough, precise, comprehensive documentation. Cisco apparently has a giant department of technical writers, and I have thoroughly enjoyed their output.) We also purchased a `SmartNet' contract with our AS5300, which provides 24/7 access to Cisco's legendary Technical Assistance Center (TAC), and access to Cisco Connection Online. CCO provides an incredible amount of searchable documentation, as well as access to the latest software revisions. Whereas the router itself runs IOS, there is a separate `portware' for the modems. (This corresponds roughly to the distinct images for different devices in the TC system.) The AS5300 is also a bit more generally useful than TC systems that I have observed; that is, providing dialup remote access is just one of the many things you can do with it. Configuring it did take me some time, because you not only have to state (via the configuration language) what you want to do (e.g., provide dialin service via PPP with PAP authentication using RADIUS authentication and accounting assigning IP addresses from a local pool), but also the specific parameters. Netservers and the HARC seem to lack that flexibility. Cisco Corporation has some interesting characteristics, visible through CCO. For example, they track bugs vigorously; in the setup process, I found that IOS didn't correctly parse hostnames like 4.auth.datasys.net. because of the leading digit. When I commented about that on a list for discussion of the AS5300 and AS5200, as5200@wwa.com, a Cisco engineer immediately recognized my concern and recorded it as a bug. The bug was assigned an ID, and I can track its progress through Cisco's development cycle, using CCO. In summary, good, important things that I've noticed about the AS5300 include * built like a router, because access servers *are* routers * excellent documentation * nice integration of parts * excellent operating system, with a comfortable interface * excellent support (so far) and bads things include * relatively low density -- only 4 T1s per chassis * a lack of blinky lights to let us know what's happening * no nifty toolkit I'll be happy to expand on anything I've said here more; just ask for details. Some examples ~~~~~~~~~~~~~~ It's probably true that most or all of the information available via the IOS CLI is available via USR enterprise MIBs via SNMP with TC systems, but that's really an inconvenient way for us to work. Here, for example, is information from the "show modem operational-status" command: Modem(2/29) Operational-Status: Parameter #0 Disconnect Reason Info: (0x0) Type (=0 ): <unknown> Class (=0 ): Other Reason (=0 ): no disconnect has yet occurred Parameter #1 Connect Protocol: LAP-M Parameter #2 Compression: V.42bis both Parameter #3 EC Retransmission Count: 68 Parameter #4 Self Test Error Count: 0 Parameter #5 Call Timer: 2142 secs Parameter #6 Total Retrains: 20 Parameter #7 Sq Value: 3 Parameter #8 Connected Standard: V.90 Parameter #9 TX,RX Bit Rate: 46666, 28800 Parameter #11 TX,RX Symbol Rate: 8000, 3200 Parameter #13 TX,RX Carrier Frequency: 0, 1829 Parameter #15 TX,RX Trellis Coding: 0, 16 Parameter #16 TX,RX Preemphasis Index: 0, 6 Parameter #17 TX,RX Constellation Shaping: Off, Off Parameter #18 TX,RX Nonlinear Encoding: Off, Off Parameter #19 TX,RX Precoding: Off, Off Parameter #20 TX,RX Xmit Level Reduction: 0, 0 dBm Parameter #21 Signal Noise Ratio: 36 dB Parameter #22 Receive Level: -17 dBm Parameter #23 Frequency Offset: 0 Hz Parameter #24 Phase Jitter Frequency: 0 Hz Parameter #25 Phase Jitter Level: 0 degrees Parameter #26 Far End Echo Level: -37 dBm Parameter #27 Phase Roll: 0 degrees Parameter #28 Round Trip Delay: 3 msecs Parameter #30 Characters transmitted, received: 178566, 37195 Parameter #32 Characters received BAD: 5 Parameter #33 PPP/SLIP packets transmitted, received: 879, 980 Parameter #35 PPP/SLIP packets received (BAD/ABORTED): 0 Parameter #36 EC packets transmitted, received OK: 2365, 1545 Parameter #38 EC packets (Received BAD/ABORTED): 68 Parameter #39 Robbed Bit Signalling (RBS) pattern: 0 Parameter #40 Digital Pad: 4.500 dB, Digital Pad Compensation: None Line Shape: ..........................* ................................* .................................* .................................* ................................* ................................* .................................* ................................* .................................* .................................* ................................* ................................* .................................* ................................* ................................* ................................* ................................* ................................* ................................* ................................* ................................* ................................* ...............................* ...............................* ...............................* ...............................* ..............................* ..............................* .............................* ...........................* ......................*

Subject: Re: (usr-tc) support woes
From: Jesse Sipprell <jss@evcom.net>
Date: 1998-12-09 23:21:35

On Wed, Dec 09, 1998 at 10:41:14PM -0600, Brian K McIntire wrote: > >-----Original Message----- > >From: owner-usr-tc@lists.xmission.com > >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Charles Sprickman > >Sent: Wednesday, December 09, 1998 9:00 PM > >To: usr-tc@lists.xmission.com > >Subject: Re: (usr-tc) support woes > > > > > > > >On Wed, 9 Dec 1998, Ricky Beam wrote: > > > >> Bob Purdon was heard to say: > >> >Unless I'm mistaken, Cisco manage it... > >> > >> Cisco takes your word for it... > > > >And that's why I feel confident recommending their products to people. > >Sure, some of the stuff is a bit overpriced, and they've released some > >crappy software, but at least I know that if I have an issue for a 2501 > >w/no contract but my 7200 is covered I can go grab a version of software > >that will fix things without hassling the support people. Am I stealing? > >Well, I don't go get the super-firewall version if the router came with > >IPPlus... And generally if you call them with an emergency, they will > >help you, contract or not. They airdropped a new router to one of our > >customers recently, even though they had no such contract. Made for a > >very happy customer that will buy more of their stuff. It's the hardware > >that should generate the $$. > > Kind of depends on the market i would think. 3COM has had to compete harder > and harder on their hardware prices. Much less margin in it than there used > to be. And Cisco doesn't have competition in their market? The way to be top dog in an open market is to offer superior technology AND superior support. This is what allows Cisco to charge a premium for their products and still ensure that customers will keep coming back for more. Initial product price slashing and gouging on the support side is a short sighted technique and won't build long term customer loyalty (and thus long term revenue). How many of you out there would rather pay more for your initial investment and not have to worry about support issues later? -- Jesse Sipprell Technical Operations Director Evolution Communications, Inc. 800-496-4736 (ext 106) * Finger jss@evcom.net for my PGP Public Key *

Subject: (usr-tc) NETservers and chat scripts
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-12-09 23:29:55

As promised, here's a problem I'm having. :) We have problems with users dialing into the NETservers (3.7.24) and logging in using a chat script. In other words, they actually type their username and password in at the NETserver's "login:" prompt after connecting. The NETserver then starts PPP on them (because their Radius entry specifies "Framed-Protocol = PPP"), but something doesn't get negotiated correctly. It seems that different options get negotiated this way; maybe it skips PAP or something, I don't know, I haven't traced it down 100% yet. (Hence my earlier question about taplogin on NETservers being screwy... I'm trying to cook up a better PPP negotiation debugger.) The ARC (4.1.72) doesn't seem to care; he can get on just fine, chat script or not. It seems to be OS-independent. Some Win95 people that have tried this can connect, get an IP address, but DNS fails miserably. On 95/98 it's easy to fix of course; just go into the DUN settings and turn scripting off. The guy I'm dealing with now has an SGI O2 running Irix 6.x. I think he can fix this by manually editing /etc/uucp/Systems or something similar (anyone with an SGI know offhand? I'm a FreeBSD person)... but still, why would it work with it as-is on an ARC and not on a NETserver? It'd be nice if I could get him to just dial the ARC every time, instead of our 2 NETservers, but Bellsouth says they can't set our PRI's up that way, or at least seemed extremely confused when I asked. (We need CLECs here, and we need them yesterday. :-) Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ # view;touch;unzip;finger;mount;mv;mv;mv;yes;mv;yes;mv;yes;umount;sleep

Subject: Re: (usr-tc) support woes
From: Jesse Sipprell <jss@evcom.net>
Date: 1998-12-09 23:34:36

On Wed, Dec 09, 1998 at 09:33:48PM -0600, Allen Marsalis wrote: > At 10:00 PM 12/9/98 -0500, Charles Sprickman wrote: > >On Wed, 9 Dec 1998, Ricky Beam wrote: > > > >> Bob Purdon was heard to say: > >> >Unless I'm mistaken, Cisco manage it... > >> > >> Cisco takes your word for it... > > > >And that's why I feel confident recommending their products to people. > >Sure, some of the stuff is a bit overpriced, and they've released some > >crappy software, but at least I know that if I have an issue for a 2501 > > We made both of these purchases approx 24 months ago: > > Fair Market Price Now 12mos ago 24mos ago > > Cisco 2501 $1100 $1500 $2300 > USR 1706 $5000 $18000 $32000 > > I think the feeling people have about Cisco and the utility and lifespan > of their products is reflected in what people will pay for them. In > other words, there are many reasons to provide good support and *sales* > is number one.. Absolutely. I think 3com is actually under-pricing TCRs in an attempt to grab rapid market share from Lucent, and then jacking up support costs on the post-sale end to cover their profits. Bad move, VERY bad move. I, for one, would prefer to pay MORE for the chassis/HARCs up front (I actually like the HARC better than the pm3, purely from a technical perspective, at this point -- and so does our tech support department). -- Jesse Sipprell Technical Operations Director Evolution Communications, Inc. 800-496-4736 (ext 106) * Finger jss@evcom.net for my PGP Public Key *

Subject: Re: (usr-tc) support woes
From: Ronald E. Kushner <ron@glis.net>
Date: 1998-12-09 23:38:25

Brian K McIntire wrote: > > > Or maybe if they'd quit putting out such bug-ridden code, they'd get less > >calls and their support overhead would drop. My 1(one) chassis is 8 months > >old and has been upgraded 4 or 5 times. Each time something has bit me in > >the ass. $2k plus a year to talk to idiots hasn't helped. > > This is a marketing complaint. 3COM does not have the margin they used to > in the hardware to constantly revamp and add features to all software for > free. Like any other company they need to make sure each piece of the > puzzle is making money. Yes, the HiPer ARC and HiPer DSP's have had a lot > of problems. They have also added a lot of features to an otherwise > antiquated product line. No one rights perfect code. They have a lot to > contend with. Once they get the code running smoothly I believe we will see > the software as steady as Ciscos's. Or at least close. That's my .02 > anyway The Netservers never worked all that well, but it's transparent to the end user alot of times. Alot of the problems are transparent to the end users. If you think you'll have better luck with a PM-3, try explaining to a customer why their Lucent modem will not connect to your Lucent PM-3. The US-Robotics modems are still the best modems out there. You know that Rockwell, Lucent, PCTel, etc, all test their new products to the Total Control. Even though everyone has different results in the field, I've had the best luck with connections into the Total Control. I replaced a Quad modem chassis with a HiPer chassis and did not have one complaint about not being able to connect, and the people who had problems with the old quads was, humm, maybe 5 out of 1,000... I get customers every day from other ISP's that use Lucent PM-3's, Ascend, Bay, Cisco... All because their V.90 modem (or worse, their V.34 modem) doesn't connect properly to their ISP since they upgraded to V.90. There are alot of issues involved, but alot of them have to do with local conditions of the customers loops and padding at the telco, SLC's, etc. The USR modems handle these varying conditions the best out of everything I have tried. I think 3Com's biggest problem right now is their close relationship with Source Technology. Whenever a whore enters the distributor business, it drives other distributors away from the product if you give the whores special breaks. I can't see how Source makes money, and I'll be surprised if they will be around for the long haul. I have seen so many businesses fail because they think they will make it up in volume. The dirty little secret is, anything times 0 is still 0. Alot of people I have run into in the ISP business are not business savvy, and Source seems to be one of them. I worry that Lucent will buy 3Com after the 1st of the year and close down the remote access products. Lucent gets their purse strings loosened after January 1st, and will go on a buying spree. I sure hope this does not happen. -Ron GLISnet, Inc. +1 810/939.9885

Subject: (usr-tc) support woes
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-09 23:46:34

FYI: Cisco isn't so giving: -----Original Message----- [mailto:owner-isp-equipment@isp-equipment.com] On Behalf Of DataComm Specialist Sent: Monday, December 07, 1998 5:23 PM I have a customer that has purchased an AS5248 Access Server. The units were rec'd with passwords enabled. I have contacted cisco and they mentio= n a $2000 contract to crack these passowrds. Does anyone have procedures to do so without their help? I have heard the phrase "Brain Dump". I would b= e interested if you knew how to initiate that as well. Any information pertaining to this would be greatly appreciated. Steve Rivera WRCA, Inc. http://www.wrca.net 481 Wright Debow Rd mailto:sales@wrca.net Jackson, NJ 08527 Online Orders Accepted p: 732-833-2111 f: 732-833-2115 "Everything DataCom, Nothing but Net" ___________ =95 ISP-EQUIPMENT Email Discussion 4Sale/WTB List =95________= _____ To Remove, Send An Email To: mailto:remove-isp-equipment@isp-equipment.co= m To Join, Send An Email To: mailto:join-isp-equipment@isp-equipment.com - Register as a V-ONE NSP Partner and Secure Your Clients' Sites With SmartGate. Qualify for V-ONE's Specially Priced Starter Kit of Client/ Server VPN Software. Limited Time Only-Register Now! www.v-one.com/NSP.ht= ml

Subject: RE: (usr-tc) support woes
From: K Mitchell <mitch@keyconn.net>
Date: 1998-12-09 23:50:38

At 11:03 PM 12/9/98 -0600, Brian K McIntire wrote: >Hold on. They aren't all bad. There has been a lot of turbulence since >3COM bought USR. There have been a lot of changes with more to come. They >have added a tremendous number of people to the front lines. I know for a >fact they are working to make sure they are all trained better. You should >at least take in to consideration 3COM's efforts to make things better. That's all well and good, but I'm stuck paying premium prices for interns. You pay to see a doctor or lawyer *after* he's completed schooling, not while he's still in his 2nd semester. >>into 3Com support twice, and I'd classify the knowledge at the other end >>marginal at best. At $1k per call, I should have a freaking guru at the >>other end, and a christmas card to boot. I'm also curious as to why 3Com >>feels that, after paying over $10k for a chassis, I need to pay more for a >>poorly working RADIUS server to authenticate users into it. > >This is a marketing complaint. 3COM does not have the margin they used to >in the hardware to constantly revamp and add features to all software for >free. Like any other company they need to make sure each piece of the >puzzle is making money. Yes, the HiPer ARC and HiPer DSP's have had a lot >of problems. They have also added a lot of features to an otherwise >antiquated product line. No one rights perfect code. They have a lot to >contend with. Once they get the code running smoothly I believe we will see >the software as steady as Ciscos's. Or at least close. That's my .02 >anyway Another well and good, but how much is it going to cost me in continued support to ensure that I'm allowed to get the decent code when it's available? I'm all for 3Com training their people and continuing to improve their code, but they persist in charging finished product prices for beta. I can't afford to be a paying-out-the-ass guinea pig unless they're going to compensate me for each customer I lose because of connection difficulties. I am by no stretch an expert in remote access equipment. When I bought my chassis, I paid a truckfull of money for support so that I'd have knowledgeable help as I struggle through the learning process. As it stands, I have almost as much chance of making things worse then improving them by using the support I'm paying top dollar for. If it wasn't for this list and my own playing around looking for answers, I'd be sitting here with a whole lot of blinkys and no customers. Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

Subject: Re: (usr-tc) support woes
From: Peter D. Mayer <dmayer@netwalk.com>
Date: 1998-12-10 00:04:21

Boy this is turning into a monster thread. I for one would prefer just to buy a subscription to software updates, and to hell with phone and hardware support. I'm willing to bet that this would bring the cost down to about $200 or so per year per chassis, which I wouldn't mind paying at all. Then I would gladly pay per incident for phone support if I really needed it, and outright buy replacment hardware for any that failed. I think someone mentioned this type of support earlier, is this possible? In one and a half years I've never really gotten anything but the runaround and a sore ear from phone support, and I had two power supplies that blew and I sent in the chassis they were in and then told me it wasn't broken (the typical phone support "it must be the hardware" routine). I get the answers to most of my questions right here by passively watching the list, and I do my fair share of contributing from time to time. I'm very thankful that there is a thing such as this list to keep me from going insane. Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com -----Original Message----- > > > Technically, no. If you have a support contract for one chassis, then you > > > have access to the firmware for every chassis you have. 3Com has no way of > > > insuring you are not updating more than the chassis under contract. > > > > Unless I'm mistaken, Cisco manage it... > > nope. Cisco is on the honor system. Once you have a CCO account, you can > download all kinds of stuff, not just what your contract covers. Sorry, I wasn't quite clear. I meant "Cisco manage to live with it". 3COM require a contract on every box to, reportedly, ensure people aren't ripping them off on the software. Cisco on the other hand manage to live with it, knowing that some people will rip them off, but many won't. Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Subject: Re: (usr-tc) support woes
From: Allen Marsalis <am@shreve.net>
Date: 1998-12-10 00:20:18

At 11:20 PM 12/9/98 -0500, Mike Andrews wrote: >On Wed, 9 Dec 1998, Brian wrote: > >> let me add some to that: >> >> Bugs found/encountered in code during 24months: >> >> Cisco 2501 (IOS 11.x) 0 >> USR 1706 20 (give or take) > >There was a pretty bad security hole (or two?) in IOS 11.something a few >months ago... just to be totally fair. :) Yes but what if someone purchased 5 2501's and purchased an extended contract for just one. Would Cisco not honor the contract to upgrade even that one? Would they have to go though some other backdoor to get the code such as email a cisco engineer who understands and is kind enough to help in his spare time? Would they have to rant to the dealer and Cisco rep to get the contract activated? Maybe wait until the moon was full? I don't think so. Cisco views us more as valued customers rather than potential theives.. or at least their actions would have me believe that. That is I hope I'm being totally fair in saying that 3COM has just plain lost it when it comes to support contracts.. Even their dealers and managers don't know their own policies.. Why even create an item number and distribution network and go tell dealers to *sell contracts* and then not honor or activate them? It doesn't even make sense.. How can it get all the way though the entire process of packaging, distribution, financing, sale, installation, and months of use before realizing that, hey, you know that contract you thought you purchased, well, think again.. (We could have saved about $70/mo on the lease w/o the dead contract) And given a circumstance like this one, would the cisco dealer say "hey, we'll just give you a few $$ off you next 4 purchases from us"?.. That's sorta not right.. kinda arrogant or something.. like they know we will be back.. or now we will be if we want any of our money back.. (new marketing strategy perhaps? :) I think I am being totally fair in saying that spending more $$ to bring us up to speed with their relatively new Hiper products is just not right, especially after waiting almost a year for MPIP, dealing with numerous bug issues, and being *forced* into the situation to eliminate Quake lag in the first place. But I do wish I didn't feel this way.. Allen

Subject: Re: (usr-tc) support woes
From: Allen Marsalis <am@shreve.net>
Date: 1998-12-10 00:41:30

At 11:34 PM 12/9/98 -0500, Jesse Sipprell wrote: >Absolutely. I think 3com is actually under-pricing TCRs in an attempt to grab >rapid market share from Lucent, and then jacking up support costs on the >post-sale end to cover their profits. hmm, and I always thought it was an attempt to sell 8 Sportsters for every quad/hiperdsp port.. :) (back in the x2 days anyway) Allen

Subject: Re: (usr-tc) NETservers and chat scripts
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-12-10 08:05:08

Thus spake Mike Andrews >The guy I'm dealing with now has an SGI O2 running Irix 6.x. I think he >can fix this by manually editing /etc/uucp/Systems or something similar >(anyone with an SGI know offhand? I'm a FreeBSD person)... but still, why >would it work with it as-is on an ARC and not on a NETserver? I'm not familiar with SGI's ppp, but if you can get some debug info out of it, particularly about the ppp negotiation, that would help a lot. I *love* Linux's debug for that...decodes all the values that it knows for you. :) Then it should just be a simple matter of figuring out where the negotiations differ. >It'd be nice if I could get him to just dial the ARC every time, instead >of our 2 NETservers, but Bellsouth says they can't set our PRI's up that >way, or at least seemed extremely confused when I asked. (We need CLECs >here, and we need them yesterday. :-) I keep hearing rumours from ICG that they're coming, but I don't know when. Of course, when you get ICG, that probably also means you get us as direct competition. ;) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) support woes
From: matthews <matthews@brunnet.net>
Date: 1998-12-10 08:57:06

On Wednesday, December 09, 1998 11:34 PM, Allen Marsalis [SMTP:am@shreve.net] wrote: > know what you mean.. We own a Cisco fasthub that we have had for over a year > with no contract ever. We recently noticed a problem that we considered a > defect in design and with only one phone call, they shipped us a new unit > before we even returned our old unit so we wouldn't be down.. They trusted > us. Incidents like this does influence our decision to purchase Cisco with > confidence in the future.. They have earned that confidence and it's worth $$$ > to them.. I purchase USR/3COM with considerable more reluctance, and only for > their modems.. I'll buy a Yugo before _attempting_ to buy another 3COM > support > contract. I guess the lack of trust on the subject is now mutual.. Exactly. I decided a long time ago when 3Com started pulling funny stuff with their contracts that it would be a cold day in hell before I'd ever authorize another 3Com chassis purchase. Are Bay and Lucent's tech support prices and competence any better? I don't know. But could they be any worse than 3Com? Don't get me wrong, there are a lot of clueful people at 3Com. Some of them even talk on the phone occasionally. I simply believe that whoever came up with the idea of paying half the value of a chassis for support should be fired. Tarred and feathered would be my preference, but fired would do just fine. Be Seeing You... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Matthew Stainforth<>Technical Services Manager<>BrunNet Inc.<>(506)450-4562 Don't rush me, sonny. You rush a miracle maker and you get rotten miracles. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Subject: RE: (usr-tc) support woes
From: matthews <matthews@brunnet.net>
Date: 1998-12-10 09:01:00

On Thursday, December 10, 1998 12:05 AM, Dan Hollis [SMTP:goemon@sasami.anime.net] wrote: > Cisco emergency bugfix IOS releases are free for customers with or without > support contracts (as long as you get the IOS with the same feature set). > > Theres a reason Cisco is #1. Of course Cisco has been at this a long time > and has the battle scars. Not only is it free, I had a Cisco guy calling me weekly to ask if I had applied the new version to my routers and offering to help me do it. No contract here. Be Seeing You... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Matthew Stainforth<>Technical Services Manager<>BrunNet Inc.<>(506)450-4562 Don't rush me, sonny. You rush a miracle maker and you get rotten miracles. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Subject: RE: (usr-tc) support woes
From: matthews <matthews@brunnet.net>
Date: 1998-12-10 09:04:34

On Thursday, December 10, 1998 1:04 AM, Brian K McIntire [SMTP:bmcintire@commnet.com] wrote: > This is a marketing complaint. 3COM does not have the margin they used to > in the hardware to constantly revamp and add features to all software for > free. Like any other company they need to make sure each piece of the > puzzle is making money. Yes, the HiPer ARC and HiPer DSP's have had a lot > of problems. They have also added a lot of features to an otherwise > antiquated product line. No one rights perfect code. They have a lot to > contend with. Once they get the code running smoothly I believe we will see > the software as steady as Ciscos's. Or at least close. That's my .02 > anyway They never WILL have the margin they need in order to offer those services for free unless they start respecting their customers a little more. And that means giving us what we paid for. Be Seeing You... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Matthew Stainforth<>Technical Services Manager<>BrunNet Inc.<>(506)450-4562 Don't rush me, sonny. You rush a miracle maker and you get rotten miracles. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Subject: RE: (usr-tc) support woes
From: matthews <matthews@brunnet.net>
Date: 1998-12-10 09:29:59

On Thursday, December 10, 1998 2:20 AM, Allen Marsalis [SMTP:am@shreve.net] wrote: > At 11:20 PM 12/9/98 -0500, Mike Andrews wrote: > >On Wed, 9 Dec 1998, Brian wrote: > > > >There was a pretty bad security hole (or two?) in IOS 11.something a few > >months ago... just to be totally fair. :) > > Yes but what if someone purchased 5 2501's and purchased an extended > contract for just one. Would Cisco not honor the contract to upgrade > even that one? Would they have to go though some other backdoor to get > the code such as email a cisco engineer who understands and is kind enough > to help in his spare time? No. Cisco publicly stated that anyone with an affected version of IOS would receive a free upgrade to a bug-free version, whether they had a support contract or not. For me, that involved a free upgrade from IOS 10.x to 11.x. They went the extra mile for me and I won't soon forget that. All 3Com has done is sell me a bunch of boxes and then stand there with their hand out asking for more money for them to honor what I believe should be covered under warranty anyway. Be Seeing You... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Matthew Stainforth<>Technical Services Manager<>BrunNet Inc.<>(506)450-4562 Don't rush me, sonny. You rush a miracle maker and you get rotten miracles. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Subject: Re: (usr-tc) support woes
From: Brian <signal@shreve.net>
Date: 1998-12-10 09:46:06

On Wed, 9 Dec 1998, Brian K McIntire wrote: > FYI: > Cisco isn't so giving: This is totally different though. Had *cisco* sent him that box with passwords enabled, they would surely do it for free. I mean, if someone sells someone a fscked up box then I don't think the vendor should have to pay the price for that. > -----Original Message----- > From: owner-isp-equipment@isp-equipment.com > [mailto:owner-isp-equipment@isp-equipment.com] On Behalf Of DataComm > Specialist > Sent: Monday, December 07, 1998 5:23 PM > To: isp-equipment@isp-equipment.com > Subject: ISP-EQUIPMENT: AS5248 Password question? >=20 >=20 > I have a customer that has purchased an AS5248 Access Server. The units > were rec'd with passwords enabled. I have contacted cisco and they mentio= n > a $2000 contract to crack these passowrds. Does anyone have procedures to > do so without their help? I have heard the phrase "Brain Dump". I would b= e > interested if you knew how to initiate that as well. >=20 > Any information pertaining to this would be greatly appreciated. >=20 >=20 > Steve Rivera > --------------------------------------- > WRCA, Inc. =09=09http://www.wrca.net > 481 Wright Debow Rd=09mailto:sales@wrca.net > Jackson, NJ 08527=09Online Orders Accepted >=20 > p: 732-833-2111=09=09f: 732-833-2115 >=20 > "Everything DataCom, Nothing but Net" >=20 >=20 >=20 >=20 >=20 >=20 > ___________ =95 ISP-EQUIPMENT Email Discussion 4Sale/WTB List =95________= _____ > To Remove, Send An Email To: mailto:remove-isp-equipment@isp-equipment.co= m > To Join, Send An Email To: mailto:join-isp-equipment@isp-equipment.com > - > Register as a V-ONE NSP Partner and Secure Your Clients' Sites With > SmartGate. Qualify for V-ONE's Specially Priced Starter Kit of Client/ > Server VPN Software. Limited Time Only-Register Now! www.v-one.com/NSP.ht= ml >=20 >=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 Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider= =20 Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts,=20 (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Subject: Re: (usr-tc) support woes
From: Bob Purdon <bobp@southcom.com.au>
Date: 1998-12-10 10:02:03

> Technically, no. If you have a support contract for one chassis, then you > have access to the firmware for every chassis you have. 3Com has no way of > insuring you are not updating more than the chassis under contract. Unless I'm mistaken, Cisco manage it... > Auditing an ISP is nearly impossible -- hardware is scattered over hundreds > of miles. Plus, who's to say the card died in the supported chassis; you > can move cards around :-) When we took out our contract, they made us supply serial numbers of everything we wanted covered... Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Subject: (usr-tc) totalservice
From: Brian <signal@shreve.net>
Date: 1998-12-10 10:13:34

Where on totalservice do you enter information about the products you own, such as serial numbers etc to activate 90 day warranty service? 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

Subject: Re: (usr-tc) totalservice
From: David Cartwright <david_cartwright@mw.3com.com>
Date: 1998-12-10 10:18:06

Brian Go to the Totalservice home page at http://totalservice.usr.com/ Then select "Warranty and Product Registration" Dave Brian <signal@shreve.net> on 12/10/98 10:13:34 AM Please respond to usr-tc@lists.xmission.com cc: (David Cartwright/MW/US/3Com) Where on totalservice do you enter information about the products you own, such as serial numbers etc to activate 90 day warranty service? 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.

Subject: Re: (usr-tc) Connected Message
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-10 10:57:04

On Thu, 10 Dec 1998, Mark Pansing wrote: > > I have a TC with the full compliment of quad modems and two HiperDSPs. > When logging in using a manual login (Terminal program) I receive a > Connected message after the login message and before the password prompt. > The TC also fails to authorize the connection. If I use a standard PAP > login(Win95), I get authorized without a problem. This happens when > connecting to the Quads, I haven't had an opportunity to try it on the > HiperDsps. Any suggestions? > > Dialing... > CONNECT 42666/ARQ/V90/LAPM/V42BIS > > InfiNet login: XXXX > Connected ^^^^^^^^^^^^^ - Right here - who is sending this Connected info? Looks like this is being treated as the password and you get disconnected. krish > Password: > Login incorrect > > Mark Pansing > Infinet Engineering Staff > (614) 848-4638 x203 > markp@infinet.com > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) support woes
From: Charles Sprickman <spork@inch.com>
Date: 1998-12-10 11:03:02

On Wed, 9 Dec 1998, Brian K McIntire wrote: > FYI: > Cisco isn't so giving: I think that person must be on crack. Support would not cost $2000. Chalk it up to internet loonies... Charles > -----Original Message----- > From: owner-isp-equipment@isp-equipment.com > [mailto:owner-isp-equipment@isp-equipment.com] On Behalf Of DataComm > Specialist > Sent: Monday, December 07, 1998 5:23 PM > To: isp-equipment@isp-equipment.com > Subject: ISP-EQUIPMENT: AS5248 Password question? >=20 >=20 > I have a customer that has purchased an AS5248 Access Server. The units > were rec'd with passwords enabled. I have contacted cisco and they mentio= n > a $2000 contract to crack these passowrds. Does anyone have procedures to > do so without their help? I have heard the phrase "Brain Dump". I would b= e > interested if you knew how to initiate that as well. >=20 > Any information pertaining to this would be greatly appreciated. >=20 >=20 > Steve Rivera > --------------------------------------- > WRCA, Inc. =09=09http://www.wrca.net > 481 Wright Debow Rd=09mailto:sales@wrca.net > Jackson, NJ 08527=09Online Orders Accepted >=20 > p: 732-833-2111=09=09f: 732-833-2115 >=20 > "Everything DataCom, Nothing but Net" >=20 >=20 >=20 >=20 >=20 >=20 > ___________ =95 ISP-EQUIPMENT Email Discussion 4Sale/WTB List =95________= _____ > To Remove, Send An Email To: mailto:remove-isp-equipment@isp-equipment.co= m > To Join, Send An Email To: mailto:join-isp-equipment@isp-equipment.com > - > Register as a V-ONE NSP Partner and Secure Your Clients' Sites With > SmartGate. Qualify for V-ONE's Specially Priced Starter Kit of Client/ > Server VPN Software. Limited Time Only-Register Now! www.v-one.com/NSP.ht= ml >=20 >=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

Subject: Re: (usr-tc) support woes
From: Charles Sprickman <spork@inch.com>
Date: 1998-12-10 11:06:31

On Thu, 10 Dec 1998, Allen Marsalis wrote: > At 11:20 PM 12/9/98 -0500, Mike Andrews wrote: > >On Wed, 9 Dec 1998, Brian wrote: > > > >There was a pretty bad security hole (or two?) in IOS 11.something a few > >months ago... just to be totally fair. :) > Yes but what if someone purchased 5 2501's and purchased an extended > contract for just one. Would Cisco not honor the contract to upgrade > even that one? Even better, if you own the product and they have a massive problem like this the new code is *free*, with or without contract. They just play fair, that's all. You buy the hw/sw, they find a mistake in the code that affects advertised functionality and they fix it for free. Isn't it sick that that idea sounds so radical??? And you don't even have to force their employees to look the other way as they give you the code, it's policy... Charles > Would they have to go though some other backdoor to get > the code such as email a cisco engineer who understands and is kind enough > to help in his spare time? Would they have to rant to the dealer and > Cisco rep to get the contract activated? Maybe wait until the moon was > full? I don't think so. Cisco views us more as valued customers rather > than potential theives.. or at least their actions would have me > believe that. > > That is I hope I'm being totally fair in saying that 3COM has just plain > lost it when it comes to support contracts.. Even their dealers and > managers don't know their own policies.. Why even create an item number > and distribution network and go tell dealers to *sell contracts* and > then not honor or activate them? It doesn't even make sense.. How > can it get all the way though the entire process of packaging, distribution, > financing, sale, installation, and months of use before realizing that, > hey, you know that contract you thought you purchased, well, think again.. > (We could have saved about $70/mo on the lease w/o the dead contract) > > And given a circumstance like this one, would the cisco dealer say "hey, > we'll just give you a few $$ off you next 4 purchases from us"?.. That's > sorta not right.. kinda arrogant or something.. like they know we will > be back.. or now we will be if we want any of our money back.. (new > marketing strategy perhaps? :) > > I think I am being totally fair in saying that spending more $$ to bring > us up to speed with their relatively new Hiper products is just not > right, especially after waiting almost a year for MPIP, dealing with > numerous bug issues, and being *forced* into the situation to eliminate > Quake lag in the first place. But I do wish I didn't feel this way.. > > > Allen > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) support woes
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1998-12-10 11:07:00

Peter, You can buy just software support w/o the phone and hardware. I think the part number is 002796 . It still runs over $1k per chassis. Jeff u>Boy this is turning into a monster thread. u>I for one would prefer just to buy a subscription to software updates, u>and to hell with phone and hardware support. I'm willing to bet that u>this would bring the cost down to about $200 or so per year per u>chassis, which I wouldn't mind paying at all. Then I would gladly pay u>per incident for phone support if I really needed it, and outright buy u>replacment hardware for any that failed. I think someone mentioned u>this type of support earlier, is this possible? u>In one and a half years I've never really gotten anything but the u>and runaround a sore ear from phone support, and I had two power u>and supplies that blew I sent in the chassis they were in and then u>told me it wasn't broken (the typical phone support "it must be the u>hardware" routine). I get the answers to most of my questions right u>here by passively watching the list, and I do my fair share of u>contributing from time to time. I'm very thankful that there is a u>thing such as this list to keep me from going insane. u>Peter D. Mayer u>NetWalk System Administrator u>dmayer@netwalk.com u>-----Original Message----- u>From: Bob Purdon <bobp@southcom.com.au> u>To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> u>Date: Wednesday, December 09, 1998 11:37 PM u>Subject: Re: (usr-tc) support woes u>> > > Technically, no. If you have a support contract for one u>chassis, then you u>> > > have access to the firmware for every chassis you have. 3Com u>has no way of u>> > > insuring you are not updating more than the chassis under u>> >contract. u>> > Unless I'm mistaken, Cisco manage it... u>> u>> nope. Cisco is on the honor system. Once you have a CCO account, u>> you can download all kinds of stuff, not just what your contract u>> covers. u>Sorry, I wasn't quite clear. I meant "Cisco manage to live with it". u>3COM require a contract on every box to, reportedly, ensure people u>aren't ripping them off on the software. Cisco on the other hand u>manage to live with it, knowing that some people will rip them off, u>but many won't. u>Regards, u>Bob Purdon, u>Technical Manager, u>Southern Internet Services. 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

Subject: (usr-tc) RE: (USR-TC) SUPPORT WOES
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1998-12-10 11:07:00

U>>-----Original Message----- U>>From: owner-usr-tc@lists.xmission.com U>>[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams U>>Sent: Wednesday, December 09, 1998 7:52 PM U>>To: usr-tc@lists.xmission.com U>>Subject: Re: (usr-tc) support woes U>> U>> U>>Thus spake Brian K McIntire U>>>Truth is, 3COM thinks they are getting ripped of by ISP's U>>>with dozens of chassis and 1 contract so they are trying to hold U>>>everyone accountable. U>> U>>Oh, I'm sure this does happen, but if the support contract prices U>>weren't so *TOTALLY* outrageous, it wouldn't happen *nearly* as much. U>Of course the other side of the coin is the contracts wouldn't be so U>high if there wern't so many people "stealing" service. U>Out of my hands. Oh well That would be a bad assumption from a business perspective. If I were running a business and I thought all of my customers were trying to steal from me, I'd ask myself what I was doing wrong or get out of business. The fact that many others do things succesfully and charge much less for their support, says that something is wrong at 3Com and who/how they price their support services. On the other hand they also need to look at what type of support calls they are getting. Hardware ? Software ? If I was making hardware and it kept breaking all of the time and I forced folks to buy service contracts, I just created my own market. I'm not saying 3Com is doing this but I do know that many companies do this sort of analysis. My 2 cents worth. Jeff Binkley ASA Network Computing CMPQwk 1.42 9999

Subject: (usr-tc) RE: (USR-TC) SUPPORT WOES
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1998-12-10 11:07:00

The serial number is the way to go. Another question is whether you want everything covered or not. What if I am an ISP but don't want to cover all of my chassis'. For instace I may have some Netserver chassis's that I am planning on getting rid of during the next year ? I sure wouldn't want to pay $2,500+ per chassis for maintenance. Every vendor I know of allows you to pick and choose which products you want to cover udner maintenance or not. Jeff Binkley ASA Network Computing U>> Technically, no. If you have a support contract for one chassis, U>> then you have access to the firmware for every chassis you have. U>> 3Com has no way of insuring you are not updating more than the U>> chassis under contract. U>Unless I'm mistaken, Cisco manage it... U>> Auditing an ISP is nearly impossible -- hardware is scattered over U>> hundreds of miles. Plus, who's to say the card died in the U>> supported chassis; you can move cards around :-) U>When we took out our contract, they made us supply serial numbers of U>everything we wanted covered... U>Regards, U>Bob Purdon, U>Technical Manager, U>Southern Internet Services. CMPQwk 1.42 9999

Subject: RE: (usr-tc) Connected Message
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-12-10 11:13:04

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mark Pansing |Sent: Thursday, December 10, 1998 10:35 AM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) Connected Message | | | |I have a TC with the full compliment of quad modems and two HiperDSPs. |When logging in using a manual login (Terminal program) I receive a |Connected message after the login message and before the password prompt. |The TC also fails to authorize the connection. If I use a standard PAP |login(Win95), I get authorized without a problem. This happens when |connecting to the Quads, I haven't had an opportunity to try it on the |HiperDsps. Any suggestions? | |Dialing... |CONNECT 42666/ARQ/V90/LAPM/V42BIS | |InfiNet login: XXXX |Connected |Password: |Login incorrect Looks like you have a default host configured.. After the username the box is rloging you to some other box that is promting for password.. When its waiting there for password, get on the NS and type "show netc". See if you see a session between the NS and some UNIX box. -M

Subject: Re: (usr-tc) Connected Message
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-10 11:16:56

On Thu, 10 Dec 1998, Mark Pansing wrote: > > As far as I can make out, its something on the TC. > Look at your port setting - maybe you have setup the port to directly telnet or rlogin to a unix host. The TC does not give you this unless and untill you are trying to connect to a host. In that case it should not ask you for a login. Is this a NETServer or HiPer arc? krish > > On Thu, 10 Dec 1998, Tatai SV Krishnan wrote: > > > On Thu, 10 Dec 1998, Mark Pansing wrote: > > > > > > > > I have a TC with the full compliment of quad modems and two HiperDSPs. > > > When logging in using a manual login (Terminal program) I receive a > > > Connected message after the login message and before the password prompt. > > > The TC also fails to authorize the connection. If I use a standard PAP > > > login(Win95), I get authorized without a problem. This happens when > > > connecting to the Quads, I haven't had an opportunity to try it on the > > > HiperDsps. Any suggestions? > > > > > > Dialing... > > > CONNECT 42666/ARQ/V90/LAPM/V42BIS > > > > > > InfiNet login: XXXX > > > Connected > > ^^^^^^^^^^^^^ - Right here - who is sending this Connected info? Looks > > like this is being treated as the password and you get disconnected. > > > > krish > > > > > Password: > > > Login incorrect > > > > > > Mark Pansing > > > Infinet Engineering Staff > > > (614) 848-4638 x203 > > > markp@infinet.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. > > > > Mark Pansing > Infinet Engineering Staff > (614) 848-4638 x203 > markp@infinet.com > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Wanted USR / 3COM Total Control Units
From: Jack Singer <jsinger@usacars.com>
Date: 1998-12-10 11:33:21

I need USR / 3COM Total Control units... Prefer eithernet ready with 486 and PRI but will consider any other option. Either email or call me direct. Quad or Hyper, I just need equipment. Jack Singer jsinger@i-c.net (800) 224-3806

Subject: (usr-tc) Connected Message
From: Mark Pansing <markp@infinet.com>
Date: 1998-12-10 11:34:57

I have a TC with the full compliment of quad modems and two HiperDSPs. When logging in using a manual login (Terminal program) I receive a Connected message after the login message and before the password prompt. The TC also fails to authorize the connection. If I use a standard PAP login(Win95), I get authorized without a problem. This happens when connecting to the Quads, I haven't had an opportunity to try it on the HiperDsps. Any suggestions? Dialing... CONNECT 42666/ARQ/V90/LAPM/V42BIS InfiNet login: XXXX Connected Password: Login incorrect Mark Pansing Infinet Engineering Staff (614) 848-4638 x203 markp@infinet.com

Subject: Re: (usr-tc) RE: (USR-TC) SUPPORT WOES
From: Jack Singer <jsinger@usacars.com>
Date: 1998-12-10 11:39:10

When the used market for a unit is $2500 to $3500 per unit, who would pay $2500 for support. Maybe if they lowered the support fee to $500 per unit, I might register my units and they would get a lot more money than they get now from me. It is cheaper to hire a staff than pay 3COM. Jeff Binkley wrote: > The serial number is the way to go. Another question is whether you > want everything covered or not. What if I am an ISP but don't want to > cover all of my chassis'. For instace I may have some Netserver > chassis's that I am planning on getting rid of during the next year ? I > sure wouldn't want to pay $2,500+ per chassis for maintenance. Every > vendor I know of allows you to pick and choose which products you want > to cover udner maintenance or not. > > Jeff Binkley > ASA Network Computing > > U>> Technically, no. If you have a support contract for one chassis, > U>> then you have access to the firmware for every chassis you have. > U>> 3Com has no way of insuring you are not updating more than the > U>> chassis under contract. > > U>Unless I'm mistaken, Cisco manage it... > > U>> Auditing an ISP is nearly impossible -- hardware is scattered over > U>> hundreds of miles. Plus, who's to say the card died in the > U>> supported chassis; you can move cards around :-) > > U>When we took out our contract, they made us supply serial numbers of > U>everything we wanted covered... > > U>Regards, > > U>Bob Purdon, > U>Technical Manager, > U>Southern Internet Services. > > CMPQwk 1.42 9999 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Connected Message
From: Mark Pansing <markp@infinet.com>
Date: 1998-12-10 11:59:08

As far as I can make out, its something on the TC. On Thu, 10 Dec 1998, Tatai SV Krishnan wrote: > On Thu, 10 Dec 1998, Mark Pansing wrote: > > > > > I have a TC with the full compliment of quad modems and two HiperDSPs. > > When logging in using a manual login (Terminal program) I receive a > > Connected message after the login message and before the password prompt. > > The TC also fails to authorize the connection. If I use a standard PAP > > login(Win95), I get authorized without a problem. This happens when > > connecting to the Quads, I haven't had an opportunity to try it on the > > HiperDsps. Any suggestions? > > > > Dialing... > > CONNECT 42666/ARQ/V90/LAPM/V42BIS > > > > InfiNet login: XXXX > > Connected > ^^^^^^^^^^^^^ - Right here - who is sending this Connected info? Looks > like this is being treated as the password and you get disconnected. > > krish > > > Password: > > Login incorrect > > > > Mark Pansing > > Infinet Engineering Staff > > (614) 848-4638 x203 > > markp@infinet.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. > Mark Pansing Infinet Engineering Staff (614) 848-4638 x203 markp@infinet.com

Subject: Re: (usr-tc) Connected Message
From: Brian Elfert <brian@citilink.com>
Date: 1998-12-10 12:18:04

On Thu, 10 Dec 1998, Mark Pansing wrote: > > As far as I can make out, its something on the TC. > On a Netserver, do a 'set connect off'. Otherwise, on a rlogin or telnet session, it sends 'connected' to the screen after the connection is established. Brian

Subject: Re: (usr-tc) support woes
From: Allen Marsalis <am@shreve.net>
Date: 1998-12-10 12:53:10

At 12:04 AM 12/10/98 -0500, Peter D. Mayer wrote: >Boy this is turning into a monster thread. > >I for one would prefer just to buy a subscription to software updates, and >to hell with phone and hardware support. I'm willing to bet that this would >bring the cost down to about $200 or so per year per chassis, which I >wouldn't mind paying at all. Then I would gladly pay per incident for phone >support if I really needed it, and outright buy replacment hardware for any >that failed. I think someone mentioned this type of support earlier, is >this possible? > I like this idea too. Even a tiered plan would be ok.. something like: #Contracts Cost/yr (software only) 1 $1K 2-5 $500 6-9 $250 10-99 $200 100+ special arrangement Even if the RBOC's and bandwidth wholesalers don't, I believe in volume discounts.. (Still pondering why retail bandwidth costs less than wholesale bandwidth from UUNet. And why our 300+ business lines cost more each than a single residential line out in the boonies) But I like the idea of having a choice when it comes to which boxen I want to cover with a contract.. It is good pricing that will make people want to cover all their chassis.. Then being out $250 for selling off a box early isn't so bad.. Allen

Subject: Re: (usr-tc) Second rack config, route distribution questions
From: Jesse Sipprell <jss@evcom.net>
Date: 1998-12-10 13:03:11

On Thu, Dec 10, 1998 at 05:13:33PM -0000, Ray Bellis wrote: > Hi there, I'm new to the list (only just found it, would you believe, > after running a TC rack for two and a half years!) > > Anyway, I've had a second rack for some time, but its single existing > PRI has been on a separate number for a special customer project. I've > just had a new PRI installed which is to be on the same hunt group as > the two PRIs on my existing rack. > > I'm using the old TC hardware with recent firmware and no Hyper > equipment. > > Now the problems, which I'm sure you've all solved before :-) > > 1. Subnetted customers > > Following the instructions from this lists archive, I've turned on RIPv2 > and configured by gated box to redistribute those routes to OSPF. > However, my LAN customers are currently configured using static routes > on the NETserver card. > > What is the correct format for the 'Framed-Route' attribute so that I > can set the routes automatically from RADIUS when the user logs in? You don't need to worry about Framed-Route, this is used to send/receive RIP with your customers (typically not done). I always set it to `None'. All you need to do is: Framed-IP-Address = 10.0.0.1, Framed-IP-Netmask = 255.255.255.224 This will cause the netserver to broadcast a ripv2 route for 10.0.0.1/27, which the router you bounce the ripv2 off can then distribute into OSPF. > > 2. Dynamic pools and /32 statics > > Is there a way to aggregate the /26 dynamic pool handled by each rack, > or do I have to export a /32 via RIPv2 for each customer as they log in? > > We've also got a large number of /32 statics for SMTP customers which > (obviously) aren't in the pool. I think I'll have to stick with a /32 > export for those. I have read that the netserver can aggregate the pool and announce it as a single route, however I have never been able to get it to work. What I do is use a simple access-list on the cisco side to filter out all /32 announcements for the pool and nail down a static route from the cisco to the netserver. After all, the pool will never move to a different TCR, so.... Outside of the pool, I do as above and redistribute into OSPF. Note that this still puts /32s into OSPF because static IP customers are not in the pool and can potentially move about between chassis. (BTW, using a HARC, it's trivial to aggregate dial-up pools <grin>). The only annoying bit is that ripv2 has to timeout if a static IP customer disconnects and rapidly reconnects to a different chassis, so they can potentially perceive an initial loss-of-service during a rapid reconnection. Doesn't happen very often though. One could play with ripv2 hold-down timers, I suppose. When the HARC supports OSPF, I'll be a very very happy camper. > 3. MPIP > > Everything I've seen before today implied that spreading an MLPPP > connection across racks was fully supported, but the archive (which > isn't completely up to date) seems to say that it's not supported. > What's the current state of play? > > thanks in advance, > > Ray. Works. Haven't tried with the HARC yet though, but using it successfully with Netservers. -- Jesse Sipprell Technical Operations Director Evolution Communications, Inc. 800-496-4736 (ext 106) * Finger jss@evcom.net for my PGP Public Key *

Subject: RE: (usr-tc) Connected Message
From: Mark Pansing <markp@infinet.com>
Date: 1998-12-10 13:15:15

After some suggestions from krish to look at my port set up, I found that I didn't have security on. Turning that on, solved the problem. Think I would remember that after setting up so many PM2s. Thanks > | > | > |I have a TC with the full compliment of quad modems and two HiperDSPs. > |When logging in using a manual login (Terminal program) I receive a > |Connected message after the login message and before the password prompt. > |The TC also fails to authorize the connection. If I use a standard PAP > |login(Win95), I get authorized without a problem. This happens when > |connecting to the Quads, I haven't had an opportunity to try it on the > |HiperDsps. Any suggestions? > | > |Dialing... > |CONNECT 42666/ARQ/V90/LAPM/V42BIS > | > |InfiNet login: XXXX > |Connected > |Password: > |Login incorrect > > Looks like you have a default host configured.. After the username the box is > rloging you to some other box that is > promting for password.. When its waiting there for password, get on the NS and > type "show netc". See if you see a > session between the NS and some UNIX box. > > > -M > > > Mark Pansing Infinet Engineering Staff (614) 848-4638 x203 markp@infinet.com

Subject: Re: (usr-tc) Second rack config, route distribution questions
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-12-10 14:33:33

Ray Bellis said once upon a time: >2. Dynamic pools and /32 statics > >Is there a way to aggregate the /26 dynamic pool handled by each rack, >or do I have to export a /32 via RIPv2 for each customer as they log in? > >We've also got a large number of /32 statics for SMTP customers which >(obviously) aren't in the pool. I think I'll have to stick with a /32 >export for those. What I did is make a /26 static on the Cisco, then proceeded to block any RIP advertisements inside that /26 with an access list on my "router rip". >Everything I've seen before today implied that spreading an MLPPP >connection across racks was fully supported, but the archive (which >isn't completely up to date) seems to say that it's not supported. >What's the current state of play? Hard to say, USR/3com claims that it works great in its current state. My subscribers say otherwise.

Subject: RE: (usr-tc) HiPER DSP Bad Span Connectors??
From: Terry Kennedy <terry@olypen.com>
Date: 1998-12-10 14:47:14

Superglue... :) > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Matthew E Pearson > Sent: Thursday, December 10, 1998 1:12 PM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) HiPER DSP Bad Span Connectors?? > > > Question, > > I have a stack of HiPER DSPs which seem to be missing the RJ45 locking tab > on the Span connector (although it exists on the Console & Aux > ports) it's a > little black tab on the "bottom" of the socket where the locking tab goes. > As a result my calbes literally slip out of the socket! > > Any thoughts? I have HiPERS with the tabs on them also? Did USR change > design? Should I use something other than a standard RJ45 connector tab on > my cabling? > > Help! > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Settings for Ch. T-1 on a HiPerDSP
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-12-10 14:49:51

Randy Doran said once upon a time: > >On a HiPerDSP, what do you have to change from the default settings to >bring up a Channelized T-1? I have already set the "Signal Mode" to >"robbedBit." The circuit appears to be up and all 24 DS0s are "inService". > I have verified that the circuit itself works by plugging it into a Dual >T-1 card and calls came right in on the Quad modem cards. Smells like a Netserver in that chassis. Don't forget that you need to do significant singing and dancing in order to get the Netserver to properly recognize your HDM. I can't remember the exact command lines, but it won't answer the phone until you do them.

Subject: Re: (usr-tc) Second rack config, route distribution questions
From: Jesse Sipprell <jss@evcom.net>
Date: 1998-12-10 14:50:39

On Thu, Dec 10, 1998 at 06:51:07PM -0000, Ray Bellis wrote: > > You don't need to worry about Framed-Route, this is used to > > send/receive RIP with your customers (typically not done). > > I always set it to `None'. All you > > need to do is: > > > > Framed-IP-Address = 10.0.0.1, > > Framed-IP-Netmask = 255.255.255.224 > > > > This will cause the netserver to broadcast a ripv2 route for 10.0.0.1/27, > > which the router you bounce the ripv2 off can then distribute into OSPF. > > My RADIUS database already appears as you describe (except my dictionary > doesn't contain the '-IP-' part of the Radius attribute name, I assume it's > the same thing). Yes, it is the same thing. ;) RADIUS attributes are actually just numbers, the "names" such as "Framed-IP-Address" or "Framed-Address" are simply mappings from your dictionary. I believe that the official naming for Address/Netmask are now "Framed-IP-Address" and "Framed-IP-Netmask", so your dictionary may be out of date, but it doesn't actually technically matter. > > I usually use unnumbered links for my LAN customers, and so I've previously > had to install static routes on the NETserver for the customer's range with > the next hop set to the customer router's IP address *but* with a hop count > of 2. This has previously been necessary to get any routed communication > with the customer's LAN. Not sure what you mean by "unnumbered" in this context. By default, all interfaces on a Netserver are unnumbered (in Cisco-speak), except for net0. There is no reason you should have to put in static routes on the Netserver unless you are assigning the LAN customers a /32 static IP and then routing a subnet to that IP (which I would not recommend). Here's what happens you you use Framed-IP-Address = 10.0.0.1, Framed-IP-Netmask = 255.255.255.224: 1. Caller connects and is handed the IP address 10.0.0.1. 2. Netserver installs a route for 10.0.0.0/27, with the next hop pointing to 10.0.0.1 3. Netserver broadcasts this route via ripv2. > I'm not convinced that what I've done today will drop the requirement to > install a static route within the NETserver itself, since I'm already > setting the RADIUS attributes as you describe. The only thing that has > changed is that I'm now advertising RIPv2. > > thanks, > > Ray. -- Jesse Sipprell Technical Operations Director Evolution Communications, Inc. 800-496-4736 (ext 106) * Finger jss@evcom.net for my PGP Public Key *

Subject: (usr-tc) NT4 with Sportster 128 into a TCH
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-12-10 15:07:51

OK, I've had several customers with this problem and still haven't found a solution (other than bomb redmond, but my biases are showing). Windows NT 4.0, with a Sportster 128, dialing into our NETServers... Apparently, NT dials both channels of the Sportster at the same time (why? I have no stinkin' idea). Microsoft apparently has a knowledgebase article on their site (I say apparently, because I refuse to 'register' to get access to their support stuff, but others here have done so), which lays the blame on Livingston PortMaster equipment not handling the bundling correctly when two channels are dialed at the same time. Personally, I think its broken that they dial both channels at the same time, but for some reason NT seems to insist on doing this. The knowledgebase article number that I have is Q169136 FWIW. What can I do here? My personal inclination is to say NT is broken (well...I *know* its broken...in many ways...but in this specific way its broken as well) and tell the customer to find a new dial-up product to use, but I figured I could at least make an effort to find a solution to this. Any ideas? -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) Anyone running 8meg Netserver cards?
From: Suncoast Networking USR Mailbox <usrtcmail@flasuncoast.net>
Date: 1998-12-10 15:10:31

Is anyone successfully running a Netserver card in a TC rack with 8 megs of ram, V.90 (3.7.24) code and 2 pri spans? We have one. Until recently it had only 1 pri span. We just added a second PRI and started having problems with quad cards, both digital and v.34/digital cards going dead. TCM shows them yellow, NMC goes red. Calls to those ports ring with no answer. Pulling the card and replacing it brings it back up, but within a day or two another card will do the same thing. Before upgrading in October from 2.5.1 to V.90 (3.1.1) I never saw this problem. After upgrading it happened a couple of times. Now its happening all the time, and of course the natives are getting restless. Saturday night 3 quads went down. I'm wondering if going to 16megs on the Netserver card and upgrading the firmware to 3.8.1 would fix this problem? Thanks, Steve

Subject: Re: (usr-tc) Anyone running 8meg Netserver cards?
From: Jesse Sipprell <jss@evcom.net>
Date: 1998-12-10 15:23:27

On Thu, Dec 10, 1998 at 03:10:31PM -0500, Suncoast Networking USR Mailbox wrote: > Is anyone successfully running a Netserver card in a TC rack > with 8 megs of ram, V.90 (3.7.24) code and 2 pri spans? > > We have one. Until recently it had only 1 pri span. We > just added a second PRI and started having problems with > quad cards, both digital and v.34/digital cards going dead. > TCM shows them yellow, NMC goes red. Calls to those ports > ring with no answer. Pulling the card and replacing it brings > it back up, but within a day or two another card will do the > same thing. > > Before upgrading in October from 2.5.1 to V.90 (3.1.1) I never > saw this problem. After upgrading it happened a couple of times. > Now its happening all the time, and of course the natives are > getting restless. Saturday night 3 quads went down. I'm wondering > if going to 16megs on the Netserver card and upgrading the > firmware to 3.8.1 would fix this problem? > > Thanks, > Steve > Steve, In my experience this is not a Netserver memory issue, although you may definitely have problems with your chassis or NMC. I say this because I tried to run 3.8.1 on an 8 meg Netserver. When it ran out of memory, life got pretty fun. ;) Basically, the chassis looked good and callers could connect/ping, but TCP refused to work, and I couldn't telnet in to the Netserver. Up'd the Netservers memory to 20 megs, and life has been good ever since. -- Jesse Sipprell Technical Operations Director Evolution Communications, Inc. 800-496-4736 (ext 106) * Finger jss@evcom.net for my PGP Public Key *

Subject: Re: (usr-tc) support woes
From: Bob Purdon <bobp@southcom.com.au>
Date: 1998-12-10 15:35:28

> > > Technically, no. If you have a support contract for one chassis, then you > > > have access to the firmware for every chassis you have. 3Com has no way of > > > insuring you are not updating more than the chassis under contract. > > > > Unless I'm mistaken, Cisco manage it... > > nope. Cisco is on the honor system. Once you have a CCO account, you can > download all kinds of stuff, not just what your contract covers. Sorry, I wasn't quite clear. I meant "Cisco manage to live with it". 3COM require a contract on every box to, reportedly, ensure people aren't ripping them off on the software. Cisco on the other hand manage to live with it, knowing that some people will rip them off, but many won't. Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Subject: (usr-tc) HiPER DSP Bad Span Connectors??
From: Matthew E Pearson <mpearson@tiac.net>
Date: 1998-12-10 16:12:03

Question, I have a stack of HiPER DSPs which seem to be missing the RJ45 locking tab on the Span connector (although it exists on the Console & Aux ports) it's a little black tab on the "bottom" of the socket where the locking tab goes. As a result my calbes literally slip out of the socket! Any thoughts? I have HiPERS with the tabs on them also? Did USR change design? Should I use something other than a standard RJ45 connector tab on my cabling? Help!

Subject: Re: (usr-tc) VJ Header Compression
From: MegaZone <megazone@megazone.org>
Date: 1998-12-10 17:07:08

Once upon a time Dan Hollis shaped the electrons to say... >One wonders why such options as VJ and MTU are in radius at all then... 1. SLIP 2. Scripted login for PPP. -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!

Subject: Re: (usr-tc) support woes
From: MegaZone <megazone@megazone.org>
Date: 1998-12-10 17:08:48

Once upon a time Allen Marsalis shaped the electrons to say... >will be given a $500 credit on our next 4 chassis purchases! We may have >purchased a support contract, but in effect, we have given 3COM a loan >for a year and we are paying the interest! Makes one wonder how other vendors can afford to just give free 5x12 support, free software upgrades, free server software, free management software, etc - and still make a profit. Something to ponder. -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!

Subject: (usr-tc) Second rack config, route distribution questions
From: Ray Bellis <rpb@community.net.uk>
Date: 1998-12-10 17:13:33

Hi there, I'm new to the list (only just found it, would you believe, after running a TC rack for two and a half years!) Anyway, I've had a second rack for some time, but its single existing PRI has been on a separate number for a special customer project. I've just had a new PRI installed which is to be on the same hunt group as the two PRIs on my existing rack. I'm using the old TC hardware with recent firmware and no Hyper equipment. Now the problems, which I'm sure you've all solved before :-) 1. Subnetted customers Following the instructions from this lists archive, I've turned on RIPv2 and configured by gated box to redistribute those routes to OSPF. However, my LAN customers are currently configured using static routes on the NETserver card. What is the correct format for the 'Framed-Route' attribute so that I can set the routes automatically from RADIUS when the user logs in? 2. Dynamic pools and /32 statics Is there a way to aggregate the /26 dynamic pool handled by each rack, or do I have to export a /32 via RIPv2 for each customer as they log in? We've also got a large number of /32 statics for SMTP customers which (obviously) aren't in the pool. I think I'll have to stick with a /32 export for those. 3. MPIP Everything I've seen before today implied that spreading an MLPPP connection across racks was fully supported, but the archive (which isn't completely up to date) seems to say that it's not supported. What's the current state of play? thanks in advance, Ray. -- Ray Bellis, MA(Oxon) - Technical Director - Oxford CommUnity Internet plc Windsor House, 12 High Street, Kidlington, OXFORD OX5 2PJ UK Telephone: +44-1865-856000 Fax: +44-1865-856001 Email: ray.bellis@community.net.uk URL: http://www.community.co.uk/

Subject: Re: (usr-tc) support woes
From: MegaZone <megazone@megazone.org>
Date: 1998-12-10 17:24:31

Once upon a time matthews shaped the electrons to say... >authorize another 3Com chassis purchase. Are Bay and Lucent's tech support >prices and competence any better? I don't know. But could they be any Lucent RABU: 5x12 support: free All OS upgrades: free Server software (RADIUS & ChoiceNet): free Management software (100% Java - PMVision, PMTools, debuggers, etc): free All manuals, notes, etc are freely available on their website. They also readily cross-ship RMA repalcements when there is a problem. Regularly doing so even for units out of warranty. I will say I haave always thought they charge WAY too much for 7x24 support contracts, but they claim to be working on a new pricing structure that is better balanced for smaller players. I'd also give them modem edge to 3Com. ALL products have modem issues, but the 3Com modems tend to connect to the widest variety of modems. I'd have to give the NAS OS edge to Lucent though. HW - the HiPer is a nice product. It falls between the PM-3 and PM-4 in density. The PM-3 is up for replacement soon I bet (I've heard talk of a PM-3+ with 4 or 8 ports). The PM-4 is out and hits 864 DS0s with T1/PRI lines at this point, more to come. I'm really curious to see if 3Com could ever manage to double the density on the HiPer to manage to handle a T3. -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!

Subject: Re: (usr-tc) dspInterruptTimeout
From: David Bolen <db3l@ans.net>
Date: 1998-12-10 17:31:42

Bob Purdon <bobp@southcom.com.au> writes: > Anyone know what a 'dspInterruptTimeout' call failure reason means? It > was taking calls OK, but now sounds like a strangled fax machine when it > answers, and fails EVERY call... > > If it means foobared hardware then I'll be really pissed, as this'll be 2 > out of 4 dead quad cards so far, and this one is a 400 mile round trip > away. Technically, I believe it means that the DSP did not trip a programmed interrupt to signal completion of an operation initiated by the controller on the specific modem. This would normally be modem specific (e.g., it's per each modem on the quad card since such cards have individual DSPs for each modem). I don't know if I can claim it's _always_ a hardware failure, but we always replace the hardware whenever we start seeing instances of this, and I can't recall ever seeing one fix itself for any significant period of time via resets, card reseats, etc.. > It refused to take 'nic' or 't1' as the line type (reverted back > instantly), refused to accept an 'n:5' on the PRI card, accepted an 'out > of service', but then took calls anyway, and generally didn't want to be > disabled. This doesn't sound related, but may be something else. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: Re: (usr-tc) syslogging
From: David Bolen <db3l@ans.net>
Date: 1998-12-10 17:41:54

Brian <signal@shreve.net> writes: > Do most of you syslog all your calls? if so at what event levels? > (default?) For the NETServer, we just syslog everything (not that there's a choice). For the ARC, I think we're still experimenting somewhat, but currently log unusual by default (leaving open the choice to turn it up for periods of times of debugging). > How do you handle the data, do you roll it over daily then delete it > weekly? database it somehow? Each of our racks in the field have a local management workstation (Unix) which has at least a 1GB disk on it (those in the newer denser racks have somewhat larger disks). Among other things, we maintain all raw logs of all types (traps, syslogs, etc..) for a week, rotating daily, on each management workstation. We don't currently archive past a week - in general, I've found that being able to do back one full "cycle" (a lot of activity is cyclical at the day and week boundaries) is sufficient for most post-mortem activities. If you sometimes get caught with an issue older than that, you can normally wait for it to occur again and/or recreate it purposefully. (If you can't, then in most cases you can note the problem as a transient :-)) Note that while we don't store the raw logs anywhere, portions of the syslog messages do contribute (along with traps and polls) to some of the data in our "call records". We keep a full month of call records for the local equipment on each management workstation, and the call records themselves are sent back to a central database for full archiving and stuff. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: Re: (usr-tc) VJ Header Compression
From: MegaZone <megazone@megazone.org>
Date: 1998-12-10 17:45:55

Once upon a time Jeff Mcadams shaped the electrons to say... >And, as I mentioned in another post, at least *theoretically*, the NAS As they said in The Crow "This is the Really Real World." Yeah - the RFC allows for it, but I can't think of any NAS that bothers trying. And that's for the best. :-) -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!

Subject: Re: (usr-tc) Lost in the 3Com(USR) World
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-10 18:10:09

> Hi Everyone, > > Please excuse this very uninformed and silly question post! (I found this > list about a week ago, and until then I thought 3Com/USR TC Units were > great - still do - just don't like the stories I am hearing) > > We have a single TC unit here, my question is what version of software > should be running on it?? > > If I do a version on the netserver I get: > > Command> version > U.S. Robotics > Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.7.73 > Build date: Mar 19 1998 > Build time: 21:32:39 > > Network Interface Card: Ethernet & Frame Relay Combination (26) > ISDN Interface Card : MUNICH32 (4) > Packet Bus Circuit : Enhanced > You are running an Engineer release code. This code is built off 3.7.24 but had some fixes for MPIP. > We are using it to handle incoming connections only at this point, although > I believe we can use it as a router if we want to. (and replace my cisco! > NEVER!) > > Also we are in New Zealand, (I don't know if there are different versions > of the software for different regions etc.) > The software is same for every country ( on the NETServer) the current release is 3.8.1. You can get it from http://totalservice.usr.com krish > Last question, if it needs to be upgraded, where can I get the upgrade? > > Regards, > > Drew Whittle > System Admin - Black Albatross > University of Otago > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Second rack config, route distribution questions
From: David Bolen <db3l@ans.net>
Date: 1998-12-10 18:42:02

Jesse Sipprell <jss@evcom.net> writes: > I have read that the netserver can aggregate the pool and announce > it as a single route, however I have never been able to get it to > work. What I do is use a simple access-list on the cisco side to > filter out all /32 announcements for the pool and nail down a static > route from the cisco to the netserver. After all, the pool will > never move to a different TCR, so.... Outside of the pool, I do as > above and redistribute into OSPF. Note that this still puts /32s > into OSPF because static IP customers are not in the pool and can > potentially move about between chassis. (BTW, using a HARC, it's > trivial to aggregate dial-up pools <grin>). A slightly different approach is to create a single static route to Null0 on the Cisco for the entire address space used at the site for which the Cisco is routing to the backbone (or multiple statics if the address space is more than one contiguous block), and redistribute those statics into your IGP (in our case it goes into both BGP and OSPF). Then, let your Cisco listen to all RIP announcements from the NETServers/ARCs but don't redistribute the RIP anywhere, and declare the ethernet a passive interface in your RIP configuration so the Cisco doesn't make any announcements of its own. This leaves you with a configuration where you send a minimum number of routes to the backbone, which at all times knows how to get to the Cisco for any addresses used by that site. The RIP announcements take care of the "next hop" from the Cisco to whatever NETServer or ARC is appropriate but exist only in the local routing tables (as /32s) of the Cisco and the NETServers/ARCs at the site. And if traffic tries to reach a user no longer on, it'll get to the Cisco but just die as the Cisco dumps it to the Null0 interface. There's also no need to change the Cisco configuration for any reconfigurations within the site, as long as such work remains within the overall address block(s) assigned to the site. > The only annoying bit is that ripv2 has to timeout if a static IP > customer disconnects and rapidly reconnects to a different chassis, > so they can potentially perceive an initial loss-of-service during a > rapid reconnection. Doesn't happen very often though. One could > play with ripv2 hold-down timers, I suppose. That's what we do - we drop the hold down timers to nothing on our Ciscos. Since the only purpose for the RIP announcement is to get the next hop right on the Cisco, it really doesn't hurt to let the Cisco adjust instantaneously to any change. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: RE: (usr-tc) Second rack config, route distribution questions
From: Ray Bellis <rpb@community.net.uk>
Date: 1998-12-10 18:51:07

> You don't need to worry about Framed-Route, this is used to > send/receive RIP with your customers (typically not done). > I always set it to `None'. All you > need to do is: > > Framed-IP-Address = 10.0.0.1, > Framed-IP-Netmask = 255.255.255.224 > > This will cause the netserver to broadcast a ripv2 route for 10.0.0.1/27, > which the router you bounce the ripv2 off can then distribute into OSPF. My RADIUS database already appears as you describe (except my dictionary doesn't contain the '-IP-' part of the Radius attribute name, I assume it's the same thing). I usually use unnumbered links for my LAN customers, and so I've previously had to install static routes on the NETserver for the customer's range with the next hop set to the customer router's IP address *but* with a hop count of 2. This has previously been necessary to get any routed communication with the customer's LAN. I'm not convinced that what I've done today will drop the requirement to install a static route within the NETserver itself, since I'm already setting the RADIUS attributes as you describe. The only thing that has changed is that I'm now advertising RIPv2. thanks, Ray. -- Ray Bellis, MA(Oxon) - Technical Director - Oxford CommUnity Internet plc Windsor House, 12 High Street, Kidlington, OXFORD OX5 2PJ UK Telephone: +44-1865-856000 Fax: +44-1865-856001 Email: ray.bellis@community.net.uk URL: http://www.community.co.uk/

Subject: Re: (usr-tc) Second rack config, route distribution questions
From: Jesse Sipprell <jss@evcom.net>
Date: 1998-12-10 19:15:32

On Thu, Dec 10, 1998 at 06:42:02PM -0500, David Bolen wrote: > Jesse Sipprell <jss@evcom.net> writes: > > > I have read that the netserver can aggregate the pool and announce > > it as a single route, however I have never been able to get it to > > work. What I do is use a simple access-list on the cisco side to > > filter out all /32 announcements for the pool and nail down a static > > route from the cisco to the netserver. After all, the pool will > > never move to a different TCR, so.... Outside of the pool, I do as > > above and redistribute into OSPF. Note that this still puts /32s > > into OSPF because static IP customers are not in the pool and can > > potentially move about between chassis. (BTW, using a HARC, it's > > trivial to aggregate dial-up pools <grin>). > > A slightly different approach is to create a single static route to > Null0 on the Cisco for the entire address space used at the site for > which the Cisco is routing to the backbone (or multiple statics if the > address space is more than one contiguous block), and redistribute > those statics into your IGP (in our case it goes into both BGP and > OSPF). > > Then, let your Cisco listen to all RIP announcements from the > NETServers/ARCs but don't redistribute the RIP anywhere, and declare > the ethernet a passive interface in your RIP configuration so the > Cisco doesn't make any announcements of its own. > > This leaves you with a configuration where you send a minimum number > of routes to the backbone, which at all times knows how to get to the > Cisco for any addresses used by that site. The RIP announcements take > care of the "next hop" from the Cisco to whatever NETServer or ARC is > appropriate but exist only in the local routing tables (as /32s) of > the Cisco and the NETServers/ARCs at the site. And if traffic tries > to reach a user no longer on, it'll get to the Cisco but just die as > the Cisco dumps it to the Null0 interface. > > There's also no need to change the Cisco configuration for any > reconfigurations within the site, as long as such work remains within > the overall address block(s) assigned to the site. My only problem with this technique (the not-redistributing-RIP part, not "nail to null0 and aggregate into EBGP", which is the standard way to make BGP work) is that it doesn't scale well on a WAN. For example, consider the following simplistic fully-meshed WAN: tcr1 tcr2 \ / Router A ----------------- Router B \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / - Router C - |------------- To backbone(s) Now, using your scenario, a customer transitioning from tcr2 to tcr1 cannot have the same subnet (even a /32) because Router C won't know how to reach it. You've treated A,B & C as individual sites, nailing routes to null0 in each one, so C still thinks the route to customer goes through B even though it has moved. In order to make this work with your technique, I would have to do IP assignments based on the location (A|B) rather than simply doing them universally and letting RIP->OSPF take care of the whole thing; which is not desireable, IMO. -- Jesse Sipprell Technical Operations Director Evolution Communications, Inc. 800-496-4736 (ext 106) * Finger jss@evcom.net for my PGP Public Key *

Subject: Re: (usr-tc) Second rack config, route distribution questions
From: David Bolen <db3l@ans.net>
Date: 1998-12-10 20:10:05

Jesse Sipprell <jss@evcom.net> writes: > My only problem with this technique (the not-redistributing-RIP > part, not "nail to null0 and aggregate into EBGP", which is the > standard way to make BGP work) is that it doesn't scale well on a > WAN. Oh, I don't know - I think scale is kind of at the crux of things - I'm certainly not a fan of injecting arbitrary routes (/32s in the case of individual users) from RIP into a the wide-area portion of a network of hundreds of sites and hundreds of thousands of modems :-) You are correct however, that this does not permit a given user to have a fixed /32 (or any route) no matter what number they call into, but such fixed operations are handled at the "site" level (normally a single access number). If the cross-site mobility is a design requirement for more than a small percentage of users in a particular network, then this probably necessarily the approach to use. > You've treated A,B & C as individual sites, nailing routes to null0 in > each one Not so much A, B, and C, but A and B yes - although in our case we have a lot more than a single TC chassis hung from a given router. In our configuration, with very few exceptions the addressing plan is pre-allocated amongst all sites, in a manner that permits aggregation of the address blocks at each higher level of the system (such that within the core there are very few routes flying around). It also has the advantage that we don't flap a route for each dialup user, but keep such activity local between the NETServer/ARC and its local Cisco. > In order to make this work with your technique, I would have to do > IP assignments based on the location (A|B) rather than simply doing > them universally and letting RIP->OSPF take care of the whole thing; > which is not desireable, IMO. I think it's a question of scale. For us, the address allocation in a scaleable (aggregateable) fashion was definitely desirable. On a global level, I didn't want thousands of dialup user routes (or whatever churn of the total population) flapping through the system each time a user hung up or called in. So the address allocation is carefully allocated. It supports fixed addressing with mobility within a site (normally an access number), but not across access numbers without punching explicit holes out of the allocation - not a normal event. As with most network designs, one solution won't fit everyone - but I think it does still address the original question at least as far as the e-mail described it (which of course, didn't cover other requirements that might be true across more than the pool that was under discussion). -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: Re: (usr-tc) Second rack config, route distribution questions
From: David Bolen <db3l@ans.net>
Date: 1998-12-10 20:16:20

In my last note, I wrote (erroneously): > If the cross-site mobility is a design > requirement for more than a small percentage of users in a particular > network, then this probably necessarily the approach to use. ^^^^^^^^^^^^^^^^^^^^^^^^^ Urgh ... clearly this should say "... this is probably not ..." /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: Re: (usr-tc) VJ Header Compression
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-12-10 20:29:07

Thus spake MegaZone >Once upon a time Dan Hollis shaped the electrons to say... >>One wonders why such options as VJ and MTU are in radius at all then... >1. SLIP >2. Scripted login for PPP. And, as I mentioned in another post, at least *theoretically*, the NAS could re-start LCP with the new MTU setting, but given the sorry state of CPE PPP devices, I think its probably best that I can't think of a single NAS that does this. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) support woes
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-12-10 20:50:01

MegaZone was heard to say: >Once upon a time Allen Marsalis shaped the electrons to say... >>will be given a $500 credit on our next 4 chassis purchases! We may have >>purchased a support contract, but in effect, we have given 3COM a loan >>for a year and we are paying the interest! > >Makes one wonder how other vendors can afford to just give free 5x12 support, >free software upgrades, free server software, free management software, etc - >and still make a profit. Nah, those companies charge you want the hardware costs. How much is a P50 these days? --Ricky

Subject: RE: (usr-tc) Settings for Ch. T-1 on a HiPerDSP
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-10 20:51:05

>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Pete Ashdown >Sent: Thursday, December 10, 1998 3:50 PM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) Settings for Ch. T-1 on a HiPerDSP > > >Randy Doran said once upon a time: >> >>On a HiPerDSP, what do you have to change from the default settings to >>bring up a Channelized T-1? I have already set the "Signal Mode" to >>"robbedBit." The circuit appears to be up and all 24 DS0s are >"inService". >> I have verified that the circuit itself works by plugging it into a Dual >>T-1 card and calls came right in on the Quad modem cards. > >Smells like a Netserver in that chassis. Don't forget that you need to do >significant singing and dancing in order to get the Netserver to properly >recognize your HDM. I can't remember the exact command lines, but it won't >answer the phone until you do them. I think i know what singing and dancing you are talking about. I know the documentation doesn't tell you the following tricks but it is very easy to add a HiPer DSP card to a chassis with a NetServer. lets say you plug one in to slot 14: telnet to the NetServer set modem density 14 24 (By default the NetServer thinks slots 1-16 have 4 modems each) set modem s1-s100 inactive save all reset all sh modem If the start slot is 1 do the following: Add 4 if it is 2 set modem s5-s52 active (You can set s5-s76 active all at once but sometimes you have to do them separately. set modem s53-s76 active save all reset all Assuming you have never had a modem installed to correspond to ports s53-s76; In a few moments the NetServer will show ARP for ports s5-s52 and AR- or AR? for ports s53-s76 Reboot the NMC card to make ports s53-s76 go ARP Very easy once you have done this a few times. If all of the above doesn't set it up correctly rebooting the NetServer and repeating the above steps, if necessary, will. > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Second rack config, route distribution questions
From: Jesse Sipprell <jss@evcom.net>
Date: 1998-12-10 20:51:39

On Thu, Dec 10, 1998 at 08:10:05PM -0500, David Bolen wrote: > Jesse Sipprell <jss@evcom.net> writes: > > My only problem with this technique (the not-redistributing-RIP > > part, not "nail to null0 and aggregate into EBGP", which is the > > standard way to make BGP work) is that it doesn't scale well on a > > WAN. > > Oh, I don't know - I think scale is kind of at the crux of things - > I'm certainly not a fan of injecting arbitrary routes (/32s in the > case of individual users) from RIP into a the wide-area portion of a > network of hundreds of sites and hundreds of thousands of modems :-) You are correct, scale is very important. On a large scale, I wouldn't want /32s being announced all over the backbone either. I think our only difference in opinion is in the definition of "site". Rather than defining "site" as a POP with a single access number, I'm defining it as a "medium" sized network who's topology _roughly_ maps to a given geographical region. In this definition, I see no problem with /32s via OSPF seen by the entire site's network. If this site is part of a larger network, I would give the site it's own OSPF area, aggregate at the borders and disallow cross-site mobility of address space larger (erm, I guess "longer" is a better word) than /24. Conceptually the same thing that you are talking about. The reason "cross-access-number" portability is important on our network is because we operate in a region that has a great deal of local calling areas, and it's actually not uncommon for a customer to move between them. It's far easier for us to allocate address space for the entire region than for a specific POP. > > You've treated A,B & C as individual sites, nailing routes to null0 in > > each one > > Not so much A, B, and C, but A and B yes - although in our case we > have a lot more than a single TC chassis hung from a given router. Well, yes, that diagram was definitely too simplistic for a real-world network. ;) -- Jesse Sipprell Technical Operations Director Evolution Communications, Inc. 800-496-4736 (ext 106) * Finger jss@evcom.net for my PGP Public Key *

Subject: RE: (usr-tc) Now to solve my E1 PRI Card problem ...
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-10 21:07:59

>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ray Bellis >Sent: Thursday, December 10, 1998 6:39 PM >To: usr-tc@lists.xmission.com >Subject: (usr-tc) Now to solve my E1 PRI Card problem ... > > >Here's another curious one, I've seen it before on my old rack, and >ultimately managed to cure the fault, but now my new rack has it as well: > >I've had four quad cards in slots 10 thru 13, and they were >correctly listed >in the PRI console's card configuration menu. I've just added another 7 >cards in slots 2 thu 8, but the PRI console now shows: > > Slot# Type Slot# Type > 1 Dual-PRI 9 NONE > 2 NONE 10 Qbch-I_mdm > 3 NONE 11 Qbch-I_mdm > 4 Qbch-I_mdm 12 Qbch-I_mdm > 5 Qbch-I_mdm 13 Qbch-I_mdm > 6 NONE 14 NONE > 7 NONE 15 NONE > 8 NONE 16 ISDN-GW > >If I then try to run i:2,3,6,7,8 the system seems to completely ignore the >command and takes me back to the card configuration menu. >Hardware reset of >the PRI or the NetServer card has no effect. With this configuration the >other 5 new cards are being ignored for incoming calls. Before you can map the modems to the PRI you must make certain you have configured the modems correctly. You didn't mention that you did so... Load TCM 1. Click on the top light on one of your new modem cards. 2. Then hold down the control key and click on the top light of the rest of the new modem cards. 3. Go to configure/program setting/Line Interface Options 4. Go down to the bottom where it says Line Interface source 5. If it's t1tdm change the first to pritdm. 6. With pritdm highlighted click copy 7. Click on the words "Line Interface Source" to highlight the whole row 8. hold down the control key and hit "v" for copy 9. click set/ok 10. go to configure/action commands/save to nvram 11. Once you have a success all the way down then change save to nvram to software reset. When the modems come back up they should be properly mapped to the dual PRI card. Let me know if they don't. > >Any ideas, anyone? > >thanks, > >Ray. > >-- >Ray Bellis, MA(Oxon) - Technical Director - Oxford CommUnity Internet plc >Windsor House, 12 High Street, Kidlington, OXFORD OX5 2PJ UK > Telephone: +44-1865-856000 Fax: +44-1865-856001 >Email: ray.bellis@community.net.uk URL: http://www.community.co.uk/ > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) strange "unauthenticated" very long stop record
From: Aaron Nabil <nabil@spiritone.com>
Date: 1998-12-10 21:14:58

Sorry I don't have the versions in front of me, anyone seen this before (note the acct-session-time)? Couldn't find a matching start record. Thu Dec 10 19:54:47 1998 User-Name = "unauthenticated" NAS-IP-Address = 192.168.0.235 Acct-Status-Type = Stop Acct-Session-Id = "17501764" Acct-Delay-Time = 0 Service-Type = 0 NAS-Port-Type = Async NAS-Port = 36 USR-Interface-Index = 1524 USR-Chassis-Call-Slot = 2 USR-Chassis-Call-Span = 1 USR-Chassis-Call-Channel = 12 USR-Unauthenticated-Time = 0 USR-Modem-Training-Time = 92864314 Calling-Station-Id = "" Called-Station-Id = "" USR-Modulation-Type = x2 USR-Simplified-MNP-Levels = ccittV42 USR-Simplified-V42bis-Usage = ccittV42bis USR-Connect-Speed = 33333_BPS Acct-Session-Time = 92864314 Acct-Terminate-Cause = Lost-Carrier Acct-Input-Octets = 0 Acct-Output-Octets = 0 NAS-Type = 3comHiperArc Timestamp = 913348487 -- Aaron Nabil

Subject: RE: (usr-tc) support woes
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-10 21:21:23

>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of MegaZone >Sent: Thursday, December 10, 1998 7:25 PM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) support woes > > >Once upon a time matthews shaped the electrons to say... >>authorize another 3Com chassis purchase. Are Bay and Lucent's >tech support >>prices and competence any better? I don't know. But could they be any > >Lucent RABU: >5x12 support: free >All OS upgrades: free >Server software (RADIUS & ChoiceNet): free >Management software (100% Java - PMVision, PMTools, debuggers, etc): free > >All manuals, notes, etc are freely available on their website. > >They also readily cross-ship RMA repalcements when there is a problem. >Regularly doing so even for units out of warranty. > >I will say I haave always thought they charge WAY too much for 7x24 support >contracts, but they claim to be working on a new pricing structure that is >better balanced for smaller players. > >I'd also give them modem edge to 3Com. ALL products have modem issues, but >the 3Com modems tend to connect to the widest variety of modems. >I'd have to >give the NAS OS edge to Lucent though. HW - the HiPer is a nice product. >It falls between the PM-3 and PM-4 in density. The PM-3 is up for >replacement >soon I bet (I've heard talk of a PM-3+ with 4 or 8 ports). The PM-4 is out >and hits 864 DS0s with T1/PRI lines at this point, more to come. > >I'm really curious to see if 3Com could ever manage to double the >density on >the HiPer to manage to handle a T3. Unless they have scrapped their designs the 3COM chassis will eventually increase even further in density. The rough picture I saw had 14 48 modem DSP's and 2 very high powered HiPer ARC's. All I ever saw was a rough schematic. It may have been a fairy tale but it looked real enough. I don't know if it will require a different chassis. I haven't examined the specs of the backplane but it seems like it would run out of bandwidth eventually. Also, I haven't seen anything on this other then a small note in a 3COM internal use only book for HiPer DSP's, but it mentioned support for a 60 modem card. > >-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! > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) support woes
From: Brian <signal@shreve.net>
Date: 1998-12-10 21:29:55

> > Unless they have scrapped their designs the 3COM chassis will eventually > increase even further in density. The rough picture I saw had 14 48 modem > DSP's and 2 very high powered HiPer ARC's. All I ever saw was a rough > schematic. It may have been a fairy tale but it looked real enough. I > don't know if it will require a different chassis. I haven't examined the > specs of the backplane but it seems like it would run out of bandwidth > eventually. > > Also, I haven't seen anything on this other then a small note in a 3COM > internal use only book for HiPer DSP's, but it mentioned support for a 60 > modem card. AFAIK, all that would be needed to do is to double up the amount of modems each DSP drives. Currently each DSP does 4 softmodems (I think thats right.....6 dsp's, 24 modems?), and so you would have to write it so each DSP did 8 modems, which is very doable I would think......... Brian > > > > >-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! > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and 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

Subject: RE: (usr-tc) support woes
From: David Bolen <db3l@ans.net>
Date: 1998-12-10 21:50:17

"Brian K McIntire" <bmcintire@commnet.com> writes: (ObCaveat: I really don't have any special knowledge on this subject) > I > don't know if it will require a different chassis. I haven't examined the > specs of the backplane but it seems like it would run out of bandwidth > eventually. If I recall correctly, the midplane in the TC chassis was documented at an aggregate bandwidth of about 1Gbps. Assuming a full 256 timeslots for the TDM bus that's only about 16Mbps for that, so there should be plenty of capacity on the packet bus for loads of density, providing you can manage to get it in and out of the chassis. The TDM was really the most limiting factor, which of course became a non-issue when the HiperDSPs integrated the span and modem support on the single card. > Also, I haven't seen anything on this other then a small note in a 3COM > internal use only book for HiPer DSP's, but it mentioned support for a 60 > modem card. Well, presuming capacity were handled by doubling in some manner (whether through additional sharing of DSPs or denser cards), one would imagine that such doubling would hold both for the main HiperDSP card as well as the E1 daughtercard, potentially yielding a 60 port dual E1 configuration :-) -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: (usr-tc) WTB: HDM's
From: Brian <signal@shreve.net>
Date: 1998-12-10 22:11:18

If anyone is selling HDM's please email me, we are wanting to purchase some. 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

Subject: (usr-tc) New 3Com/USR/Sportster firmware 5.0.0
From: Richard Gamberg <bbhi@prodigy.net>
Date: 1998-12-10 22:17:00

Available for at least some models now. It made the Sportster I have here (1786-02) faster than my Courier (to IBM/IGN TotalControl). Update at http://808hi.com/56k/ Aloha, Richard http://808hi.com/56k/ 56k=v.Unreliable

Subject: RE: (usr-tc) Second rack config, route distribution questions
From: Ray Bellis <rpb@community.net.uk>
Date: 1998-12-11 00:26:33

> Yes, it is the same thing. ;) RADIUS attributes are actually > just numbers, the "names" such as "Framed-IP-Address" or > "Framed-Address" are simply mappings from your dictionary. > I believe that the official naming for Address/Netmask are now > "Framed-IP-Address" and "Framed-IP-Netmask", so your dictionary > may be out of date, but it doesn't actually technically matter. I knew that, I was just making sure we were actually talking about the same numbered attribute! :-) > Here's what happens you you use Framed-IP-Address = 10.0.0.1, > Framed-IP-Netmask = 255.255.255.224: > > 1. Caller connects and is handed the IP address 10.0.0.1. > > 2. Netserver installs a route for 10.0.0.0/27, with the next hop pointing > to 10.0.0.1 > > 3. Netserver broadcasts this route via ripv2. I'll try it out on a friendly customer tomorrow and let you all know if it actually works ;-) thanks again, Ray. -- Ray Bellis, MA(Oxon) - Technical Director - Oxford CommUnity Internet plc Windsor House, 12 High Street, Kidlington, OXFORD OX5 2PJ UK Telephone: +44-1865-856000 Fax: +44-1865-856001 Email: ray.bellis@community.net.uk URL: http://www.community.co.uk/

Subject: (usr-tc) Now to solve my E1 PRI Card problem ...
From: Ray Bellis <rpb@community.net.uk>
Date: 1998-12-11 00:39:29

Here's another curious one, I've seen it before on my old rack, and ultimately managed to cure the fault, but now my new rack has it as well: I've had four quad cards in slots 10 thru 13, and they were correctly listed in the PRI console's card configuration menu. I've just added another 7 cards in slots 2 thu 8, but the PRI console now shows: Slot# Type Slot# Type 1 Dual-PRI 9 NONE 2 NONE 10 Qbch-I_mdm 3 NONE 11 Qbch-I_mdm 4 Qbch-I_mdm 12 Qbch-I_mdm 5 Qbch-I_mdm 13 Qbch-I_mdm 6 NONE 14 NONE 7 NONE 15 NONE 8 NONE 16 ISDN-GW If I then try to run i:2,3,6,7,8 the system seems to completely ignore the command and takes me back to the card configuration menu. Hardware reset of the PRI or the NETserver card has no effect. With this configuration the other 5 new cards are being ignored for incoming calls. Any ideas, anyone? thanks, Ray. -- Ray Bellis, MA(Oxon) - Technical Director - Oxford CommUnity Internet plc Windsor House, 12 High Street, Kidlington, OXFORD OX5 2PJ UK Telephone: +44-1865-856000 Fax: +44-1865-856001 Email: ray.bellis@community.net.uk URL: http://www.community.co.uk/

Subject: Re: (usr-tc) strange "unauthenticated" very long stop record
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1998-12-11 07:17:37

: Sorry I don't have the versions in front of me, anyone seen : this before (note the acct-session-time)? Couldn't find a : matching start record. : : Thu Dec 10 19:54:47 1998 : User-Name = "unauthenticated" : NAS-IP-Address = 192.168.0.235 [...] : Acct-Session-Time = 92864314 Bizarre. That number represents a session in excess of 35 months. Reboot more often. ;^)

Subject: RE: (usr-tc) strange "unauthenticated" very long stop record
From: Ricky <rickyz@mindspring.com>
Date: 1998-12-11 07:56:07

------ =_NextPart_000_01BE24DB.BC3FFB20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good deal; I'm not crazy. Just loaded 4.1.72-7 on two different hiperARC's, and they both randomly = take calls that show up like this. Can't pin it to any specific user, = just randomly happens. Doing a mon ppp shows a failed authentication = attempt for " ". (just period; no username). Then, an acounting packet = is sent for a user named "unauthenticated". And the service type is = always "0". Called 3Com to see if this was a known issue, and they were = stumped. I KNOW this only started after loading 4.1.72-7 though. Still = have 1.2.5 on the DSP's...maybe 3Com's doing their testing for 4.1.72-7 = with more current code on their DSP's? I hadn't noticed what the account session time was on ours, but it = shouldn't be more than 24 hours; we JUST loaded that ARC code yesterday. o o =20 \_ _/=20 <(@@)> ----------------000----()----000------------------- RickyZ@mindspring.com THE TRUTH IS OUT THERE 00O O00 =A9 -----Original Message----- Sent: Friday, December 11, 1998 12:15 AM Sorry I don't have the versions in front of me, anyone seen this before (note the acct-session-time)? Couldn't find a=20 matching start record. Thu Dec 10 19:54:47 1998 User-Name =3D "unauthenticated" NAS-IP-Address =3D 192.168.0.235 Acct-Status-Type =3D Stop Acct-Session-Id =3D "17501764" Acct-Delay-Time =3D 0 Service-Type =3D 0 NAS-Port-Type =3D Async NAS-Port =3D 36 USR-Interface-Index =3D 1524 USR-Chassis-Call-Slot =3D 2 USR-Chassis-Call-Span =3D 1 USR-Chassis-Call-Channel =3D 12 USR-Unauthenticated-Time =3D 0 USR-Modem-Training-Time =3D 92864314 Calling-Station-Id =3D "" Called-Station-Id =3D "" USR-Modulation-Type =3D x2 USR-Simplified-MNP-Levels =3D ccittV42 USR-Simplified-V42bis-Usage =3D ccittV42bis USR-Connect-Speed =3D 33333_BPS Acct-Session-Time =3D 92864314 Acct-Terminate-Cause =3D Lost-Carrier Acct-Input-Octets =3D 0 Acct-Output-Octets =3D 0 NAS-Type =3D 3comHiperArc Timestamp =3D 913348487 --=20 Aaron Nabil - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message. ------ =_NextPart_000_01BE24DB.BC3FFB20 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IhIMAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYA0AEAAAEAAAAQAAAAAwAAMAIAAAAL AA8OAAAAAAIB/w8BAAAAUQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHVzci10Y0BsaXN0cy54 bWlzc2lvbi5jb20AU01UUAB1c3ItdGNAbGlzdHMueG1pc3Npb24uY29tAAAAAB4AAjABAAAABQAA AFNNVFAAAAAAHgADMAEAAAAaAAAAdXNyLXRjQGxpc3RzLnhtaXNzaW9uLmNvbQAAAAMAFQwBAAAA AwD+DwYAAAAeAAEwAQAAABwAAAAndXNyLXRjQGxpc3RzLnhtaXNzaW9uLmNvbScAAgELMAEAAAAf AAAAU01UUDpVU1ItVENATElTVFMuWE1JU1NJT04uQ09NAAADAAA5AAAAAAsAQDoBAAAAHgD2XwEA AAAaAAAAdXNyLXRjQGxpc3RzLnhtaXNzaW9uLmNvbQAAAAIB918BAAAAUQAAAAAAAACBKx+kvqMQ GZ1uAN0BD1QCAAAAAHVzci10Y0BsaXN0cy54bWlzc2lvbi5jb20AU01UUAB1c3ItdGNAbGlzdHMu eG1pc3Npb24uY29tAAAAAAMA/V8BAAAAAwD/XwAAAAACAfYPAQAAAAQAAAAAAAAC+WgBBIABAD0A AABSRTogKHVzci10Yykgc3RyYW5nZSAidW5hdXRoZW50aWNhdGVkIiB2ZXJ5IGxvbmcgc3RvcCBy ZWNvcmQAmRUBBYADAA4AAADOBwwACwAHADgABwAFADcBASCAAwAOAAAAzgcMAAsABwAvACwABQBT AQEJgAEAIQAAADA1RkM2N0IyNzg5MEQyMTE4NDFFNDQ0NTUzNTQwMDAwAMMGAQOQBgAQCwAAIQAA AAsAAgABAAAACwAjAAAAAAADACYAAAAAAAsAKQAAAAAAAwAuAAAAAAADADYAAAAAAEAAOQBgdUee BSW+AR4AcAABAAAAPQAAAFJFOiAodXNyLXRjKSBzdHJhbmdlICJ1bmF1dGhlbnRpY2F0ZWQiIHZl cnkgbG9uZyBzdG9wIHJlY29yZAAAAAACAXEAAQAAABYAAAABviUFni2yZ/wGkHgR0oQeREVTVAAA AAAeAB4MAQAAAAUAAABTTVRQAAAAAB4AHwwBAAAABwAAAHJpY2t5egAAAwAGEJ4btqgDAAcQfgcA AB4ACBABAAAAZQAAAEdPT0RERUFMO0lNTk9UQ1JBWllKVVNUTE9BREVENDE3Mi03T05UV09ESUZG RVJFTlRISVBFUkFSQ1MsQU5EVEhFWUJPVEhSQU5ET01MWVRBS0VDQUxMU1RIQVRTSE9XVVBMSUsA AAAAAgEJEAEAAADcBwAA2AcAADEOAABMWkZ1Pk3UfHcACgEDAfcgAqQD4wIAY4JoCsBzZXQwIAcT hwKDAFAO9nBycTIPX78CkhFxEN8PswXrAoMzAuOxEYlUYWgDcQKDNBLrTQ/2fQqACMggOwlvMsQ1 NRmKMTI4CiQZj7ccARihDGBjAFALA2MAQcELYG5nMTAzFYELxGggR28EcCABABAxIMBJJ20gbm8F QAUAcGF6eS4KogqECoBKbHVzBUAJAGEBAB+wNIguMS4BwC03IAIgsCB0d28fwAaQZgSQGwnwBUBo BSAEkEFSQzAncywgAHAfsHRo2GV5IAbgJTAgIMAlAM0DcGwlYAGQa2UgoAdA1mwEICUwYQVAcxaw B+B0dXAiEGkmgSUwBAAuVCBDAHAnBUBwC4AgumkFQHQjcABwJWBzJFCyYwaQaWMnoA+wciTQ7moh 4iXXEbBwJFAAgChw1ERvC4BnJOAgBGADoF8rwCfAJ2IEICyQZgtwbHkiYWF1JTECMCowJzBp4yMh JzB0ZW0FMQIQBcB2Ii/AKHAoKsMkUS7QZKcgECBwKlNuYQeAKShw3lQuUSTSJOAFoHUucSxh/Qqw YyaABUAEACdQI/Ivkt8skCpiIGAxgR+wIjKgLimbCYAv8UElBDOhcnYqMB0oEXkkUDNyB0B3YXl5 BCAiMC/xKJAm0CJhM18IUCBQKWEPsDdxZigjIOs34C1yayBwdykRBBAKUM0k2Xcj0SdQdHUvUAmA gShwSSBLTk9XOdT/AiAmMSHwCsA14STgAYA0gZ8iIixSIpclMAhgZ2gocG5TLoAm0CuRdiaQIrAy jC41IxM2kURTUCSw5i5CIADAeWImkDjyJLD3H8AsQyUxaQXALzAh8CxSvy+SIpcD8CWhBGA8EWMI cL8j4wWgAQBBVUOxQdM/IRp7PNARsGQosiBxNwEfsHf/JyI2ggDQMoMzoQQQLtIugN8HgDojIyEI YSTBYi4wKSL5J2F1bEiTQoFFgycRA6A8MjQkIEuyIBA78CBKeFVTVCIWJxMkgUZEeXtD8QSQZDfw IQsd1gLRMfYgAzAeMmJSgFMfU5UeIfcYECNwU5NvHiJUdSEVVYQnVu9USVKBXF9SgF8vz1KUISNX X1Q6PCgKIA/g5EBAUuEpPllYCvQqIPAtMTQ0AUAn4F3DDNDHXcMeMBWAaSAtX11V4zppD+AwYNBe 6WBWKCl/YQ9gvl9uVj9SgwLRGBBSQSowa3laQG0LgGTXKdAFEB6QLgWgbVvhY0GPIRVS92MEUlJU SEUWgNxSVWpgICAF8E9qwGpS9FJFZVczZB9tb25/ZRnvHeZab2lbYLJPayBg0GZm+CdhOWhiISQV cVzqF0LMMTZRaifgMzZosQNgrS8wYwVAbtNPBRBnC4DHB0AF0EqBYWdlb4t3BO9oswsxdwRdijhg 4V6FUvDaRgNhOgyDW/FBCsAjIQZOAaADEVtTTVRQ9joxcH2xQCnQQ7ApMAIg+mVoIl1oxwZgAjB8 p3xg9mlQwSTQRAWQL0BCgAXAhDExJNAxOTk4QPBIMjoxQUBBTWjHVAZvfKch4HItdGNA9yfgIfAo YHhngEqTaCN/p1h1Ymp3MXynKIRUKb88MSXReKA1Dy/QQNByJWD3CQAsYSHwbyfAHEAFoQsx33k/ ekh2lAu2ISlTBbCJwf880CYAKLJAszaCiaFKogQgdykBA1EkAW85wAeAJNJ5/38ROWILkCEjOeNC gC+RJpDOKCBxj2RJ8XQtSnWEgPkHcSk/UoAIUUzEKiAlAf8skCEUAMCEkCQwihM+AYqFeyELMeB1 gWJA8A/ggkA6cDU0OjQjAIJCWZxVrSpxLX2QSxE9iH8iWZwATkFTLUlQLUH8ZGQcQAQRm5CCQEEg dbBIOC4wQRAzNVmcQc+T0kBQJzAh4C1UN1KbkN9AUIpgn4+gkZQlSR+wm5GQMTc1MKPgNjScvfeg Y4FwC2B5oRBLApuQaLW/cTYGYTbyoRamfZ2iUAkR4aEWQXN5bgDgqH+pguebgXawmh1TUp3QAjAE kK8tsKexrWABAHiegjVN8PmsTy1DEbBKkaEAOIKgoP8JAKviVhWvL7A3CrADoJ6R97E/r9yv4W5/ IAMgnpGxL12tQFU1PKX/rMhNBHFtv6EQIMALgCxRuGaewDikQP4zXcBZnDiCusKgsqNInL1/OIS9 T7kPuhFMsL+0oSV4e7ZPrUBTB3ALUCoRuEFN8k6d8ExlQNAm4ZuQSgDxKTB0VjTC38PrxdF9sP+h AJrweJHFWcgBxg+v0AIgP38goIIkUCJhrAHLkl9CvFBTpH+i6LsPzE9UBJCfZ4E10bBRKmGbgUxv IfC/sFFF8AiRzs+T8K1gcC4wv3ewd0APwJ5ypn2gY08uMFfTL5z9oSUzaDFIJENyX6qNB2MBkC9Q zhIxHtA0+jjacDdRDgqAbtCWBX05/9srWZWDoCegAICGgATyQoH/KWGEVCTQM7EuAQOgL0AtwTUp UiIAwGqKwQNwb0D/hSqctkUzm7HeuIRUL9ApAfs2ggbgZCVgkOE2ggeBeIL/IQV8UAWxC4AvkZZx LtIjIf8jkHighOEjEAXAHECIEAiQ/zbwRDIt0S1xJQEG8B+w5dXPM5OK5S/AJUBscC/QKWH/NoOb UiJAnjMocCwhIGPQsvxxdXcRkDORcAhw5c0YoQIA8AADABAQAAAAAAMAERABAAAAAwCAEP////9A AAcwYAZNcgQlvgFAAAgwYAZNcgQlvgELACSACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMA JYAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAmgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUA ALcNAAAeACeACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA4LjAAAwAogAggBgAAAAAA wAAAAAAAAEYAAAAAAYUAAAAAAAALACmACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAKoAI IAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwArgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAA AAAeACyACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgAtgAggBgAAAAAAwAAA AAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4ALoAIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAA AQAAAAAAAAAeAD0AAQAAAAUAAABSRTogAAAAAAMADTT9NwAASF0= ------ =_NextPart_000_01BE24DB.BC3FFB20--

Subject: (usr-tc) strange "unauthe
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1998-12-11 08:12:00

Yep. I have reported this to 3Com before. It only happens on unauthenticated users and intermittiently. I am not sure what the status on it is. Maybe Krish can jump in ? It started after they added accounting reporting for unauthenticated users so we could track hackers trying to break in via RADIUS. I forget which version of HiPerArc code that was in. Jeff Binkley ASA Network Computing u>Sorry I don't have the versions in front of me, anyone seen u>this before (note the acct-session-time)? Couldn't find a u>matching start record. u>Thu Dec 10 19:54:47 1998 u> User-Name = "unauthenticated" u> NAS-IP-Address = 192.168.0.235 u> Acct-Status-Type = Stop u> Acct-Session-Id = "17501764" u> Acct-Delay-Time = 0 u> Service-Type = 0 u> NAS-Port-Type = Async u> NAS-Port = 36 u> USR-Interface-Index = 1524 u> USR-Chassis-Call-Slot = 2 u> USR-Chassis-Call-Span = 1 u> USR-Chassis-Call-Channel = 12 u> USR-Unauthenticated-Time = 0 u> USR-Modem-Training-Time = 92864314 u> Calling-Station-Id = "" u> Called-Station-Id = "" u> USR-Modulation-Type = x2 u> USR-Simplified-MNP-Levels = ccittV42 u> USR-Simplified-V42bis-Usage = ccittV42bis u> USR-Connect-Speed = 33333_BPS u> Acct-Session-Time = 92864314 u> Acct-Terminate-Cause = Lost-Carrier u> Acct-Input-Octets = 0 u> Acct-Output-Octets = 0 u> NAS-Type = 3comHiperArc u> Timestamp = 913348487 u>-- u>Aaron Nabil 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. u> CMPQwk 1.42 9999

Subject: RE: (usr-tc) Settings for Ch. T-1 on a HiPerDSP
From: matthews <matthews@brunnet.net>
Date: 1998-12-11 08:26:25

On Thursday, December 10, 1998 10:51 PM, Brian K McIntire [SMTP:bmcintire@commnet.com] wrote: > I think i know what singing and dancing you are talking about. I know the > documentation doesn't tell you the following tricks but it is very easy to > add a HiPer DSP card to a chassis with a NetServer. lets say you plug one > in to slot 14: How well does the NETServer perform when faced with one or two HDMs in addition to 12 quads? Be Seeing You... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Matthew Stainforth<>Technical Services Manager<>BrunNet Inc.<>(506)450-4562 Don't rush me, sonny. You rush a miracle maker and you get rotten miracles. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Subject: RE: (usr-tc) Now to solve my E1 PRI Card problem ...
From: Ray Bellis <rpb@community.net.uk>
Date: 1998-12-11 08:29:16

> Before you can map the modems to the PRI you must make > certain you have configured the modems correctly. You > didn't mention that you did so... Already tried, I'm afraid, although I usually do it with AT%D2 in the INIT string instead of using TCM. thanks anyway, Ray. -- Ray Bellis, MA(Oxon) - Technical Director - Oxford CommUnity Internet plc Windsor House, 12 High Street, Kidlington, OXFORD OX5 2PJ UK Telephone: +44-1865-856000 Fax: +44-1865-856001 Email: ray.bellis@community.net.uk URL: http://www.community.co.uk/

Subject: RE: (usr-tc) Now to solve my E1 PRI Card problem ...
From: Ray Bellis <rpb@community.net.uk>
Date: 1998-12-11 08:50:24

> > Before you can map the modems to the PRI you must make > > certain you have configured the modems correctly. You > > didn't mention that you did so... > > Already tried, I'm afraid, although I usually do it with AT%D2 in the > INIT string instead of using TCM. Problem solved, I had to do a hardware reset of the modem cards using TCM, resetting the individual modems from the NETserver hadn't been enough, even though TCM was already showing the correct line source for each modem. Ray. -- Ray Bellis, MA(Oxon) - Technical Director - Oxford CommUnity Internet plc Windsor House, 12 High Street, Kidlington, OXFORD OX5 2PJ UK Telephone: +44-1865-856000 Fax: +44-1865-856001 Email: ray.bellis@community.net.uk URL: http://www.community.co.uk/

Subject: Re: (usr-tc) strange "unauthenticated" very long stop record
From: Jamie Orzechowski <mhz@ripnet.com>
Date: 1998-12-11 09:07:05

I am running 4.1.72-7 I I saw the same unauthenticated entries also... I just turned log_unauthenticated calls off in the ARC for now ... ----- Original Message ----- Sent: Friday, December 11, 1998 7:17 AM >: Sorry I don't have the versions in front of me, anyone seen >: this before (note the acct-session-time)? Couldn't find a >: matching start record. >: >: Thu Dec 10 19:54:47 1998 >: User-Name = "unauthenticated" >: NAS-IP-Address = 192.168.0.235 >[...] >: Acct-Session-Time = 92864314 > >Bizarre. That number represents a session in excess of 35 months. > >Reboot more often. > >;^) > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) Settings for Ch. T-1 on a HiPerDSP
From: Randy Doran <randydoran@usa.net>
Date: 1998-12-11 09:30:48

I have done all that. The NetServer looks OK. I have many many (about 30)"doubled up" NetServer chassis (2 HiPerDSP cards) but they all are PRI. They all worked fine out of the box but I just can't get calls to set up on the Channelized T-1s. Those same T-1s work just fine in a dual T-1 card. The NetServer is v3.7.24 All ports are A R P and a show modems command shows this: command>sh modem Starting Slot: 2 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- - S1 S5 S9 S13 S17 S21 S25 S29 S33 S37 S41 S45 S49 S73 - - S2 S6 S10 S14 S18 S22 S26 S30 S34 S38 S42 S46 S50 S74 - - S3 S7 S11 S15 S19 S23 S27 S31 S35 S39 S43 S47 S51 S75 - - S4 S8 S12 S16 S20 S24 S28 S32 S36 S40 S44 S48 S52 S76 - S53 S77 S54 S78 S55 S79 S56 S80 S57 S81 S58 S82 S59 S83 S60 S84 S61 S85 S62 S86 S63 S87 S64 S88 -- Press Return for More -- S65 S89 S66 S90 S67 S91 S68 S92 S69 S93 S70 S94 S71 S95 S72 S96 Randy Doran Circuit Engineer \ Dialup Network Coordinator e.spire Communication's CyberGate Internet Services At 08:51 PM 12/10/98 -0600, Brian K McIntire wrote: >> >>Randy Doran said once upon a time: >>> >>>On a HiPerDSP, what do you have to change from the default settings to >>>bring up a Channelized T-1? I have already set the "Signal Mode" to >>>"robbedBit." The circuit appears to be up and all 24 DS0s are >>"inService". >>> I have verified that the circuit itself works by plugging it into a Dual >>>T-1 card and calls came right in on the Quad modem cards. >> >>Smells like a Netserver in that chassis. Don't forget that you need to do >>significant singing and dancing in order to get the Netserver to properly >>recognize your HDM. I can't remember the exact command lines, but it won't >>answer the phone until you do them. > >I think i know what singing and dancing you are talking about. I know the >documentation doesn't tell you the following tricks but it is very easy to >add a HiPer DSP card to a chassis with a NetServer. lets say you plug one >in to slot 14: > >telnet to the NetServer >set modem density 14 24 (By default the NetServer thinks slots 1-16 have 4 >modems each) >set modem s1-s100 inactive >save all >reset all >sh modem >If the start slot is 1 do the following: Add 4 if it is 2 >set modem s5-s52 active (You can set s5-s76 active all at once but >sometimes you have to do > them separately. >set modem s53-s76 active >save all >reset all >Assuming you have never had a modem installed to correspond to ports >s53-s76; In a few moments the NetServer will show ARP for ports s5-s52 and >AR- or AR? for ports s53-s76 >Reboot the NMC card to make ports s53-s76 go ARP > >Very easy once you have done this a few times. If all of the above doesn't >set it up correctly rebooting the NetServer and repeating the above steps, >if necessary, will.

Subject: RE: (usr-tc) strange "unauthenticated" very long stop record
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-12-11 09:40:17

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil |Sent: Thursday, December 10, 1998 11:15 PM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) strange "unauthenticated" very long stop record | | | |Sorry I don't have the versions in front of me, anyone seen |this before (note the acct-session-time)? Couldn't find a |matching start record. | |Thu Dec 10 19:54:47 1998 | User-Name = "unauthenticated" | NAS-IP-Address = 192.168.0.235 | This record shows a user that connected and didn't get through authentication. The time is broken and will be fixed in an upcoming service release. It is used to track failed attempts at login. You don't get a Start/Stop pair for these. -M

Subject: Re: (usr-tc) dspInterruptTimeout
From: Bob Purdon <bobp@southcom.com.au>
Date: 1998-12-11 10:29:45

> Technically, I believe it means that the DSP did not trip a programmed > interrupt to signal completion of an operation initiated by the > controller on the specific modem. This would normally be modem > specific (e.g., it's per each modem on the quad card since such cards > have individual DSPs for each modem). > > I don't know if I can claim it's _always_ a hardware failure, but we > always replace the hardware whenever we start seeing instances of > this, and I can't recall ever seeing one fix itself for any > significant period of time via resets, card reseats, etc.. Hmmm, OK. Looks like I replace it. It's happening on all 4 channels of the Quad... Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Subject: (usr-tc) Lost in the 3Com(USR) World
From: Drew Whittle <drew@csarc.otago.ac.nz>
Date: 1998-12-11 11:04:27

Hi Everyone, Please excuse this very uninformed and silly question post! (I found this list about a week ago, and until then I thought 3Com/USR TC Units were great - still do - just don't like the stories I am hearing) We have a single TC unit here, my question is what version of software should be running on it?? If I do a version on the netserver I get: Command> version U.S. Robotics Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.7.73 Build date: Mar 19 1998 Build time: 21:32:39 Network Interface Card: Ethernet & Frame Relay Combination (26) ISDN Interface Card : MUNICH32 (4) Packet Bus Circuit : Enhanced We are using it to handle incoming connections only at this point, although I believe we can use it as a router if we want to. (and replace my cisco! NEVER!) Also we are in New Zealand, (I don't know if there are different versions of the software for different regions etc.) Last question, if it needs to be upgraded, where can I get the upgrade? Regards, Drew Whittle System Admin - Black Albatross University of Otago

Subject: (usr-tc) online warranty registration
From: Brian <signal@shreve.net>
Date: 1998-12-11 16:10:05

I found online at Total Service where to register a product for 90 days support. After doing this, the software was unlocked. Is their a way online to obtain the contract number for that support? When you call 3Com they are going to want a contract number, and I didn't know if their was a way online to get that information. It would also be nice if their was a way to get a complete list of all your hubs you have registered with them, since I can't quite recall which hubs we have registered and which ones we have not. 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

Subject: (usr-tc) LT/Winmodem, HiperArc - Quadmodems
From: Laszlo Vecsey <master@internexus.net>
Date: 1998-12-11 16:56:12

Wondering if people could post some feedback and experiences with the LTWinmodem, relavent software revisions to get them working at high speed, etc. I recall seeing a webpage that discussed this but the hiper issue was left kind of iffy at the time (i.e., usr/3com or lucent was working on it)

Subject: Re: (usr-tc) LT/Winmodem, HiperArc - Quadmodems
From: Kingsley S. Grant <ksg@recorder.ca>
Date: 1998-12-11 17:05:15

Laszlo, If you can get the update for LT winmodem 5.23 everything works great (even better than the usr sportster) IBM has it on their site under the auto update area for IBM owners. Lucent has a version on their site but the problem is gettin a download that is not corrupted. (they say the trick is to right click on the link and save as instead of left click). 5.18 available in most places will work but not near as nice as 5.23 you can always have them add -V90=0 to the extra settings to get them on the net and go to their manufactures website in order to get the updates http://www.56k.com also has some links to firmware updates as well. Also look under Trouble shooting at 56k.com and then how to disable V90 on my modem for other init settings that will get other modem types hooking up at 33.6 so they can get on to update their code. King. Laszlo Vecsey wrote: > Wondering if people could post some feedback and experiences with the > LTWinmodem, relavent software revisions to get them working at high speed, > etc. I recall seeing a webpage that discussed this but the hiper issue was > left kind of iffy at the time (i.e., usr/3com or lucent was working on 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. -- Kingsley S. Grant RipNET Manager RipNET Internet Services 31 Broad Street Brockville ON, Canada K6V 4T9 (613) 342-3946 work (613) 342-8672 fax (613) 340-1144 Cel (613) 923-2596 Res (613) 341-0882 Pager 1-888-509-6677 E-Mail mailto:ksg@recorder.ca

Subject: RE: (usr-tc) LT/Winmodem, HiperArc - Quadmodems
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-11 17:23:54

http://www.808hi.com/56k/x2-lucent.htm#firmware You would be much better off with 5.32. You can get it from the above link ======================================================================== = Brian K. McIntire bmcintire@commnet.com http://www.commnet.com = = Project Manager, CommNetPlus, Indianapolis, IN 317-558-5050 x113 = = Your Remote Access and Security Experts! = = = = Our experienced technicians can design and install your high speed = = network for you. From Operating Systems and servers to routers and = = firewalls nobody does it better than CommNetPlus. Our Technical = = Support staff is available to you 24 hours a day to meet your needs.= = Offering remote management and monitoring packages for dedicated = = clients. (Specializing in ISP's). "Let us do the work for you!" = = Sales 800-845-2981 x117 (Aggressive Pricing) = = Serving North America and parts of Canada. Reselling to the world. = ======================================================================== >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Kingsley S. Grant >Sent: Friday, December 11, 1998 4:05 PM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) LT/Winmodem, HiperArc - Quadmodems > > > Laszlo, >If you can get the update for LT winmodem 5.23 everything works great (even >better than the usr sportster) IBM has it on their site under the >auto update >area for IBM owners. Lucent has a version on their site but the problem is >gettin a download that is not corrupted. (they say the trick is to >right click >on the link and save as instead of left click). 5.18 available in >most places >will work but not near as nice as 5.23 you can always have them >add -V90=0 to >the extra settings to get them on the net and go to their >manufactures website >in order to get the updates http://www.56k.com also has some links >to firmware >updates as well. Also look under Trouble shooting at 56k.com and >then how to >disable V90 on my modem for other init settings that will get other modem >types hooking up at 33.6 so they can get on to update their code. > King. > >Laszlo Vecsey wrote: > >> Wondering if people could post some feedback and experiences with the >> LTWinmodem, relavent software revisions to get them working at >high speed, >> etc. I recall seeing a webpage that discussed this but the hiper >issue was >> left kind of iffy at the time (i.e., usr/3com or lucent was >working on 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. > >-- >Kingsley S. Grant >RipNET Manager >RipNET Internet Services >31 Broad Street >Brockville ON, Canada >K6V 4T9 >(613) 342-3946 work >(613) 342-8672 fax >(613) 340-1144 Cel >(613) 923-2596 Res >(613) 341-0882 Pager >1-888-509-6677 >E-Mail mailto:ksg@recorder.ca > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) online warranty registration
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-11 17:28:18

No, you have to call your contact admin. Call 1-847-262-1150 for Louisiana She's there now. I just talked to her >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian >Sent: Friday, December 11, 1998 4:10 PM >To: USRobotics TC Mailing List >Subject: (usr-tc) online warranty registration > > >I found online at Total Service where to register a product for 90 days >support. After doing this, the software was unlocked. Is their a way >online to obtain the contract number for that support? When you call 3Com >they are going to want a contract number, and I didn't know if their was a >way online to get that information. It would also be nice if their was a >way to get a complete list of all your hubs you have registered with them, >since I can't quite recall which hubs we have registered and which ones we >have not. > >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. >

Subject: Re: (usr-tc) LT/Winmodem, HiperArc - Quadmodems
From: John Powell <jp@packet.ae.usr.com>
Date: 1998-12-11 20:10:21

There are no known issues on the quads with relation to the LT's. The best suggestion I have is to make sure the LT code is the latest. They have made lots of improvements lately. JP On Fri, 11 Dec 1998, Laszlo Vecsey wrote: > Wondering if people could post some feedback and experiences with the > LTWinmodem, relavent software revisions to get them working at high speed, > etc. I recall seeing a webpage that discussed this but the hiper issue was > left kind of iffy at the time (i.e., usr/3com or lucent was working on 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. >

Subject: RE: (usr-tc) strange "unauthenticated" very long stop record
From: Ricky <rickyz@mindspring.com>
Date: 1998-12-11 22:38:12

------ =_NextPart_000_01BE2556.F2B33AC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I guess we can appreciate the fact that the ARC will send these packets = at the very least to give a heads up that someone is having trouble = connecting. Here's OUR issue: the 4.1.72-7 code actually caused some = users who were previously able to connect using 4.0.30, to fail. 3Com = said to set log_unauthenticated false, but that doesn't stop the client = from NOT connecting. No one else has induced any connection problems by = going from 4.0.30 to 4.1.27-7? Is it required to delete config and = re-setup when going from 4.0.30 to 4.1.27-7?=20 Ricky -----Original Message----- Sent: Friday, December 11, 1998 10:40 AM |-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil |Sent: Thursday, December 10, 1998 11:15 PM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) strange "unauthenticated" very long stop record | | | |Sorry I don't have the versions in front of me, anyone seen |this before (note the acct-session-time)? Couldn't find a |matching start record. | |Thu Dec 10 19:54:47 1998 | User-Name =3D "unauthenticated" | NAS-IP-Address =3D 192.168.0.235 | This record shows a user that connected and didn't get through = authentication. The time is broken and will be fixed in an upcoming service release. It = is used to track failed attempts at login. You don't get a Start/Stop pair for = these. -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. ------ =_NextPart_000_01BE2556.F2B33AC0 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IhIDAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYA0AEAAAEAAAAQAAAAAwAAMAIAAAAL AA8OAAAAAAIB/w8BAAAAUQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHVzci10Y0BsaXN0cy54 bWlzc2lvbi5jb20AU01UUAB1c3ItdGNAbGlzdHMueG1pc3Npb24uY29tAAAAAB4AAjABAAAABQAA AFNNVFAAAAAAHgADMAEAAAAaAAAAdXNyLXRjQGxpc3RzLnhtaXNzaW9uLmNvbQAAAAMAFQwBAAAA AwD+DwYAAAAeAAEwAQAAABwAAAAndXNyLXRjQGxpc3RzLnhtaXNzaW9uLmNvbScAAgELMAEAAAAf AAAAU01UUDpVU1ItVENATElTVFMuWE1JU1NJT04uQ09NAAADAAA5AAAAAAsAQDoBAAAAHgD2XwEA AAAaAAAAdXNyLXRjQGxpc3RzLnhtaXNzaW9uLmNvbQAAAAIB918BAAAAUQAAAAAAAACBKx+kvqMQ GZ1uAN0BD1QCAAAAAHVzci10Y0BsaXN0cy54bWlzc2lvbi5jb20AU01UUAB1c3ItdGNAbGlzdHMu eG1pc3Npb24uY29tAAAAAAMA/V8BAAAAAwD/XwAAAAACAfYPAQAAAAQAAAAAAAAC+WgBBIABAD0A AABSRTogKHVzci10Yykgc3RyYW5nZSAidW5hdXRoZW50aWNhdGVkIiB2ZXJ5IGxvbmcgc3RvcCBy ZWNvcmQAmRUBBYADAA4AAADOBwwACwAWACYADAAFADkBASCAAwAOAAAAzgcMAAsAEwACABgABQAe AQEJgAEAIQAAAEJBRjM4NDg5MTg5MUQyMTE4NDFFNDQ0NTUzNTQwMDAwAMgGAQOQBgAYCQAAIQAA AAsAAgABAAAACwAjAAAAAAADACYAAAAAAAsAKQAAAAAAAwAuAAAAAAADADYAAAAAAEAAOQDAxDLY gCW+AR4AcAABAAAAPQAAAFJFOiAodXNyLXRjKSBzdHJhbmdlICJ1bmF1dGhlbnRpY2F0ZWQiIHZl cnkgbG9uZyBzdG9wIHJlY29yZAAAAAACAXEAAQAAABYAAAABviWA1++JhPO7kRgR0oQeREVTVAAA AAAeAB4MAQAAAAUAAABTTVRQAAAAAB4AHwwBAAAABwAAAHJpY2t5egAAAwAGEP/5D4cDAAcQoQUA AB4ACBABAAAAZQAAAElHVUVTU1dFQ0FOQVBQUkVDSUFURVRIRUZBQ1RUSEFUVEhFQVJDV0lMTFNF TkRUSEVTRVBBQ0tFVFNBVFRIRVZFUllMRUFTVFRPR0lWRUFIRUFEU1VQVEhBVFNPTUVPTkVJU0gA AAAAAgEJEAEAAADkBQAA4AUAAGcJAABMWkZ15neMcHcACgEDAfcgAqQD4wIAY4JoCsBzZXQwIAcT hwKDAFAO9nBycTIPX48CkhFxAwERiVRhaANxbQKDMxC7D/Z9CoAIyCBiOwlvMjU1AoAKgXU2YwBQ CwNjAEELYG5nGDEwMxSRC8QgSSCGZwpQBBF3ZSBjA5FcYXARQAWQBzB0GuB0+mga4GYA0AVAG/Ab sBvjeEFSQxrAAxADIA+wbpZkG+IPsCAKsGNrD8ALBCAcpXYEkHkgbGXUYXMcYW8aYGkfQBswkiAc AGFkBCB1cBx0enMDcGUCIBrgBAAggGHadguAZxvgA2B1AmAa4Y8CICHAHFAiUS4gSASQRGUnBCBP VVIh4XOFClA6G+M0LjEuAcC8LTcjAQEAGzAcUHUHQPZsH3AbAHUPsB3QIXIg4P8PsA+gGsAUABrB CXAeQAlw+yJACGBzJnEBoCLhH/EjFQcnUSJSJTAwLjMwLE8f4hwwAxAjsCAzCFBtPx2QC3Ad0SAA D7EfgG9nuF91biawG/ECMGkbALcbwB3QHDBsD7AqwGItAMkcdGRvB5BuJyFRH/D7IQIa4WwIkAIw HCADYQewtE9UIwtOIAAhsmUt8fciEQQgC4BkGHAm4QBwJoFXIyUCIChBbyLRbQQgYvkfcGdvIlIw UypkH+IlMvQyNyWQPxpAMoEFQAlw+HF1aQlxH+IBAB+QG8F5IxFmaSJwAHAd0AlwLf8PsSDxJ8AJ 8DTPNdwY8Q/gfwMwGQIKsQqECoQY4gLRMfMH8C1ga3k8ZRLBPNkUg8wxNjzKL/AzNgFANBHrG8Ac US1Bok8FECAgLODlAyBNGpFhZzkQQaI8Zh9BNEEBCxNBNAIAaS0xjDQ0AUAv8DE4MAFAowzQRUNi IEYDYToMg5JiD+BNaR6AIFcDYAEAgGtpIFtTTVRoUDptR3FABaEJgHVAbXAuYWUuJsBy8i4FoG1d PGVGcAZgAjCnRtdGkCvwYXkqwEQFkEU0YGIEkCAxMSrAMcg5OThMgDA6RWAP8DJNSidUb0bXSaEt dIxjQC/wH8BzLnhIkN8EEDPRSdJKKCLAaiNRRtdUUkUk0ChO5CkvQXLrGVEa4CIs3SIfNQIgInD/ L1MbcQWwCzFDb0R4QMQLtm08c3xBr0K9fEaTMcB3zyHATwBO70/8fFsAwAMQTR/wOltPXFxdTwOg QrJlEbBsZiQwYKBBCsB9M+FOAaATEVh0SrMT0GgdCHBzS70qsUzUMTox6DUgUE2VfE4xTt9crt9R BlI/U09UX1VqfGt/YdP/BbAfYRpQLtAvEiIhG9QfQe9P8jKCMEIwIW9goAeAKsD/MyEhsg+wCfBY ZRvwIfFMUPMCECghKG5BQRvjANAcUK85IU/jZZAHcSk2oCAIUdxsZC8SOIAdwWFYZQDAv2WgcWBq kwrANwJVgi5r7I9icUvyTRFMwTo1NE1AXyWgTNJYZStgeZRVJ3EtK2FQJzE9aP8ieS1OQQBTLUlQ LUFkZC8JcAQRerBM0DIlQDY48SpxMjM1a+s8ZGJwIfH3VWQdkBQAdx6xJ1McdCMV+zLzHdBkK/Av EkLQHGIiofxnaBswLQhQAn+GG9EHcf0h4mIDYB6AGyEdwR1TTFD9dIF4JuFvMQORIPBJ4XWz/wSQ IkAy4DcRH5JJgBpABUD/IfEmwjxkH/FokR5wKwMy8n8CQDRgBTAesyyRC4AjsFmvCGBtpYMSIHBT dgIvjaD/L3EKsDdgHCAFsR3zdrU8ZP4tTZaPWjxkTiEg4ACAIsD/BPKG4R/xZWQqwB2jA5E0YGsr IR/iIgDAalWRA3Bv/kBmOnvVHUEb8HrCkhhlZO9qAG8xG/IG4GQfcG/BG/L/B4FCsna1RoAFsQuA ccF1Yf8z0jPhgqBC0GXxMcAFwAlw/yKQCJAiQziAH5AesR3BBvBfHdCZNQQgHaKRVSIcAGz+cGoA inIcASvQJzEgsH1j3StRRCAAciEnUiA3QEFBX28TcFAIcJktFfEAo2ADABAQAAAAAAMAERABAAAA AwCAEP////9AAAcwwPeismIlvgFAAAgwwPeismIlvgELACSACCAGAAAAAADAAAAAAAAARgAAAAAD hQAAAAAAAAMAJYAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAmgAggBgAAAAAAwAAAAAAA AEYAAAAAUoUAALcNAAAeACeACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA4LjAAAwAo gAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALACmACCAGAAAAAADAAAAAAAAARgAAAAAOhQAA AAAAAAMAKoAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwArgAggBgAAAAAAwAAAAAAAAEYA AAAAGIUAAAAAAAAeACyACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgAtgAgg BgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4ALoAIIAYAAAAAAMAAAAAAAABGAAAA ADiFAAABAAAAAQAAAAAAAAAeAD0AAQAAAAUAAABSRTogAAAAAAMADTT9NwAA+og= ------ =_NextPart_000_01BE2556.F2B33AC0--

Subject: Re: (usr-tc) strange "unauthenticated" very long stop record
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-12-12 00:04:28

Ricky was heard to say: > Is it required to delete config and >re-setup when going from 4.0.30 to 4.1.27-7? I'm saying it is required, but it is a good idea in general. I'm one of the paranoid types that records all the commands used to setup a blank machine so I can reset anything in seconds :-) (And I do so on occasion) --Ricky

Subject: RE: (usr-tc) strange "unauthenticated" very long stop record
From: Ricky <rickyz@mindspring.com>
Date: 1998-12-12 00:30:39

------ =_NextPart_000_01BE2566.B4565040 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm with ya brother....I'm there. Thanks. o o =20 \_ _/=20 <(@@)> ----------------000----()----000------------------- RickyZ@mindspring.com THE TRUTH IS OUT THERE 00O O00 =A9 -----Original Message----- Sent: Saturday, December 12, 1998 12:04 AM Ricky was heard to say: > Is it required to delete config and >re-setup when going from 4.0.30 to 4.1.27-7? I'm saying it is required, but it is a good idea in general. I'm one of = the paranoid types that records all the commands used to setup a blank = machine so I can reset anything in seconds :-) (And I do so on occasion) --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. ------ =_NextPart_000_01BE2566.B4565040 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IgUFAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYA0AEAAAEAAAAQAAAAAwAAMAIAAAAL AA8OAAAAAAIB/w8BAAAAUQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHVzci10Y0BsaXN0cy54 bWlzc2lvbi5jb20AU01UUAB1c3ItdGNAbGlzdHMueG1pc3Npb24uY29tAAAAAB4AAjABAAAABQAA AFNNVFAAAAAAHgADMAEAAAAaAAAAdXNyLXRjQGxpc3RzLnhtaXNzaW9uLmNvbQAAAAMAFQwBAAAA AwD+DwYAAAAeAAEwAQAAABwAAAAndXNyLXRjQGxpc3RzLnhtaXNzaW9uLmNvbScAAgELMAEAAAAf AAAAU01UUDpVU1ItVENATElTVFMuWE1JU1NJT04uQ09NAAADAAA5AAAAAAsAQDoBAAAAHgD2XwEA AAAaAAAAdXNyLXRjQGxpc3RzLnhtaXNzaW9uLmNvbQAAAAIB918BAAAAUQAAAAAAAACBKx+kvqMQ GZ1uAN0BD1QCAAAAAHVzci10Y0BsaXN0cy54bWlzc2lvbi5jb20AU01UUAB1c3ItdGNAbGlzdHMu eG1pc3Npb24uY29tAAAAAAMA/V8BAAAAAwD/XwAAAAACAfYPAQAAAAQAAAAAAAAC+WgBBIABAD0A AABSRTogKHVzci10Yykgc3RyYW5nZSAidW5hdXRoZW50aWNhdGVkIiB2ZXJ5IGxvbmcgc3RvcCBy ZWNvcmQAmRUBBYADAA4AAADOBwwADAAAAB4AJwAGADgBASCAAwAOAAAAzgcMAAwAAAAdADkABgBJ AQEJgAEAIQAAADI3ODU2MjgxNTk5MUQyMTE4NDFFNDQ0NTUzNTQwMDAwAJsGAQOQBgDEBwAAIQAA AAsAAgABAAAACwAjAAAAAAADACYAAAAAAAsAKQAAAAAAAwAuAAAAAAADADYAAAAAAEAAOQCgvbeN kCW+AR4AcAABAAAAPQAAAFJFOiAodXNyLXRjKSBzdHJhbmdlICJ1bmF1dGhlbnRpY2F0ZWQiIHZl cnkgbG9uZyBzdG9wIHJlY29yZAAAAAACAXEAAQAAABYAAAABviWQjZ+BYoUokVkR0oQeREVTVAAA AAAeAB4MAQAAAAUAAABTTVRQAAAAAB4AHwwBAAAABwAAAHJpY2t5egAAAwAGEJSV374DAAcQSAMA AB4ACBABAAAAZQAAAElNV0lUSFlBQlJPVEhFUklNVEhFUkVUSEFOS1NPTy88KEBAKS0tLS0tLS0t LS0tLS0tLS0wMDAtLS0tKCktLS0tMDAwLS0tLS0tLS0tLS0tLS0tLS0tLVJJQ0tZWkBNSU5EU1AA AAAAAgEJEAEAAACQBAAAjAQAAP8HAABMWkZ1ACXUsAMACgByY3BnMTI1FjIA+Atgbg4QMDMznQH3 IAKkA+MCAGNoCsDgc2V0MCAHEwKDAFDxEHZwcnEOUBDvAfES8W8SXxEzBesCgzMC4xMJVGxhaANx AoM0FGsRdn2zCoAIyCA7CW8OMDUbCn0OIDgKJBsPHYEaIQxgYxsAUAsDYxISC8QgSScEbSAD8HRo IHlh3CBiA2Ag0ASQLiGhIHIZIWJlLhgAEzBua3M+LgqiCoQKhB+SAtExIPsDMB+yYiSAJR8llR+h GZD6byWUbx+iJnUjBSeEKO+TJkkkgVxfJIBfLySUZyMTKV8mOjwoCiARYEAyQCThKT4rWAr0ZmmQ LTE0NAFAbGkvw48M0C/DH7AXAGkgLTFddSfjaRFgMDLQMOkyVij+KTMPMr4xbig/JIMC0RmQglIN 4Gt5WkBtC4BMZHMSwAuAZy4FoG0/LeE1QSMFJPc1BCRSVEhyRRgAUlU8YCBgBfBP0zzAPFJSRTdX MzYfP2+/QH83GR9mLG87WzKyTz0g4zLQOGYnYTk6YiMUFvEzLuoYwjE2I2owEDM2XzqxIUEFkAVA QNNPBRBnDwuAB0AF0AeQc2FnZb9Bi0kEOrMLMUkEL4o4MuHrMIUk8EYDYToMgy3xORMQIEJlYSCQ W1NNQFRQOmpmYk+hQJ5JAjAEkAqwINAubhFAvl06xwZgAjBOpwYQdAhwQGRheSwgRAWQZRsG0ASQ IA4gU3AxOTmiOFQROjA0EXBNOscEVG9Op3Vzci10pGNAMBBzdCLgeDmAHQQQaQIgOiNRp3ViajNJ MU6oZTo0IFZ0KSCFVwByDxFlICJ1ShA+dSFhAjAN4FEQCYAiID52BJBPcAkADyBaUW9w/iAdwAWh CzFLP0xISJQLtvMjE080d2EEICFwCxEiENsm8EqAeU6gIxM+Qz9jHI5JBCAgwFzhcXVpHcG7YUIB AGwRQFrABaBuL5BXXIAAcF1FPh3ALRExdUVc0HdbQSBnbznxIIEDUiA0LjAuMxFgA2FRaFAxLjI3 LTf+PyMKIHJhgWfCZFEEAGR3/VNwYlsgauUhEGegBHBkQP8BACEQC4BnkAnwBJAHQCJw5yBjAiBa wG9mIhIjBAqx5wBwZ7BhMXlwB5Eg0FEQu1zlbHFsAyAhYWWhbQOBP3DxVnBk5Gb0IREPAWsgrQDB aAuAbvVzJvBJZaDvA5EdwBExZhF5INBqswOgZxEwZbFw8TotWkA0IEF7OaB0gWRhYSbwAiAm4GP/ W5BXgjRAIxlA0DkTIw55Ef8rlVXAVmAAgFigBPJQYGFC/1Z0U3ARMHcBA5FTwAtwcUE1JvAiAMBq XSEDcG9A/VdKIiuVILNa4XuYVnRb4PdtUXFiBuBkT3BupHOASmTfIvVOUAWxC4ACEHIAwFtw+3ey A6BkSeAHkFcQJuAFwPcdwFpwCJB2Z8MDEAeRZiF9JuBsYTCCtQQgfOIrlSL5IXBscFvgYVFxYkqA B4C5ZhBkZHTxIuAkgEQm8PdvoAVAcjEgZKBJEWQxA6AueQhhgq0aIQCM4AMAEBAAAAAAAwAREAEA AAADAIAQ/////0AABzDAOmF0kCW+AUAACDDAOmF0kCW+AQsAJIAIIAYAAAAAAMAAAAAAAABGAAAA AAOFAAAAAAAAAwAlgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADACaACCAGAAAAAADAAAAA AAAARgAAAABShQAAtw0AAB4AJ4AIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABAAAADguMAAD ACiACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAAsAKYAIIAYAAAAAAMAAAAAAAABGAAAAAA6F AAAAAAAAAwAqgAggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAAAAADACuACCAGAAAAAADAAAAAAAAA RgAAAAAYhQAAAAAAAB4ALIAIIAYAAAAAAMAAAAAAAABGAAAAADaFAAABAAAAAQAAAAAAAAAeAC2A CCAGAAAAAADAAAAAAAAARgAAAAA3hQAAAQAAAAEAAAAAAAAAHgAugAggBgAAAAAAwAAAAAAAAEYA AAAAOIUAAAEAAAABAAAAAAAAAB4APQABAAAABQAAAFJFOiAAAAAAAwANNP03AAD19g== ------ =_NextPart_000_01BE2566.B4565040--

Subject: RE: (usr-tc) Support Issues
From: Mario M. Bustamante <mario@accesspro.net>
Date: 1998-12-12 02:32:15

Thats not fair. Lei has helped me before and done a very professional job. Thanks, _______________________________________________ Mario M. Bustamante, President AccessPro Communications Inc. Miami, Florida > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of > Jamie Orzechowski > Sent: Friday, September 11, 1998 5:49 PM > 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. >

Subject: (usr-tc) 56k Connects kFlex v. 3Com
From: Greg Coffey <greg@coffey.com>
Date: 1998-12-12 10:19:07

Here is a good one for you. We are two blocks away from USWest's local CO and are running Ct1's to our TC hub. Has been running for 18 mos this way and have v.90 running. One of our competitors is at least 1 mile or so away from the CO and is running a k56 flavor of v.90. One of our subscribers that has never gotten >33.6 speed with us informed me that he is consistently getting 44k with the competition using the same setup and the same location. No, its not a k56flex modem either, its a USR Sportster. One of my tech's lives out in that neighborhood and he checked it last night and gets v.90 connects with the comp but not us. Never has gotten a >33.6 connect with us. He is running a newer modem with a TI chipset in it. What are we doing wrong? This could open up a significant area of town that we previously wrote off due to phone line conditions. 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

Subject: RE: (usr-tc) strange "unauthenticated" very long stop record
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-12 11:30:07

On Fri, 11 Dec 1998, Ricky wrote: > I guess we can appreciate the fact that the ARC will send these packets = > at the very least to give a heads up that someone is having trouble = > connecting. Here's OUR issue: the 4.1.72-7 code actually caused some = > users who were previously able to connect using 4.0.30, to fail. 3Com = > said to set log_unauthenticated false, but that doesn't stop the client = > from NOT connecting. No one else has induced any connection problems by = > going from 4.0.30 to 4.1.27-7? Is it required to delete config and = > re-setup when going from 4.0.30 to 4.1.27-7?=20 No you need not delete config to upgrade. You may run into problems depending upon how your ppp is setup. In 4.0.30 we had options to set ppp to pap or chap or either. In this code you have more options. In 4.0.30 if client had specifies an address the hiper arc would connect even if the radius had given you a strict address - In 4.1.72 it will not. In 4.0.30 some clients like geo book etc with wrong lcp length will connect in 4.1 it will not be so. This is the basic difference. The unauthenticated basically means that a user dialed and disconnected within 10 sec - meaning the modem did not even negotiate the connection - that is what is shown there. If you dial with a phone and try to connect you will get unauthenticated data in your radius. krish > > Ricky > > > -----Original Message----- > From: Mike Wronski [SMTP:mike@coredump.ae.usr.com] > Sent: Friday, December 11, 1998 10:40 AM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) strange "unauthenticated" very long stop record > > |-----Original Message----- > |From: owner-usr-tc@lists.xmission.com > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil > |Sent: Thursday, December 10, 1998 11:15 PM > |To: usr-tc@lists.xmission.com > |Subject: (usr-tc) strange "unauthenticated" very long stop record > | > | > | > |Sorry I don't have the versions in front of me, anyone seen > |this before (note the acct-session-time)? Couldn't find a > |matching start record. > | > |Thu Dec 10 19:54:47 1998 > | User-Name =3D "unauthenticated" > | NAS-IP-Address =3D 192.168.0.235 > | > > This record shows a user that connected and didn't get through = > authentication. > The time is broken and will be fixed in an upcoming service release. It = > is used > to track failed attempts at login. You don't get a Start/Stop pair for = > these. > > -M > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) MRTG modem useage monitoring
From: Jeff Lynch <jeff@mercury.jorsm.com>
Date: 1998-12-12 12:03:13

On Sat, 5 Dec 1998, Mike Andrews wrote: > Here's exactly what I have, minus of course the community name: > > Target[fra3-arc]: 1.3.6.1.4.1.429.4.2.1.10.0&1.3.6.1.4.1.429.4.2.1.10.0:______@fra3-arc.dcr.net > MaxBytes[fra3-arc]: 188 > AbsMax[fra3-arc]: 336 > Title[fra3-arc]: Number of Busy Modems on 3rd USR Total Control hub only > PageTop[fra3-arc]: <h1>Number of Busy Modems on 3rd USR Total Control hub only</h1> > Options[fra3-arc]: gauge > YLegend[fra3-arc]: Busy Modems > ShortLegend[fra3-arc]: Modems This appears to produce a number that is 2 greater than the actual number of ports in use. I tried to compare this by querying this oid with snmpget but it produces an error: Error in packet Reason: (noSuchName) There is no such variable name in this MIB. This name doesn't exist: Obviously I have a problem with snmpget, because mrtg is able to get a value from this oid. Just wondering if you also get an answer that is greater by two? --jeff ========================================================================= Jeffrey A. Lynch JORSM Internet email: jeff@jorsm.com Northwest Indiana's Full-Service Provider Voice: (219)322-2180 927 Sheffield Avenue, Dyer, IN 46311 Autoresponse: info@jorsm.com http://www.jorsm.com

Subject: Re: (usr-tc) MRTG modem useage monitoring
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-12-12 13:17:04

If you're using ucd-snmp, you need to put a leading dot on the OID: % snmpget -v 1 fra3-arc rednex .1.3.6.1.4.1.429.4.2.1.10.0 enterprises.429.4.2.1.10.0 = 8 and "list connections" on the ARC right now shows 8 users. If you're always getting +2 on everything, you can just put " - 2" at the end of the "Target" field... :) Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ # view;touch;unzip;finger;mount;mv;mv;mv;yes;mv;yes;mv;yes;umount;sleep On Sat, 12 Dec 1998, Jeff Lynch wrote: > On Sat, 5 Dec 1998, Mike Andrews wrote: > > > Here's exactly what I have, minus of course the community name: > > > > Target[fra3-arc]: 1.3.6.1.4.1.429.4.2.1.10.0&1.3.6.1.4.1.429.4.2.1.10.0:______@fra3-arc.dcr.net > > MaxBytes[fra3-arc]: 188 > > AbsMax[fra3-arc]: 336 > > Title[fra3-arc]: Number of Busy Modems on 3rd USR Total Control hub only > > PageTop[fra3-arc]: <h1>Number of Busy Modems on 3rd USR Total Control hub only</h1> > > Options[fra3-arc]: gauge > > YLegend[fra3-arc]: Busy Modems > > ShortLegend[fra3-arc]: Modems > > This appears to produce a number that is 2 greater than the actual number > of ports in use. I tried to compare this by querying this oid with snmpget > but it produces an error: > > Error in packet > Reason: (noSuchName) There is no such variable name in this MIB. > This name doesn't exist: > > Obviously I have a problem with snmpget, because mrtg is able to get a > value from this oid. Just wondering if you also get an answer that is > greater by two? > > --jeff > > ========================================================================= > Jeffrey A. Lynch JORSM Internet > email: jeff@jorsm.com Northwest Indiana's Full-Service Provider > Voice: (219)322-2180 927 Sheffield Avenue, Dyer, IN 46311 > Autoresponse: info@jorsm.com http://www.jorsm.com

Subject: (usr-tc) adsl/xdsl cards in tc chassis
From: matthew de Jongh <matthew.de.jongh@the-spa.com>
Date: 1998-12-12 16:52:22

does anyone on the list have any firsthand experience using the tc adsl or xdsl cards in a chassis to provide services such as high speed dedicated access to office buildings? matthew

Subject: Re: (usr-tc) adsl/xdsl cards in tc chassis
From: Dan Hollis <goemon@sasami.anime.net>
Date: 1998-12-12 17:04:43

On Sat, 12 Dec 1998, Mark R. Lindsey wrote: > The FCC doesn't like ISPs who just want to become CLECs for their own > purposes; in fact, if a CLEC has only one customer -- an ISP -- then > the FCC may well revoke its authorization. Are there any records of this ever having been done? -Dan

Subject: Re: (usr-tc) adsl/xdsl cards in tc chassis
From: Jack Singer <jsinger@usacars.com>
Date: 1998-12-12 17:27:43

We are ordering the equipment now and expect to install later this monthl. Jack jsinger@i-c.net matthew de Jongh wrote: > does anyone on the list have any firsthand experience using the tc adsl or > xdsl cards in a chassis to provide services such as high speed dedicated > access to office buildings? > > matthew > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) adsl/xdsl cards in tc chassis
From: Allen Marsalis <am@shreve.net>
Date: 1998-12-12 17:51:19

At 05:27 PM 12/12/98 -0500, Jack Singer wrote: >We are ordering the equipment now and expect to install later this monthl. Could you please fill us in on some details? Such as price per port.. Why you chose 3COM over Tut or others.. And how do you plan on making a buck off of this service? (if you don't mind me asking ;) So far ADSL has been somewhat elusive here in that "dry copper" or LADD circuits are a taboo subject with the telcos, and intra-building service is easy enough to provide via plain ole ethernet. (cat5, coax, and fibre) The main reason I'm still interested in ADSL is to span to other office buildings cheaply and route IP via ethernet as we do in this building already.. I can envision twelve xDSL ports going to the twelve major office centers downtown without having to purchase a single T1! But then if we could get the LADD, I could use Pargain's (HDSL) or anything we wanted I suppose.. Becoming a CLEC and having access to unbundled network elements might be the ultimate perk for ISP's.. (something we are strongly considering) Otherwise, a spreadspectrum cloud downtown might be nice too.. Any thoughts? Allen > >Jack >jsinger@i-c.net > >matthew de Jongh wrote: > >> does anyone on the list have any firsthand experience using the tc adsl or >> xdsl cards in a chassis to provide services such as high speed dedicated >> access to office buildings? >> >> matthew

Subject: Re: (usr-tc) Wanted Fan Tray For Total Control
From: Jack Singer <jsinger@usacars.com>
Date: 1998-12-12 18:13:33

> I need a fan tray for a total control unit, if you have one to sell, please > email or call.. Jack Singer jsinger@i-c.net (800) 224-3806

Subject: RE: (usr-tc) adsl/xdsl cards in tc chassis
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-12 18:17:24

I have installed a few sets of it. If you have any specific questions I would be happy to answer them. Please direct them to me privately http://bmcintire@commnet.com >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jack Singer >Sent: Saturday, December 12, 1998 4:28 PM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) adsl/xdsl cards in tc chassis > > >We are ordering the equipment now and expect to install later this monthl. > >Jack >jsinger@i-c.net > >matthew de Jongh wrote: > >> does anyone on the list have any firsthand experience using the >tc adsl or >> xdsl cards in a chassis to provide services such as high speed dedicated >> access to office buildings? >> >> matthew >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. > > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) adsl/xdsl cards in tc chassis
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-12 18:24:41

ignore the http in the last message. Of course, it was a brain slip. >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian K McIntire >Sent: Saturday, December 12, 1998 6:17 PM >To: usr-tc@lists.xmission.com >Subject: RE: (usr-tc) adsl/xdsl cards in tc chassis > > >I have installed a few sets of it. If you have any specific questions I >would be happy to answer them. Please direct them to me privately >mailto://bmcintire@commnet.com > >>-----Original Message----- >>From: owner-usr-tc@lists.xmission.com >>[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jack Singer >>Sent: Saturday, December 12, 1998 4:28 PM >>To: usr-tc@lists.xmission.com >>Subject: Re: (usr-tc) adsl/xdsl cards in tc chassis >> >> >>We are ordering the equipment now and expect to install later this monthl. >> >>Jack >>jsinger@i-c.net >> >>matthew de Jongh wrote: >> >>> does anyone on the list have any firsthand experience using the >>tc adsl or >>> xdsl cards in a chassis to provide services such as high speed dedicated >>> access to office buildings? >>> >>> matthew >>> >>> - >>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >>> with "unsubscribe usr-tc" in the body of the message. >>> For information on digests or retrieving files and old messages send >>> "help" to the same address. Do not use quotes in your message. >> >> >> >> >>- >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) adsl/xdsl cards in tc chassis
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1998-12-12 19:23:54

: From: Allen Marsalis <am@shreve.net> : : I can envision twelve xDSL ports going to the twelve major office : centers downtown without having to purchase a single T1! But then : if we could get the LADD, I could use Pargain's (HDSL) or anything we : wanted I suppose.. Becoming a CLEC and having access to unbundled : network elements might be the ultimate perk for ISP's.. (something : we are strongly considering) Otherwise, a spreadspectrum cloud : downtown might be nice too.. Any thoughts? The FCC doesn't like ISPs who just want to become CLECs for their own purposes; in fact, if a CLEC has only one customer -- an ISP -- then the FCC may well revoke its authorization. It seems that the drive to become CLECs *just* to get unbundled services is rather unfortunate. I would prefer to see changes that cause the telcos to sell such services to regular business customers. (Of course, they're saving oodles of money by running short T1s over HDSL circuits, so I doubt they're really itching to see the regulations changed and pass those savings to us.) You can, in fact, run ADSL over a short, loaded circuit. We have one such configuration in operation.

Subject: Re: (usr-tc) adsl/xdsl cards in tc chassis
From: Allen Marsalis <am@shreve.net>
Date: 1998-12-12 19:59:16

At 07:23 PM 12/12/98 -0500, Mark R. Lindsey wrote: >: From: Allen Marsalis <am@shreve.net> >: >: I can envision twelve xDSL ports going to the twelve major office >: centers downtown without having to purchase a single T1! But then >: if we could get the LADD, I could use Pargain's (HDSL) or anything we >: wanted I suppose.. Becoming a CLEC and having access to unbundled >: network elements might be the ultimate perk for ISP's.. (something >: we are strongly considering) Otherwise, a spreadspectrum cloud >: downtown might be nice too.. Any thoughts? > >The FCC doesn't like ISPs who just want to become CLECs for their own >purposes; in fact, if a CLEC has only one customer -- an ISP -- then >the FCC may well revoke its authorization. > >It seems that the drive to become CLECs *just* to get unbundled services >is rather unfortunate. Well, that isn't the primary reason we are considering becoming a CLEC. The primary reason is thousand dollar PRI's.. The tier 3 markets such as the one we are in hasn't attracted alot of competition yet so why not crank up some? Access to UNE's is just the cherry on the cake. And so are the other telco revenue opportunities such as terminating IXC traffic on idle lines. I should have mentioned that if we go CLEC, it will be facilities based, not just resale to get to UNE's. And although this is getting sorta off topic (I was more interested in the specifics of using Total Control ADSL for profit) we plan on offering service to more customers than just ourselves. We feel that by offering good internet service via ethernet thoughout our office center, we have paved the way to offer some telco services.. I'm also tired of steering so much business to the telcos with little or no appreciation (or compensation).. :-\ Allen

Subject: Re: (usr-tc) adsl/xdsl cards in tc chassis
From: Allen Marsalis <am@shreve.net>
Date: 1998-12-12 20:11:44

At 05:04 PM 12/12/98 -0800, Dan Hollis wrote: >On Sat, 12 Dec 1998, Mark R. Lindsey wrote: >> The FCC doesn't like ISPs who just want to become CLECs for their own >> purposes; in fact, if a CLEC has only one customer -- an ISP -- then >> the FCC may well revoke its authorization. > >Are there any records of this ever having been done? > Our attorney who is carrying us though the certification process says that it is a good idea to have a few customers, just to be safe. I think the FCC might be considering some amendments due to the fact that many folks are becoming CLEC's for reasons that they didn't count on (like to save money instead of making money though expanded competition) So we hope to "grandfather" ourselves in while there is little to stop us. However, with all the different brands of xDSL out there, I can imagine that Bell will scream bloody murder if we try to use any of them. Meanwhile, they are marketing ADSL all over our state but are *way* ahead of themselves.. If we wait on them to deploy, it will be expensive and put all ISP's on the same level and a notch below themselves I imagine.. It really looks like a holy war ahead to me.. And I'd like to hedge my bet or at least have some options.. But back to the present. Can anyone mention how much the Total Control ADSL stuff costs and how they plan on making a buck off it? Any comments on how it compares to other brands of ADSL? And will 3COM give out 30 day evals? Allen

Subject: Re: (usr-tc) adsl/xdsl cards in tc chassis
From: Brian <signal@shreve.net>
Date: 1998-12-12 22:32:11

On Sat, 12 Dec 1998, Mark R. Lindsey wrote: > : From: Allen Marsalis <am@shreve.net> > : > : I can envision twelve xDSL ports going to the twelve major office > : centers downtown without having to purchase a single T1! But then > : if we could get the LADD, I could use Pargain's (HDSL) or anything we > : wanted I suppose.. Becoming a CLEC and having access to unbundled > : network elements might be the ultimate perk for ISP's.. (something > : we are strongly considering) Otherwise, a spreadspectrum cloud > : downtown might be nice too.. Any thoughts? > > The FCC doesn't like ISPs who just want to become CLECs for their own > purposes; in fact, if a CLEC has only one customer -- an ISP -- then > the FCC may well revoke its authorization. well, yes and no. The FCC can revoke anyones licenses for not following regulations. But their are *alot* of ISP's who are CLEC's, and CLEC's for no other reason than to sell themselves competitive services, and become facilities based. > > It seems that the drive to become CLECs *just* to get unbundled services > is rather unfortunate. I would prefer to see changes that cause the telcos > to sell such services to regular business customers. (Of course, they're > saving oodles of money by running short T1s over HDSL circuits, so I doubt > they're really itching to see the regulations changed and pass those > savings to us.) > > You can, in fact, run ADSL over a short, loaded circuit. We have one such > configuration in operation. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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

Subject: (usr-tc) RAS configuration...
From: Mahinder Kumar <mahinder@gto.net.om>
Date: 1998-12-12 23:37:51

Hi, I am facing some problems while configuring RAS on TCH having an EdgeServerPro card, five no. of Quad DS Modem cards and a NMC card. S/W ver. on NMC is 5.5.5 and on Quad Modems card is 5.9.9 While configuring RAS system is not able to find any RAS configurable device. I can see all the the modem cards by doble clicking at edgeserver icon under control panel. What could be the problem. Any suggestions please? TIA

Subject: Re: (usr-tc) adsl/xdsl cards in tc chassis
From: Dan Hollis <goemon@sasami.anime.net>
Date: 1998-12-13 03:49:31

On Sat, 12 Dec 1998, Allen Marsalis wrote: > However, with all the different brands of xDSL out there, I can imagine > that Bell will scream bloody murder if we try to use any of them. Why? A good majority of T1 spans are deployed by the telcos using HDSL. Or is it a case of "do as i say not do as i do". -Dan

Subject: Re: (usr-tc) ISDN dialout from TC
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-13 08:30:30

On Sun, 13 Dec 1998, Carl Ansley wrote: > > Hi, > > We're trying to get our chassis (Netserver running 3.8.1, Quad Imodems > running 5.10.9, PRI card ) to do ISDN dial out into various different SOHO > ISDN routers (Cisco 760, plus a couple of Teltrends). The idea is to do > dial-on-demand to these boxes, however we're not having any luck getting > connects. You can get complete details on how to configure the cisco and the TC to do this. Search on yadda yadda search http://interproc.ae.usr.com/tkb.html search for lan-to-lan krish > > Connecting to one of the Imodems directly and doing: > > at*v2=5dt<phonenum> > > results in a "NO CARRIER" message after several seconds with both the > Teltrends and the Cisco. Modem light is orange while trying to connect, > but never goes green. > > Here are the modem settings: > > ati4 > USRobotics Analog/Digital Quad Settings... > Copyright, 1988-97, U.S. Robotics. All rights reserved. > > B0 C1 E1 F1 Q0 V1 X1 > BAUD=38400 PARITY=N WORDLEN=8 DTE=GATEWAY NAC > DIAL=TONE ON HOOK TIMER LINE=ISDN PRI > > &A1 &B0 &C1 &D2 &G2 &H0 &I0 &K1 &L0 &M4 &N0 &P1 &R1 &S0 > &T4 &U0 &X0 &Y1 %N6 *U1=0 *U2=0 *U3=0 *V2=5 *X0=2048 *X1=2 > > S00=001 S01=000 S02=043 S03=013 S04=010 S05=008 S06=002 S07=060 > S08=002 S09=006 S10=007 S11=070 S12=050 S13=000 S14=000 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=001 S28=008 S29=020 S30=000 S31=000 > S32=009 S33=000 S34=000 S35=000 S36=000 S37=000 S38=000 S39=011 > S40=000 S41=000 S42=126 S43=200 S44=015 S45=000 S46=255 S47=032 > S48=000 S49=016 S50=100 S51=000 S52=005 S53=000 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=005 S68=000 S69=000 S70=000 S71=084 > S72=000 S73=001 S74=000 S75=000 S76=000 S77=000 S78=000 S79=000 > S80=000 S81=002 S82=012 > > > The strange thing is the connect is successful if we dial back into our > own chassis, or into an Ascend box. > > Unfortunately I don't know much about the Cisco 760, (e.g. is dialin fully > supported?), and this is the first time i've played with dialout on the > TC, so I'm a bit unsure whether this is a config problem with the Cisco or > TC. Given it also doesn't work with the Teltrends (which are definately > setup to accept ISDN calls) makes me think it's possibly a TC problem. > At this point any ideas would be mucho appreciated... > > -- > Carl Ansley (carl@caverock.com) Phone: +64 3 3664242 > Cave Rock Software / Cave Rock Internet Fax: +64 3 3665478 > Unit 1a, 492 Moorhouse Ave, PO Box 22488, Christchurch, New Zealand > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) adsl/xdsl cards in tc chassis
From: Allen Marsalis <am@shreve.net>
Date: 1998-12-13 15:13:01

At 03:49 AM 12/13/98 -0800, Dan Hollis wrote: >On Sat, 12 Dec 1998, Allen Marsalis wrote: >> However, with all the different brands of xDSL out there, I can imagine >> that Bell will scream bloody murder if we try to use any of them. > >Why? A good majority of T1 spans are deployed by the telcos using HDSL. exactly. It's ok for the telco, but a non-telco entity will get stonewalled if they ever wanted to "build out" a circuit.. Telcos would rather charge $500/mo for a LADD with 2 $700 Pairgain HDSL units attached than $20/mo for a LADD with nothing on the ends.. I suspect that when ADSL rolls out in the marketplace in full force, it will be the RBOC's, and maybe a few CLECS co-locating at the RBOC's CO's, who deploy their own equipment (see above) Then they will offer to "ADSL enable" ISP's with a simple high speed connection to *their* network such as frame or ATM.. It's another way to make $20K a month off a few copper pairs to ISP's while we foot the bandwidth transit bill.. What is interesting to me here is that *we* will have no choice as to what brand or flavor of xDSL will be offered/used.. So 3COM won't be marketing this stuff to us (except for intra-office apps). 3COM will have to market it to the telcos.. In fact, I think 3COM has it's eye's set on the (potential) telco markets right now even more than the ISP markets.. The sales of IP telephony gateways, networking equipment, and now xDSL hubs is a *much* larger market than we are.. > >Or is it a case of "do as i say not do as i do". yup. Allen > >-Dan > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >

Subject: (usr-tc) MPIP links not being removed
From: rickp@corp.netcom.net.uk
Date: 1998-12-13 15:20:45

We're seeing links being remembered and advertised to the MPIP Server by chassis long after the user has disconnected. The fault seems to lie on the client, as it has the user listed in the locallinks section. Eg: on the client: HiPer>> list mpip localLINKS Local MPIP Links Index Bundle Owner User 1 xxx.yyy.xx.132 smithad 2 xxx.yyy.xx.132 smithad And on the MPIP Server HiPer>> list mpip bundLES MPIP Bundles Bundle EndPointDescriminator No. User Owner Value Type Links Name xxx.yyy.xx.37 F6090000000000000000 4 1 uk,ppp,smithad xxx.yyy.xx.32 00000000000000000000 4 2 uk,ppp,smithad Yet the user isn't on either of the clients listed as bundle owners, and isn't connected anywhere. Both the MPIP Clients and Servers are HiperARC's running 4.1.72-6. Any clues? There doesn't appear to be a command to remove a particular user from the MPIP Locallinks table. Currently the only way of clearing these out is to reboot the client chassis with the duff info. Rick

Subject: Re: (usr-tc) MPIP links not being removed
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-13 18:16:53

On Sun, 13 Dec 1998 rickp@corp.netcom.net.uk wrote: > > We're seeing links being remembered and advertised to the MPIP Server > by chassis long after the user has disconnected. > > The fault seems to lie on the client, as it has the user listed in the > locallinks section. > > Eg: on the client: > > HiPer>> list mpip localLINKS > > Local MPIP Links > Index Bundle Owner User > 1 xxx.yyy.xx.132 smithad > 2 xxx.yyy.xx.132 smithad > > And on the MPIP Server > > HiPer>> list mpip bundLES > > MPIP Bundles > Bundle EndPointDescriminator No. User > Owner Value Type Links Name > xxx.yyy.xx.37 F6090000000000000000 4 1 uk,ppp,smithad > xxx.yyy.xx.32 00000000000000000000 4 2 uk,ppp,smithad > > Yet the user isn't on either of the clients listed as bundle owners, > and isn't connected anywhere. > > Both the MPIP Clients and Servers are HiperARC's running 4.1.72-6. > > Any clues? There doesn't appear to be a command to remove a particular > user from the MPIP Locallinks table. Currently the only way of > clearing these out is to reboot the client chassis with the duff info. > This is the problem that the service release 4.1.72 -7 fixes. If you are using hiper ar with netserver then you must also get the 3.8.85 ER code for the netserver to fix this problem. krish > Rick > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) MPIP links not being removed
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-12-13 20:38:04

Thus spake Tatai SV Krishnan >This is the problem that the service release 4.1.72 -7 fixes. If you are >using hiper ar with netserver then you must also get the 3.8.85 ER code >for the netserver to fix this problem. I'm sorry to say, I have 3.8.76 on my NETServers and the problem is *NOT* fixed. It's *much* improved over the 3.7.76 and 3.8.90 that I had on previously, but it is still happening occasionally. I still have a dedicated MPIP server that I'm rebooting once an hour as a work-around (yes, rebooting the MPIP server is a work-around...it doesn't clear out the bogus info, but it does avoid it for a while). In short, I would recommend loading something newer than 3.8.85 (I've got 3.8.76 and it looks mostly solid) as it seems to address a lot of problems, but it still doesn't take care of them all. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) ISDN dialout from TC
From: Carl Ansley <carl@caverock.com>
Date: 1998-12-13 21:44:44

Hi, We're trying to get our chassis (Netserver running 3.8.1, Quad Imodems running 5.10.9, PRI card ) to do ISDN dial out into various different SOHO ISDN routers (Cisco 760, plus a couple of Teltrends). The idea is to do dial-on-demand to these boxes, however we're not having any luck getting connects. Connecting to one of the Imodems directly and doing: at*v2=5dt<phonenum> results in a "NO CARRIER" message after several seconds with both the Teltrends and the Cisco. Modem light is orange while trying to connect, but never goes green. Here are the modem settings: ati4 USRobotics Analog/Digital Quad Settings... Copyright, 1988-97, U.S. Robotics. All rights reserved. B0 C1 E1 F1 Q0 V1 X1 BAUD=38400 PARITY=N WORDLEN=8 DTE=GATEWAY NAC DIAL=TONE ON HOOK TIMER LINE=ISDN PRI &A1 &B0 &C1 &D2 &G2 &H0 &I0 &K1 &L0 &M4 &N0 &P1 &R1 &S0 &T4 &U0 &X0 &Y1 %N6 *U1=0 *U2=0 *U3=0 *V2=5 *X0=2048 *X1=2 S00=001 S01=000 S02=043 S03=013 S04=010 S05=008 S06=002 S07=060 S08=002 S09=006 S10=007 S11=070 S12=050 S13=000 S14=000 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=001 S28=008 S29=020 S30=000 S31=000 S32=009 S33=000 S34=000 S35=000 S36=000 S37=000 S38=000 S39=011 S40=000 S41=000 S42=126 S43=200 S44=015 S45=000 S46=255 S47=032 S48=000 S49=016 S50=100 S51=000 S52=005 S53=000 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=005 S68=000 S69=000 S70=000 S71=084 S72=000 S73=001 S74=000 S75=000 S76=000 S77=000 S78=000 S79=000 S80=000 S81=002 S82=012 The strange thing is the connect is successful if we dial back into our own chassis, or into an Ascend box. Unfortunately I don't know much about the Cisco 760, (e.g. is dialin fully supported?), and this is the first time i've played with dialout on the TC, so I'm a bit unsure whether this is a config problem with the Cisco or TC. Given it also doesn't work with the Teltrends (which are definately setup to accept ISDN calls) makes me think it's possibly a TC problem. At this point any ideas would be mucho appreciated... -- Carl Ansley (carl@caverock.com) Phone: +64 3 3664242 Cave Rock Software / Cave Rock Internet Fax: +64 3 3665478 Unit 1a, 492 Moorhouse Ave, PO Box 22488, Christchurch, New Zealand

Subject: Re: (usr-tc) adsl/xdsl cards in tc chassis
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-12-13 22:36:16

Allen Marsalis was heard to say: >However, with all the different brands of xDSL out there, I can imagine >that Bell will scream bloody murder if we try to use any of them. No they won't... remember how DSL works -- the connection is from customer to serving CO. You will either "buy" termination from Bell or buy rack space at the CO(s) to put your own termination equipment. In all cases, Bell is going to charge you some "client access" fee _per_ _client_. [I screamed bloddy murder the instant I say how HellSouth was going to "allow" competition in th DLS world.] >Meanwhile, they are marketing ADSL all over our state but are *way* >ahead of themselves.. If we wait on them to deploy, it will be >expensive and put all ISP's on the same level and a notch below >themselves I imagine.. It really looks like a holy war ahead to me.. >And I'd like to hedge my bet or at least have some options.. What options? Unless you run a piece of copper into your customers house, then you aren't going to get around Bell. >will 3COM give out 30 day evals? I'm sure some people could get a few free cards out of them :-) --Ricky

Subject: Re: (usr-tc) ISDN dialout from TC
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-12-13 22:42:22

Carl Ansley was heard to say: >We're trying to get our chassis (Netserver running 3.8.1, Quad Imodems >running 5.10.9, PRI card ) to do ISDN dial out into various different SOHO >ISDN routers (Cisco 760, plus a couple of Teltrends). The idea is to do >dial-on-demand to these boxes, however we're not having any luck getting >connects. > >Connecting to one of the Imodems directly and doing: > >at*v2=5dt<phonenum> > >results in a "NO CARRIER" message after several seconds with both the >Teltrends and the Cisco. Modem light is orange while trying to connect, >but never goes green. Modem setting are irrelevant. The problem is the netserver! Version 3.8+ CANNOT DIAL OUT. 3Com was made aware of this problem multiple times while 3.8 was in beta and they ignored it. I was sent an ER after 3.8.1 went public that still doesn't fix the problem. You could try disabling packet bus call control (but then the netserver will never answer any calls.) --Ricky PS: They've got ~20 days to fix it :-)

Subject: Re: (usr-tc) adsl/xdsl cards in tc chassis
From: William Behrens <wbehrens@feist.com>
Date: 1998-12-13 23:50:48

Theres always spread spectrum wireless :). >What options? Unless you run a piece of copper into your customers house, >then you aren't going to get around Bell. > >>will 3COM give out 30 day evals? > >I'm sure some people could get a few free cards out of them :-) > >--Ricky

Subject: (usr-tc) Modem disconnects
From: Victor J. Velazquez <victorv@infi.net>
Date: 1998-12-14 09:32:42

I'm getting complaints of disconnects during ppp dialup sessions. I checked the TCH config and all looks good. I'm running 5.6.7 code for the Quad cards. Was there any problems with disconnects with that version of code? Victor

Subject: RE: (usr-tc) MRTG modem useage monitoring
From: Eric Billeter <ebilleter@cableone.net>
Date: 1998-12-14 09:35:09

I have some perl scripts that perform a snmp walk for the status of the DS0's. I have them for Hiper chassis as well as Netserver PRI and Netserver T1 configurations. Let me know if you are interested. 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 Mike Andrews Sent: Saturday, December 12, 1998 11:17 AM If you're using ucd-snmp, you need to put a leading dot on the OID: % snmpget -v 1 fra3-arc rednex .1.3.6.1.4.1.429.4.2.1.10.0 enterprises.429.4.2.1.10.0 = 8 and "list connections" on the ARC right now shows 8 users. If you're always getting +2 on everything, you can just put " - 2" at the end of the "Target" field... :) Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ # view;touch;unzip;finger;mount;mv;mv;mv;yes;mv;yes;mv;yes;umount;sleep On Sat, 12 Dec 1998, Jeff Lynch wrote: > On Sat, 5 Dec 1998, Mike Andrews wrote: > > > Here's exactly what I have, minus of course the community name: > > > > Target[fra3-arc]: 1.3.6.1.4.1.429.4.2.1.10.0&1.3.6.1.4.1.429.4.2.1.10.0:______@fra3-arc.dcr.ne t > > MaxBytes[fra3-arc]: 188 > > AbsMax[fra3-arc]: 336 > > Title[fra3-arc]: Number of Busy Modems on 3rd USR Total Control hub only > > PageTop[fra3-arc]: <h1>Number of Busy Modems on 3rd USR Total Control hub only</h1> > > Options[fra3-arc]: gauge > > YLegend[fra3-arc]: Busy Modems > > ShortLegend[fra3-arc]: Modems > > This appears to produce a number that is 2 greater than the actual number > of ports in use. I tried to compare this by querying this oid with snmpget > but it produces an error: > > Error in packet > Reason: (noSuchName) There is no such variable name in this MIB. > This name doesn't exist: > > Obviously I have a problem with snmpget, because mrtg is able to get a > value from this oid. Just wondering if you also get an answer that is > greater by two? > > --jeff > > ========================================================================= > Jeffrey A. Lynch JORSM Internet > email: jeff@jorsm.com Northwest Indiana's Full-Service Provider > Voice: (219)322-2180 927 Sheffield Avenue, Dyer, IN 46311 > Autoresponse: info@jorsm.com http://www.jorsm.com - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) AOPEN modem
From: Dan Lan <admin@tieus.com>
Date: 1998-12-14 09:52:55

A lot of our customer got AOpen Modem and they just cannot connect to the Total Control Chassis. They got drop of every time, cannot get even 33.6K connection. I have called usr tech support for this issue. They just saying some of the patch code will release, but I dont think so ? I also appreciate if any one got answer how to overcome this problem ? -----Original Message----- >Any one out there having difficulties with Aopen modems connecting to Total >Control Chassis'? Any success in resolving issues? > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) AOPEN modem
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-14 10:34:29

Any one out there having difficulties with Aopen modems connecting to Total Control Chassis'? Any success in resolving issues?

Subject: (usr-tc) USR Winmodems??!%#%
From: Brian Gordon <administrator@westelcom.com>
Date: 1998-12-14 11:22:54

Help those DAMN USR Windmodems! A lot of my users have been calling today saying that they are having trouble connecting. Please help! Anyone know of a initialization string or anything we can tell them. Brian Gordon, MCP Network Administrator Westelcom Internet 518-566-8376 Voice 518-566-8348 Fax administrator@westelcom.com http://home.westelcom.com

Subject: Re: (usr-tc) adsl/xdsl cards in tc chassis
From: Allen Marsalis <am@shreve.net>
Date: 1998-12-14 11:31:07

At 10:36 PM 12/13/98 -0500, Ricky Beam wrote: >Allen Marsalis was heard to say: >>However, with all the different brands of xDSL out there, I can imagine >>that Bell will scream bloody murder if we try to use any of them. > >No they won't... remember how DSL works -- the connection is from customer >to serving CO. You will either "buy" termination from Bell Ok so we pay Bell to terminate the DSL circuit. If we are not a CLEC, then we have no colocation rights. Therefore the termination equipment (DSLAM and ADSL hub) will be owned by Bell and they will charge *alot* for the service. Not only that, the aggregate bandwidth will have to be backhauled somehow to get to us.. another expensive service.. All that will be left for us to do is billing.. :-\ >or buy rack >space at the CO(s) to put your own termination equipment. Only if you are a CLEC. Which was my original observation. It's sorta strange we are forced to become an ISP-CLEC in order to have the right to choose, own, and deploy xDSL services.. and to distinguish our service from Bell and others.. remembering the x2 vs kflex wars, I'm not so sure Bell would have chosen wisely. And I really don't want them to make these kind of decisions for us.. (besides keeping 75% of revenues) >In all cases, >Bell is going to charge you some "client access" fee _per_ _client_. >[I screamed bloddy murder the instant I say how HellSouth was going to > "allow" competition in th DLS world.] Well they won't tell me a thing other than they are marketing way to early here and won't know if they can offer us service until it's turned up.. I hardly expect fair treatment from them based on past history/experience.. call me cynical... :> > >>Meanwhile, they are marketing ADSL all over our state but are *way* >>ahead of themselves.. If we wait on them to deploy, it will be >>expensive and put all ISP's on the same level and a notch below >>themselves I imagine.. It really looks like a holy war ahead to me.. >>And I'd like to hedge my bet or at least have some options.. > >What options? Well first, the option to deploy DSL equipment ourselves or buy the service from someone wanting to offer it. Can't do the former without becoming a CLEC.. Just having the option to purchase dry copper and build out with our own flavor of xDSL would be a big option.. And I'd like the option of hauling the aggregate bandwidth back home anyway I want.. like via ATM, frame cloud, xDSL, or even wireless spread spectrum, (I'm sure Bell would not like seeing yagi antenna's outside of their CO's.. :) Otherwise if Bell does it all "turn-key" you can bet most of the xDSL revenues will go there likewise and give bellsouth.net another advantage.. >Unless you run a piece of copper into your customers house, >then you aren't going to get around Bell. Well for me it's the choice between having no choice (don't be a CLEC and be at Bell's total mercy), or having some choices (become a CLEC and have interconnection and colocation rights) And cutting PRI costs in half or less by owning our own switch is another reason.. :) > >>will 3COM give out 30 day evals? > >I'm sure some people could get a few free cards out of them :-) I'm probably not one of them :-\ And I think I'll need a chassis and powersupply to go with those cards.. :) It really would be interesting to play with one though.. Anyone know offhand what the cost per port is? Allen

Subject: Re: (usr-tc) Modem disconnects
From: John Powell <jp@packet.ae.usr.com>
Date: 1998-12-14 11:31:09

On Mon, 14 Dec 1998, Victor J. Velazquez wrote: > I'm getting complaints of disconnects during ppp dialup sessions. > I checked the TCH config and all looks good. I'm running 5.6.7 > code for the Quad cards. Was there any problems with disconnects > with that version of code? Nothing I know of. Any details like specific modulations or modem brands? Also, just wondering, is there are reason you are not running 5.10.9? JP

Subject: Re: (usr-tc) USR Winmodems??!%#%
From: John Powell <jp@packet.ae.usr.com>
Date: 1998-12-14 11:41:50

On Mon, 14 Dec 1998, Brian Gordon wrote: > Help those DAMN USR Windmodems! > > A lot of my users have been calling today saying that they are having > trouble connecting. Did something change in the last couple days that might point to the problem? It seems strange that would suddenly occur to lots of users without something changing. Any hints on what they are experiencing? - Are they getting noticeable changes in training sounds? - Are they getting specific errors from the DUN stack? - If you look at their stats from the headend (such as TCM performance monitor) are you noticing anything strange (like lack of error correction, lots of errors, etc.). - Are the truly "not connecting" at the modem level, or not being able to login, etc. - Are all the people using USR Winmodems that suddenly are having problems? Basically, some clues on the real problem will help with the solution. JP

Subject: Re: (usr-tc) Modem disconnects
From: Victor J. Velazquez <victorv@infi.net>
Date: 1998-12-14 12:57:35

At 11:31 AM 12/14/98 -0600, you wrote: > >On Mon, 14 Dec 1998, Victor J. Velazquez wrote: > >> I'm getting complaints of disconnects during ppp dialup sessions. >> I checked the TCH config and all looks good. I'm running 5.6.7 >> code for the Quad cards. Was there any problems with disconnects >> with that version of code? > >Nothing I know of. Any details like specific modulations or modem brands? The customer has a dell laptop. I don't what kind of modem he's using. No particular reason why we are not using 5.10.9. Is 5.10.9 stable code? > >Also, just wondering, is there are reason you are not running 5.10.9? > >JP > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >

Subject: Re: (usr-tc) adsl/xdsl cards in tc chassis
From: Jack Singer <jsinger@usacars.com>
Date: 1998-12-14 13:11:50

We are setting up a dslam next to the phone company at a customer site and ordering alarm copper from there to another customer. We are running a local t-1 to the dslam. It is that simple. Alarm copper can be ordered without load coils. Allen Marsalis wrote: > At 10:36 PM 12/13/98 -0500, Ricky Beam wrote: > >Allen Marsalis was heard to say: > >>However, with all the different brands of xDSL out there, I can imagine > >>that Bell will scream bloody murder if we try to use any of them. > > > >No they won't... remember how DSL works -- the connection is from customer > >to serving CO. You will either "buy" termination from Bell > > Ok so we pay Bell to terminate the DSL circuit. If we are not a CLEC, > then we have no colocation rights. Therefore the termination equipment > (DSLAM and ADSL hub) will be owned by Bell and they will charge *alot* > for the service. Not only that, the aggregate bandwidth will have to > be backhauled somehow to get to us.. another expensive service.. All > that will be left for us to do is billing.. :-\ > > >or buy rack > >space at the CO(s) to put your own termination equipment. > > Only if you are a CLEC. Which was my original observation. It's > sorta strange we are forced to become an ISP-CLEC in order to have > the right to choose, own, and deploy xDSL services.. and > to distinguish our service from Bell and others.. remembering the > x2 vs kflex wars, I'm not so sure Bell would have chosen wisely. And > I really don't want them to make these kind of decisions for us.. > (besides keeping 75% of revenues) > > >In all cases, > >Bell is going to charge you some "client access" fee _per_ _client_. > >[I screamed bloddy murder the instant I say how HellSouth was going to > > "allow" competition in th DLS world.] > > Well they won't tell me a thing other than they are marketing way > to early here and won't know if they can offer us service until it's > turned up.. I hardly expect fair treatment from them based on past > history/experience.. call me cynical... :> > > > > >>Meanwhile, they are marketing ADSL all over our state but are *way* > >>ahead of themselves.. If we wait on them to deploy, it will be > >>expensive and put all ISP's on the same level and a notch below > >>themselves I imagine.. It really looks like a holy war ahead to me.. > >>And I'd like to hedge my bet or at least have some options.. > > > >What options? > > Well first, the option to deploy DSL equipment ourselves or buy the > service from someone wanting to offer it. Can't do the former without > becoming a CLEC.. Just having the option to purchase dry copper and > build out with our own flavor of xDSL would be a big option.. > > And I'd like the option of hauling the aggregate bandwidth back home > anyway I want.. like via ATM, frame cloud, xDSL, or even wireless spread > spectrum, (I'm sure Bell would not like seeing yagi antenna's outside > of their CO's.. :) Otherwise if Bell does it all "turn-key" you can > bet most of the xDSL revenues will go there likewise and give > bellsouth.net another advantage.. > > >Unless you run a piece of copper into your customers house, > >then you aren't going to get around Bell. > > Well for me it's the choice between having no choice (don't be a CLEC and > be at Bell's total mercy), or having some choices (become a CLEC and > have interconnection and colocation rights) And cutting PRI costs in > half or less by owning our own switch is another reason.. :) > > > > >>will 3COM give out 30 day evals? > > > >I'm sure some people could get a few free cards out of them :-) > > I'm probably not one of them :-\ And I think I'll need a chassis and > powersupply to go with those cards.. :) It really would be interesting > to play with one though.. Anyone know offhand what the cost per port > is? > > Allen > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) adsl/xdsl cards in tc chassis
From: Behrens, William <wbehrens@paracom.com>
Date: 1998-12-14 14:13:06

Only if it is still tarriffed. We tried to turn out xDSL over a year ago and Bell pulled the tarriff in Kansas for BA circuits stating that it was legacy and no one was using the service (ha). I am personally more interested in a low cost spread spectrum RF soulution that puts the Telco out of the picture all together. They will never play by the rules they expect everyone else to abide by. RF puts them out of the ball game altogether. William -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jack Singer Sent: Monday, December 14, 1998 12:12 PM We are setting up a dslam next to the phone company at a customer site and ordering alarm copper from there to another customer. We are running a local t-1 to the dslam. It is that simple. Alarm copper can be ordered without load coils.

Subject: RE: (usr-tc) AOPEN modem
From: fithen@networksplus.net
Date: 1998-12-14 14:15:50

We have one customer with that has a 'new' machine with a 'new' AOpen FM56-H fax/voice/modem. dual standards v90 and flex that he gets 52kbps connects everytime to our ARC chassis. which chassis ARC or NetServer? if ARC, what does 'mon ppp' tell you? > -----Original Message----- > From: Dan Lan [mailto:admin@tieus.com] > Sent: Monday, December 14, 1998 11:53 AM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) AOPEN modem > > > > A lot of our customer got AOpen Modem and they just cannot > connect to the > Total Control Chassis. They got drop of every time, cannot > get even 33.6K > connection. > I have called usr tech support for this issue. They just > saying some of the > patch code will release, but I dont think so ? > I also appreciate if any one got answer how to overcome this problem ? > -----Original Message----- > From: Brian K McIntire <bmcintire@commnet.com> > To: usr tc <usr-tc@lists.xmission.com> > Date: Monday, December 14, 1998 7:45 AM > Subject: (usr-tc) AOPEN modem > > > >Any one out there having difficulties with Aopen modems > connecting to Total > >Control Chassis'? Any success in resolving issues? > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) AOPEN modem
From: Dan Lan <admin@tieus.com>
Date: 1998-12-14 14:21:59

We are using NetServer. If I remember right, until now there is 5 A-Open users, only one can connect successfully. The others....., drop every time, and sometimes even get rediculas 1200bps connection. -----Original Message----- >We have one customer with that has a 'new' machine with >a 'new' AOpen FM56-H fax/voice/modem. dual standards v90 >and flex that he gets 52kbps connects everytime to our ARC >chassis. which chassis ARC or NetServer? if ARC, what >does 'mon ppp' tell you? > >> -----Original Message----- >> From: Dan Lan [mailto:admin@tieus.com] >> Sent: Monday, December 14, 1998 11:53 AM >> To: usr-tc@lists.xmission.com >> Subject: Re: (usr-tc) AOPEN modem >>

Subject: Re: (usr-tc) AOPEN modem
From: John Powell <jp@packet.ae.usr.com>
Date: 1998-12-14 16:30:31

Does anyone have any details on this modem? I have never heard of it and have no idea what chipset it is based on. JP On Mon, 14 Dec 1998, Dan Lan wrote: > We are using NetServer. If I remember right, until now there is 5 A-Open > users, only one can connect successfully. The others....., drop every time, > and sometimes even get rediculas 1200bps connection. > -----Original Message----- > From: fithen@networksplus.net <fithen@networksplus.net> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Monday, December 14, 1998 12:08 PM > Subject: RE: (usr-tc) AOPEN modem > > > >We have one customer with that has a 'new' machine with > >a 'new' AOpen FM56-H fax/voice/modem. dual standards v90 > >and flex that he gets 52kbps connects everytime to our ARC > >chassis. which chassis ARC or NetServer? if ARC, what > >does 'mon ppp' tell you? > > > >> -----Original Message----- > >> From: Dan Lan [mailto:admin@tieus.com] > >> Sent: Monday, December 14, 1998 11:53 AM > >> To: usr-tc@lists.xmission.com > >> Subject: Re: (usr-tc) AOPEN modem > >> > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) PPP troubles
From: Dale Hege <fhege@sover.net>
Date: 1998-12-14 16:38:19

Has anyone else been seeing lots of these PPP Link Down to . Unexpected (LCP) Layer Down, ID 7, Restarting Link 21475704, to . PPP connection down to . when monitoring ppp call events? We've also been getting lots of complaints like this He gets as far as verification, then the connection drops. After several tries he gets connected. He gets a message that he can't establish network connection, error 650. he was disconnected before verification 4 times, on the fifth try, he connected, was verified, then disconnected after a few seconds. from our customers. Does anyone have any ideas? We are running ARC 4.1.72-7 DSP 1.2.60 NMC 5.5.5 Any help would be great. Thanks -Dale

Subject: RE: (usr-tc) AOPEN modem
From: fithen@networksplus.net
Date: 1998-12-14 16:50:02

make sure they go directly from the modem to the wall jack (one cable - no splitters, caller ID, ans. machine, degaussing coils, etc..) also, open TCM, pull-up the hub, select all the modems, click on configuration, signal converter settings, and make sure 'link speed rate select' is set to 'variable'. if that doesn't do it put 3 commas after the dail string, OR, in DUN (extra settings) put AT&F to reset the modem to fact. settings. > -----Original Message----- > From: Dan Lan [mailto:admin@tieus.com] > Sent: Monday, December 14, 1998 4:22 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) AOPEN modem > > > We are using NetServer. If I remember right, until now there > is 5 A-Open > users, only one can connect successfully. The others....., > drop every time, > and sometimes even get rediculas 1200bps connection. > -----Original Message----- > From: fithen@networksplus.net <fithen@networksplus.net> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Monday, December 14, 1998 12:08 PM > Subject: RE: (usr-tc) AOPEN modem > > > >We have one customer with that has a 'new' machine with > >a 'new' AOpen FM56-H fax/voice/modem. dual standards v90 > >and flex that he gets 52kbps connects everytime to our ARC > >chassis. which chassis ARC or NetServer? if ARC, what > >does 'mon ppp' tell you? > > > >> -----Original Message----- > >> From: Dan Lan [mailto:admin@tieus.com] > >> Sent: Monday, December 14, 1998 11:53 AM > >> To: usr-tc@lists.xmission.com > >> Subject: Re: (usr-tc) AOPEN modem > >> > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) MPIP on NETserver
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-12-15 08:06:47

Thus spake Ray Bellis >I've followed instructions posted on the net for turning on MPIP between >two racks, but my MPIP server doesn't seem to be doing anything. On >'show netconns' there's no sign of any socket listening on port 5912. >server: >set mpipserver on >add mpipclient xx.xx.xx.xx secret You need to add the mpipserver as a client of itself. >client: >set mpipserver 1 xx.xx.xx.xx secret >I've rebooted the systems with no effect, is there anything else I need >to do? -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) Replacement NMC NIC cards anywhere?
From: Ray Bellis <rpb@community.net.uk>
Date: 1998-12-15 08:59:44

I've got a faulty Ethernet NIC card on one of my NMCs, it causes the NMC to reboot continuously if it's plugged in. My usual supplier has been told by 3Com that they can't supply the NIC on its own, I'd have to obtain a complete replacement NMC! Can anyone suggest where I might obtain just the NIC card at reasonable cost? thanks, Ray. -- Ray Bellis, MA(Oxon) - Technical Director - Oxford CommUnity Internet plc Windsor House, 12 High Street, Kidlington, OXFORD OX5 2PJ UK Telephone: +44-1865-856000 Fax: +44-1865-856001 Email: ray.bellis@community.net.uk URL: http://www.community.co.uk/

Subject: Re: (usr-tc) MPIP on NETserver
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-15 09:18:04

On Tue, 15 Dec 1998, Ray Bellis wrote: > I've followed instructions posted on the net for turning on MPIP between > two racks, but my MPIP server doesn't seem to be doing anything. On > 'show netconns' there's no sign of any socket listening on port 5912. > > server: > > set mpipserver on You are missing this set mpipserver x.x.x.x secret krish > add mpipclient xx.xx.xx.xx secret > > client: > set mpipserver 1 xx.xx.xx.xx secret > > I've rebooted the systems with no effect, is there anything else I need > to do? > > thanks, > > Ray. > > -- > Ray Bellis, MA(Oxon) - Technical Director - Oxford CommUnity Internet > plc > Windsor House, 12 High Street, Kidlington, OXFORD OX5 2PJ UK > Telephone: +44-1865-856000 Fax: +44-1865-856001 > Email: ray.bellis@community.net.uk URL: http://www.community.co.uk/ > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) MPIP on NETserver
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-12-15 09:32:49

Subject: (usr-tc) USR HiPerDSP and PRI Card settings for DSX-1 RX/TX levels
From: Sean Barrett <sbarrett@cyberzone.net>
Date: 1998-12-15 10:29:52

Does anybody have any suggestions for the TX/RX levels on the Total Controls? We currently use T-3's to bring in our PRI's. The T-3 comes into a Carrier Access Corp. WideBank 28 MUX, and is broken down to DSX-1's on the far side. The levels coming out of the Mux are at 0.0dB and appear fine. When we hook the PRI to the USR PRI or HiPerDSP card the Rx level on the USR stays at 0.0dB, but the TX level from the USR jumps to -10dB (Even though it is set to use the DSX1-0to133ft 0.0dB setting. The USR is attenuating 0dB on the PRI but I can't seem to get the ShortHaulNic settings to keep (I would assume that other settings have it functioning as a CSU) Does anybody know of a way to get the levels coming from the USR to come up to 0.0dB? Thanks- Sean -- - Sean P. Barrett, CEO - Mailing Address: - - CyberZone Internet Services - 942 Main Street - - MicroLine Computer Systems - Hartford, CT 06103 - - http://www.cyberzone.net - USA - - http://www.mcs-corp.com - Phone:(860) 520-6550- - sbarrett@cyberzone.net - Fax: (860) 520-6553-

Subject: (usr-tc) MPIP on NETserver
From: Ray Bellis <rpb@community.net.uk>
Date: 1998-12-15 10:54:12

I've followed instructions posted on the net for turning on MPIP between two racks, but my MPIP server doesn't seem to be doing anything. On 'show netconns' there's no sign of any socket listening on port 5912. server: set mpipserver on add mpipclient xx.xx.xx.xx secret client: set mpipserver 1 xx.xx.xx.xx secret I've rebooted the systems with no effect, is there anything else I need to do? thanks, Ray. -- Ray Bellis, MA(Oxon) - Technical Director - Oxford CommUnity Internet plc Windsor House, 12 High Street, Kidlington, OXFORD OX5 2PJ UK Telephone: +44-1865-856000 Fax: +44-1865-856001 Email: ray.bellis@community.net.uk URL: http://www.community.co.uk/

Subject: RE: (usr-tc) USR HiPerDSP and PRI Card settings for DSX-1 RX/TX levels
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-15 12:52:23

>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Sean Barrett >Sent: Tuesday, December 15, 1998 9:30 AM >To: usr-tc@lists.xmission.com >Subject: (usr-tc) USR HiPerDSP and PRI Card settings for DSX-1 RX/TX >levels > > >Does anybody have any suggestions for the TX/RX levels on the Total >Controls? > >We currently use T-3's to bring in our PRI's. The T-3 comes into a >Carrier Access Corp. WideBank 28 MUX, and is broken down to DSX-1's on >the far side. The levels coming out of the Mux are at 0.0dB and appear >fine. When we hook the PRI to the USR PRI or HiPerDSP card the Rx level >on the USR stays at 0.0dB, but the TX level from the USR jumps to -10dB >(Even though it is set to use the DSX1-0to133ft 0.0dB setting. Where are you reading this "jump" to -10db > >The USR is attenuating 0dB on the PRI but I can't seem to get the >ShortHaulNic settings to keep (I would assume that other settings have >it functioning as a CSU) > >Does anybody know of a way to get the levels coming from the USR to come >up to 0.0dB? > > >Thanks- > >Sean > > > >-- > >------------------------------------------------------------------ >- Sean P. Barrett, CEO - Mailing Address: - >- CyberZone Internet Services - 942 Main Street - >- MicroLine Computer Systems - Hartford, CT 06103 - >- http://www.cyberzone.net - USA - >- http://www.mcs-corp.com - Phone:(860) 520-6550- >- sbarrett@cyberzone.net - Fax: (860) 520-6553- >------------------------------------------------------------------ > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) didn't get online
From: Erri Wibowo <erri@mailserver.idola.net.id>
Date: 1998-12-15 15:34:12

We have Remote Access Server US. Robotics with Total Control Net Server card. Our user often disconnected after few second. The logfile in our logserver is: Dec 10 08:43:46 usrobotic1 S18 didn't get online! status=-1, connect_fail=79, link_fail=31 ^^^ The port is different every log messages and that messages appear every 10 minutes. What is that mean ? How to overcome this problem ? Any help would be appreciated tx Erri Wibowo

Subject: Re: (usr-tc) adsl/xdsl cards in tc chassis
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-12-15 16:34:51

matthew de Jongh said once upon a time: > does anyone on the list have any firsthand experience using the tc adsl or >xdsl cards in a chassis to provide services such as high speed dedicated >access to office buildings? I used Pairgain 384K and Tut System 384K units on a LADA (alarm) circuit to my house, in addition to the USR unit. The USR unit was the only one that failed and the documentation was so miserable that I had no idea whether it was the configuration of the card, or the length of the copper.

Subject: (usr-tc) Funked up HDM card
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-12-15 16:44:34

I've got an HDM card that is repeatedly rebooting. I suspect the flash has gone bad. Is there a way to flash an HDM card via serial? Attempting to do so via the NMC is futile.

Subject: Re: (usr-tc) Funked up HDM card
From: David Bolen <db3l@ans.net>
Date: 1998-12-15 18:53:04

Pete Ashdown <pashdown@xmission.com> writes: > I've got an HDM card that is repeatedly rebooting. I suspect the flash has > gone bad. Is there a way to flash an HDM card via serial? Attempting to > do so via the NMC is futile. Connect to the serial port and wait for the next reboot, when you get an "SDL-2" banner. You have a short period (maybe ~15s or so) to enter in the command "AT{Z}" (or "AT{Z{F}}" to format flash first - rarely necessary) - don't include the quotes. Once you have done that the card will go into Z-Modem receive mode, and you can just transmit the DMF file with your favorite communication package using Z-Modem. This process should work on any SDL-2 capable card (such as the HiperDSP and HiperARC). Although I think some of the cards may also auto-detect a Z-Modem download following the SDL-2 prompt, the AT sequence is more generic. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: (usr-tc) HiperDSP modems stop talking?
From: Dan Hollis <goemon@sasami.anime.net>
Date: 1998-12-15 20:54:53

All of a sudden, two modems on a HiperDSP (5 and 6) refuse to receive calls. Reboots have no effect. This chassis has not been touched in months. HiperARC 4.0.30, HiperDSP 1.2.5. Strange output from 'list pbus ses': HiPer>> list pbus ses Interface Slot Channel Session Rpkts Spkts PktSize slot:1/mod:1 1 1 0 1433 1478 4096 slot:1/mod:2 1 2 1 4588 4754 4096 slot:1/mod:3 1 3 2 451 449 4096 slot:1/mod:4 1 4 3 7895 6696 4096 slot:1/mod:5 1 5 4 0 0 4096 slot:1/mod:6 1 6 5 1 1 4096 slot:1/mod:7 1 7 6 790 714 4096 slot:1/mod:8 1 8 7 9812 8058 4096 slot:1/mod:9 1 9 8 5230 4387 4096 Nothing in syslog to indicate any problems, even on 'verbose'. Just says slot:1/mod:5 and slot:1/mod:6 are recieving calls, but it never completes them. I just get Facility "Auth Facility", Level "COMMON":: A call, call id = 279333, has arrived on interface slot:1/mod:5 Facility "Auth Facility", Level "COMMON":: A call, call id = 344871, has arrived on interface slot:1/mod:6 Over and over and over. Server is at a remote unmanned POP so I cannot attach a console to the DSP card. -Dan

Subject: Re: (usr-tc) HiperDSP modems stop talking?
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-16 08:55:42

Do a list interface on the hiper arc. Tell me how these two modem interfaces are show on the hiper arc. They should be slot:x/mod:y up up 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, 15 Dec 1998, Dan Hollis wrote: > All of a sudden, two modems on a HiperDSP (5 and 6) refuse to receive > calls. Reboots have no effect. This chassis has not been touched in > months. > > HiperARC 4.0.30, HiperDSP 1.2.5. > > Strange output from 'list pbus ses': > > HiPer>> list pbus ses > Interface Slot Channel Session Rpkts Spkts PktSize > slot:1/mod:1 1 1 0 1433 1478 4096 > slot:1/mod:2 1 2 1 4588 4754 4096 > slot:1/mod:3 1 3 2 451 449 4096 > slot:1/mod:4 1 4 3 7895 6696 4096 > slot:1/mod:5 1 5 4 0 0 4096 > slot:1/mod:6 1 6 5 1 1 4096 > slot:1/mod:7 1 7 6 790 714 4096 > slot:1/mod:8 1 8 7 9812 8058 4096 > slot:1/mod:9 1 9 8 5230 4387 4096 > > Nothing in syslog to indicate any problems, even on 'verbose'. Just says > slot:1/mod:5 and slot:1/mod:6 are recieving calls, but it never completes > them. I just get > > Facility "Auth Facility", Level "COMMON":: A call, call id = 279333, has > arrived on interface slot:1/mod:5 > Facility "Auth Facility", Level "COMMON":: A call, call id = 344871, has > arrived on interface slot:1/mod:6 > > Over and over and over. > > Server is at a remote unmanned POP so I cannot attach a console to the DSP > card. > > -Dan > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) Adding administrators to NETServer
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-12-16 09:37:57

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Peter D. Mayer |Sent: Wednesday, December 16, 1998 8:52 AM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) Adding administrators to NETServer | | |Is there any way to add extra administrator accounts to the NETServer like |you can with the HiPer ARC? No.

Subject: (usr-tc) Adding administrators to NETServer
From: Peter D. Mayer <dmayer@netwalk.com>
Date: 1998-12-16 09:51:53

Is there any way to add extra administrator accounts to the NETServer like you can with the HiPer ARC? Thanks, Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com

Subject: (usr-tc) v.90
From: Brian Jacklin <csabmj@mail.tds.net>
Date: 1998-12-16 09:53:36

I'm testing v.90 on a Hiper DSP and HiperArc card. We plan on rolling the two out together. However I must be missing some settings somewhere. When I call into the Hiper card, I get a connection but no better than 38000. I move the same span to a Netserver/Quad combination running x2 code and get a 43k connection. I'm dialing in with a courier modem with the latest code on it. The HiperArc is running 4.1.11 and the DSP 1.2.5 Any help Thanks Brian

Subject: Re: (usr-tc) HiperDSP modems stop talking?
From: Dan Hollis <goemon@sasami.anime.net>
Date: 1998-12-16 10:29:35

On Wed, 16 Dec 1998, Tatai SV Krishnan wrote: > Do a list interface on the hiper arc. Tell me how these two modem > interfaces are show on the hiper arc. They should be > slot:x/mod:y up up They are. Anything else? -Dan

Subject: (usr-tc) SNMPSet Based Call Termination on TotalControl
From: Lim Fung <limfung@pacific.net.sg>
Date: 1998-12-16 10:44:19

hi, I was wondering if anyone has tried to do a SNMP-Based call termination for the TotalControl boxes? It seemed that from the usrUsrMan (user management group) of the TC MIB, that we can use uumActiveSessionAction OBJECT-TYPE SYNTAX INTEGER { disconnect(6) } ACCESS write-only STATUS mandatory DESCRIPTION "We need to be able to disconnect all users with a particular user name" ::= { uumActiveSessionEntry 5 } to disconnect the user. However, other OIDs in the same group such as uumActiveSessionUserNAme are under the "not-accessible" access type so is there a way to terminate a user by userid or session-id (also documented as not-accessible in the MIB) on the TC box? rgds, lf.

Subject: Re: (usr-tc) HiperDSP modems stop talking?
From: Dan Hollis <goemon@sasami.anime.net>
Date: 1998-12-16 11:01:34

On Wed, 16 Dec 1998, Tatai SV Krishnan wrote: > On Wed, 16 Dec 1998, Dan Hollis wrote: > > On Wed, 16 Dec 1998, Tatai SV Krishnan wrote: > > > Do a list interface on the hiper arc. Tell me how these two modem > > > interfaces are show on the hiper arc. They should be > > > slot:x/mod:y up up > > They are. Anything else? > This basically says that the modem is active on the packet bus and the > Hiper arc is not getting a call from the modem. It may be possible that > you have a couple of modems on the DSP gone bad. The only way I would be > able to tell you that the modems are gone bad is to actually be able to > logon to your hiper arc and see if we get a message on the packet bus > when a call comes to this particular modem Reboots didnt help at all, but a chassis power cycle cleared everything up and its receiving calls perfectly again. So this looks like a firmware bug on the HiperDSP or something. Not good. -Dan

Subject: Re: (usr-tc) HiperDSP modems stop talking?
From: Dan Hollis <goemon@sasami.anime.net>
Date: 1998-12-16 11:03:20

On Wed, 16 Dec 1998, Ricky Beam wrote: > Hmm, can you setup a "telnet" dialout group for the modem(s) in question and > see if you can get any command response out of them? If you can (and the > trunk supports it) see if you can dialout. How do you do that? > If you can dialout, then I'd guess it's either the card call routing setup > is hosed, How? The chassis configuration hasnt been touched in months. > the configuration is hosed, How? The chassis configuration hasnt been touched in months. > or the telco is playing tricks with ya'. A chassis power cycle cleared the problem, so this looks like a HiperDSP bug. -Dan

Subject: Re: (usr-tc) v.90
From: Ronald E. Kushner <ron@glis.net>
Date: 1998-12-16 11:12:03

Brian Jacklin wrote: > > I'm testing v.90 on a Hiper DSP and HiperArc card. > We plan on rolling the two out together. However I must be missing > some settings somewhere. When I call into the Hiper card, I get a > connection but no better than 38000. I move the same span to > a Netserver/Quad combination running x2 code and get a 43k connection. > > I'm dialing in with a courier modem with the latest code on it. > The HiperArc is running 4.1.11 and the DSP 1.2.5 > Any help > Thanks > Brian X2 reports what it thinks it will connect at, V.90 shows actual connect speed. Are you going by what you see through TCM as current link speed, or are you just going by what the modem reports? You should connect, pass some data for a few minutes, and then check the current speed through TCM. X2 and V.90 usually will be within 2400 of each other. I saw a real boost in throughput when I went to V.90, even though the V.90 connect speeds seem to be a notch lower than X2. -Ron GLISnet, Inc. +1 810/939.9885

Subject: Re: (usr-tc) HiperDSP modems stop talking?
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-16 12:43:04

On Wed, 16 Dec 1998, Dan Hollis wrote: > On Wed, 16 Dec 1998, Tatai SV Krishnan wrote: > > Do a list interface on the hiper arc. Tell me how these two modem > > interfaces are show on the hiper arc. They should be > > slot:x/mod:y up up > > They are. Anything else? This basically says that the modem is active on the packet bus and the Hiper arc is not getting a call from the modem. It may be possible that you have a couple of modems on the DSP gone bad. The only way I would be able to tell you that the modems are gone bad is to actually be able to logon to your hiper arc and see if we get a message on the packet bus when a call comes to this particular modem krish > > -Dan >

Subject: Re: (usr-tc) HiperDSP modems stop talking?
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-12-16 13:42:31

Tatai SV Krishnan was heard to say: >On Wed, 16 Dec 1998, Dan Hollis wrote: >> On Wed, 16 Dec 1998, Tatai SV Krishnan wrote: >> > Do a list interface on the hiper arc. Tell me how these two modem >> > interfaces are show on the hiper arc. They should be >> > slot:x/mod:y up up >> >> They are. Anything else? > >This basically says that the modem is active on the packet bus and the >Hiper arc is not getting a call from the modem. It may be possible that >you have a couple of modems on the DSP gone bad. The only way I would be >able to tell you that the modems are gone bad is to actually be able to >logon to your hiper arc and see if we get a message on the packet bus >when a call comes to this particular modem Hmm, can you setup a "telnet" dialout group for the modem(s) in question and see if you can get any command response out of them? If you can (and the trunk supports it) see if you can dialout. If you can dialout, then I'd guess it's either the card call routing setup is hosed, the configuration is hosed, or the telco is playing tricks with ya'. --Ricky

Subject: Re: (usr-tc) HiperDSP modems stop talking?
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-12-16 14:52:23

Dan Hollis was heard to say: >On Wed, 16 Dec 1998, Ricky Beam wrote: >> Hmm, can you setup a "telnet" dialout group for the modem(s) in question and >> see if you can get any command response out of them? If you can (and the >> trunk supports it) see if you can dialout. > >How do you do that? I'll send that later. >> If you can dialout, then I'd guess it's either the card call routing setup >> is hosed, > >How? The chassis configuration hasnt been touched in months. > >> the configuration is hosed, > >How? The chassis configuration hasnt been touched in months. > >> or the telco is playing tricks with ya'. > >A chassis power cycle cleared the problem, so this looks like a HiperDSP >bug. Heh, these things happen. I have chassis' go nuts sometimes. I'd blame comsic radiation... --Ricky

Subject: (usr-tc) Dual PRI/T1 Card Wanted
From: Dwight G. Jones <djones@imagen.net>
Date: 1998-12-16 15:30:45

Please contact djones@imagen.net if you have such a puppy.

Subject: Re: (usr-tc) HiperDSP modems stop talking?
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-12-16 17:43:03

Ricky Beam was heard to say: >Dan Hollis was heard to say: >>On Wed, 16 Dec 1998, Ricky Beam wrote: >>> Hmm, can you setup a "telnet" dialout group for the modem(s) in question and >>> see if you can get any command response out of them? If you can (and the >>> trunk supports it) see if you can dialout. >> >>How do you do that? > >I'll send that later. Here's how I did it... ### Dialout add network service dialout:1 server_type telnetd socket 7001 data "service_type =dialout,modem_group=\"slot:14\",login_banner=\"\r\nInterpath Communications, In c.\r\n\",login_prompt=\"dialout:1 Login: \",auth=on" # add network service dialout:2 server_type telnetd socket 7002 data "service_type =dialout,modem_group=\"slot:15\",login_banner=\"\r\nInterpath Communications, In c.\r\n\",login_prompt=\"dialout:2 Login: \",auth=on" #################### add network service ntty:1 server_type cleartcpd socket 6001 data "service_type= dialout,modem_group=\"slot:14\",login_banner=\"\r\nInterpath Communications, Inc .\r\n\",login_prompt=\"ntty:1 Login: \",auth=on" # add network service ntty:2 server_type cleartcpd socket 6002 data "service_type= dialout,modem_group=\"slot:15\",login_banner=\"\r\nInterpath Communications, Inc .\r\n\",login_prompt=\"ntty:2 Login: \",auth=on" ... works like a charm (when the PRIs are plugged in :-)) Remember to reset the modem back to nvram/template configuration when you disconnect as it doesn't do it on its own (i.e. at*v2=3 sticks) --Ricky

Subject: (usr-tc) health checks on the hubs
From: Brian <signal@shreve.net>
Date: 1998-12-17 08:40:50

What sort of sanity checking do you all do routinly to make sure nothing is amiss? Somethings I do here: grep -i critical /var/log/<usrtc_syslogs> "show pbus sess" on hubs and make sure packet counters look sane "list interfaces" to make sure they are all up list various "counters" on the arc to make sure they are too high Any others? I find "list interfaces" is a must when things go bad, because I have seen many times modems become deactive on the pbus. 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

Subject: (usr-tc) health checks on the hubs
From: Brian <signal@shreve.net>
Date: 1998-12-17 08:40:50

Subject: RE: (usr-tc) HiperDSP modems stop talking?
From: Robert von Bismarck <rvb@petrel.ch>
Date: 1998-12-17 11:16:23

This sounds like you inspect your PoP's with a geiger counter... You living near three-mile-island nuclear power plant ? ;-) Robert > Heh, these things happen. I have chassis' go nuts sometimes. I'd > blame > comsic radiation... > > --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.

Subject: Re: (usr-tc) NT4 with Sportster 128 into a TCH
From: C Thompson <cthompson@wingnet.net>
Date: 1998-12-17 11:46:02

Is there some way to set NT4's dial up connection so that the ISDN profile only lists -one- SPID? That wouldn't allow 128 at all, but it would at least get them online. > OK, > > I've had several customers with this problem and still haven't found a > solution (other than bomb redmond, but my biases are showing). > > Windows NT 4.0, with a Sportster 128, dialing into our NETServers... > > Apparently, NT dials both channels of the Sportster at the same time > (why? I have no stinkin' idea). > > Microsoft apparently has a knowledgebase article on their site (I say > apparently, because I refuse to 'register' to get access to their > support stuff, but others here have done so), which lays the blame on > Livingston PortMaster equipment not handling the bundling correctly when > two channels are dialed at the same time. Personally, I think its > broken that they dial both channels at the same time, but for some > reason NT seems to insist on doing this. The knowledgebase article > number that I have is Q169136 FWIW. > > What can I do here? My personal inclination is to say NT is broken > (well...I *know* its broken...in many ways...but in this specific way > its broken as well) and tell the customer to find a new dial-up product > to use, but I figured I could at least make an effort to find a > solution to this. > > Any ideas? > -- > 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. > 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: O, give thanks unto the Lord for He is good, for His mercy endureth forever.

Subject: Re: (usr-tc) Ooops.... two ARC's crashing at short intervals..
From: Frank Basso <frank@got.net>
Date: 1998-12-17 12:28:24

We still use 4.0.30 and have uptimes over 150 days. -Frank -----Original Message----- >Weird, I had two ARC's crash on me at short intervals (one week), >resulting in following crashdumps. > >I'm still running 4.0.29, as I haven't found time to upgrade yet and I >found it to be very stable (50+ days uptime as yet) > >Should I take time to upgrade to 4.1.72-7 or 4.0.30 ? >Are those dumps possible DoS attacks ? >Will Mars invade Earth on 1 Jan 1999 ? > >Thanks for any pointers, here come the dumps : > > >EXCEPTION 0000 CRASH DUMP (mm-dd-yy : 11-29-1998 hr-min-sec : >08-26-15) > >AppVer: 4.0.29-22 KernVer: 0x00000028 > >GPRs: >R0: 0x00278278 R1: 0x03FAF7F0 R2: 0x000B3794 R3: 0x019A07B8 >R4: 0x019A0790 R5: 0x00000000 R6: 0x019A07A4 R7: 0x0003FFFC >R8: 0x0000FFFF R9: 0x019A07A4 R10: 0x00000000 R11: 0x00000011 >R12: 0x00000091 R13: 0x000BB964 R14: 0x0044B980 R15: 0x00002710 >R16: 0x0044B98C R17: 0x000B3B94 R18: 0x0044B978 R19: 0x00000000 >R20: 0x013729C4 R21: 0x00000021 R22: 0x013729A3 R23: 0x01958410 >R24: 0x02124910 R25: 0x0209C5D0 R26: 0x00192001 R27: 0x01A65710 >R28: 0x00000000 R29: 0x0000000A R30: 0x0209C5D0 R31: 0x01958410 > >CR: 0x44000000 XER: 0x20000014 LR: 0x00278278 CTR: >0x003FBAB0 >SRR0: 0x00277E70 SRR1: 0x0000B930 DSISR: 0x57415443 DAR: >0x48444F47 > >82660 Registers: >Err Status 1: 0x00, Err Status 2: 0x00, CPU Err: 0x14, PCI Err: 0x06 >CPU/PCI Addr: 0x00050C40, Sys Error Addr: 0x0005FDE0 > > >Call Stack: > 0x00277E70 (Exception return address - SRR0) > 0x00278278 > 0x0026108C > 0x00261128 > 0x002E620C > 0x002F2C44 > 0x002F432C > 0x002E59E8 > 0x003721C4 > 0x003739C0 > 0x0037F7F0 > 0x00393E8C > 0x003A3728 > 0x003A9244 > 0x003A7EB0 > 0x003A20EC > 0x00393E8C > 0x00399CB0 > 0x0039B168 > 0x0039E324 > 0x003972FC > > >Here goes the second..... > > >EXCEPTION 0300 CRASH DUMP (mm-dd-yy : 12-07-1998 hr-min-sec : >14-55-21) > >AppVer: 4.0.29-22 KernVer: 0x00000028 > >GPRs: >R0: 0x00000000 R1: 0x03FAF8C8 R2: 0x000B3794 R3: 0x00000001 >R4: 0x00000016 R5: 0x00000022 R6: 0x0000000E R7: 0x00000000 >R8: 0x00000000 R9: 0x00000012 R10: 0x4C000064 R11: 0x48003B19 >R12: 0x00000004 R13: 0x000BB964 R14: 0x0044B980 R15: 0x00002710 >R16: 0x0044B98C R17: 0x000B3B94 R18: 0x0044B978 R19: 0x013D9310 >R20: 0x0230B8D0 R21: 0x00000012 R22: 0x0129DBE3 R23: 0x00000000 >R24: 0x00000000 R25: 0x00000001 R26: 0x00000016 R27: 0x00000003 >R28: 0x02334890 R29: 0x94003B7D R30: 0x00000000 R31: 0x02334890 > >CR: 0x24000000 XER: 0x00000004 LR: 0x002F3B30 CTR: >0x0030B314 >SRR0: 0x002F3D00 SRR1: 0x0000B930 DSISR: 0x40000000 DAR: >0x94003B86 > >82660 Registers: >Err Status 1: 0x00, Err Status 2: 0x00, CPU Err: 0x14, PCI Err: 0x06 >CPU/PCI Addr: 0x00050C40, Sys Error Addr: 0x0005FDE0 > > >Call Stack: > 0x002F3D00 (Exception return address - SRR0) > 0x002F3B30 > 0x002F4318 > 0x002E59E8 > 0x003721C4 > 0x003739C0 > 0x0037F7F0 > 0x00393E8C > 0x003A3728 > 0x003A9244 > 0x003A7EB0 > 0x003A20EC > 0x00393E8C > 0x00399CB0 > 0x0039B168 > 0x0039E324 > 0x003972FC > 0x00396378 > 0x00393E8C > 0x003B818C > 0x003936A8 > 0x00392750 > > > >Robert von Bismarck >Network Systems Engineer >Petrel Communications SA *** SPAN / SCAN *** > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) HiperDSP modems stop talking?
From: Randy Doran <randydoran@usa.net>
Date: 1998-12-17 14:50:53

Krish, When logged into the HiPerARC, how can you see messages on the packet bus from calls? - Randy At 12:43 PM 12/16/98 -0600, you wrote: >On Wed, 16 Dec 1998, Dan Hollis wrote: > >> On Wed, 16 Dec 1998, Tatai SV Krishnan wrote: >> > Do a list interface on the hiper arc. Tell me how these two modem >> > interfaces are show on the hiper arc. They should be >> > slot:x/mod:y up up >> >> They are. Anything else? > >This basically says that the modem is active on the packet bus and the >Hiper arc is not getting a call from the modem. It may be possible that >you have a couple of modems on the DSP gone bad. The only way I would be >able to tell you that the modems are gone bad is to actually be able to >logon to your hiper arc and see if we get a message on the packet bus >when a call comes to this particular modem > >krish > >> >> -Dan >> > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Ooops.... two ARC's crashing at short intervals..
From: Brian <signal@shreve.net>
Date: 1998-12-17 15:12:48

On Thu, 17 Dec 1998, Robert von Bismarck wrote: > Weird, I had two ARC's crash on me at short intervals (one week), > resulting in following crashdumps. > > I'm still running 4.0.29, as I haven't found time to upgrade yet and I > found it to be very stable (50+ days uptime as yet) > > Should I take time to upgrade to 4.1.72-7 or 4.0.30 ? > Are those dumps possible DoS attacks ? > Will Mars invade Earth on 1 Jan 1999 ? More than likely they are mem leaks If both hubs were rebooted before at the same time, then more than likley it was your busier hub that crashed first, followed by the next busiest. > > Thanks for any pointers, here come the dumps : > > > EXCEPTION 0000 CRASH DUMP (mm-dd-yy : 11-29-1998 hr-min-sec : > 08-26-15) > > AppVer: 4.0.29-22 KernVer: 0x00000028 > > GPRs: > R0: 0x00278278 R1: 0x03FAF7F0 R2: 0x000B3794 R3: 0x019A07B8 > R4: 0x019A0790 R5: 0x00000000 R6: 0x019A07A4 R7: 0x0003FFFC > R8: 0x0000FFFF R9: 0x019A07A4 R10: 0x00000000 R11: 0x00000011 > R12: 0x00000091 R13: 0x000BB964 R14: 0x0044B980 R15: 0x00002710 > R16: 0x0044B98C R17: 0x000B3B94 R18: 0x0044B978 R19: 0x00000000 > R20: 0x013729C4 R21: 0x00000021 R22: 0x013729A3 R23: 0x01958410 > R24: 0x02124910 R25: 0x0209C5D0 R26: 0x00192001 R27: 0x01A65710 > R28: 0x00000000 R29: 0x0000000A R30: 0x0209C5D0 R31: 0x01958410 > > CR: 0x44000000 XER: 0x20000014 LR: 0x00278278 CTR: > 0x003FBAB0 > SRR0: 0x00277E70 SRR1: 0x0000B930 DSISR: 0x57415443 DAR: > 0x48444F47 > > 82660 Registers: > Err Status 1: 0x00, Err Status 2: 0x00, CPU Err: 0x14, PCI Err: 0x06 > CPU/PCI Addr: 0x00050C40, Sys Error Addr: 0x0005FDE0 > > > Call Stack: > 0x00277E70 (Exception return address - SRR0) > 0x00278278 > 0x0026108C > 0x00261128 > 0x002E620C > 0x002F2C44 > 0x002F432C > 0x002E59E8 > 0x003721C4 > 0x003739C0 > 0x0037F7F0 > 0x00393E8C > 0x003A3728 > 0x003A9244 > 0x003A7EB0 > 0x003A20EC > 0x00393E8C > 0x00399CB0 > 0x0039B168 > 0x0039E324 > 0x003972FC > > > Here goes the second..... > > > EXCEPTION 0300 CRASH DUMP (mm-dd-yy : 12-07-1998 hr-min-sec : > 14-55-21) > > AppVer: 4.0.29-22 KernVer: 0x00000028 > > GPRs: > R0: 0x00000000 R1: 0x03FAF8C8 R2: 0x000B3794 R3: 0x00000001 > R4: 0x00000016 R5: 0x00000022 R6: 0x0000000E R7: 0x00000000 > R8: 0x00000000 R9: 0x00000012 R10: 0x4C000064 R11: 0x48003B19 > R12: 0x00000004 R13: 0x000BB964 R14: 0x0044B980 R15: 0x00002710 > R16: 0x0044B98C R17: 0x000B3B94 R18: 0x0044B978 R19: 0x013D9310 > R20: 0x0230B8D0 R21: 0x00000012 R22: 0x0129DBE3 R23: 0x00000000 > R24: 0x00000000 R25: 0x00000001 R26: 0x00000016 R27: 0x00000003 > R28: 0x02334890 R29: 0x94003B7D R30: 0x00000000 R31: 0x02334890 > > CR: 0x24000000 XER: 0x00000004 LR: 0x002F3B30 CTR: > 0x0030B314 > SRR0: 0x002F3D00 SRR1: 0x0000B930 DSISR: 0x40000000 DAR: > 0x94003B86 > > 82660 Registers: > Err Status 1: 0x00, Err Status 2: 0x00, CPU Err: 0x14, PCI Err: 0x06 > CPU/PCI Addr: 0x00050C40, Sys Error Addr: 0x0005FDE0 > > > Call Stack: > 0x002F3D00 (Exception return address - SRR0) > 0x002F3B30 > 0x002F4318 > 0x002E59E8 > 0x003721C4 > 0x003739C0 > 0x0037F7F0 > 0x00393E8C > 0x003A3728 > 0x003A9244 > 0x003A7EB0 > 0x003A20EC > 0x00393E8C > 0x00399CB0 > 0x0039B168 > 0x0039E324 > 0x003972FC > 0x00396378 > 0x00393E8C > 0x003B818C > 0x003936A8 > 0x00392750 > > > > Robert von Bismarck > Network Systems Engineer > Petrel Communications SA *** SPAN / SCAN *** > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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

Subject: Re: (usr-tc) Ooops.... two ARC's crashing at short intervals..
From: Brian <signal@shreve.net>
Date: 1998-12-17 15:12:48

Subject: Re: (usr-tc) Ooops.... two ARC's crashing at short intervals..
From: Brian <signal@shreve.net>
Date: 1998-12-17 15:13:16

On Thu, 17 Dec 1998, Frank Basso wrote: > We still use 4.0.30 and have uptimes over 150 days. How many modems in use on those hubs? > > -Frank > -----Original Message----- > From: Robert von Bismarck <rvb@petrel.ch> > To: 'usr-tc@xmission.com' <usr-tc@xmission.com> > Date: Thursday, December 17, 1998 12:15 PM > Subject: (usr-tc) Ooops.... two ARC's crashing at short intervals.. > > > >Weird, I had two ARC's crash on me at short intervals (one week), > >resulting in following crashdumps. > > > >I'm still running 4.0.29, as I haven't found time to upgrade yet and I > >found it to be very stable (50+ days uptime as yet) > > > >Should I take time to upgrade to 4.1.72-7 or 4.0.30 ? > >Are those dumps possible DoS attacks ? > >Will Mars invade Earth on 1 Jan 1999 ? > > > >Thanks for any pointers, here come the dumps : > > > > > >EXCEPTION 0000 CRASH DUMP (mm-dd-yy : 11-29-1998 hr-min-sec : > >08-26-15) > > > >AppVer: 4.0.29-22 KernVer: 0x00000028 > > > >GPRs: > >R0: 0x00278278 R1: 0x03FAF7F0 R2: 0x000B3794 R3: 0x019A07B8 > >R4: 0x019A0790 R5: 0x00000000 R6: 0x019A07A4 R7: 0x0003FFFC > >R8: 0x0000FFFF R9: 0x019A07A4 R10: 0x00000000 R11: 0x00000011 > >R12: 0x00000091 R13: 0x000BB964 R14: 0x0044B980 R15: 0x00002710 > >R16: 0x0044B98C R17: 0x000B3B94 R18: 0x0044B978 R19: 0x00000000 > >R20: 0x013729C4 R21: 0x00000021 R22: 0x013729A3 R23: 0x01958410 > >R24: 0x02124910 R25: 0x0209C5D0 R26: 0x00192001 R27: 0x01A65710 > >R28: 0x00000000 R29: 0x0000000A R30: 0x0209C5D0 R31: 0x01958410 > > > >CR: 0x44000000 XER: 0x20000014 LR: 0x00278278 CTR: > >0x003FBAB0 > >SRR0: 0x00277E70 SRR1: 0x0000B930 DSISR: 0x57415443 DAR: > >0x48444F47 > > > >82660 Registers: > >Err Status 1: 0x00, Err Status 2: 0x00, CPU Err: 0x14, PCI Err: 0x06 > >CPU/PCI Addr: 0x00050C40, Sys Error Addr: 0x0005FDE0 > > > > > >Call Stack: > > 0x00277E70 (Exception return address - SRR0) > > 0x00278278 > > 0x0026108C > > 0x00261128 > > 0x002E620C > > 0x002F2C44 > > 0x002F432C > > 0x002E59E8 > > 0x003721C4 > > 0x003739C0 > > 0x0037F7F0 > > 0x00393E8C > > 0x003A3728 > > 0x003A9244 > > 0x003A7EB0 > > 0x003A20EC > > 0x00393E8C > > 0x00399CB0 > > 0x0039B168 > > 0x0039E324 > > 0x003972FC > > > > > >Here goes the second..... > > > > > >EXCEPTION 0300 CRASH DUMP (mm-dd-yy : 12-07-1998 hr-min-sec : > >14-55-21) > > > >AppVer: 4.0.29-22 KernVer: 0x00000028 > > > >GPRs: > >R0: 0x00000000 R1: 0x03FAF8C8 R2: 0x000B3794 R3: 0x00000001 > >R4: 0x00000016 R5: 0x00000022 R6: 0x0000000E R7: 0x00000000 > >R8: 0x00000000 R9: 0x00000012 R10: 0x4C000064 R11: 0x48003B19 > >R12: 0x00000004 R13: 0x000BB964 R14: 0x0044B980 R15: 0x00002710 > >R16: 0x0044B98C R17: 0x000B3B94 R18: 0x0044B978 R19: 0x013D9310 > >R20: 0x0230B8D0 R21: 0x00000012 R22: 0x0129DBE3 R23: 0x00000000 > >R24: 0x00000000 R25: 0x00000001 R26: 0x00000016 R27: 0x00000003 > >R28: 0x02334890 R29: 0x94003B7D R30: 0x00000000 R31: 0x02334890 > > > >CR: 0x24000000 XER: 0x00000004 LR: 0x002F3B30 CTR: > >0x0030B314 > >SRR0: 0x002F3D00 SRR1: 0x0000B930 DSISR: 0x40000000 DAR: > >0x94003B86 > > > >82660 Registers: > >Err Status 1: 0x00, Err Status 2: 0x00, CPU Err: 0x14, PCI Err: 0x06 > >CPU/PCI Addr: 0x00050C40, Sys Error Addr: 0x0005FDE0 > > > > > >Call Stack: > > 0x002F3D00 (Exception return address - SRR0) > > 0x002F3B30 > > 0x002F4318 > > 0x002E59E8 > > 0x003721C4 > > 0x003739C0 > > 0x0037F7F0 > > 0x00393E8C > > 0x003A3728 > > 0x003A9244 > > 0x003A7EB0 > > 0x003A20EC > > 0x00393E8C > > 0x00399CB0 > > 0x0039B168 > > 0x0039E324 > > 0x003972FC > > 0x00396378 > > 0x00393E8C > > 0x003B818C > > 0x003936A8 > > 0x00392750 > > > > > > > >Robert von Bismarck > >Network Systems Engineer > >Petrel Communications SA *** SPAN / SCAN *** > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and 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

Subject: Re: (usr-tc) health checks on the hubs
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-12-17 15:27:06

Nice list David. Wouldn't it be great if 3com/USR had software to do all of that for us mere mortals?

Subject: Re: (usr-tc) HiperDSP modems stop talking?
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-17 15:54:52

You can issues debug commands to see if the call is being sent to the hiper arc. You can set facilities to see if the call is actually arrived. set fac call log deb will show if the incoming is being sent 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, 17 Dec 1998, Randy Doran wrote: > Krish, > > When logged into the HiPerARC, how can you see messages on the packet bus > from calls? > > - Randy > > At 12:43 PM 12/16/98 -0600, you wrote: > >On Wed, 16 Dec 1998, Dan Hollis wrote: > > > >> On Wed, 16 Dec 1998, Tatai SV Krishnan wrote: > >> > Do a list interface on the hiper arc. Tell me how these two modem > >> > interfaces are show on the hiper arc. They should be > >> > slot:x/mod:y up up > >> > >> They are. Anything else? > > > >This basically says that the modem is active on the packet bus and the > >Hiper arc is not getting a call from the modem. It may be possible that > >you have a couple of modems on the DSP gone bad. The only way I would be > >able to tell you that the modems are gone bad is to actually be able to > >logon to your hiper arc and see if we get a message on the packet bus > >when a call comes to this particular modem > > > >krish > > > >> > >> -Dan > >> > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Latest ER code for HiPer
From: Randy Doran <randydoran@usa.net>
Date: 1998-12-17 16:36:04

BellSouth reconfigured our POPs that are on 5ESS's to roundRobin hunting. It was very easy for them to do and they didn't have to take down the trunks. Now when a call hits a DS0 on one span the the next call goes to the next span and so on until every span has taken a call and then it goes back to the first span in the hunt. In a large hunt group, all empty modems will have to take a call before it goes back to one that was just dropped. This should give plenty of time for a modem to reset usnless the hunt is full, then your probably more worried about busies than stuck modems. The fast busies and operator intercept messages appear to have stopped. We have our call routing set to fixed assignment. (This can't be done on a DMS100 switch unless you have an NFAS set up and as of now the most recent HiPerDSP release code cannot do NFAS.) Randy Doran Circuit Engineer \ Dialup Network Coordinator e.spire Communication's CyberGate Internet Services At 01:55 PM 11/7/98 -0500, you wrote: >Thus spake Brian >>On Fri, 6 Nov 1998, Brian K McIntire wrote: >>> try setting the dsp's for round robin. Did you restore from default on the >>> modems and the templates, save both to nvram and reboot? >>> What do you have for the number of dtmftones > >>I have seen dead-air on answer on our racks from time to time. I run >>fixed assignment right now on the HDM's and may try Round-Robin to see if >>this clears things up. Has 3Com acknowledged that their is an issue with >>fixed assignment on the HDM's? > >Guys...this *isn't* a bug. The ds0 is reset'ing, the modem is >reset'ing...just the ds0 is faster at it is all. If you use >fixed-assignment on the DSP's with first-available from the telco, this >is the risk you take and what you're going to run into. Either don't >use first-available with the telco, or don't use fixed-assignment on the >DSP's, that's all there is to it. >-- >Jeff McAdams Email: jeffm@iglou.com >Head Network Administrator Voice: (502) 966-3848 >IgLou Internet Services (800) 436-4456 > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) health checks on the hubs
From: David Bolen <db3l@ans.net>
Date: 1998-12-17 17:12:47

Brian <signal@shreve.net> writes: > What sort of sanity checking do you all do routinly to make sure nothing > is amiss? This isn't completely exhaustive, but here's some examples of activities that we have automated in terms of monitoring (the times for scheduled stuff is our current cycle but it gets adjusted at times). I'm haven't quite gotten into the details of each SNMP object or log message that is polled/scanned but this should give a good general idea - the specifics would take a _large_ message :-) In general, any of these tasks or events can and often do take automatic action (say, to busy out a channel) when they can. Any alerts are inserted into an alert tree on the local management workstation which is polled centrally and made available through a single alert management tool to any operator or engineer. All alerts are tagged with identification information for the component in the system, the owner (script) of the alert, severity/id and textual information for the alert. All traps and syslog messages generated by the gear are logged and kept on the local management workstations for a week, so in the event that these monitoring tools fire or we need to post-mortem a failure we learn about any other way, we can go back at least that far in terms of raw information. For the actual monitoring tools below, their own log files are often kept for much longer (in some cases, like serial number polling, for the lifetime of a site). Scheduled Tasks

Subject: Re: (usr-tc) Replacement NMC NIC cards anywhere?
From: Suncoast Networking USR Mailbox <usrtcmail@flasuncoast.net>
Date: 1998-12-17 17:17:33

I've got a bad PRI NIC I've been meaning to get replaced. Am I going to have to buy a PRI processor NAC card with it? Or is this just a UK thing. ??? Steve >I've got a faulty Ethernet NIC card on one of my NMCs, it causes the NMC >to reboot continuously if it's plugged in. > >My usual supplier has been told by 3Com that they can't supply the NIC >on its own, I'd have to obtain a complete replacement NMC! > >Can anyone suggest where I might obtain just the NIC card at reasonable >cost? > >thanks, > >Ray. > >-- >Ray Bellis, MA(Oxon) - Technical Director - Oxford CommUnity Internet >plc >Windsor House, 12 High Street, Kidlington, OXFORD OX5 2PJ UK > Telephone: +44-1865-856000 Fax: +44-1865-856001 >Email: ray.bellis@community.net.uk URL: http://www.community.co.uk/ > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >

Subject: (usr-tc) Ooops.... two ARC's crashing at short intervals..
From: Robert von Bismarck <rvb@petrel.ch>
Date: 1998-12-17 17:31:36

Weird, I had two ARC's crash on me at short intervals (one week), resulting in following crashdumps. I'm still running 4.0.29, as I haven't found time to upgrade yet and I found it to be very stable (50+ days uptime as yet) Should I take time to upgrade to 4.1.72-7 or 4.0.30 ? Are those dumps possible DoS attacks ? Will Mars invade Earth on 1 Jan 1999 ? Thanks for any pointers, here come the dumps : EXCEPTION 0000 CRASH DUMP (mm-dd-yy : 11-29-1998 hr-min-sec : 08-26-15) AppVer: 4.0.29-22 KernVer: 0x00000028 GPRs: R0: 0x00278278 R1: 0x03FAF7F0 R2: 0x000B3794 R3: 0x019A07B8 R4: 0x019A0790 R5: 0x00000000 R6: 0x019A07A4 R7: 0x0003FFFC R8: 0x0000FFFF R9: 0x019A07A4 R10: 0x00000000 R11: 0x00000011 R12: 0x00000091 R13: 0x000BB964 R14: 0x0044B980 R15: 0x00002710 R16: 0x0044B98C R17: 0x000B3B94 R18: 0x0044B978 R19: 0x00000000 R20: 0x013729C4 R21: 0x00000021 R22: 0x013729A3 R23: 0x01958410 R24: 0x02124910 R25: 0x0209C5D0 R26: 0x00192001 R27: 0x01A65710 R28: 0x00000000 R29: 0x0000000A R30: 0x0209C5D0 R31: 0x01958410 CR: 0x44000000 XER: 0x20000014 LR: 0x00278278 CTR: 0x003FBAB0 SRR0: 0x00277E70 SRR1: 0x0000B930 DSISR: 0x57415443 DAR: 0x48444F47 82660 Registers: Err Status 1: 0x00, Err Status 2: 0x00, CPU Err: 0x14, PCI Err: 0x06 CPU/PCI Addr: 0x00050C40, Sys Error Addr: 0x0005FDE0 Call Stack: 0x00277E70 (Exception return address - SRR0) 0x00278278 0x0026108C 0x00261128 0x002E620C 0x002F2C44 0x002F432C 0x002E59E8 0x003721C4 0x003739C0 0x0037F7F0 0x00393E8C 0x003A3728 0x003A9244 0x003A7EB0 0x003A20EC 0x00393E8C 0x00399CB0 0x0039B168 0x0039E324 0x003972FC Here goes the second..... EXCEPTION 0300 CRASH DUMP (mm-dd-yy : 12-07-1998 hr-min-sec : 14-55-21) AppVer: 4.0.29-22 KernVer: 0x00000028 GPRs: R0: 0x00000000 R1: 0x03FAF8C8 R2: 0x000B3794 R3: 0x00000001 R4: 0x00000016 R5: 0x00000022 R6: 0x0000000E R7: 0x00000000 R8: 0x00000000 R9: 0x00000012 R10: 0x4C000064 R11: 0x48003B19 R12: 0x00000004 R13: 0x000BB964 R14: 0x0044B980 R15: 0x00002710 R16: 0x0044B98C R17: 0x000B3B94 R18: 0x0044B978 R19: 0x013D9310 R20: 0x0230B8D0 R21: 0x00000012 R22: 0x0129DBE3 R23: 0x00000000 R24: 0x00000000 R25: 0x00000001 R26: 0x00000016 R27: 0x00000003 R28: 0x02334890 R29: 0x94003B7D R30: 0x00000000 R31: 0x02334890 CR: 0x24000000 XER: 0x00000004 LR: 0x002F3B30 CTR: 0x0030B314 SRR0: 0x002F3D00 SRR1: 0x0000B930 DSISR: 0x40000000 DAR: 0x94003B86 82660 Registers: Err Status 1: 0x00, Err Status 2: 0x00, CPU Err: 0x14, PCI Err: 0x06 CPU/PCI Addr: 0x00050C40, Sys Error Addr: 0x0005FDE0 Call Stack: 0x002F3D00 (Exception return address - SRR0) 0x002F3B30 0x002F4318 0x002E59E8 0x003721C4 0x003739C0 0x0037F7F0 0x00393E8C 0x003A3728 0x003A9244 0x003A7EB0 0x003A20EC 0x00393E8C 0x00399CB0 0x0039B168 0x0039E324 0x003972FC 0x00396378 0x00393E8C 0x003B818C 0x003936A8 0x00392750 Robert von Bismarck Network Systems Engineer Petrel Communications SA *** SPAN / SCAN ***

Subject: Re: (usr-tc) health checks on the hubs
From: David Bolen <db3l@ans.net>
Date: 1998-12-17 17:44:14

Pete Ashdown <pashdown@xmission.com> writes: > Nice list David. Wouldn't it be great if 3com/USR had software to do all > of that for us mere mortals? But then what software development (one of my major joys) would I have gotten to do these past years? :-) On a slightly more serious note - some of our stuff falls naturally out of design choices made early on (like decently-powered workstations local to all equipment) which may not always be feasible to solve with general purpose tools. I wouldn't want to try to build a package expecting to perform some of this monitoring on the timescales we do it, from a single central location. Even our backbone NOC, while using some commercial products, does much of its monitoring with custom developed tools for efficiency or functionality purposes. It sometimes seems that coming up with a generic enough operational tool that performs well and is flexible enough to fit specific needs of a wide range of users is a very non-trivial thing. It would be nice though, and certainly not something to stop wishing for. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: Re: (usr-tc) health checks on the hubs
From: Charles Sprickman <spork@inch.com>
Date: 1998-12-17 17:49:27

Also, I'm running a HArc with 4.0.30. I just set up syslogging so I can watch some stuff, but the loglevel setting (set sysloG 207.240.xxx.xxx faCILITY log_Local6 logLEVEL commON) doesn't seem to do anything... This isn't a 'save and reboot' item is it? I've tried all levels and I still get junk about appletalk in the logs... Thanks, Charles -- =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------= On Thu, 17 Dec 1998, Brian wrote: > What sort of sanity checking do you all do routinly to make sure nothing > is amiss? Somethings I do here: > > grep -i critical /var/log/<usrtc_syslogs> > "show pbus sess" on hubs and make sure packet counters look sane > "list interfaces" to make sure they are all up > list various "counters" on the arc to make sure they are too high > > Any others? > > I find "list interfaces" is a must when things go bad, because I have seen > many times modems become deactive on the pbus. > > 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. >

Subject: Re: (usr-tc) health checks on the hubs
From: Charles Sprickman <spork@inch.com>
Date: 1998-12-17 17:49:27

Subject: Re: (usr-tc) NT4 with Sportster 128 into a TCH
From: John Powell <jp@packet.ae.usr.com>
Date: 1998-12-17 18:15:26

On Thu, 17 Dec 1998, C Thompson wrote: > Is there some way to set NT4's dial up connection so that the ISDN > profile only lists -one- SPID? That wouldn't allow 128 at all, but > it would at least get them online. Interesting idea, but in most cases that would not stop the card from trying both channels. Only the DMS-100 will only allow one B to be used by one SPID. The finer implementations of ISDN BRI (read: anything but DMS) will allow multiple digital calls off one one SPID. I have a BRI off a 5E here at home. I have one SPID dedicated to the ISDN phone (that I love) and the other SPID is attached to whatever BRI device I choose to use at the time, I can make 128K calls to my heart's content, it just places both calls using the same TEI/LT assigned to that SPID. On a 5E, that requires CSD=2 on the switch translation for that SPID, but that is pretty standard (I did not request it, I got it by default). EWSD is pretty much the same, different parameter though. This would, of course, also not work outside North America where they really did ISDN right (Euro-ISDN rules). All of this is just a kludge anyway, you could just tell Windoze to only use 1 B channel if that were the objective (the objective, I assume, is to get 128K). JP

Subject: Re: (usr-tc) NT4 with Sportster 128 into a TCH
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-12-17 18:47:21

Thus spake C Thompson >Is there some way to set NT4's dial up connection so that the ISDN >profile only lists -one- SPID? That wouldn't allow 128 at all, but >it would at least get them online. I think our customers that are getting this are getting online ok, just bundling the second channel is what gives the error. Besides...that wouldn't be taken as much of a "solution" and would likely tick off my customer even more. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) health checks on the hubs
From: Brian <signal@shreve.net>
Date: 1998-12-17 22:24:30

On Thu, 17 Dec 1998, Charles Sprickman wrote: > Also, I'm running a HArc with 4.0.30. I just set up syslogging so I can > watch some stuff, but the loglevel setting (set sysloG 207.240.xxx.xxx > faCILITY log_Local6 logLEVEL commON) doesn't seem to do anything... This > isn't a 'save and reboot' item is it? I've tried all levels and I still > get junk about appletalk in the logs... did you add appropriate entries in syslog.conf? Are you running syslog with its ability to log remote machines? > > Thanks, > > Charles > > -- > =-----------------= = > | Charles Sprickman Internet Channel | > | INCH System Administration Team (212)243-5200 | > | spork@inch.com access@inch.com | > = =----------------= > > On Thu, 17 Dec 1998, Brian wrote: > > > What sort of sanity checking do you all do routinly to make sure nothing > > is amiss? Somethings I do here: > > > > grep -i critical /var/log/<usrtc_syslogs> > > "show pbus sess" on hubs and make sure packet counters look sane > > "list interfaces" to make sure they are all up > > list various "counters" on the arc to make sure they are too high > > > > Any others? > > > > I find "list interfaces" is a must when things go bad, because I have seen > > many times modems become deactive on the pbus. > > > > 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

Subject: Re: (usr-tc) health checks on the hubs
From: Brian <signal@shreve.net>
Date: 1998-12-17 22:24:30

Subject: Re: (usr-tc) health checks on the hubs
From: Charles Sprickman <spork@inch.com>
Date: 1998-12-18 00:23:24

Oh, I get the syslog entries fine, it's just that I get EVERYTHING no matter what loglevel I specify. Even stuff about appletalk, which is thoroughly baffling... Is there also a knob to twiddle on the netserver to limit verbosity? Running 3.7.73... Thanks, Charles > On Thu, 17 Dec 1998, Charles Sprickman wrote: > > > Also, I'm running a HArc with 4.0.30. I just set up syslogging so I can > > watch some stuff, but the loglevel setting (set sysloG 207.240.xxx.xxx > > faCILITY log_Local6 logLEVEL commON) doesn't seem to do anything... This > > isn't a 'save and reboot' item is it? I've tried all levels and I still > > get junk about appletalk in the logs... > > > did you add appropriate entries in syslog.conf? Are you running syslog > with its ability to log remote machines? > > > > > > > Thanks, > > > > Charles > > > > -- > > =-----------------= = > > | Charles Sprickman Internet Channel | > > | INCH System Administration Team (212)243-5200 | > > | spork@inch.com access@inch.com | > > = =----------------= > > > > On Thu, 17 Dec 1998, Brian wrote: > > > > > What sort of sanity checking do you all do routinly to make sure nothing > > > is amiss? Somethings I do here: > > > > > > grep -i critical /var/log/<usrtc_syslogs> > > > "show pbus sess" on hubs and make sure packet counters look sane > > > "list interfaces" to make sure they are all up > > > list various "counters" on the arc to make sure they are too high > > > > > > Any others? > > > > > > I find "list interfaces" is a must when things go bad, because I have seen > > > many times modems become deactive on the pbus. > > > > > > 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. >

Subject: (usr-tc) arc chassis awareness
From: Jeff Lynch <jeff@mercury.jorsm.com>
Date: 1998-12-18 08:46:00

We have a chassis with hiperarc, quads (slots 2-13) and and hiperdsp in slot 14. We have the arc configured for chassis_awareness enabled but the arc will not recognize the hdm. We're running 4.1.72 on the harc and 1.2.60 on the hdm. Here's a "list int" .... slot:12/mod:2 Up Up slot:12/mod:3 Up Up slot:12/mod:4 Up Up slot:13/mod:1 Up Up slot:13/mod:2 Up Up slot:13/mod:3 Up Up slot:13/mod:4 Up Up internal Up Up loopback Up Up Here's a "sho nmc settings" NMC SETTINGS Chassis Awareness: ENABLED Dynamic Slot Assignment: DISABLED DSA Idle Rebalancing: ENABLED Any ideas why we still don't see the hiperdsp in slot 14? --jeff ========================================================================= Jeffrey A. Lynch JORSM Internet email: jeff@jorsm.com Northwest Indiana's Full-Service Provider Voice: (219)322-2180 927 Sheffield Avenue, Dyer, IN 46311 Autoresponse: info@jorsm.com http://www.jorsm.com

Subject: Re: (usr-tc) arc chassis awareness
From: Brian <signal@shreve.net>
Date: 1998-12-18 09:21:22

I gave up on Chassis Awareness early in the game, I think others did too. Card positions usually are not very dynamic in an ISP, so statically assigning them is usually not a bad idea, then at least you know that's one less thing to worry about. Brian On Fri, 18 Dec 1998, Jeff Lynch wrote: > We have a chassis with hiperarc, quads (slots 2-13) and and hiperdsp > in slot 14. We have the arc configured for chassis_awareness enabled > but the arc will not recognize the hdm. We're running 4.1.72 on the > harc and 1.2.60 on the hdm. > > Here's a "list int" > .... > slot:12/mod:2 Up Up > slot:12/mod:3 Up Up > slot:12/mod:4 Up Up > slot:13/mod:1 Up Up > slot:13/mod:2 Up Up > slot:13/mod:3 Up Up > slot:13/mod:4 Up Up > internal Up Up > loopback Up Up > > Here's a "sho nmc settings" > > NMC SETTINGS > Chassis Awareness: ENABLED > Dynamic Slot Assignment: DISABLED > DSA Idle Rebalancing: ENABLED > > Any ideas why we still don't see the hiperdsp in slot 14? > > --jeff > > ========================================================================= > Jeffrey A. Lynch JORSM Internet > email: jeff@jorsm.com Northwest Indiana's Full-Service Provider > Voice: (219)322-2180 927 Sheffield Avenue, Dyer, IN 46311 > Autoresponse: info@jorsm.com http://www.jorsm.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. > 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

Subject: RE: (usr-tc) arc chassis awareness
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-12-18 09:41:27

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Lynch |Sent: Friday, December 18, 1998 8:46 AM |To: usr-tc@xmission.com |Subject: (usr-tc) arc chassis awareness | | |We have a chassis with hiperarc, quads (slots 2-13) and and hiperdsp |in slot 14. We have the arc configured for chassis_awareness enabled |but the arc will not recognize the hdm. We're running 4.1.72 on the |harc and 1.2.60 on the hdm. | |Here's a "list int" |.... |slot:12/mod:2 Up Up |slot:12/mod:3 Up Up |slot:12/mod:4 Up Up |slot:13/mod:1 Up Up |slot:13/mod:2 Up Up |slot:13/mod:3 Up Up |slot:13/mod:4 Up Up |internal Up Up |loopback Up Up | |Here's a "sho nmc settings" | |NMC SETTINGS |Chassis Awareness: ENABLED |Dynamic Slot Assignment: DISABLED |DSA Idle Rebalancing: ENABLED | |Any ideas why we still don't see the hiperdsp in slot 14? First turn off the DSA idle Rebalancing. This feature does not apply until you get 6.x NMC and 2.x DSP code. The harc has support for features that are not yet in the code for the rest of the components. What does "List chassis" show? Second: Is there any other card in the chassis. A netserver maybe that is idle.. If so make sure it does not have controll of the DSP. This would cause packet bus contention and the symptom seen above. Third: Have you tried to configure the DSP statically without chassis awareness?? -M

Subject: RE: (usr-tc) arc chassis awareness
From: Jeff Lynch <jeff@mercury.jorsm.com>
Date: 1998-12-18 10:48:06

On Fri, 18 Dec 1998, Mike Wronski wrote: > |-----Original Message----- > |From: owner-usr-tc@lists.xmission.com > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Lynch > |Sent: Friday, December 18, 1998 8:46 AM > |To: usr-tc@xmission.com > |Subject: (usr-tc) arc chassis awareness > | > | > |We have a chassis with hiperarc, quads (slots 2-13) and and hiperdsp > |in slot 14. We have the arc configured for chassis_awareness enabled > |but the arc will not recognize the hdm. We're running 4.1.72 on the > |harc and 1.2.60 on the hdm. > | > |Here's a "list int" > |.... > |slot:12/mod:2 Up Up > |slot:12/mod:3 Up Up > |slot:12/mod:4 Up Up > |slot:13/mod:1 Up Up > |slot:13/mod:2 Up Up > |slot:13/mod:3 Up Up > |slot:13/mod:4 Up Up > |internal Up Up > |loopback Up Up > | > |Here's a "sho nmc settings" > | > |NMC SETTINGS > |Chassis Awareness: ENABLED > |Dynamic Slot Assignment: DISABLED > |DSA Idle Rebalancing: ENABLED > | > |Any ideas why we still don't see the hiperdsp in slot 14? > > First turn off the DSA idle Rebalancing. This feature does not apply until you > get 6.x NMC and 2.x DSP code. The harc has support for features that are not yet > in the code for the rest of the components. > > What does "List chassis" show? Here's the problem. Still getting used to hiperarcs. The list chassis did not show the harc as the owner of slot 14. Changed that now the hdm shows up in list interfaces and takes calls. Just curious, all our hubs have the same NMC settings (above) and are working fine. Are there any side effects if we don't turn off DSA idle rebalancing before the hdm/nmc releases that support this? We prefer to leave things as vanilla as possible so we only change a minnimum of settings from factory default that are necessary for proper/reliable operation. I would not hesitate to do so if recommended. > > Second: Is there any other card in the chassis. A netserver maybe that is idle.. > If so make sure it does not have controll of the DSP. This would cause packet bus > contention and the symptom seen above. No but I see how this would complicate matters. > > Third: Have you tried to configure the DSP statically without chassis awareness?? Wasn't necessary. I think we'll try keeping chassis awareness enabled until we _have_ to disable it. We have had great stability for two week now on 4.1.72, 1.2.60, 5.10.9, and 5.5.5. I realize things change a bit w.r.t. chassis awareness when multiple harcs or netservers are in a single chassis. ========================================================================= Jeffrey A. Lynch JORSM Internet email: jeff@jorsm.com Northwest Indiana's Full-Service Provider Voice: (219)322-2180 927 Sheffield Avenue, Dyer, IN 46311 Autoresponse: info@jorsm.com http://www.jorsm.com

Subject: Re: (usr-tc) arc chassis awareness
From: Jeff Lynch <jeff@mercury.jorsm.com>
Date: 1998-12-18 10:54:18

On Fri, 18 Dec 1998, Brian wrote: > > I gave up on Chassis Awareness early in the game, I think others did too. > Card positions usually are not very dynamic in an ISP, so statically > assigning them is usually not a bad idea, then at least you know that's > one less thing to worry about. > > Brian I know you've been burned before. But I think things have improved since early adopters like you found most of the problems. If we get burned on this, we'll go that route as well. However, chassis awareness has worked fine for us so far, but it's only been about 3 weeks sent we went hiper. --jeff > > > On Fri, 18 Dec 1998, Jeff Lynch wrote: > > > We have a chassis with hiperarc, quads (slots 2-13) and and hiperdsp > > in slot 14. We have the arc configured for chassis_awareness enabled > > but the arc will not recognize the hdm. We're running 4.1.72 on the > > harc and 1.2.60 on the hdm. > > > > Here's a "list int" > > .... > > slot:12/mod:2 Up Up > > slot:12/mod:3 Up Up > > slot:12/mod:4 Up Up > > slot:13/mod:1 Up Up > > slot:13/mod:2 Up Up > > slot:13/mod:3 Up Up > > slot:13/mod:4 Up Up > > internal Up Up > > loopback Up Up > > > > Here's a "sho nmc settings" > > > > NMC SETTINGS > > Chassis Awareness: ENABLED > > Dynamic Slot Assignment: DISABLED > > DSA Idle Rebalancing: ENABLED > > > > Any ideas why we still don't see the hiperdsp in slot 14? > > > > --jeff > > > > ========================================================================= > > Jeffrey A. Lynch JORSM Internet > > email: jeff@jorsm.com Northwest Indiana's Full-Service Provider > > Voice: (219)322-2180 927 Sheffield Avenue, Dyer, IN 46311 > > Autoresponse: info@jorsm.com http://www.jorsm.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. > > > > -------------------------------------------------------------------------- > 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. > ========================================================================= Jeffrey A. Lynch JORSM Internet email: jeff@jorsm.com Northwest Indiana's Full-Service Provider Voice: (219)322-2180 927 Sheffield Avenue, Dyer, IN 46311 Autoresponse: info@jorsm.com http://www.jorsm.com

Subject: RE: (usr-tc) arc chassis awareness
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-12-18 11:17:42

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Lynch |Sent: Friday, December 18, 1998 10:48 AM |To: usr-tc@lists.xmission.com |Subject: RE: (usr-tc) arc chassis awareness | | |On Fri, 18 Dec 1998, Mike Wronski wrote: | |> |> What does "List chassis" show? | |Here's the problem. Still getting used to hiperarcs. The list chassis |did not show the harc as the owner of slot 14. Changed that now the hdm |shows up in list interfaces and takes calls. | |Just curious, all our hubs have the same NMC settings (above) and are |working fine. Are there any side effects if we don't turn off DSA idle |rebalancing before the hdm/nmc releases that support this? |We prefer to leave things as vanilla as possible so we only change a |minnimum of settings from factory default that are necessary for |proper/reliable operation. I would not hesitate to do so if recommended. This is kind of an unknown.. As of now there are no reported problems from the field and we have not seen any in house either.. 4.1.72-7 is fairly well distributed at this time. The facility relies on messages from the NMC and DSP to do the balancing. It "should not"(tm) cause you any problems if left alone. I just tend to go with the safe option and turn anything that is not being used "OFF".. You can use your best judgement on this one. -M

Subject: RE: (usr-tc) Hiper ARC ethernet
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-12-18 12:16:07

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Andres Kroonmaa |Sent: Friday, December 18, 1998 10:24 AM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) Hiper ARC ethernet | | | | Hi, | | Quick question. | Hiper ARC ethernet port is 10/100 capable, right? | Now, does is support full-duplex in a) 100tx mode, b) 10tx mode? Yes full in both modes. | How can you force full-duplex or half-duplex operation? You cant. The HARC is auto detect only. You can force your switch port to full or half and the HARC will comply. What switch is it? | I have one Harc connected to a switch port that's 10baseT full-duplex | and the switch is seeing lots of errors coming from the Harc. The | switch does not allow auto-neg on 10base-t ports. |

Subject: (usr-tc) Netserver 16I
From: Tony Loosle <tony@tcsourceone.com>
Date: 1998-12-18 12:24:03

I have seen talk about the v.90 code for the netserver. Does anyone know when it will be released. Also, has anyone tried the new code for the netserver? Tony

Subject: RE: (usr-tc) Hiper ARC ethernet
From: Brian <signal@shreve.net>
Date: 1998-12-18 14:40:53

> | Quick question. > | Hiper ARC ethernet port is 10/100 capable, right? > | Now, does is support full-duplex in a) 100tx mode, b) 10tx mode? > Yes full in both modes. > > | How can you force full-duplex or half-duplex operation? > > You cant. The HARC is auto detect only. You can force your switch port to full or > half and the HARC will comply. > What switch is it? I think it would be great if you could view the duplex the arc was in at a given moment, this would be good for diagnosing problems. Brian > > | I have one Harc connected to a switch port that's 10baseT full-duplex > | and the switch is seeing lots of errors coming from the Harc. The > | switch does not allow auto-neg on 10base-t ports. > | > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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

Subject: RE: (usr-tc) health checks on the hubs
From: David Bolen <db3l@ans.net>
Date: 1998-12-18 14:41:15

stauffer@galenica.ch (Stauffer Walter) writes: > your list sounds impressive indeed. May I ask for a few details ? > What kind of "workstation" are you using ? What trap receiver ? We use a local Unix management workstation in every "rack" of equipment we place in the field. For the most part, all of the operational code (daemons, scripts, management tools) running on the management workstations and our central systems are locally developed. Our development is targetted at Unix in general, with primary target platforms currently AIX 3.2, BSDI (2.1 and 4.0) and Solaris 2.5/2.6, since those are the main machine types in use here (RS/6000 and EdgeServer[/Pro] (running BSDI) management workstations, and Sparcs running Solaris as desktop and central machines) I've covered various high level info on our configuration in some earlier notes to this list, so rather than re-sending them they should be available in the archives - one in particular ("Re: (usr-tc) Stats?", Message-Id <CMM.0.90.2.868654981.db3l@foo.ans.net> on 7/11/97) provides a high level view of on how data collection flows in our system. If you can't find it in the archives, drop me a private note and I can scrounge up a copy. > I checked out the NMC and the corresponding Windows app and > found it not very useful for my needs (alerts when modems stop > working; too many / too few calls for the time of the day; etc). > I gave it back (the NMC). Did I miss something, or are you using > something completely different ? We don't use any 3Com software, but directly interact with the NMC (or NETServer/HiperARC) via SNMP with our own software. I'd agree that the 3Com management software might not fit all needs, but we have been very pleased with the SNMP management capabilities provided by the NMC. Personally, I'd never run a chassis without the NMC since there are many things that can only be done through that path. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: Re: (usr-tc) Netserver 16I
From: John Rockwell <jrockwel@clarityconnect.com>
Date: 1998-12-18 17:42:55

Evil, evil, evil. Once we upgraded our Netserver 16/Is to 4.1.7 (one of the early releases of USR code for the unit) we were graced with modems that would hang in a "DLL None" state. Units would simply stop responding to telnet, dialins wouldn't yield a login prompt, console connections wouldn't work, the run/fail light would just sit there and blink, so basically the unit was useless until you power cycled it. At one point we had this happening no less than once per week, sometimes more. 3com made numerous suggestions as to how we could resolve this issue, but in the end I was told "This code doesn't work. Downgrade to Livingston code (the 3.x codebase)". Under the 3.x codebase we had absolutely no problems. The units have been rock solid since the down(up?)grade. The only problem that I have seen is that the RIP support leaves something to be desired and it doesn't appear to support multi-link PPP for ISDN connections. Your best bet, in my mind, would be to run the latest rev. of Livingston code, and the latest beta of their (USRs) modem code (which fixed most of the "DLL None" problems). I have heard mixed stories from 3com about the status of the v.90 code for the Netservers, but the consensus seems to be that it won't be released. Feel free to drop me a line if you have any questions about the Netservers and the various codebases for them. I've shed much blood on that product. >I have seen talk about the v.90 code for the netserver. Does anyone >know when it will be released. Also, has anyone tried the new code for >the netserver? > > >Tony > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 Rockwell e-mail: jrockwel@clarityconnect.com Network Engineer Clarityconnect, Inc. Ithaca Area: (607)257-8268 Outside Ithaca Area: (888)322-4900 Try us: http://www.clarityconnect.com

Subject: (usr-tc) Analog calls work but ISDN dosen't...
From: Dave Martin <dpm@netcetera.com>
Date: 1998-12-18 17:43:59

We've recently installed our first PRI-based system in the hopes of being able to use it to terminate ISDN calls as well as analog (we're currently using Livingston PM2ei's for this function) and are having problems getting ISDN sessions working. The calls are hitting the DSP and the ARC is logging the following PPP negotiations: Outgoing PPP Data on interface: slot:1/mod:1 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 57 24 92 de PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 It sends out the above packet ~5 times and then gives up. We've tried connecting with a variety of ISDN devices (including a Cisco 1605 router, a Motorola BitSurfr Pro) with no joy. The 1605 logs the following: 4d19h: BR0:1 LCP: O CONFREQ [REQsent] id 157 len 10 4d19h: BR0:1 LCP: MagicNumber 0xF902B8DE (0x0506F902B8DE) 4d19h: BR0:1 LCP: I CONFREQ [REQsent] id 2 len 35 4d19h: BR0:1 LCP: MRU 1514 (0x010405EA) 4d19h: BR0:1 LCP: AuthProto PAP (0x0304C023) 4d19h: BR0:1 LCP: MagicNumber 0x24E05BB0 (0x050624E05BB0) 4d19h: BR0:1 LCP: PFC (0x0702) 4d19h: BR0:1 LCP: ACFC (0x0802) 4d19h: BR0:1 LCP: MRRU 1514 (0x110405EA) 4d19h: BR0:1 L.CP: EndpointDisc 3 00c0.4911.0d5e (0x13090300C049110D5E) 4d19h: BR0:1 LCP: O CONFREJ [REQsent] id 2 len 17 4d19h: BR0:1 LCP: MRRU 1514 (0x110405EA) 4d19h: BR0:1 LCP: EndpointDisc 3 00c0.4911.0d5e (0x13090300C049110D5E). 4d19h: BR0:1 LCP: TIMEout: Time 0x18E40504 State REQsent Not being a PPP wizard, I take the above to indicate that the 1605 and the TC were unable to negotiate a suitable MRRU. True? The ARC is running 4.1.72-7 and the DSP is running 1.2.5. I have a ticket open with 3com tech support (#127-272), but they've gone dark for over 24 hours so now I'm escalating the ticket to this list. Grateful for any insights...

Subject: (usr-tc) quick start for Hiper ARC ???
From: C Thompson <cthompson@wingnet.net>
Date: 1998-12-18 19:11:18

I've tried setting up a new Hiper ARC (4.1.1) with an existing quad modem chassis. I got as far as users not being authenticated because the RADIUS user being sent was the name 'unauthenticated.' This is using a standard Livingston RADIUS (actually, ESVA). Can anyone give some hints, help on doing a quick start in a situation like this? I'd like to test this over the weekend 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 Elvis is dead and I don't feel so good myself.

Subject: (usr-tc) Hiper ARC ethernet
From: Andres Kroonmaa <andre@ml.ee>
Date: 1998-12-18 19:24:27

Hi, Quick question. Hiper ARC ethernet port is 10/100 capable, right? Now, does is support full-duplex in a) 100tx mode, b) 10tx mode? How can you force full-duplex or half-duplex operation? I have one Harc connected to a switch port that's 10baseT full-duplex and the switch is seeing lots of errors coming from the Harc. The switch does not allow auto-neg on 10base-t ports. Another Harc is on 100baseT and works fine. ---------------------------------------------------------------------- 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 ----------------------------------------------------------------------

Subject: RE: (usr-tc) health checks on the hubs
From: Stauffer Walter <stauffer@galenica.ch>
Date: 1998-12-18 19:41:10

David Bolen wrote: > This isn't completely exhaustive, but here's some examples of > activities that we have automated in terms of monitoring (the times > for scheduled stuff is our current cycle but it gets adjusted at > times). I'm haven't quite gotten into the details of each SNMP object > or log message that is polled/scanned but this should give a good > general idea - the specifics would take a _large_ message :-) <snip> David, your list sounds impressive indeed. May I ask for a few details ? What kind of "workstation" are you using ? What trap receiver ? I checked out the NMC and the corresponding Windows app and found it not very useful for my needs (alerts when modems stop working; too many / too few calls for the time of the day; etc). I gave it back (the NMC). Did I miss something, or are you using something completely different ? TIA & best regards, Walter

Subject: (usr-tc) TC-HUB Backdoor passwords...
From: Ricky <rickyz@mindspring.com>
Date: 1998-12-18 22:03:05

Krish, and the rest of you 3Com Gurus... I get this email from a customer today: "I have a former employee who claims that he "found" the backdoor password to the ARC card and was able to login to = the hub via telnet and expose all user names AND passwords in plain-text. I just need to make sure with the appropriate persons at 3Com. I can't = afford to have him or any other bozo screw up our hubs given our recent spate = of partial unavailability." Now, I am under the impression that: there is no embedded back door password; If it doesn't show up in a: Hiper>list users It ain't a doorway to login.=20 Snmp-wise, however, I know you need to secure the chassis with = different nmc community strings, and also, in the ARC, do a: Hiper>list snmp communities What shows up there is a doorway...it'll say "R", or "RW" as to whether = it is read, or read write (and this is for use with HARM...snmp), but=20 How 'bout the "default" user? Is there way to hack through that?=20 I don't expect you to give details on how, just say whether or not it's = possible (and be honest; like Clinton). o o =20 \_ _/=20 <(@@)> ----------------000----()----000------------------- RickyZ@mindspring.com THE TRUTH IS OUT THERE 00O O00 =A9

Subject: (usr-tc) USR message from Syslog....
From: Sean Barrett <sbarrett@cyberzone.net>
Date: 1998-12-18 23:23:29

Anybody know what this means??? It is from my syslog on the USR HiPer chassis..... Looks like idle disconnect, but I am not sure.... " At 23:29:33, Facility "GWC Modem Driver", Level "UNUSUAL":: GWCMDM, stopping drain timer for interface slot:7/mod:12 " TIA- Sean -- - Sean P. Barrett, CEO - Mailing Address: - - CyberZone Internet Services - 942 Main Street - - MicroLine Computer Systems - Hartford, CT 06103 - - http://www.cyberzone.net - USA - - http://www.mcs-corp.com - Phone:(860) 520-6550- - sbarrett@cyberzone.net - Fax: (860) 520-6553-

Subject: Re: (usr-tc) Analog calls work but ISDN dosen't...
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-19 08:57:48

On Fri, 18 Dec 1998, Dave Martin wrote: > We've recently installed our first PRI-based system in the hopes of being > able to use it to terminate ISDN calls as well as analog (we're currently > using Livingston PM2ei's for this function) and are having problems getting > ISDN sessions working. > > The calls are hitting the DSP and the ARC is logging the following PPP > negotiations: > > Outgoing PPP Data on interface: slot:1/mod:1 > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM 57 24 92 de > PROTO_COMP > AC_COMP > MPP_MRRU 05 ea > MPP_ENDPTID 00 > > It sends out the above packet ~5 times and then gives up. We've tried > connecting with a variety of ISDN devices (including a Cisco 1605 router, a The above packets are lcp config request going out from the hiper arc to the client ( cisco / bit surfer ) - you say that you see 5 of these and then it disconnects. If you are seening 5 of these same packets - yes the hiper arc will disconnect - beacause - The hiper arc is sending lcp request to your client and the client is not responding. There is only one way traffic. To start off I would suspect a configuration issue. First I would add a local user on the hiper arc and then would just use a terminal to dial in and see if I get any ppp charecters on connecting, then I will work my way up. If you need to look at a cisco configuration and hiper arc configuration take a look at the yadda yadda search site http://interproc.ae.usr.com/tkb.html search for lan to lan or cisco krish > Motorola BitSurfr Pro) with no joy. The 1605 logs the following: > > 4d19h: BR0:1 LCP: O CONFREQ [REQsent] id 157 len 10 > 4d19h: BR0:1 LCP: MagicNumber 0xF902B8DE (0x0506F902B8DE) > 4d19h: BR0:1 LCP: I CONFREQ [REQsent] id 2 len 35 > 4d19h: BR0:1 LCP: MRU 1514 (0x010405EA) > 4d19h: BR0:1 LCP: AuthProto PAP (0x0304C023) > 4d19h: BR0:1 LCP: MagicNumber 0x24E05BB0 (0x050624E05BB0) > 4d19h: BR0:1 LCP: PFC (0x0702) > 4d19h: BR0:1 LCP: ACFC (0x0802) > 4d19h: BR0:1 LCP: MRRU 1514 (0x110405EA) > 4d19h: BR0:1 L.CP: EndpointDisc 3 00c0.4911.0d5e (0x13090300C049110D5E) > 4d19h: BR0:1 LCP: O CONFREJ [REQsent] id 2 len 17 > 4d19h: BR0:1 LCP: MRRU 1514 (0x110405EA) > 4d19h: BR0:1 LCP: EndpointDisc 3 00c0.4911.0d5e (0x13090300C049110D5E). > 4d19h: BR0:1 LCP: TIMEout: Time 0x18E40504 State REQsent > > Not being a PPP wizard, I take the above to indicate that the 1605 and the > TC were unable to negotiate a suitable MRRU. True? > > The ARC is running 4.1.72-7 and the DSP is running 1.2.5. > > I have a ticket open with 3com tech support (#127-272), but they've gone > dark for over 24 hours so now I'm escalating the ticket to this list. > > Grateful for any insights... > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) TC-HUB Backdoor passwords...
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-19 09:02:06

On Fri, 18 Dec 1998, Ricky wrote: > Krish, and the rest of you 3Com Gurus... > I get this email from a customer today: >=20 > "I have a former employee who claims that he > "found" the backdoor password to the ARC card and was able to login to th= e > hub via telnet and expose all user names AND passwords in plain-text. I > just need to make sure with the appropriate persons at 3Com. I can't affo= rd > to have him or any other bozo screw up our hubs given our recent spate of > partial unavailability." In 4.1.x release - there is a open user - This particular information is=20 documented in every release note that I know. Again here is what it is There is a user called adm This user does not have a password. this user is a manage user. You=20 have to disable this user or you have to give this user a password. This= =20 is the only back door that I am aware of. Other than this I am sure that= =20 there is not other way out. =20 Some of the people may not be disabling this user - It is necessary that=20 you either disable this user or give the user a password - Deleting this=20 user is not an option - because in certain 4.1.x version if the card=20 reboots the user will be back so deleteing is not an option. As far as the former 3com employee goes - I can take a guess who it is...:-= ) krish >=20 > Now, I am under the impression that: > there is no embedded back door password; If it doesn't show > up in a: > Hiper>list users > It ain't a doorway to login.=20 >=20 > Snmp-wise, however, I know you need to secure the chassis with different= nmc > community strings, and also, in the ARC, do a: > Hiper>list snmp communities >=20 > What shows up there is a doorway...it'll say "R", or "RW" as to whether i= t > is read, or read write (and this is for use with HARM...snmp), but=20 > How 'bout the "default" user? Is there way to hack through that?=20 > I don't expect you to give details on how, just say whether or not it's p= ossible (and be honest; like Clinton). >=20 >=20 >=20 > o o =20 > \_ _/=20 > <(@@)> > ----------------000----()----000------------------- > RickyZ@mindspring.com > THE TRUTH IS OUT THERE > ------------------------------------------------------ > 00O O00 =A9 >=20 >=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

Subject: Re: (usr-tc) USR message from Syslog....
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-19 09:05:56

On Fri, 18 Dec 1998, Sean Barrett wrote: > Anybody know what this means??? > > It is from my syslog on the USR HiPer chassis..... Looks like idle > disconnect, but I am not sure.... > > " > At 23:29:33, Facility "GWC Modem Driver", Level "UNUSUAL":: GWCMDM, > stopping drain timer for interface slot:7/mod:12 > " Yes. This means that there was call in slot:7/mod:12 and the user disconnected the call. The hiper arc now sees no call, but the modem after disconnection sent some data to the hiper arc - So the hiper arc drained the pine to the modem thus removeing all old data. krish > > > TIA- > > Sean > > -- > > ------------------------------------------------------------------ > - Sean P. Barrett, CEO - Mailing Address: - > - CyberZone Internet Services - 942 Main Street - > - MicroLine Computer Systems - Hartford, CT 06103 - > - http://www.cyberzone.net - USA - > - http://www.mcs-corp.com - Phone:(860) 520-6550- > - sbarrett@cyberzone.net - Fax: (860) 520-6553- > ------------------------------------------------------------------ > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) USR message from Syslog....
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-19 09:40:47

On Sat, 19 Dec 1998, Marcelo Souza wrote: > > BTW, is there a complete list of those messages? > There is no comprehensive collection of all messages. > And also, why am I having lots of messages like this: > > --syslog capture: 53da4d5d slot:2/mod:3 --syslog capture:stop > This more with your syslog demon, you are seeing the stop at the capture stage. 53da4d5d is some value which could be translated but I am not sure wht it is. krish > > - Marcelo > > On Sat, 19 Dec 1998, Tatai SV Krishnan wrote: > > |On Fri, 18 Dec 1998, Sean Barrett wrote: > | > |> Anybody know what this means??? > |> > |> It is from my syslog on the USR HiPer chassis..... Looks like idle > |> disconnect, but I am not sure.... > |> > |> " > |> At 23:29:33, Facility "GWC Modem Driver", Level "UNUSUAL":: GWCMDM, > |> stopping drain timer for interface slot:7/mod:12 > |> " > | > |Yes. This means that there was call in slot:7/mod:12 and the user > |disconnected the call. The hiper arc now sees no call, but the modem > |after disconnection sent some data to the hiper arc - So the hiper arc > |drained the pine to the modem thus removeing all old data. > | > |krish > | > |> > |> > |> TIA- > |> > |> Sean > |> > |> -- > |> > |> ------------------------------------------------------------------ > |> - Sean P. Barrett, CEO - Mailing Address: - > |> - CyberZone Internet Services - 942 Main Street - > |> - MicroLine Computer Systems - Hartford, CT 06103 - > |> - http://www.cyberzone.net - USA - > |> - http://www.mcs-corp.com - Phone:(860) 520-6550- > |> - sbarrett@cyberzone.net - Fax: (860) 520-6553- > |> ------------------------------------------------------------------ > |> > |> - > |> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > |> with "unsubscribe usr-tc" in the body of the message. > |> For information on digests or retrieving files and 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. > | > > - 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. >

Subject: Re: (usr-tc) USR message from Syslog....
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1998-12-19 13:09:19

Subject: (usr-tc) Token ring / ethernet netserver problem
From: eric@dol.net
Date: 1998-12-20 12:14:25

I just bought a tc chassis that was set up for token ring. I has 15 quad modem cards, netserver , nmc. I bought two ethernet nic cards from source technology. One for the netserver one for the nmc. I have bee and ble to get the nmc card working but the netserver card boots then there is slight blink on the rl light then the top two lights the rl/fl and lan tx go red for a about 20 seconds then I think the card reboots repeatedly. I cannot communicate with the card via the serial port with the ethernet nic installed. When I put the token ring card back in I can at least get the login prompt but it apears that the password was not cleared from the last customer. Is there something in the netserver card itself that needs to be reset or reflashed in order for the ethernet card to work with it and can I reset the card to erase the password setting in it currently? Should I jumper the erase cmos jumpre from the normal setting? This will be a long day I can tell. The nic card has the jumper settings correct. There is either a nac or nmc card setting. It is on the nac setting. All advise is appreciated. thanks eric Delaware Online!.........The SMART Choice! With 56K V.90 & X2 & Flex Modems Phone : 302-762-0375 Fax: 302-762-3462 Failure is NOT an option...

Subject: Re: (usr-tc) Token ring / ethernet netserver problem
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-20 17:56:11

On Sun, 20 Dec 1998 eric@dol.net wrote: > I just bought a tc chassis that was set up for token ring. > I has 15 quad modem cards, netserver , nmc. I bought two > ethernet nic cards from source technology. One for the > netserver one for the nmc. I have bee and ble to get the > nmc card working but the netserver card boots then there is > slight blink on the rl light then the top two lights the rl/fl > and lan tx go red for a about 20 seconds then I think the card reboots > repeatedly. I cannot communicate with the card via the serial port > with the ethernet nic installed. When I put the token ring card > back in I can at least get the login prompt but it apears that the > password was not cleared from the last customer. Before you go much further - you must get rid of the netserver token ring code on the netserver. So you must download the ethernet code to the netserver which currently has the token ring code. You must put the ethernet nic and the netserver and then download code - ethernet code - to the netserver using pcsdl. This will then enable the card to boot on the ethernet. krish > > Is there something in the netserver card itself that needs to be reset > or reflashed in order for the ethernet card to work with it and can > I reset the card to erase the password setting in it currently? > Should I jumper the erase cmos jumpre from the normal setting? > > This will be a long day I can tell. The nic card has the jumper > settings correct. There is either a nac or nmc card setting. It is > on the nac setting. > All advise is appreciated. > thanks > eric > Delaware Online!.........The SMART Choice! With 56K V.90 & X2 & Flex Modems > Phone : 302-762-0375 Fax: 302-762-3462 Failure is NOT an option... > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Token ring / ethernet netserver problem
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-12-20 19:42:07

Tatai SV Krishnan was heard to say: >Before you go much further - you must get rid of the netserver token ring >code on the netserver. So you must download the ethernet code to the >netserver which currently has the token ring code. You must put the >ethernet nic and the netserver and then download code - ethernet code - to >the netserver using pcsdl. This will then enable the card to boot on the >ethernet. Or use the netserver manager to download the ethernet code directly to flash. Then just swap the NICs and reset the netserver. --Ricky

Subject: (usr-tc) ethernet solved / now I need to clear the password
From: eric@dol.net
Date: 1998-12-20 20:04:27

I used the pcsdl program to load the code and now I can talk to the card with the ethernet card in. It is now asking for a password. How can I reset the password on the card. Should I put the jumper on "erase the cmos" and reboot the netserver card? I would like to finish this tonight to install in production on Monday. Thanks for the help. eric At 07:42 PM 12/20/98 -0500, you wrote: >Tatai SV Krishnan was heard to say: >>Before you go much further - you must get rid of the netserver token ring >>code on the netserver. So you must download the ethernet code to the >>netserver which currently has the token ring code. You must put the >>ethernet nic and the netserver and then download code - ethernet code - to >>the netserver using pcsdl. This will then enable the card to boot on the >>ethernet. > >Or use the netserver manager to download the ethernet code directly to flash. >Then just swap the NICs and reset the netserver. > >--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. >Delaware Online!.........The SMART Choice! With 56K V.90 & X2 & Flex Modems Phone : 302-762-0375 Fax: 302-762-3462 Failure is NOT an option...

Subject: Re: (usr-tc) ethernet solved / now I need to clear the password
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-20 21:31:58

On Sun, 20 Dec 1998 eric@dol.net wrote: > I used the pcsdl program to load the code and now I can talk to the card > with the ethernet card in. It is now asking for a password. How can I > reset the password on the card. Should I put the jumper on "erase the cmos" > and reboot the netserver card? I do not understand here - You downloaded the code and now you can talk to the card. Meaning you can from the console logon to the card. At the login prompt you login as !root the default password is carriage-return. There is no password. If this is what you are asking - then just press enter. As far as the card is concerned - you have just loaded ethernet code and this code is just new - there should not be any configuration. However if you want to satisfy yourself - you can put the dip switch 5 in the on position which will again erase all the config if you set any. > I would like to finish this tonight to install in production on Monday. Default !root user does not have a password. Hope this is what you are asking. krish > Thanks for the help. > eric > > > > At 07:42 PM 12/20/98 -0500, you wrote: > >Tatai SV Krishnan was heard to say: > >>Before you go much further - you must get rid of the netserver token ring > >>code on the netserver. So you must download the ethernet code to the > >>netserver which currently has the token ring code. You must put the > >>ethernet nic and the netserver and then download code - ethernet code - to > >>the netserver using pcsdl. This will then enable the card to boot on the > >>ethernet. > > > >Or use the netserver manager to download the ethernet code directly to flash. > >Then just swap the NICs and reset the netserver. > > > >--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. > >Delaware Online!.........The SMART Choice! With 56K V.90 & X2 & Flex Modems > Phone : 302-762-0375 Fax: 302-762-3462 Failure is NOT an option... > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) password cleared
From: eric@dol.net
Date: 1998-12-21 00:50:28

> >As far as the card is concerned - you have just loaded ethernet code and >this code is just new - there should not be any configuration. However >if you want to satisfy yourself - you can put the dip switch 5 in the on >position which will again erase all the config if you set any. > I had to do this step. The machine still wanted a password after I flashed it and would not accept a blank password for user !root after flashing. I had tried that before sending the note. Setting dip switch 5 and rebooting, setting a password, resetting dip switch was the fix. I greatly appreciate the help in getting my equipment up and running. You da man! thanks eric Delaware Online!.........The SMART Choice! With 56K V.90 & X2 & Flex Modems Phone : 302-762-0375 Fax: 302-762-3462 Failure is NOT an option...

Subject: (usr-tc) New MP8/16I code
From: Brian Elfert <brian@citilink.com>
Date: 1998-12-21 08:06:39

This may be slightly off topic for this list, but the MP8/16I is in the Total Control family. I just noticed a new release of code for the MP8/16I, dated 12/16/98, and numbered 2.2.97. Has anyone tried this out? What is it supposed to fix? Will it help with the units that go crazy and need to be power cycled? I've only had this happen once, but apparently some folks see this on a regular basis. Brian

Subject: RE: (usr-tc) New MP8/16I code
From: Brian Elfert <brian@citilink.com>
Date: 1998-12-21 08:23:44

On Mon, 21 Dec 1998, Brian K McIntire wrote: > According to the Readme file that comes with the code: > 1). Corrected possible lockup condition if a disconnect occurs while > training. > 2). Corrected a dial-in busy scenario when auto-answer set but dial-in users > hung up during the first ring. But, readme.txt says it is for 2.2.2, not 2.2.97. Brian

Subject: RE: (usr-tc) TC-HUB Backdoor passwords...
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-21 09:14:11

>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan >Sent: Saturday, December 19, 1998 9:02 AM >To: Ricky >Cc: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) TC-HUB Backdoor passwords... > > >On Fri, 18 Dec 1998, Ricky wrote: > >> Krish, and the rest of you 3Com Gurus... >> I get this email from a customer today: >> >> "I have a former employee who claims that he >> "found" the backdoor password to the ARC card and was able to >login to the >> hub via telnet and expose all user names AND passwords in plain-text. = I >> just need to make sure with the appropriate persons at 3Com. I >can't afford >> to have him or any other bozo screw up our hubs given our recent spate= of >> partial unavailability." > >In 4.1.x release - there is a open user - This particular information is >documented in every release note that I know. Again here is what it is > >There is a user called adm > >This user does not have a password. this user is a manage user. You >have to disable this user or you have to give this user a password. Thi= s >is the only back door that I am aware of. Other than this I am sure tha= t >there is not other way out. > > >Some of the people may not be disabling this user - It is necessary that >you either disable this user or give the user a password - Deleting this >user is not an option - because in certain 4.1.x version if the card >reboots the user will be back so deleteing is not an option. > >As far as the former 3com employee goes - I can take a guess who >it is...:-) He was talking about his former employee not yours. At least, that's how his statement above reads. > > >krish > >> >> Now, I am under the impression that: >> there is no embedded back door password; If it doesn't show >> up in a: >> Hiper>list users >> It ain't a doorway to login. >> >> Snmp-wise, however, I know you need to secure the chassis with >different nmc >> community strings, and also, in the ARC, do a: >> Hiper>list snmp communities >> >> What shows up there is a doorway...it'll say "R", or "RW" as to >whether it >> is read, or read write (and this is for use with HARM...snmp), but >> How 'bout the "default" user? Is there way to hack through that? >> I don't expect you to give details on how, just say whether or >not it's possible (and be honest; like Clinton). >> >> >> >> o o >> \_ _/ >> <(@@)> >> ----------------000----()----000------------------- >> RickyZ@mindspring.com >> THE TRUTH IS OUT THERE >> ------------------------------------------------------ >> 00O O00 =A9 >> >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) New MP8/16I code
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-21 09:23:58

According to the Readme file that comes with the code: 1). Corrected possible lockup condition if a disconnect occurs while training. 2). Corrected a dial-in busy scenario when auto-answer set but dial-in users hung up during the first ring. >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian Elfert >Sent: Monday, December 21, 1998 8:07 AM >To: usr-tc@xmission.com >Subject: (usr-tc) New MP8/16I code > > >This may be slightly off topic for this list, but the MP8/16I is in the >Total Control family. > >I just noticed a new release of code for the MP8/16I, dated 12/16/98, and >numbered 2.2.97. > >Has anyone tried this out? What is it supposed to fix? Will it help >with the units that go crazy and need to be power cycled? I've only had >this happen once, but apparently some folks see this on a regular basis. > >Brian > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) New MP8/16I code
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-21 09:38:31

>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian Elfert >Sent: Monday, December 21, 1998 8:24 AM >To: usr-tc@lists.xmission.com >Subject: RE: (usr-tc) New MP8/16I code > > > > >On Mon, 21 Dec 1998, Brian K McIntire wrote: > >> According to the Readme file that comes with the code: >> 1). Corrected possible lockup condition if a disconnect occurs while >> training. >> 2). Corrected a dial-in busy scenario when auto-answer set but >dial-in users >> hung up during the first ring. > >But, readme.txt says it is for 2.2.2, not 2.2.97. I'm sure it's a typo > >Brian > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) TC-HUB Backdoor passwords...
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-12-21 10:51:40

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ricky |Sent: Friday, December 18, 1998 9:03 PM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) TC-HUB Backdoor passwords... | | |Krish, and the rest of you 3Com Gurus... |I get this email from a customer today: | |"I have a former employee who claims that he |"found" the backdoor password to the ARC card and was able to login to the |hub via telnet and expose all user names AND passwords in plain-text. I |just need to make sure with the appropriate persons at 3Com. I can't afford |to have him or any other bozo screw up our hubs given our recent spate of |partial unavailability." This is BS. There is no backdoor. |Now, I am under the impression that: |there is no embedded back door password; If it doesn't show |up in a: |Hiper>list users |It ain't a doorway to login. Correct. There is the 'adm' user on all the 4.1 that should be disabled. If you disable or set a password on the adm user, (It cant be deleted..) no "unauthorized" access will be granted. |Snmp-wise, however, I know you need to secure the chassis with different nmc |community strings, and also, in the ARC, do a: |Hiper>list snmp communities No SNMP is configured by default. If you have a private string I would sugest using an access list on the HARC to prevent hack attempts. |What shows up there is a doorway...it'll say "R", or "RW" as to whether it |is read, or read write (and this is for use with HARM...snmp), but |How 'bout the "default" user? Is there way to hack through that? |I don't expect you to give details on how, just say whether or not it's |possible (and be honest; like Clinton). DEFAULT user cannot log into the box. -M

Subject: RE: (usr-tc) quick start for Hiper ARC ???
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-12-21 10:56:43

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of C Thompson |Sent: Friday, December 18, 1998 6:11 PM |To: usr-tc@xmission.com |Subject: (usr-tc) quick start for Hiper ARC ??? | | |I've tried setting up a new Hiper ARC (4.1.1) with an existing quad |modem chassis. | |I got as far as users not being authenticated because the RADIUS user |being sent was the name 'unauthenticated.' The above message is generated for every failed call that doesnt get past the Name/Password stage. It can be disabled so the message is not generated. It is not the cause of your problems. |This is using a standard Livingston RADIUS (actually, ESVA). | |Can anyone give some hints, help on doing a quick start in a situation |like this? I'd like to test this over the weekend if possible. | You need to make sure your radius is configured correctly first and that the HARC is in its clients file with the correct secret. After that configure the HARC with the proper server and secret. You can then do a basic test with the "_AUTH" command SYNTAX: "_auth <UNAME> <PASSWORD>" . That will return a sucess/fail. If you get sucess then your RADIUS should be configured correctly. -M

Subject: Re: (usr-tc) New MP8/16I code
From: Brian Biggs <bb@sonic.net>
Date: 1998-12-21 11:48:41

> But, readme.txt says it is for 2.2.2, not 2.2.97. The readme states that these are changes to the 2.2.2 code. I'm wondering when they'll release v.90 for these things...? -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 #

Subject: (usr-tc) Adding HARC filters
From: Jeremy Shaffner <jer@jorsm.com>
Date: 1998-12-21 13:41:32

In trying to add (and subsequently verify) a filter I receive the following error. HiPer>> add filter signup.in FM: In filter file signup.in, protocol IP, action PERMIT/DENY at line 999 must end the section And indeed it does.. HiPer>> show file signup.in #filter IP: 010 AND dst-addr = XXX.XXX.XXX.2; 011 ACCEPT tcp-dst-port = 53; 020 AND dst-addr = XXX.XXX.XXX.1; 021 ACCEPT tcp-dst-port = 53; 030 AND dst-addr = XXX.XXX.XXX.2; 031 ACCEPT udp-dst-port = 53; 040 AND dst-addr = XXX.XXX.XXX.1; 041 ACCEPT udp-dst-port = 53; 050 AND dst-addr = XXX.XXX.XXX.5; 051 ACCEPT tcp-dst-port = 80; 060 AND dst-addr = XXX.XXX.XXX.5; 061 ACCEPT tcp-dst-port = 443; 999 DENY; HiPer>> I've turned on filter_access on all ports and disabled them and reenabled them. I get the same error on the outbound filter (same layout, complement rules) as well. There's no trailing spaces or tabs or newlines after "999 DENY;". (Just how picky is the Hiper anyway?) Any thoughts? TIA, -Jeremy -===================================================================- Jeremy Shaffner JORSM Internet Senior Technical Support Northwest Indiana's Premium jer@jorsm.com Internet Service Provider support@jorsm.com http://www.jorsm.com -===================================================================-

Subject: (usr-tc) FS: USR TC parts
From: Brian <signal@shreve.net>
Date: 1998-12-21 14:25:50

2 NMC cards (16MB) w/ NICs 2 1706 chassis (chassis and fan tray only, no cards) 1 70A power supply make offer on any of the above. 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

Subject: (usr-tc) RadiusNT
From: fithen@networksplus.net
Date: 1998-12-21 23:35:33

Hello, we're moving away from 3Com (for authentication) and I'd like to use RadiusNT from IEA. I'm about an hour in to the setup but now all I can get the 3Com ARC to do is: Resp Time: 16 Auth: 0/0 -> 0 Acct: 0/0/0 -> 0 radrecv: Request from host ce68b001 code=1, id=12, length=139 User-Name = "test" Password = "`2" NAS-IP-Address = n.n.n.n NAS-Port = 1 Acct-Session-Id = "test1" Vendor-Specific = "" User-Service = Login-User Vendor-Specific = "" Vendor-Specific = "" Vendor-Specific = "" Request from n.n.n.n - Malformed Packet Resp Time: 0 Auth: 0/0 -> 0 Acct: 0/0/0 -> 0 now back to RTFM. Thanks for any advice. blake

Subject: Re: (usr-tc) RadiusNT
From: Frank Basso <frank@okwhatever.com>
Date: 1998-12-21 23:45:20

Looks like a Radius Version issue. -----Original Message----- >Hello, we're moving away from 3Com (for authentication) >and I'd like to use RadiusNT from IEA. I'm about an hour >in to the setup but now all I can get the 3Com ARC to do >is: > >Resp Time: 16 Auth: 0/0 -> 0 Acct: 0/0/0 -> 0 >radrecv: Request from host ce68b001 code=1, id=12, length=139 User-Name >= "test" > Password = "`2" > NAS-IP-Address = n.n.n.n > NAS-Port = 1 > Acct-Session-Id = "test1" > Vendor-Specific = "" > User-Service = Login-User > Vendor-Specific = "" > Vendor-Specific = "" > Vendor-Specific = "" >Request from n.n.n.n - Malformed Packet > > >Resp Time: 0 Auth: 0/0 -> 0 Acct: 0/0/0 -> 0 > >now back to RTFM. > >Thanks for any advice. > >blake > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Fwd: Re: 3com (fwd)
From: Brian Uechi <brianu@lava.net>
Date: 1998-12-22 00:37:36

Does anybody know what the heck this guy is talking about? NMC login accounts? Aren't all logins handled by the Netserver? In any case, I tried logging in via ppp and tty as adm with no password and it doesn't work. Also tried telnet to Netserver and NMC. ---------- Forwarded message ---------- Reply-To: Bugtraq List <BUGTRAQ@NETSPACE.ORG> The software that 3com has developed for running the NMC (network management card) for the Total Control Hubs is a bit shady. After uploading the software ( as one must do) YOU will notice a login account called "adm" with no password. Naturally no one wants the "adm" login there, so they delete it from the configuration, and go on programming the box. Once the box has been programmed and is ready to take calls, it is necessary to save all settings, and hardware reset the box, at this point the box is fully configured, and ready to take calls. The problem is this, the "adm" login requiring no password, is still there after the hardware reset!!! It cannot be deleted! I have ran a trace route on over 37 ISP's, found there HD box's, and have been able to get into 21 of them through this security hole! The admin that programmed the box has no reason to go back into the configuration after doing the hardware reset, he has already gone over and double checked his settings, they all looked good, and hardware reset has gone into action as the last step.., he has no clue that the "adm" he has deleted is still there, and active. In order to stop the "adm" login one can only dis-able the "adm" login, not delete it....this is the only way to stop the login. I have tested this on the current, and last 3 releases of software put out by 3com for the NMC card. 3Com has been notified I hope this helps. Entr0py

Subject: Re: (usr-tc) Fwd: Re: 3com (fwd)
From: Brian Uechi <brianu@lava.net>
Date: 1998-12-22 03:47:07

On Tue, 22 Dec 1998, Jeff Mcadams wrote: > Thus spake Brian Uechi > >Does anybody know what the heck this guy is talking about? NMC login > >accounts? Aren't all logins handled by the Netserver? In any case, I > >tried logging in via ppp and tty as adm with no password and it > >doesn't work. Also tried telnet to Netserver and NMC. > > This is referring to the HiPer Arc's, not the NETServers or NMC. Not > having Arc's to play with much (I have one, but haven't played with it > much yet), I can't confirm that this is what's happening, but I have no > reason to doubt it. Sounds like poor design wrt the adm account on the > ARC, though it can be set up to not be a security whole, its slightly > counter-intuitive on how to do it. Thanks! I'm not using HARC's yet so I'll file this one away for now. --- Brian K. Uechi Email: brianu@lava.net Technical Support Engineer Phone: 808-545-5282 LavaNet, Inc. FAX : 808-545-7020

Subject: Re: (usr-tc) Fwd: Re: 3com (fwd)
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-12-22 07:39:19

Thus spake Brian Uechi >Does anybody know what the heck this guy is talking about? NMC login >accounts? Aren't all logins handled by the Netserver? In any case, I >tried logging in via ppp and tty as adm with no password and it >doesn't work. Also tried telnet to Netserver and NMC. This is referring to the HiPer Arc's, not the NETServers or NMC. Not having Arc's to play with much (I have one, but haven't played with it much yet), I can't confirm that this is what's happening, but I have no reason to doubt it. Sounds like poor design wrt the adm account on the ARC, though it can be set up to not be a security whole, its slightly counter-intuitive on how to do it. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) Fwd: Re: 3com (fwd)
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-22 08:45:50

When he said he has tested this on 3 releases of software for the NMC card I'm sure he meant HiPer ARC. The only logins that exist on the NMC are the community strings (except for debug of course). As Krish and Mike have told you this is not a security hole. A security hole is something you don't know about or can't fix. This is documented everywhere. All you have to do is read. If you don't at least take a peek at the release notes that come with the product/software you don't have any business using it. 3COM isn't full of idiots like some of you seem to think. The next time you post why don't you ask them why the adm user was added to the default configuration. My speculation is it is a good way to regain access to the HiPer ARC should you lose the normal management user account password. You could simply use HARM to bring up the ARC and delete the user. Save. And reboot. If you don't have access to the console or you require a login at console this may be your only hope of regaining full access to the HiPer ARC via telnet. Anyway, that's my .02 >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams >Sent: Tuesday, December 22, 1998 6:39 AM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) Fwd: Re: 3com (fwd) > > >Thus spake Brian Uechi >>Does anybody know what the heck this guy is talking about? NMC login >>accounts? Aren't all logins handled by the Netserver? In any case, I >>tried logging in via ppp and tty as adm with no password and it >>doesn't work. Also tried telnet to Netserver and NMC. > >This is referring to the HiPer Arc's, not the NETServers or NMC. Not >having Arc's to play with much (I have one, but haven't played with it >much yet), I can't confirm that this is what's happening, but I have no >reason to doubt it. Sounds like poor design wrt the adm account on the >ARC, though it can be set up to not be a security whole, its slightly >counter-intuitive on how to do it. >-- >Jeff McAdams Email: jeffm@iglou.com >Head Network Administrator Voice: (502) 966-3848 >IgLou Internet Services (800) 436-4456 > > The software that 3com has developed for running the NMC (network >management card) for the Total Control Hubs is a bit shady. >After uploading the software ( as one must do) YOU will notice a login > account called "adm" with no password. > Naturally no one wants the "adm" login there, so they delete it from the >configuration, and go on programming the box. Once the box has been > programmed and is ready to take calls, it is necessary to save all >settings, and hardware reset the box, at this point the box is fully >configured, and ready to > take calls. The problem is this, the "adm" login requiring no password, is > still there after the hardware reset!!! It cannot be deleted! > I have ran a trace route on over 37 ISP's, found there HD box's, and >have been able to get > into 21 of them through this security hole! > The admin that programmed the box has no reason to go back into the >configuration after doing the >hardware reset, he has already gone over and double checked his settings, >they all looked good, and hardware reset has gone into action as the last >step.., he has no clue that the "adm" he has deleted is still there, and >active. > In order to stop the "adm" login one can only dis-able the "adm" > login, not delete it....this is the only way to stop the login. As Krish and Mike told you; you can give the user a password. > > I have tested this on the current, and last 3 releases of software put out > by 3com for the NMC card. Learn the products. This is not an NMC card. >3Com has been notified What that supposed to mean. They designed it that way intentionally. It wasn't an arbitrary decision. There is a reason for it. > > I hope this helps. > > Entr0py >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) Fwd: Re: 3com (fwd)
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-22 08:53:08

>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian Uechi >Sent: Tuesday, December 22, 1998 7:47 AM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) Fwd: Re: 3com (fwd) > > >On Tue, 22 Dec 1998, Jeff Mcadams wrote: > >> Thus spake Brian Uechi >> >Does anybody know what the heck this guy is talking about? NMC login >> >accounts? Aren't all logins handled by the Netserver? In any case, I >> >tried logging in via ppp and tty as adm with no password and it >> >doesn't work. Also tried telnet to Netserver and NMC. >> >> This is referring to the HiPer Arc's, not the NETServers or NMC. Not >> having Arc's to play with much (I have one, but haven't played with it >> much yet), I can't confirm that this is what's happening, but I have no >> reason to doubt it. Sounds like poor design wrt the adm account on the >> ARC, though it can be set up to not be a security whole, its slightly >> counter-intuitive on how to do it. > >Thanks! I'm not using HARC's yet so I'll file this one away for now. One thing Krish and Mike didn't mention. In addition to disabling the user or giving it a password you can also change the type of the adm user to prevent administrative access. > >--- >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. >

Subject: Re: (usr-tc) Fwd: Re: 3com (fwd)
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-22 09:15:53

On Tue, 22 Dec 1998, Brian Uechi wrote: > Does anybody know what the heck this guy is talking about? NMC login > accounts? Aren't all logins handled by the Netserver? In any case, I > tried logging in via ppp and tty as adm with no password and it > doesn't work. Also tried telnet to Netserver and NMC. > This is a documented information for all 4.1.x releases. This is about the HiPer arc not the NETServer or the NMC. The adm user is a user in the Hiper arc. You can set a password for the user and you can disable the user. krish > ---------- Forwarded message ---------- > Date: Mon, 21 Dec 1998 11:23:57 -0800 > From: Entropy <entropy@THEGRID.NET> > Reply-To: Bugtraq List <BUGTRAQ@NETSPACE.ORG> > To: BUGTRAQ@NETSPACE.ORG > Subject: Fwd: Re: 3com > > The software that 3com has developed for running the NMC (network > management card) for the Total Control Hubs is a bit shady. > After uploading the software ( as one must do) YOU will notice a login > account called "adm" with no password. > Naturally no one wants the "adm" login there, so they delete it from the > configuration, and go on programming the box. Once the box has been > programmed and is ready to take calls, it is necessary to save all > settings, and hardware reset the box, at this point the box is fully > configured, and ready to > take calls. The problem is this, the "adm" login requiring no password, is > still there after the hardware reset!!! It cannot be deleted! > I have ran a trace route on over 37 ISP's, found there HD box's, and > have been able to get > into 21 of them through this security hole! > The admin that programmed the box has no reason to go back into the > configuration after doing the > hardware reset, he has already gone over and double checked his settings, > they all looked good, and hardware reset has gone into action as the last > step.., he has no clue that the "adm" he has deleted is still there, and > active. > In order to stop the "adm" login one can only dis-able the "adm" > login, not delete it....this is the only way to stop the login. > > I have tested this on the current, and last 3 releases of software put out > by 3com for the NMC card. 3Com has been notified > > I hope this helps. > > Entr0py > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Echo request?
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-22 09:20:01

This is lcp echo request and reply some clients do this. this is normal 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 Dec 1998, K Mitchell wrote: > I apologize if this is a stupid question, > I have an iMac user who seems to be having problems bringing up webpages. > I'm not sure of it's a true problem or operator error at this point. She's > connecting fine and, I'm guessing, running IE. This is what I'm getting on > <mon ppp> <user>; > Incoming PPP Data on interface: slot:14/mod:20 > LCP ECHO_REQ 47 86 d9 3f 82 cc ab 1f > > Outgoing PPP Data on interface: slot:14/mod:20 > LCP ECHO_RPLY 22 3c 6f 25 > > This comes across approx every 8-10 seconds and is the only traffic going > through her connection. I've never seen this on other users. > What is this telling me? > > Thanks, > 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. >

Subject: (usr-tc) Echo request?
From: K Mitchell <mitch@keyconn.net>
Date: 1998-12-22 09:27:16

I apologize if this is a stupid question, I have an iMac user who seems to be having problems bringing up webpages. I'm not sure of it's a true problem or operator error at this point. She's connecting fine and, I'm guessing, running IE. This is what I'm getting on <mon ppp> <user>; Incoming PPP Data on interface: slot:14/mod:20 LCP ECHO_REQ 47 86 d9 3f 82 cc ab 1f Outgoing PPP Data on interface: slot:14/mod:20 LCP ECHO_RPLY 22 3c 6f 25 This comes across approx every 8-10 seconds and is the only traffic going through her connection. I've never seen this on other users. What is this telling me? Thanks, Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

Subject: (usr-tc) 3Com HiperARC "adm" user. WAS:RE: Re: 3com
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-12-22 09:48:50

Copy of my reply on the Bugtraq list. I am sure you are all interested. :).. BTW: Happy Holidays to everyone... -M |-----Original Message----- |From: Bugtraq List [mailto:BUGTRAQ@netspace.org]On Behalf Of Entropy |Sent: Monday, December 21, 1998 1:24 PM |To: BUGTRAQ@netspace.org |Subject: Fwd: Re: 3com | | | The software that 3com has developed for running the NMC (network |management card) for the Total Control Hubs is a bit shady. This has nothing to do with the NMC card. The "adm" user is on the HiperARC card. |After uploading the software ( as one must do) YOU will notice a login | account called "adm" with no password. | Naturally no one wants the "adm" login there, so they delete it from the |configuration, and go on programming the box. Once the box has been | programmed and is ready to take calls, it is necessary to save all |settings, and hardware reset the box, at this point the box is fully |configured, and ready to | take calls. The problem is this, the "adm" login requiring no password, is | still there after the hardware reset!!! It cannot be deleted! | I have ran a trace route on over 37 ISP's, found there HD box's, and |have been able to get | into 21 of them through this security hole! The 'adm' user is no different than the manage user on the older Netserver product. Both are clearly described in the release notes that they come with no password set. This information is posted on the Totalservice along with the 4.1.11 code. (ftp://totalservice.usr.com/pub/.docs/config.txt) The difference on the newer HARC cards is that you can add more manage users and disable the adm if so desired. The fact that people don't read documentation when they install new software is the cause of this problem. The latest release of code 4.1.72-7 (located on the Totalservice web site) has the ability to delete the "adm" user and it will not come back after a reboot. This posting does serve a purpose since it seem that many have overlooked this and left themselves open. Misconfiguration is often the cause of security breach, but I wouldn't call this a hole. Hopefully those that overlooked this will at least read the release notes next time. Since the manual is out of the question. :). | The admin that programmed the box has no reason to go back into the |configuration after doing the |hardware reset, he has already gone over and double checked his settings, |they all looked good, and hardware reset has gone into action as the last |step.., he has no clue that the "adm" he has deleted is still there, and |active. | In order to stop the "adm" login one can only dis-able the "adm" | login, not delete it....this is the only way to stop the login. | I have tested this on the current, and last 3 releases of software put out | by 3com for the NMC card. 3Com has been notified. Once again. No such password exists on the NMC. It is a item on the HARC. 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."

Subject: RE: (usr-tc) Echo request?
From: K Mitchell <mitch@keyconn.net>
Date: 1998-12-22 10:18:44

At 02:54 PM 12/22/98 -0000, you wrote: >> This comes across approx every 8-10 seconds and is the only >> traffic going >> through her connection. I've never seen this on other users. >> What is this telling me? > >Nothing except that the PPP session itself is still active. That's what I figured, but didn't want to be wrongly assuming that there might not be another reason. Thanks >The initial LCP and IPCP negotiations are where the interesting stuff >can usually be found, typically an LCP protocol reject indicating that >no TCP/IP protocol stack is available at the remote end. > >I may be able to make a Perl utility available to the group which can >parse the hex output from the TAP syslogs and turn it into a human >readable PPP trace which can make fixing PPP problems quite simple. That would be super. In the meantime, is there anything else I might be able to check for at her end...TCP/IP installed, etc? I know nothing about iMacs, so I have no idea what their "Internet Setup Assistant" might have missed. Thanks again, Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

Subject: (usr-tc) No help topic exists
From: Suncoast Networking USR Mailbox <usrtcmail@flasuncoast.net>
Date: 1998-12-22 11:03:01

Does everyone sometimes get "No help topic exists, contact vendor" when using TCM? Is there a special file I need to update? Thanks

Subject: (usr-tc) v.90 handshake on x2 chassis?
From: vanhalen@coredcs.com
Date: 1998-12-22 11:17:27

Hello, I'm hearing reports and can also verify with a modem that one of our TC Chassis with a Netserver card and quads is sending the v.90 "bong" when it tries to handshake. The problem is that in TCM, I don't even show v.90 as being _on_ the box at all. It only shows options for x2 configuration which are enabled. Any ideas besides that I'm a dolt? Steve

Subject: Re: (usr-tc) v.90 handshake on x2 chassis?
From: David Bolen <db3l@ans.net>
Date: 1998-12-22 12:25:47

<vanhalen@coredcs.com> writes: > I'm hearing reports and can also verify with a modem that one of our TC > Chassis with a Netserver card and quads is sending the v.90 "bong" when it > tries to handshake. Minor nit, but the "boing" is actually transmitted by the client modem and just echoed back by the chassis quad modem. So it's not like the server modem generates the tone. Of course, hearing it does indicate that the client and server both agreed that they could use V.90, and that the client thought the line should support it. > The problem is that in TCM, I don't even show v.90 as > being _on_ the box at all. It only shows options for x2 configuration > which are enabled. What release of code are you running on the quad cards? As long as you have a V.90 capable code release (5.9.x/5.10.x) and you have the x2 feature key enabled in the NMC (the key does both x2/V.90) then your modems will support V.90. Also, have you upgraded the NMC to the latest code release to match the quads? What you might have is an older NMC release running that doesn't support the new V.90 objects for the quads. Either that, or you don't have updated NMC data files for TCM, so it doesn't know about the new objects. The NETServer doesn't come into play at all with respect to modem modulations. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: RE: (usr-tc) v.90 handshake on x2 chassis?
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-22 12:27:32

>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of >vanhalen@coredcs.com >Sent: Tuesday, December 22, 1998 11:17 AM >To: usr-tc@lists.xmission.com >Subject: (usr-tc) v.90 handshake on x2 chassis? > > >Hello, > >I'm hearing reports and can also verify with a modem that one of our TC >Chassis with a Netserver card and quads is sending the v.90 "bong" when it >tries to handshake. The problem is that in TCM, I don't even show v.90 as >being _on_ the box at all. It only shows options for x2 configuration >which are enabled. > >Any ideas besides that I'm a dolt? What equipment are you running? You don't need an x2/v.90 key applied to your NMC for HiPer DSP's. What version of code are you running on all your cards? You should have 5.5.5 on your NMC. Your TCM version should be 5.5.1. If not, upgrade > >Steve > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) NetHopper router dialing NETServer
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-12-22 14:03:00

Hrmm...ok...this is an interesting twist... Had a customer switching over from an old legacy dial-up line that we had (went into an Ascend box...blech) to our newer number that hits our 3Com TC's (all NETServer based still). They were using an osicom NetHopper ISDN router. Not a bad little router actually, but it had some interesting behavior on dialing in. The NETServer (via the show bundle command) was showing the NetHopper using different EDO's for the MP bundle, so we called OsiCom about this behavior we were seeing. (Conference call with me, the customer, and OsiCom). After some almost funny interactions with the tech support dude ("But you're *supposed* to send different EDO's on each link of an MP bundle." yeesh), I finally got a call back today from someone at OsiCom that seemed to exhibit a pretty decent amount of clueage. Dude that left a voice-mail for me today says that from what he can tell with their tests and everything that the NetHopper doesn't send an EDO in LCP *at all*. Now this has me wondering. How does the NETServer handle an MP call that doesn't have an EDO in the LCP. I'm beginning to wonder if it "remembers" the EDO from previous calls or something and uses that for the link. If so, this would be broken. Anyone have any experience with making MP calls to NETServers without using EDO's? -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) NetHopper router dialing NETServer
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-12-22 14:36:03

Thus spake Rick Payne >Jeff Mcadams writes: > > Dude that left a voice-mail for me today says that from what he can tell > > with their tests and everything that the NetHopper doesn't send an EDO > > in LCP *at all*. Now this has me wondering. How does the NETServer > > handle an MP call that doesn't have an EDO in the LCP. >According to RFC-1990, you do not need to specify an EDO for Multilink >operation. If one is not supplied, then the following applies: Yup, believe me...I'm well aware of that. :) In fact, I just quoted that part of the RFC to the 3Com tech support person I had on the phone. :) What I'm seeing though is that the NETServer is showing EDO's for these links, and the vendor of the hardware claims that they don't send EDO's. Now, I don't have a setup where I can really confirm whether an EDO is being sent or not....at least not easily, but I'm wondering if the NETServer is pulling data out of some random area of memory where it expects that an EDO was previously stored and interpreting whatever it finds in that memory location as an EDO. >So, it should work. I've never tried it on a Netserver OK, the tech support guy at 3Com said he'd see if he could set up a scenario where he could see how the NETServer handled this. We'll see what they come up with. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Fwd: Re: 3com (fwd)
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-12-22 14:50:07

Jeff Mcadams was heard to say: >This is referring to the HiPer Arc's, not the NETServers or NMC. Not >having Arc's to play with much (I have one, but haven't played with it >much yet), I can't confirm that this is what's happening, but I have no >reason to doubt it. Sounds like poor design wrt the adm account on the >ARC, though it can be set up to not be a security whole, its slightly >counter-intuitive on how to do it. This was a VERY poor judgement call on the part of 3Com (I refer to it as a "jack-ass decision".) The "adm" account was complained about LOUDLY when 4.1 was in beta. 3Com basically ignored the screaming masses. I will admit the idea of the "adm" user is a good one, but there really is no point it doing this for a hiperARC. It understands administrative users via RADIUS, so what's the point in locking an admin user on the card? The "adm" user should either be non-deletable or it should only be created once -- by the flash restructuring code as part of the 4.0 to 4.1 transition. ("adm" was a stupid idea from day one.) --Ricky

Subject: RE: (usr-tc) Echo request?
From: Ray Bellis <rpb@community.net.uk>
Date: 1998-12-22 14:54:22

> This comes across approx every 8-10 seconds and is the only > traffic going > through her connection. I've never seen this on other users. > What is this telling me? Nothing except that the PPP session itself is still active. The initial LCP and IPCP negotiations are where the interesting stuff can usually be found, typically an LCP protocol reject indicating that no TCP/IP protocol stack is available at the remote end. I may be able to make a Perl utility available to the group which can parse the hex output from the TAP syslogs and turn it into a human readable PPP trace which can make fixing PPP problems quite simple. Ray. -- Ray Bellis, MA(Oxon) - Technical Director - Oxford CommUnity Internet plc Windsor House, 12 High Street, Kidlington, OXFORD OX5 2PJ UK Telephone: +44-1865-856000 Fax: +44-1865-856001 Email: ray.bellis@community.net.uk URL: http://www.community.co.uk/

Subject: (usr-tc) NT users cannot surf or get mail
From: Wayne Barber <barberw@tidewater.net>
Date: 1998-12-22 15:42:07

I have a couple of Windows NT users who connect to our ISP via the TC rack who cannot surf the net or get their email. They did work until I swapped out the standard Netserver for a Netserver PRI. While I suspect it's a routing issue, I have no idea what needs to change to get them to work. Here's my config: Default Route: Broadcast, Listen (On) Lan/Wan routing: On RIP V2 Authen: OFF 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 If you have any ideas or want to see some other configs, let me know. Thanks in advance, Wayne Barber Coastal Telco Services

Subject: RE: (usr-tc) Echo request?
From: Andy Berkvam <aberkvam@coredcs.com>
Date: 1998-12-22 15:55:17

http://asu.info.apple.com/swupdates.nsf/artnum/n10665 http://asu.info.apple.com/swupdates.nsf/artnum/n11128 On Tue, 22 Dec 1998, K Mitchell wrote: > That would be super. In the meantime, is there anything else I might be > able to check for at her end...TCP/IP installed, etc? I know nothing about > iMacs, so I have no idea what their "Internet Setup Assistant" might have > missed. > You might have some luck playing with the modem on her end. There are files available from Apple that may help her get a more stable connection. (Of course, you have to get the files to her somehow.... :( ) There is a Modem Updater that will flash the iMac's modem to the latest Rockwell version (2.2) at <http://asu.info.apple.com/swupdates.nsf/artnum/n10665>. The PPP software that comes with the iMac uses modem scripts to configure the modems. Apple has created a script that will disable any 56K features of the modem and turn it into a plain V.34 modem. You can get that at <http://asu.info.apple.com/swupdates.nsf/artnum/n11128>. As far as the setup goes, there's nothing too strange about it. The Internet Setup Assistant sets up the connection by modifying values in three Control Panels. You can go into these Control Panels by hand and verify the setup. Instructions for our customers are at <http://www.coredcs.com/kb/1004.html>. They should work for almost any ISP though. (Of course, you have to change the phone #, name servers, etc.) Andy -- =========================================================================== Andy Berkvam | The surface of the strange, forbidden planet was | roughly textured and green, much like cottage Email: | cheese gets way after the date on the lid says it aberkvam@coredcs.com | is alright to buy it. - Scott Davis Jones (MIME Attachments OK)|-WWW Pages: <http://www.coredcs.com/~aberkvam/> ===========================================================================

Subject: Re: (usr-tc) NT users cannot surf or get mail
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-22 16:02:46

Either enable vj for the user or disable vj on the NT 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 Dec 1998, Wayne Barber wrote: > I have a couple of Windows NT users who connect to our ISP via the TC rack > who cannot surf the net or get their email. They did work until I swapped > out the standard Netserver for a Netserver PRI. While I suspect it's a > routing issue, I have no idea what needs to change to get them to work. > > Here's my config: > Default Route: Broadcast, Listen (On) > Lan/Wan routing: On > RIP V2 Authen: OFF > > 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 > > If you have any ideas or want to see some other configs, let me know. > > Thanks in advance, > Wayne Barber > 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. >

Subject: (usr-tc) Big Screaming BEG
From: Drew Whittle <drew@csarc.otago.ac.nz>
Date: 1998-12-22 17:32:31

Help!!! Having been given the job of looking after something I know little about I am trying to work with this box (Netserver). This morning the unit was powered down and then powered backup, it appears that now the digital calls are being switched across to the analog/digital modems which we use for our analog callers. The digital modems just flash red and go it goes down the cards until it eventually finds an analog/digital card which then seems to take the call. Does anyone have ANY idea what is going on and more importantly, WHAT CAN I DO?? HELP!!!! *BEGS* Regards, Drew

Subject: Re: (usr-tc) Big Screaming BEG
From: Drew Whittle <drew@csarc.otago.ac.nz>
Date: 1998-12-22 17:47:03

At 17:32 22/12/98 +1300, you wrote: >Help!!! > >Having been given the job of looking after something I know little about I >am trying to work with this box (Netserver). This morning the unit was >powered down and then powered backup, it appears that now the digital calls >are being switched across to the analog/digital modems which we use for our >analog callers. I think I fixed it, soft reset on the digital cards seemed to get them going again.... Thanks anyway Drew

Subject: (usr-tc) NetHopper router dialing NETServer
From: Rick Payne <rickp@ops.netcom.net.uk>
Date: 1998-12-22 19:25:16

Jeff Mcadams writes: > Dude that left a voice-mail for me today says that from what he can tell > with their tests and everything that the NetHopper doesn't send an EDO > in LCP *at all*. Now this has me wondering. How does the NETServer > handle an MP call that doesn't have an EDO in the LCP. According to RFC-1990, you do not need to specify an EDO for Multilink operation. If one is not supplied, then the following applies: (3) No discriminator, authentication: Authenticated match -> MUST join matching bundle, authenticated mismatch -> MUST establish new bundle. So, it should work. I've never tried it on a Netserver - though we are seeing an issue with Null Class EDO's on MPIP with the ARC. Rick

Subject: (usr-tc) multichannel ISDN and HiperArc
From: Steve McConnell <stevem@magneto.emji.net>
Date: 1998-12-23 03:04:55

I just upgraded our Netserver chassis (2 PRI, 6 quad digital modems, NMC all now off so I dont have the code revs, but they were all current) with ISDN calls terminated on the Netserver, to a 3 PRI DSP running 1.2.5 code a HiperArc running 4.1.72, and an NMC running 5.5.5 We are running ESVA-Radius 1.16 ( i believe) I have a co-worker that was getting 4 channels (2 BRIs) bonded on the Netserver chassis. However on the HiperArc, he only gets 2. The only thing that changed was the chassis (of course that was a big change) but is there a setting that I am missing that will enable the chassis to bond 4 channels? I have asked that question to 3com support and was told this was a function of RADIUS. Since I am using the same RADIUS set up, there must be something else?? Any help is appreciated. Steve Steve McConnell Network Admin EMJI 919-303-3217 stevem@emji.net

Subject: Re: (usr-tc) Remote Configuration of HiPer ARC
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1998-12-23 06:09:16

: Is there a possiblity to configure a new HiPer ARC completely from : Remote? I have a HiPerARC in a remote site. If you can get access to the ARC's serial port, then you should have no problem. For example, you might have them plug it into a Unix machine, then use cu or kermit to talk to it and setup the low-level items -- such as the IP address. Once that's done, you could telnet into it, or use TCM or HARM or any such.

Subject: RE: (usr-tc) multichannel ISDN and HiperArc
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-23 08:59:29

>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Steve McConnell >Sent: Wednesday, December 23, 1998 2:05 AM >To: 'usr-tc@lists.xmission.com' >Subject: (usr-tc) multichannel ISDN and HiperArc > > > >I just upgraded our Netserver chassis (2 PRI, 6 quad digital >modems, NMC all >now off so I dont have the code revs, but they were all current) with ISDN >calls terminated on the Netserver, to a 3 PRI DSP running 1.2.5 code a >HiperArc running 4.1.72, and an NMC running 5.5.5 > >We are running ESVA-Radius 1.16 ( i believe) > >I have a co-worker that was getting 4 channels (2 BRIs) bonded on the >Netserver chassis. However on the HiperArc, he only gets 2. I believe, when not configured elsewhere, the default user on the HiPer ARC limits connections to 2 channels. To change it type: set netWORK user default ppp maX_CHANNELS 4 >The only thing that changed was the chassis (of course that was a big >change) but is there a setting that I am missing that will enable the >chassis to bond 4 channels? I have asked that question to 3com support and >was told this was a function of RADIUS. Since I am using the same >RADIUS set >up, there must be something else?? > >Any help is appreciated. > >Steve > > >Steve McConnell Network Admin >EMJI 919-303-3217 >stevem@emji.net > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) Remote Configuration of HiPer ARC
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-12-23 09:54:20

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ralph Helfenberger |Sent: Wednesday, December 23, 1998 4:19 AM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) Remote Configuration of HiPer ARC | | |Hi | |Is there a possiblity to configure a new HiPer ARC completely from |Remote? I have a HiPerARC in a remote site. I'd like to do a |DELETE CONFIGURATION of this HiPerARC. Obviously there is no more IP |address on the HiPerARC. So I looked into TCM. There is a possibility |to set an IP adress for the HiPER ARC on TCM but it doesn't seem to |work. Does anybody has experience with that ? | The address in TCM is for this. To use it you must do the following.. 0) Make sure the HARC is running 4.1.11 or newer code. 1) Set the IP's in TCM 2) Save Chassis to NVRAM' 3) Enable "Auto configure on card insert" in NMC via TCM 4) "delete configs on the HARC. It will reboot" When the HARC comes up the NMC will set up the basic IP info you selected. 5) Disable "Auto configure". (Very Important step) 6) Save Chassis to NVRAM 6) HARC should be up and running.. You can telnet in and use the 'adm' user w/ no password to log on. **Remember to set a password or disable the adm user after setting up your manage user**

Subject: (usr-tc) Is there a way to show transfer with HARC?
From: vanhalen@coredcs.com
Date: 1998-12-23 10:33:02

Hello, I've looked through a ton of documentation and surfed around for the answer to this, but as of yet have been unable to locate it, maybe not looking in the right doc. Anyway, is there a way to show bytes transferred with a Hiper Arc? We're running 4.1.11. The Netserver cards we have allow us to do a simple "show all" to see that info, but I've been unable to find that with a Hiper Arc. Any help or pointers appreciated. Steve

Subject: RE: (usr-tc) Is there a way to show transfer with HARC?
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-12-23 10:41:57

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of |vanhalen@coredcs.com |Sent: Wednesday, December 23, 1998 10:33 AM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) Is there a way to show transfer with HARC? | | |Hello, | |I've looked through a ton of documentation and surfed around for the |answer to this, but as of yet have been unable to locate it, maybe not |looking in the right doc. | |Anyway, is there a way to show bytes transferred with a Hiper Arc? We're |running 4.1.11. The Netserver cards we have allow us to do a simple "show |all" to see that info, but I've been unable to find that with a Hiper Arc. | Not via CLI. This is available via SNMP. -M

Subject: (usr-tc) HiPer ARC reboots when doing "DO xxxxxx"
From: Ralph Helfenberger <rhelfenberger@comlight.ch>
Date: 1998-12-23 11:07:28

Hi I have a problem with HiPer ARC 4.1.11. When I process a configuration script with "DO <scriptname>" the HiPer ARC processes some of the commands but then boots immediately. It doesn't always stops in the same line of the script, so I think it is not the script a such. Any ideas? BTW: I did a downgrade from 4.1.72 to 4.1.11. Maybe this is the problem?

Subject: (usr-tc) Remote Configuration of HiPer ARC
From: Ralph Helfenberger <rhelfenberger@comlight.ch>
Date: 1998-12-23 11:18:35

Hi Is there a possiblity to configure a new HiPer ARC completely from Remote? I have a HiPerARC in a remote site. I'd like to do a DELETE CONFIGURATION of this HiPerARC. Obviously there is no more IP address on the HiPerARC. So I looked into TCM. There is a possibility to set an IP adress for the HiPER ARC on TCM but it doesn't seem to work. Does anybody has experience with that ? Best regards Ralph

Subject: RE: (usr-tc) Is there a way to show transfer with HARC?
From: vanhalen@coredcs.com
Date: 1998-12-23 11:26:40

On Wed, 23 Dec 1998, Mike Wronski wrote: > |Anyway, is there a way to show bytes transferred with a Hiper Arc? We're > |running 4.1.11. The Netserver cards we have allow us to do a simple "show > |all" to see that info, but I've been unable to find that with a Hiper Arc. > | > > Not via CLI. This is available via SNMP. > > -M Hey Mike, Thanks for the reply. You wouldn't happen to have the MIB around for the SNMP? Thanks, Steve

Subject: (usr-tc) Memory in Netserver
From: Erri Wibowo <erri@idola.net.id>
Date: 1998-12-23 11:53:20

Dear All, How much memory needed for USR Netserver 64 port. Is this configuration enough ? U.S. Robotics Total Control (tm) NETServer Card V.34 version 3.1.7 Build date: Jan 5 1996 Build time: 10:58:50 Licensed for 60 ports. System memory 1296500 bytes - 1280208 used, 16292 available Free blocks (block_size:count): 1152:0 128:0 640:0 160:1 144:8 224:12 2048:12 11 2:10 80:31 64:10 48:0 32:126 System nbufs 5000 - 167 used, 4833 available Please help. Our user often disconnected from our Netserver in busy hour. I need to know whether memory is enough for this Netserver. tia Erri Wibowo

Subject: RE: (usr-tc) Is there a way to show transfer with HARC?
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-23 11:55:16

Has a feature request been submitted to add this to the CLI? If not I would like to make one >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Wronski >Sent: Wednesday, December 23, 1998 10:42 AM >To: usr-tc@lists.xmission.com >Subject: RE: (usr-tc) Is there a way to show transfer with HARC? > > > > >|-----Original Message----- >|From: owner-usr-tc@lists.xmission.com >|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of >|vanhalen@coredcs.com >|Sent: Wednesday, December 23, 1998 10:33 AM >|To: usr-tc@lists.xmission.com >|Subject: (usr-tc) Is there a way to show transfer with HARC? >| >| >|Hello, >| >|I've looked through a ton of documentation and surfed around for the >|answer to this, but as of yet have been unable to locate it, maybe not >|looking in the right doc. >| >|Anyway, is there a way to show bytes transferred with a Hiper Arc? We're >|running 4.1.11. The Netserver cards we have allow us to do a simple "show >|all" to see that info, but I've been unable to find that with a Hiper Arc. >| > >Not via CLI. This is available via SNMP. > >-M > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Remote Configuration of HiPer ARC
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-12-23 12:10:49

Ralph Helfenberger was heard to say: >Is there a possiblity to configure a new HiPer ARC completely from >Remote? I have a HiPerARC in a remote site. I'd like to do a >DELETE CONFIGURATION of this HiPerARC. Obviously there is no more IP >address on the HiPerARC. So I looked into TCM. There is a possibility >to set an IP adress for the HiPER ARC on TCM but it doesn't seem to >work. Does anybody has experience with that ? Use HARM pointed at the NMC. It's slow as unholy h*** but it does let you play with the HARC without a serial connection. (I'm not sure what the magic is to get HARM to talk through the NMC, but TCM does.) --Ricky

Subject: Re: (usr-tc) Is there a way to show transfer with HARC?
From: buzzg@rconnect.com
Date: 1998-12-23 12:28:05

Is list pbus ses what you are looking for? At 10:33 AM 12/23/98 -0600, you wrote: >Hello, > >I've looked through a ton of documentation and surfed around for the >answer to this, but as of yet have been unable to locate it, maybe not >looking in the right doc. > >Anyway, is there a way to show bytes transferred with a Hiper Arc? We're >running 4.1.11. The Netserver cards we have allow us to do a simple "show >all" to see that info, but I've been unable to find that with a Hiper Arc. > >Any help or pointers appreciated. > >Steve > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) MPIP problems with ARC
From: Rob Nelson <rob@mag-net.com>
Date: 1998-12-23 12:47:20

Are there any known issues with MPIP on the Hiper Arc? I have configured two chassis here and connections across multiple chassis seem to be working, but multiple connections to the same chassis are causing some major problems. One symptom that I see is the MPIP links are not always being removed when a connection goes away. Currently I'm connected via one b-channel to our first chassis yet it shows 4 links in place for my connection. If I bring up a second b-channel and connect to the second chassis it will work correctly. If my second b-channel connects to the same chassis as my first b-channel one of two things will happen, either the second connection will fail and disconnect after approx. 3 seconds, or it will connect and all data will stop flowing until I manually disconnect all channels and reconnect. I initially configured the MPIP via the Hiper Arm software. Yesterday I reconfigured MPIP from the CLI and still no luck. NTP is configured and working. Both chassis are running 4.1.72 code. As long as the MPIP links are removed when they should be things work well, but if stale links are left behind muti-channel connections are very unreliable. Is there a CLI function to remove a specific link short of switching server status off then on again? Perhaps I've simply not confirured the MPIP settings in the correct order.

Subject: Re: (usr-tc) Is there a way to show transfer with HARC?
From: vanhalen@coredcs.com
Date: 1998-12-23 14:04:05

On Wed, 23 Dec 1998 buzzg@rconnect.com wrote: > Is list pbus ses what you are looking for? > > Actually that looks like it _could_ work, I could convert the packets to bytes but in order to use it I need a way to reset the Rpkts and Spkts values. It looks like those numbers don't get reset when I issue a disc user command or when I do a reset modems slot:x/mod:x. Any idea how to reset that counter? Thanks, Steve

Subject: (usr-tc) New DSP Code on Totalservice
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-12-23 14:24:04

DSP code version 1.2.60 has been posted to the totalservice website. Belo= w is a small sample of the resolved issues: MR 1701 Improved connectivity with V.90 modems MR 1702 Improved connection stability with V.90 modems MR 1026 Corrected ESF-FDL false loop up code MR 1577 Send ALERT in response to SETUP instead of CALL PROCEEDING MR 1578 Improved V.22 protocol support MR 1669 Improved V.22 protocol support (fallback to Bell 103) MR 1749 Corrected instance of modem hung in =91online answer=92 state MR 1753 Corrected intermittent condition that caused packet bus to toggle= with certain HiPer ARC code revisions MR 1909 Added workaround for =917E=92 ESF-FDL idle byte pattern causing a= specific manufacturer=92s DCS equipment to crash 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."

Subject: (usr-tc) NMC not responding
From: Jolliffe, Anu <ajolliffe@imagen.net>
Date: 1998-12-23 14:26:15

I just received a pre-owned TC rack with a dual PRI, 12 quads, nsc and nmc. The rack supposedly has the newest code installed for X2, but have been unable to connect to the nmc via the CH1 port. I am able to successfully connect to the nsc card, and another nmc that I temporarily installed in the rack for testing purposes. The rack boots up fine with green all across and I've verified the baud rate of the CH1 port. Any ideas on where I should go from here? Thanks.

Subject: RE: (usr-tc) NMC not responding
From: Jolliffe, Anu <ajolliffe@imagen.net>
Date: 1998-12-23 16:10:33

Yes, I switched dip switch 5 to on and reset the card. Nothing. Thanks. -----Original Message----- Sent: Wednesday, December 23, 1998 2:36 PM Have you tried resetting the card to factory defaults with the dip switch? Steve On Wed, 23 Dec 1998, Jolliffe, Anu wrote: > I just received a pre-owned TC rack with a dual PRI, 12 quads, nsc and nmc. > The rack supposedly has the newest code installed for X2, but have been > unable to connect to the nmc via the CH1 port. I am able to successfully > connect to the nsc card, and another nmc that I temporarily installed in the > rack for testing purposes. The rack boots up fine with green all across and > I've verified the baud rate of the CH1 port. > > Any ideas on where I should go from here? > > 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.

Subject: RE: (usr-tc) quick start for Hiper ARC ???
From: System Administrator <root@wingnet.net>
Date: 1998-12-23 16:25:15

Thanks. It turned out to be that the authentication was set to 'any' and should have been set to 'pap' explicitly. WingNET System Administrator 423-559-LINK (v) 423-559-5444 (f)

Subject: Re: (usr-tc) NMC not responding
From: vanhalen@coredcs.com
Date: 1998-12-23 16:35:31

Have you tried resetting the card to factory defaults with the dip switch? Steve On Wed, 23 Dec 1998, Jolliffe, Anu wrote: > I just received a pre-owned TC rack with a dual PRI, 12 quads, nsc and nmc. > The rack supposedly has the newest code installed for X2, but have been > unable to connect to the nmc via the CH1 port. I am able to successfully > connect to the nsc card, and another nmc that I temporarily installed in the > rack for testing purposes. The rack boots up fine with green all across and > I've verified the baud rate of the CH1 port. > > Any ideas on where I should go from here? > > Thanks. >

Subject: Re: (usr-tc) Remote Configuration of HiPer ARC
From: Ralph Helfenberger <rhelfenberger@comlight.ch>
Date: 1998-12-23 18:29:58

Sounds like the solution. Did you have to set something through TCM befor beeing able to access ARC through NMC? I can't do it here, HARM is timing out if I try to connect. I checked different community strings like none, public, private. Ralph Ricky Beam wrote: > > Ralph Helfenberger was heard to say: > >Is there a possiblity to configure a new HiPer ARC completely from > >Remote? I have a HiPerARC in a remote site. I'd like to do a > >DELETE CONFIGURATION of this HiPerARC. Obviously there is no more IP > >address on the HiPerARC. So I looked into TCM. There is a possibility > >to set an IP adress for the HiPER ARC on TCM but it doesn't seem to > >work. Does anybody has experience with that ? > > Use HARM pointed at the NMC. It's slow as unholy h*** but it does let you > play with the HARC without a serial connection. > > (I'm not sure what the magic is to get HARM to talk through the NMC, but TCM > does.) > > --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.

Subject: (usr-tc) Very strange TC crashes
From: Stauffer Walter <stauffer@galenica.ch>
Date: 1998-12-23 19:25:52

Fellow TC users, we use the following setup to receive orders from our customers: <fixed font> PRI 1 switch 1 ------> TC 1 | customer -----> telco | 0800 xx xx xx | PRI 2 switch 2 ------> TC 2 </fixed font> ;-) TC 1 has 4 quad modems, TC 2 has 6. Both PRI's are v3.0.2. Only one port is used on each. No NMC, no Netserver. Our DTE's are on the serial ports ... Both TC's are at the same site, but hooked up to different PRI's coming into the building from different locations. PRI 1 is limited to the number of modems in TC 1. This was necessary to make the re-routing to PRI 2 work correctly (cooperation problem between the telco sw and the TC). PRI 2 could bring more calls than we have devices in the box, but excess calls should simply get "busy" (no further re-routing from PRI 2). Last Friday and the Friday before, we had EXTREMELY much traffic. The telco reported 500 calls per min to the 0800 number (which I can hardly believe, and which we cannot handle, of course, but that's what they say). Shockingly, after 10 minutes of stress, both TC's stopped working. Most modem lights off, some yellow, but no connections established anymore. The PRI's showed no red alarm. All callers got "busy". The telco reported "no problems here, must be your device". I had to power cycle the TC's to get 'em up again. What do you think of these events ? All input GREATLY appreciated, after all, these modems are mission critical for us. TIA and best regards, Walter PS 1: we have the debug info coming out of the PRI's serial port enabled all the time. I use a PC to grab this info and make call statistics and an activity display for the operators out of it. This has been working for a year without trouble, until these last two events. Could this be a problem under heavy load ? (Yes I had a look at the NMC but found it not very useful, but having read some recent postings on this list, I will give it another try). PS 2: debug info (small extract, I have more) What does the " ... err:51" bit mean ? 18:30:41 uccidm_reserve_ds0: SUCCESS: call_type: ANALOG, span=0, ds0=3, in_flag=1 18:30:41 UCCM_BUILD_TODEV_NSF_IE: compand code used = 0 (0=A-law,1=U-law,2=country) 18:30:41 GetDS0SlotMapByte: mdm_id=18 span=0 ds0=3 octet=3 bitmap=0 18:30:41 GetDS0SlotMapByte: mdm_id=18 span=0 ds0=3 octet=2 bitmap=0 18:30:41 GetDS0SlotMapByte: mdm_id=18 span=0 ds0=3 octet=1 bitmap=0 18:30:41 GetDS0SlotMapByte: mdm_id=18 span=0 ds0=3 octet=0 bitmap=4 18:30:41 ucc_setup_in_call,send usr_X_setup_con_req to dev 18:30:41 ucc_setup_in_call:tcid:0x262,ucid:0x000082ef,sp:0,b:3,tts:47,dt:2,s/c:5/3, hdl:14 18:30:41 sfn:ucc_s3_hdl_t4d2,evt:28-T4D2,tcid:0x241,ucid:0x000082ce 18:30:41 ucc_s3_hdl_t4d2: T4D2 expired - USR_CLEAR_CONF not seen 18:30:41 sfn:ucc_nop,evt:3-USR_CLEAR_REQ,tcid:0x241,ucid:0x000082ce 18:30:41 uccu_get_tncid_uccb: tcid = 0x248, position in uccb list = 3, dsl = 0 18:30:41 sfn:ucc_s4_go_null,evt:14-CLEAR_CONF,tcid:0x248,ucid:0xffffffff 18:30:41 uccu_releasing uccb: DE-ALLOC: tcid = 0x0, ucid = 0xffffffff 18:30:41 uccidm_release_ds0: span = 0, ds0 = 8 18:30:42 uccu_release_bchs: DE-ALLOC ucid: 0xffffffff 18:30:42 uccu_get_tncid_uccb: tcid = 0x25e, position in uccb list = 15, dsl = 0 18:30:42 uccu_get_tncid_uccb: uccb_p is NULL 18:30:42 ERR:ucc_gen_error,uccproc_cc_pkg,No uccb found for cc_event:,err:51 18:30:42 uccu_get_tncid_uccb: tcid = 0x25f, position in uccb list = 12, dsl = 0 18:30:42 sfn:ucc_s1_go_t_d_disc,evt:18-DISC_IND,tcid:0x25f,ucid:0x000082ec 18:30:42 ucc_go_t_d_disc: teardown msg >DISC_REQ<, cause location = 0 18:30:42 ucc_go_t_d_disc: cause value = 102(0x66), is_usr_disc_cause flag = 0 18:30:42 uccu_get_tncid_uccb: tcid = 0x260, position in uccb list = 15, dsl = 0 18:30:42 uccu_get_tncid_uccb: uccb_p is NULL 18:30:42 ERR:ucc_gen_error,uccproc_cc_pkg,No uccb found for cc_event:,err:51 18:30:42 uccu_get_new_uccb: attach uccb to end of list. tcid: 0x263 ucid: 0x000082f0 18:30:42 uccu_get_new_uccb: ALLOC tcid: 0x263 ucid: 0x000082f0, allocated = 16, dsl_id=0 18:30:42 sfn:ucc_null,evt:20-SETUP_IND,tcid:0x263,ucid:0x000082f0 18:30:43 ucc_setup_in_call: tcid: 0x263, CRV: 20290 (0x4f42) 18:30:43 ucc_setup_in_call: ANI (calling_phnum) >0327512556<, len = 10, err = 0x45e30 18:30:43 uccidm_search_DNIS_reserved_pool: len_called_num = 2: stripped inbound phone >57<, len = 2 18:30:43 uccidm_search_DNIS_reserved_pool: local stripped DNIS >?<, len = 1 18:30:43 uccidm_search_DNIS_reserved_pool: local stripped DNIS >?<, len = 1 18:30:43 uccidm_search_DNIS_reserved_pool: local stripped DNIS >?<, len = 1 18:30:43 uccidm_search_DNIS_reserved_pool: local stripped DNIS >?<, len = 1 18:30:43 ds0_res_call_type: dsl: 0, intid: 0, ds0: 7, bct: 73, err: 0 verdict: 1

Subject: (usr-tc) Netserver to Hiper Arc Upgrade Problems
From: Russ Miescke <russm@powerweb.net>
Date: 1998-12-24 04:30:42

Tonight we replaced a Netserver card with the Hiper Arc. I followed the directions to the letter including a NMC RAM upgrade, all of the config files etc.. The upgrade went well using arcswitcher, but when the Hiper Arc was installed it failed to recognize my Quad modems and callers got a busy signal. I manually set the slots to the quad modem, set the radius secret and callers were then able to dial in. The problem is they would be disconnected 15 seconds after logging in. What did I miss? Russ Miescke Power Web Connect

Subject: Re: (usr-tc) Netserver to Hiper Arc Upgrade Problems
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-24 07:27:56

Within 15 secs of connection or witing 15 sec of dialing in? In any case gues you have problems in configuration of the chassis. Either the modems are not no the packet bus or the hiper arc is not recognizing the data sent by the modem. I would suggest delete config on the hiper arc and redo the config manulally to start with. 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 Dec 1998, Russ Miescke wrote: > > Tonight we replaced a Netserver card with the Hiper Arc. I followed the > directions to the letter including a NMC RAM upgrade, all of the config > files etc.. > The upgrade went well using arcswitcher, but when the Hiper Arc was > installed it failed to recognize my Quad modems and callers got a busy > signal. I manually set the slots to the quad modem, set the radius secret > and callers were then able to dial in. The problem is they would be > disconnected 15 seconds after logging in. What did I miss? > > Russ Miescke > Power Web Connect > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) New DSP Code on Totalservice
From: Ralph Helfenberger <rhelfenberger@comlight.ch>
Date: 1998-12-24 09:02:02

Is that for T1 only or also for E1/PRI configurations? Mike Wronski wrote: > > DSP code version 1.2.60 has been posted to the totalservice website. Below is a > small sample of the resolved issues: > > MR 1701 Improved connectivity with V.90 modems > MR 1702 Improved connection stability with V.90 modems > MR 1026 Corrected ESF-FDL false loop up code > MR 1577 Send ALERT in response to SETUP instead of CALL PROCEEDING > MR 1578 Improved V.22 protocol support > MR 1669 Improved V.22 protocol support (fallback to Bell 103) > MR 1749 Corrected instance of modem hung in �online answer� state > MR 1753 Corrected intermittent condition that caused packet bus to toggle with > certain HiPer ARC code revisions > MR 1909 Added workaround for �7E� ESF-FDL idle byte pattern causing a specific > manufacturer�s DCS equipment to crash > > --------------------------------------------------------- > 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." > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) multichannel ISDN and HiperArc
From: Dominic Ciresi <dciresi@defunct.ae.usr.com>
Date: 1998-12-24 12:45:06

Change the max-channels for the default user to 4, instead of 2. Dominic On Wed, 23 Dec 1998, Steve McConnell wrote: > > I just upgraded our Netserver chassis (2 PRI, 6 quad digital modems, NMC all > now off so I dont have the code revs, but they were all current) with ISDN > calls terminated on the Netserver, to a 3 PRI DSP running 1.2.5 code a > HiperArc running 4.1.72, and an NMC running 5.5.5 > > We are running ESVA-Radius 1.16 ( i believe) > > I have a co-worker that was getting 4 channels (2 BRIs) bonded on the > Netserver chassis. However on the HiperArc, he only gets 2. > > The only thing that changed was the chassis (of course that was a big > change) but is there a setting that I am missing that will enable the > chassis to bond 4 channels? I have asked that question to 3com support and > was told this was a function of RADIUS. Since I am using the same RADIUS set > up, there must be something else?? > > Any help is appreciated. > > Steve > > > Steve McConnell Network Admin > EMJI 919-303-3217 > stevem@emji.net > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) New DSP Code on Totalservice
From: John Powell <jp@packet.ae.usr.com>
Date: 1998-12-24 16:48:52

Only T1 was posted. If anyone needs E1 (PRI only), shoot me a note, I have it and can point you to where to download it.=20 You will be only the second person that asked for it, so it has little field time on it. JP On Thu, 24 Dec 1998, Ralph Helfenberger wrote: > Is that for T1 only or also for E1/PRI configurations? >=20 > Mike Wronski wrote: > >=20 > > DSP code version 1.2.60 has been posted to the totalservice website. Be= low is a > > small sample of the resolved issues: > >=20 > > MR 1701 Improved connectivity with V.90 modems > > MR 1702 Improved connection stability with V.90 modems > > MR 1026 Corrected ESF-FDL false loop up code > > MR 1577 Send ALERT in response to SETUP instead of CALL PROCEEDING > > MR 1578 Improved V.22 protocol support > > MR 1669 Improved V.22 protocol support (fallback to Bell 103) > > MR 1749 Corrected instance of modem hung in =91online answer=92 state > > MR 1753 Corrected intermittent condition that caused packet bus to togg= le with > > certain HiPer ARC code revisions > > MR 1909 Added workaround for =917E=92 ESF-FDL idle byte pattern causing= a specific > > manufacturer=92s DCS equipment to crash > >=20 > > --------------------------------------------------------- > > 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." > >=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 > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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

Subject: (usr-tc) Rudolph Repost..
From: Allen Marsalis <am@shreve.net>
Date: 1998-12-25 18:52:58

Has it been a year already?? Merry Christmas everyone!! Allen >>>>>>>>> RUDOLPH THE X2 MODEM Rudolph, the X2 modem, has a very shiny light. And if you ever upgrade. you would even say it's bright. All of the other modems, used to hardwire 56K. They never bet poor Rudolf, could upgrade each and every day. Then one noisy Christmas Eve, Rockwell went off line. Rudolph with your light so bright, won't you flash upgrade tonight? Then all the modems loved him, as they vote at ITU-T. Rudolph the X2 modem, you have good flash mem-o-ry! <<<<<<<<<<<<<

Subject: (usr-tc) DUal T-1 Cards Stats
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1998-12-26 23:00:00

Is anyone using NRTG to pull T-1 stats from either a Dual PRI card or an HDM card ? If so, can you share your config file. I am primarily looking for the ESF stats. Thanks, Jeff Binkley ASA Network Computing

Subject: Re: (usr-tc) New MP8/16I code
From: Michael R. Gile <gilem@wsg.net>
Date: 1998-12-27 08:35:20

Yeah, what _IS_ the hold-up anyway? v.90 has actually made it through the exceedingly slow committees, and every other digital server modem has v.90 support, EXCEPT the MP/Netserver line. Has anyone asked USR about this, or know what is going on with beta testing? At 11:48 AM 12/21/1998 -0800, you wrote: >> But, readme.txt says it is for 2.2.2, not 2.2.97. > >The readme states that these are changes to the 2.2.2 code. I'm wondering >when they'll release v.90 for these things...? > > -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 # > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. ====================================================== Michael Gile gilem@wsg.net President (518)435-0682 Web Services Group http://www.wsg.net/

Subject: (usr-tc) PM codes?
From: x@asdf.com
Date: 1998-12-28 11:03:35

Hello I tried to search through the archive of this mailing list first but did not find an answer. Does anyone know where I can find the codes for the Reason for Call Failure option in Performance Monitor? Specifically, I get a value of 80 and I can't figure out where to find out what 80 means ;-P Thanks -=X=-

Subject: (usr-tc) Unreal Problems
From: dale <adp@cybertours.com>
Date: 1998-12-28 11:52:50

Alot of my customers are playing unreal, they are receiving very slow ping times. Does anyone have an Idea of a fix for this. I'm running the latest code on all my chassis.

Subject: Re: (usr-tc) Unreal Problems
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-12-28 12:01:52

Thus spake dale >Alot of my customers are playing unreal, they are receiving very slow ping >times. Does anyone have an Idea of a fix for this. I'm running the latest >code on all my chassis. Hrmm...sounds suspiciously like the "Quake Lag" issue. You running NETServer's or HiPer Arc's? -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Unreal Problems
From: Jamie Orzechowski <mhz@ripnet.com>
Date: 1998-12-28 12:04:17

is this a NETServer chassis? ... if so it will have the same problems as quake, quake2, etc ... ----- Original Message ----- Sent: Monday, December 28, 1998 11:52 AM >Alot of my customers are playing unreal, they are receiving very slow ping >times. Does anyone have an Idea of a fix for this. I'm running the latest >code on all my chassis. > > > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) SNMP Led status
From: Dale Hege <fhege@sover.net>
Date: 1998-12-28 13:28:59

Can someone help me decode this into something a human can read? Thanks -Dale enterprises.usr.nas.chs.uchasConfig.uchasFrontPanelLedStates.0 = Hex: 99 00 00 00 00 00 99 00 00 00 00 01 99 00 00 00 00 00 99 00 00 00 00 00 99 00 00 00 00 01 99 00 00 00 00 01 99 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 99 10 00 00 00 00 99 00 00 00 00 00 01 00 00 00 00 00 00 00 enterprises.usr.nas.chs.uchasConfig.uchasFrontPanelLedColor.0 = Hex: 11 00 00 00 00 00 11 00 00 00 00 01 11 00 00 00 00 00 11 00 00 00 00 00 11 00 00 00 00 01 11 00 00 00 00 01 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 11 10 00 00 00 00 11 00 00 00 00 00 01 00 00 00 00 00 00 00 enterprises.usr.nas.chs.uchasConfig.uchasNicStates.0 = Hex: 88 00 00 00 00 00 88 00 00 00 00 00 88 00 00 00 00 00 88 00 00 00 00 00 88 00 00 00 00 00 88 00 00 00 00 00 88 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 88 00 00 00 00 00 88 00 00 00 00 00 00 00 00 00 00 00 00 00 enterprises.usr.nas.chs.uchasConfig.uchasFrontPanelLedStates2.0 = Hex: 89 10 00 00 00 00 99 10 00 00 00 00 89 10 00 00 00 00 99 10 00 00 00 00 99 10 00 00 00 00 99 10 00 00 00 00 99 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 88 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 enterprises.usr.nas.chs.uchasConfig.uchasFrontPanelLedColor2.0 = Hex: 01 10 00 00 00 00 11 10 00 00 00 00 01 10 00 00 00 00 11 10 00 00 00 00 11 10 00 00 00 00 11 10 00 00 00 00 11 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Subject: (usr-tc) V.90 Code Feature Question
From: John Verreault <verreaul@aei.ca>
Date: 1998-12-28 13:37:05

Does the X2/v.90 code feature have to be enabled on the NMC cards for Quad Modem Cards to accept X2/v.90 calls?? I flashed a chassis that I had with the following. PRI 3.02 Quad Modem 5.10.9 Netserver (8Mb) 3.7.24 NMC(16Mb) 5.5 The Quad Modem cards say X2 v.90 enabled The NMC card says X2 v.90 Not enabled. Does it work or do I have to enable the feature on the NMC ??? Thanks John

Subject: Re: (usr-tc) MPIP problems with ARC
From: Jeremy Shaffner <jer@jorsm.com>
Date: 1998-12-28 13:57:49

On Wed, 23 Dec 1998, Rob Nelson wrote: > Are there any known issues with MPIP on the Hiper Arc? I have configured > two chassis here and connections across multiple chassis seem to be > working, but multiple connections to the same chassis are causing some > major problems. > > One symptom that I see is the MPIP links are not always being removed when > a connection goes away. Currently I'm connected via one b-channel to our > first chassis yet it shows 4 links in place for my connection. If I bring > up a second b-channel and connect to the second chassis it will work > correctly. If my second b-channel connects to the same chassis as my first > b-channel one of two things will happen, either the second connection will > fail and disconnect after approx. 3 seconds, or it will connect and all > data will stop flowing until I manually disconnect all channels and reconnect. Is the MPIP Server also configured as a Client? And are both chassis listed as clients on the server? > I initially configured the MPIP via the Hiper Arm software. Yesterday I > reconfigured MPIP from the CLI and still no luck. NTP is configured and > working. Both chassis are running 4.1.72 code. As long as the MPIP links > are removed when they should be things work well, but if stale links are > left behind muti-channel connections are very unreliable. > > Is there a CLI function to remove a specific link short of switching server > status off then on again? Perhaps I've simply not confirured the MPIP > settings in the correct order. What order might that be? -Jeremy -===================================================================- Jeremy Shaffner JORSM Internet Senior Technical Support Northwest Indiana's Premium jer@jorsm.com Internet Service Provider support@jorsm.com http://www.jorsm.com -===================================================================-

Subject: Re: (usr-tc) V.90 Code Feature Question
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-12-28 14:23:38

You need the x2 feature enabled for Quads, yeah. You don't for HiPer DSP's. Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ # view;touch;unzip;finger;mount;mv;mv;mv;yes;mv;yes;mv;yes;umount;sleep On Mon, 28 Dec 1998, John Verreault wrote: > Does the X2/v.90 code feature have to be enabled on the NMC cards for Quad Modem Cards to accept X2/v.90 calls?? > > I flashed a chassis that I had with the following. > > PRI 3.02 > Quad Modem 5.10.9 > Netserver (8Mb) 3.7.24 > NMC(16Mb) 5.5 > > The Quad Modem cards say X2 v.90 enabled > > The NMC card says X2 v.90 Not enabled. > > > Does it work or do I have to enable the feature on the NMC ??? > > Thanks > John > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) NMC not responding
From: Wojciech Janiszewski <janisz@bydgoszcz.mtl.pl>
Date: 1998-12-28 15:05:05

Jolliffe, Anu wrote: > I just received a pre-owned TC rack with a dual PRI, 12 quads, nsc and nmc. > The rack supposedly has the newest code installed for X2, but have been > unable to connect to the nmc via the CH1 port. I am able to successfully > connect to the nsc card, and another nmc that I temporarily installed in the > rack for testing purposes. The rack boots up fine with green all across and > I've verified the baud rate of the CH1 port. > > Any ideas on where I should go from here? Try to upload software to this card via pc-sdl. Wojciech +-------------------------+-----------------+------------------------------+ > janisz@bydgoszcz.mtl.pl | WJ14-RIPE | Multinet - Bydgoszcz < +-------------------------+-----------------+------------------------------+

Subject: Re: (usr-tc) NMC not responding
From: Wojciech Janiszewski <janisz@bydgoszcz.mtl.pl>
Date: 1998-12-28 15:05:05

Subject: (usr-tc) PRI's from 2 carriers on same PRI card?
From: Suncoast Networking USR Mailbox <usrtcmail@flasuncoast.net>
Date: 1998-12-28 17:21:12

I want to have 2 Phone Companies each providing an ISDN PRI circuit to a single PRI NIC/NAC. The ILEC uses NI2 and the CLEC used 5ESS. Can this be done? This is a Netserver NMC TC bundle. Thanks, Steve Kinkaid

Subject: Re: (usr-tc) PRI's from 2 carriers on same PRI card?
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-12-28 17:31:20

Thus spake Suncoast Networking USR Mailbox >I want to have 2 Phone Companies each providing an ISDN PRI circuit >to a single PRI NIC/NAC. The ILEC uses NI2 and the CLEC used 5ESS. >Can this be done? Yeah, but you don't want to. Tell the ILEC you want 5ESS. Not because there's any problems running two different PRI's with different switch types, but because NI-2 sucks swamp water through a straw. (I'm assuming the ILEC has a 5E, whatever the case, don't use NI-2, you'll regret it) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) SNMP Led status
From: Dwight G. Jones <djones@imagen.net>
Date: 1998-12-28 17:48:38

Subject: Re: (usr-tc) PRI's from 2 carriers on same PRI card?
From: John Powell <jp@packet.ae.usr.com>
Date: 1998-12-28 18:08:25

You also need to be very careful with your timing configuration. Problems can result from using two different timing sources. Do it carefully, and watch for frame slips, etc. May not be an issue, but you need to be careful. JP On Mon, 28 Dec 1998, Jeff Mcadams wrote: > Thus spake Suncoast Networking USR Mailbox > >I want to have 2 Phone Companies each providing an ISDN PRI circuit > >to a single PRI NIC/NAC. The ILEC uses NI2 and the CLEC used 5ESS. > >Can this be done? > > Yeah, but you don't want to. Tell the ILEC you want 5ESS. Not because > there's any problems running two different PRI's with different switch > types, but because NI-2 sucks swamp water through a straw. (I'm > assuming the ILEC has a 5E, whatever the case, don't use NI-2, you'll > regret it) > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Span / DSP problems
From: Buzz Gould <buzzg@rconnect.com>
Date: 1998-12-28 21:12:28

We have a TC Chassis in service that is having problems with all of the modems dropping at once. All calls will drop and the all the trunks go to DS0 Timeslot Status (ds0OutOfServi[24]) and the DSO Service state is (remoteOutOf Service[5]) Sometimes they drop and come back a minute or two later, Sometimes they stay down for an hour or more. Callers get a busy signal during this time. I have tried a HW re-set on the DSP with no difference and have tried a re-boot of the ARC with no difference. The phone co is looking at the problem. Going to get both ends of the circuit on the phone tomorrow and see what they can find. Has anyone seen this before? Here is the provisioning on the CHT1: S1C25 Framing Mode dsx1D4 Line Coding Options dsx1AMI Send Code dsx1SendNoCode Circuit Identifier Loopback Configuration dsx1NoLoop Signal Mode robbedBit Transmit Clock Source loopTiming NIC Type longHaul Response to Remote Loopback ignore Jitter Attenuation attenJitterOnTxmtr Transmit Line Build Out dB0pt0 Dial In Address dnis Dial In/Out Trunk Start Signal Type wink Ack Wink On Dial In Address Info Received disabled Dial Out Address Delay 70 Dial In/Out Trunk Type eAndMTypeII Primary Switch Type priSwDMS100 Idle Byte Pattern 254 Receiver Gain dB26 Tone Type dtmf Number of DTMF Tones 4 This is the HyPer DSP: S1 Operational Status operational Serial Number B7T82H5N Hardware Revision 0.49.0 Software Version 1.2.5 DRAM Installed (KB) 8192 ROM Installed (KB) 2048 HyPerARC : S16 Operational Status operational Serial Number B5R8V42N Hardware Revision 1.0.0 Software Version 4.0.35 RAM Installed (KB) 65536 ROM Installed (KB) 8192 DIP Switch Settings 0 and the NMC: S17 Operational Status operational Serial Number B5D8TM44 Hardware Revision 6.0 Software Version 5.5.5 General NMC Status ok Chassis Temp (Deg. C) 20 Number of Power Up Failures 0 Software Compatibility Version 5.5.0 DIP Switch Settings 0 DRAM Installed (KB) 16384 ROM Installed (KB) 8192 Packet Bus Clocking Source backplaneActive Buzz Gould Rural Connections ~ Information Services 1(800)228-6454 www.rconnect.com

Subject: (no subject)
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1998-12-28 22:38:01

Is that true in the newer versions also? - Marcelo ---------- Forwarded message ---------- Reply-To: Bugtraq List <BUGTRAQ@netspace.org> We found 3Com's HiPer ARCs running system version 4.1.11 being vulnerable to the nestea DoS attack. The cards simply crash and reboot. The multi DoS tool targa v1.1 http://www.rootshell.com/archive-j457nxiqi3gq59dv/199806/targa.c.html started with the nestea option can be used for demonstration. *sigh* As already mentioned on Bugtraq in the past, 3Com/USR's IP stacks are not very resistant against this specific kind of DoS attack: NetServer card: http://geek-girl.com/bugtraq/1998_4/0198.html PalmPilot: http://geek-girl.com/bugtraq/1998_2/0138.html >From my experiences 3Com has fixed this bug in the recent Total Control NetServer card code base. Apparently it was re-introduced by the HiPer ARC. Olaf -- Olaf Selke, olaf.selke@mediaways.net, voice +49 5241 80-7069 - Marcelo

Subject: Re: (usr-tc) Span / DSP problems
From: Ronald E. Kushner <ron@glis.net>
Date: 1998-12-29 02:45:19

Buzz Gould wrote: > > We have a TC Chassis in service that is having problems with all of the > modems dropping at once. All calls will drop and the all the trunks go to > DS0 Timeslot Status (ds0OutOfServi[24]) and the DSO Service state is > (remoteOutOf Service[5]) Sometimes they drop and come back a minute or two > later, Sometimes they stay down for an hour or more. Callers get a busy > signal during this time. I have tried a HW re-set on the DSP with no > difference and have tried a re-boot of the ARC with no difference. The > phone co is looking at the problem. Going to get both ends of the circuit > on the phone tomorrow and see what they can find. Has anyone seen this > before? If you have Total Control Manager, you will want to monitor the Near End Total Group (24 hours), and look for errored seconds, frame slips, bi-polar error, or anything else. If you DS-1 is clean, you'll have all 0's. If you don't have TCM, you will have to hook up a serial cable to the console port and look for this information. If you have multiple DS-1's, and this is only happening on one card, move the DS-1 to see if the problem follows it. This will tell you if it's the hardware or the line. I ran into a simular experiece with WorldCom in the past. They kept blaming the USR equipment like they teach them to do in telecom school, and it was a royal pain to get them to troubleshoot this because they could loop the smartjack for hours on end without errors. Eventually they found a problem in a line pair, and they were unable to explain how they could loop the smartjack with showing any errors. -Ron GLISnet, Inc. +1 810/939.9885

Subject: (usr-tc) Possible DoS attach vulnerability
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1998-12-29 09:44:58

Subject: RE: (usr-tc) Span / DSP problems
From: Mid-Iowa - Jim Heng <micjim@pcpartner.net>
Date: 1998-12-29 10:22:53

Had the same problem here a while back. Turned out the telco had one leg provisioned for ESF/B8Zs. We'd get about 12 callers on then the whole thing would drop. Took too long to get this telco out of the office to their pop to check this... -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Buzz Gould Sent: Monday, December 28, 1998 9:12 PM We have a TC Chassis in service that is having problems with all of the modems dropping at once. All calls will drop and the all the trunks go to DS0 Timeslot Status (ds0OutOfServi[24]) and the DSO Service state is (remoteOutOf Service[5]) Sometimes they drop and come back a minute or two later, Sometimes they stay down for an hour or more. Callers get a busy signal during this time. I have tried a HW re-set on the DSP with no difference and have tried a re-boot of the ARC with no difference. The phone co is looking at the problem. Going to get both ends of the circuit on the phone tomorrow and see what they can find. Has anyone seen this before? Here is the provisioning on the CHT1: S1C25 Framing Mode dsx1D4 Line Coding Options dsx1AMI Send Code dsx1SendNoCode Circuit Identifier Loopback Configuration dsx1NoLoop Signal Mode robbedBit Transmit Clock Source loopTiming NIC Type longHaul Response to Remote Loopback ignore Jitter Attenuation attenJitterOnTxmtr Transmit Line Build Out dB0pt0 Dial In Address dnis Dial In/Out Trunk Start Signal Type wink Ack Wink On Dial In Address Info Received disabled Dial Out Address Delay 70 Dial In/Out Trunk Type eAndMTypeII Primary Switch Type priSwDMS100 Idle Byte Pattern 254 Receiver Gain dB26 Tone Type dtmf Number of DTMF Tones 4 This is the HyPer DSP: S1 Operational Status operational Serial Number B7T82H5N Hardware Revision 0.49.0 Software Version 1.2.5 DRAM Installed (KB) 8192 ROM Installed (KB) 2048 HyPerARC : S16 Operational Status operational Serial Number B5R8V42N Hardware Revision 1.0.0 Software Version 4.0.35 RAM Installed (KB) 65536 ROM Installed (KB) 8192 DIP Switch Settings 0 and the NMC: S17 Operational Status operational Serial Number B5D8TM44 Hardware Revision 6.0 Software Version 5.5.5 General NMC Status ok Chassis Temp (Deg. C) 20 Number of Power Up Failures 0 Software Compatibility Version 5.5.0 DIP Switch Settings 0 DRAM Installed (KB) 16384 ROM Installed (KB) 8192 Packet Bus Clocking Source backplaneActive Buzz Gould Rural Connections ~ Information Services 1(800)228-6454 www.rconnect.com - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) FS: USR Total Control Chassis (2059)
From: John Verreault <verreaul@aei.ca>
Date: 1998-12-29 13:34:35

For Sale Total Control 2059 Bundle Dual PRI/T1 card 12xQuad modems Netserver PRI (Ethernet) Network Management Card (Ethernet) Dual 45AMP Power Supply Chassis & Fan Tray X2/V.90 Enabled Latest Code already flashed Currently in production $5000 John Verreault AEI Internet

Subject: (usr-tc) Problems with newer 3Com/USR Sportsters -> DSP
From: Gilles Melanson <gilles@vianet.on.ca>
Date: 1998-12-29 16:04:43

I've had a good handful of users with 3com v90 internals that cannot connect to the DSPs on this end (1.2.66 currently, going to .60 shortly). All the typical at&f1 and/or &c1&d2&k0/1 init strings fail to work - these modems just handshake to death and drop carrier most of the time. Is there a known problem with recent v90 sportsters? -- Gilles Melanson ViaNet Internet Solutions System Administrator 128 Larch St. Suite 301 gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8 There isn't any reason why Linux can't be implemented as an enterprise computing solution. Find out what you've been missing while you've been rebooting Windows NT. -- Eric Hammond

Subject: Re: (usr-tc) FS: USR Total Control Chassis (2059)
From: Russ Miescke <russm@powerweb.net>
Date: 1998-12-29 17:38:45

What's wrong with it? Russ -----Original Message----- >For Sale Total Control 2059 Bundle > >Dual PRI/T1 card >12xQuad modems >Netserver PRI (Ethernet) >Network Management Card (Ethernet) >Dual 45AMP Power Supply >Chassis & Fan Tray >X2/V.90 Enabled >Latest Code already flashed >Currently in production > >$5000 > >John Verreault >AEI 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.

Subject: Re: (usr-tc) SNMP Led status
From: David Bolen <db3l@ans.net>
Date: 1998-12-29 17:56:51

Dale Hege <fhege@sover.net> writes: > Can someone help me decode this into something a human can read? Thanks You should be able to find information on decoding the led color and state objects in the NMC programming documentation for Total Control. Back in the NMC 3.x days there was a separate SNMP MIB reference manual that covered such usage, but it then got integrated into the main (huge) programming guide that also contains more or less a straight dump of the MIB files. In my 5.0 CD copy (NMCPRG50.PDF) it can be found in the "NMC Parameters" chapter, in the "LED status object sent to management stations (MS)" section on page 3-36. Basically, they are a raw octet encoding (opaque to SNMP) that shows the LED state (blinking, solid, etc..) and color (green, red, etc.) for each LED on each card. Because the initial objects only supported up to 12 LEDs per card, they added the second set of objects for cards such as the HiperDSP with more than that number of LEDs. I've enclosed an earlier e-mail of mine to this list that covers some of this with an older ASCII writeup I had lying around in case you don't have easy access to the PDF documentation. Even though dated slightly, I believe it's still accurate. 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 \ \-----------------------------------------------------------------------/ - - - - - - - - - - - - - - - - - - - - - - - - - In-Reply-To: Your message of Tue, 9 Dec 1997 21:19:44 -0800 (PST) Message-ID: <CMM.0.90.2.881738093.db3l@valheru.ny.ans.net> Jaye Mathisen <mrcpu@cdsnet.net> writes: > Heck, I haven't even figured out who the stupid things are named. Or > how to take CHS.MIB and extract the full name for the > uchasFrontPanelLedStates data. The LED objects reside in the uchasConfig tree, with a full path from the root of: iso.org.dod.internet.private.enterprises.usr.nas.chs.uchasConfig The full numeric OIDs for each of the objects are: uchasFrontPanelLedStates (1.3.6.1.4.1.429.1.1.3.5) uchasFrontPanelLedColor (1.3.6.1.4.1.429.1.1.3.6) uchasFrontPanelLedStates2 (1.3.6.1.4.1.429.1.1.3.8) uchasFrontPanelLedColor2 (1.3.6.1.4.1.429.1.1.3.9) The *2 objects are for the NMC 5.x code and support cards that have more than 12 LEDs (like the HiPer DSP). These objects are just opaque octet strings, which you have to decode yourself. You can find a description of the breakdown in the NMC 3.0 SNMP MIB documentation - I've included an early draft that I happen to have online. About the only correction is that I've found that the color object does in fact indicate the LED color for both power supplies as the first two LEDs in the last bank of octets. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/ - - - - - - - - - - - - - - - - - - - - - - - - - 4.3. THE CONFIG GROUP Most of the MIB objects in this group are self explanatory. The exceptions would be uchasFrontPanelLedStates, uchasFrontPanelLedColor and uchasNicStates. In general, these objects are bit maps. The current design handles up to 12 LEDs per card. Each LED's information is encoded in a nibble (4 bits), therefore each card takes up 6 bytes out of the octet string and 17 slots requires 102 bytes in the octet string. It is the responsibility of the management station to know how many LEDs each kind of card has on its front panel. The MIB does not identify how many of the 12 nibbles for each card carry useful information. Power supply LEDs are not included in this object. Their LED status is to be deduced by the PSU state (see power supply section below). In addition to LED state and color, a few of the bits in these objects were used for additional information. The bit definition for these three objects is shown below. uchasFrontPanelLedStates Each LED uses a nibble to indicate its current state. There are 12 nibbles (6 bytes) per card. The most significant nibble of the first byte is the first LED on the first card. The most significant nibble of the seventh byte is the first LED on the second card and so on. There is no indication in the MIB how many nibbles are valid for a given card. Let's assume we number the bits in a nibble as b3=MSB...b0=LSB. Of each nibble, the three least significant bits are defined as follows... b2 b1 b0

Subject: Re: (usr-tc) PM codes?
From: David Bolen <db3l@ans.net>
Date: 1998-12-29 18:03:38

x@asdf.com writes: > Does anyone know where I can find the codes for the Reason for Call > Failure option in Performance Monitor? Specifically, I get a value of 80 > and I can't figure out where to find out what 80 means ;-P For a non-TCM approach (sorry :-)), you can find basic enumeration labels in the MIB files (mdm.mib in this case) for your NMC release - both the disconnect reason (mdmCsDisconnectReason) object and call failure (mdmCsConnectFailReason) objects share a set of enumerations, with 80 being "remotHungUpDuringTraining". This information is also available in the online documentation for the NMC but depending on the date of your documentation it may or may not be completely up to date with the actual code you are running on your NMC. This was a new enumeration added, I believe, in the TCS 3.1 (V.90) code release, to help distinguish between a remote modem that hung up during the training sequence, versus the line being hung up at other times. Calls with this result would have typically returned the "ds0Teardown" result (enumeration 37) in prior releases. If you are just getting a value of 80 shown in TCM, you may not have the appropriate NMC data files installed for the release of code that you are running on your system. I do know that this enumeration was accidentally left out of early MIB releases with this system release, so you might want to check for the latest MIBs and/or data files and install them. I don't use TCM myself, so I suppose it's possible that while the MIBs got updated, the TCM data files didn't - perhaps someone else on the list can comment on that. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: Re: (usr-tc) Strange problem with assigned IP addresses on TC
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-12-29 21:59:06

Thus spake Bruno.Treguier@infini.fr >I'm new to this list, so I might be asking a "newbie question" (even >though I took the time to browse thru the entire archive seeking an >answer :-) ). Well...this hasn't been asked as a whole, but individual parts have been...maybe even all the individual parts. :) >but the given answer (using Framed-IP-Address in the user's >RADIUS entry), unfortunately, did not solve our problem... And the >comments in the HiperARC manual (appendix E, using RADIUS) even seems >to contradict the proposed solution: Framed-IP-Address is almost certainly what you want...I'll 'splain more below. >"Framed-IP-Address specifies the IP address that is assigned to the user >for the duration of the connection. If HiperARC is configured to use >assigned addresses, this field is not applicable." I'm not sure what this means, and we don't use HiPer Arc's yet, but I don't think you need to worry about this. >ippool 212.208.100.61/C 32 14 PUBLIC NO_AGGREGATE ACTIVE >Whenever a user with a "Framed-IP-Address" tries to log in, he gets >bumped. >Here is my entry in the RADIUS users file: >treguier Authentication-Type = UNIX-PW > Service-Type = Framed, > Framed-Protocol = PPP, > Framed-IP-Netmask = 255.255.255.0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Here's your problem I suspect...do you *really* want to give this user the whole /24? I don't think so since you have parts of it allocated elsewhere (the ippool for one). >line to my own entry, just below the "Framed-Protocol" line. The other >lines remain unchanged. I'm surprised you're not getting errors even without the Framed-IP-Address entry since you'd be trying to assign the whole /24 there too which is problematic at best....unless the HARC overrides that and assumes a /32 when assigning from the pool which seems fairly reasonable. >>At 23:29:07, Facility "IP", Level "CRITICAL":: ip_fwd_get_ opt(): Invalid Configuration, Address range overlap - IP address (212.208.100.142) >>At 23:29:07, Facility "PPP", Level "UNUSUAL":: ../../src/ppp_main.c: PPP Get Option Rejected, (bad status). >Where are those "overlapping addresses" in our configuration ? The IP address and netmask you've assigned to the user (which is the whole /24) overlaps with the ippool which is part of that same /24. Make the Netmask 255.255.255.255 and you'd almost certainly be fine. >The only remedy so far (apart from managing those particular users via the >internal HiperARC table, and not via RADIUS) has been for me to declare a >pool with only 1 address in it for each fixed IP address. I know, it's >an horrible hack. :-) Bleagh...that would really suck. >Is there a simpler solution ? Am I missing something ? Should I go to >bed ? Yes ? Oh, Ok then... ;-) Bed is always nice when you've been banging your head against a problem for quite some times...but there are some problems that just *have* to be fixed before you can go to bed. :) >Thanks for any info/pointer. Hope I've helped....hope I'm right. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) Strange problem with assigned IP addresses on TC
From: bruno.treguier@infini.fr
Date: 1998-12-30 02:20:49

Hello you all, I'm new to this list, so I might be asking a "newbie question" (even though I took the time to browse thru the entire archive seeking an answer :-) ). We just managed to get our TC rack up and (almost) running but we still seem to have a problem when using fixed IP addresses. I realize that this question has been tagged as a "newbie question" and is part the list's "mini FAQ", but the given answer (using Framed-IP-Address in the user's RADIUS entry), unfortunately, did not solve our problem... And the comments in the HiperARC manual (appendix E, using RADIUS) even seems to contradict the proposed solution: "Framed-IP-Address specifies the IP address that is assigned to the user for the duration of the connection. If HiperARC is configured to use assigned addresses, this field is not applicable." Using assigned addresses is mandatory for us, because if one uses "negociate", the client end has to have at least one valid address to propose. Otherwise, the connection is terminated. And on the other hand, when using RADIUS, one has no means to specify a per-user address selection scheme ! Our configuration: TC chassis with NMC, 8 QuadModem cards, HiperARC running 4.1.11 (I read that some recent versions DO have problems with fixed IPs), Dual E1/PRI. Users are authenticated via RADIUS. We're using the Merit 3.6B version. We've got one ip pool form 61 to 92: IP ADDRESS POOLS Name Address Size InUse State Route Status ippool 212.208.100.61/C 32 14 PUBLIC NO_AGGREGATE ACTIVE Whenever a user with a "Framed-IP-Address" tries to log in, he gets bumped. Here is my entry in the RADIUS users file: treguier Authentication-Type = UNIX-PW Service-Type = Framed, Framed-Protocol = PPP, Framed-IP-Netmask = 255.255.255.0 (to get the errors, I just added a Framed-IP-Address = 212.208.100.142, line to my own entry, just below the "Framed-Protocol" line. The other lines remain unchanged. Here are the errors we get in our log files: In the RADIUS accounting file (detail): >Wed Dec 30 00:29:08 1998 > User-Name = "treguier" > NAS-IP-Address = 212.208.100.10 > Acct-Status-Type = Stop > Acct-Session-Id = "4783" > Acct-Delay-Time = 0 > Acct-Authentic = RADIUS > Service-Type = Framed > NAS-Port-Type = Async > NAS-Port = 1 > USR-Modem-Training-Time = 13 > USR-Interface-Index = 2026 > USR-Chassis-Call-Slot = 4 > USR-Chassis-Call-Span = 1 > USR-Chassis-Call-Channel = 2 > USR-Unauthenticated-Time = 4 > Calling-Station-Id = "" > Called-Station-Id = "" > USR-Modulation-Type = x2 > USR-Simplified-MNP-Levels = ccittV42SREJ > USR-Simplified-V42bis-Usage = ccittV42bis > USR-Connect-Speed = 29333-BPS > Framed-Protocol = PPP > Framed-IP-Address = 0.0.0.0 > USR-MP-MRRU = 0 > Acct-Link-Count = 1 > Acct-Multi-Session-Id = "e08" > Acct-Session-Time = 4 > Acct-Terminate-Cause = NAS-Error > Acct-Input-Octets = 125 > Acct-Output-Octets = 280 > Acct-Input-Packets = 9 > Acct-Output-Packets = 11 The two interesting things here are the terminate cause (NAS-Error) and the IP address (0.0.0.0). :-( In the syslog logs, among other things, we've got these 2 lines: >At 23:29:07, Facility "IP", Level "CRITICAL":: ip_fwd_get_ opt(): Invalid Configuration, Address range overlap - IP address (212.208.100.142) >At 23:29:07, Facility "PPP", Level "UNUSUAL":: ../../src/ppp_main.c: PPP Get Option Rejected, (bad status). Where are those "overlapping addresses" in our configuration ? The only remedy so far (apart from managing those particular users via the internal HiperARC table, and not via RADIUS) has been for me to declare a pool with only 1 address in it for each fixed IP address. I know, it's an horrible hack. :-) Is there a simpler solution ? Am I missing something ? Should I go to bed ? Yes ? Oh, Ok then... ;-) Thanks for any info/pointer. Regards, Bruno -- Bruno TREGUIER <treguier@infini.fr> | " Il y a 3 sortes de personnes: FreeBSD 2.2.5, XFree86 3.3.1 | celles qui savent compter, Association INFINI, Brest, FRANCE | et celles qui ne savent pas..."

Subject: (usr-tc) Cannot dial out on Quad modem connected to E1/PRI
From: bruno.treguier@infini.fr
Date: 1998-12-30 02:32:50

Hello again, Another question: it seems impossible for us to dial out (even manually after having declared a dialout user, and typed in the AT commands on the Quad Modems...). We're connected to our TELCO via an E1/PRI card. Here is the configuration (ATI4): USRobotics Digital Quad Settings... Copyright, 1988-97, U.S. Robotics. All rights reserved. B0 C1 E0 F1 Q0 V0 X0 BAUD=38400 PARITY=N WORDLEN=8 DTE=GATEWAY NAC DIAL=TONE ON HOOK TIMER LINE=ISDN PRI &A0 &B1 &C1 &D2 &G2 &H1 &I0 &K1 &L0 &M4 &N0 &P1 &R2 &S0 &T4 &U0 &X0 &Y1 %N6 *U1=0 *U2=0 *U3=1 *V2=0 *X0=2048 *X1=2 S00=000 S01=000 S02=255 S03=013 S04=010 S05=008 S06=002 S07=060 S08=002 S09=006 S10=007 S11=070 S12=050 S13=000 S14=000 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=001 S28=008 S29=020 S30=000 S31=000 S32=009 S33=000 S34=000 S35=000 S36=000 S37=000 S38=000 S39=011 S40=000 S41=000 S42=126 S43=200 S44=015 S45=000 S46=255 S47=032 S48=000 S49=016 S50=100 S51=000 S52=005 S53=000 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 S70=000 S71=084 S72=001 S73=001 S74=000 S75=000 S76=000 S77=000 S78=000 S79=000 S80=000 S81=002 S82=012 ATI7 gives back: USRobotics Digital Quad Configuration Profile... Copyright, 1988-97, U.S. Robotics. All rights reserved. Product type International Rackmount Slot/Channel 2/1 Options HST,V32bis,Terbo,V.FC,V34+,x2,V90 ISDN Options V.110, V.120, SYNC, PPP, & X.75 Fax Options Class 1/Class 2.0 Clock Freq 20.16Mhz Flash Rom 512K Ram 384K Supervisor date 03/18/98 DSP date 03/18/98 Supervisor rev 5.9.9 DSP rev 5.9.9 Whenever we try to dial out, we invariably get a "NO DIAL TONE" answer (code 6)... I read in the Quad docs that on some versions, dialout was not possible. Is version 5.9.9 affected ? Thanks ! Bruno -- Bruno TREGUIER <treguier@infini.fr> | " Il y a 3 sortes de personnes: FreeBSD 2.2.5, XFree86 3.3.1 | celles qui savent compter, Association INFINI, Brest, FRANCE | et celles qui ne savent pas..."

Subject: Re: (usr-tc) Strange problem with assigned IP addresses on TC
From: K Mitchell <mitch@keyconn.net>
Date: 1998-12-30 07:58:44

At 09:59 PM 12/29/98 -0500, Jeff Mcadams wrote: [snip] >>Thanks for any info/pointer. > >Hope I've helped....hope I'm right. :) I'd also be interested in hearing if the summary/solution was correct and worked. Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

Subject: Re: (usr-tc) Strange problem with assigned IP addresses on TC
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-30 08:21:46

On Wed, 30 Dec 1998 Bruno.Treguier@infini.fr wrote: > Hello you all, > > I'm new to this list, so I might be asking a "newbie question" (even > though I took the time to browse thru the entire archive seeking an > answer :-) ). > > We just managed to get our TC rack up and (almost) running but we still > seem to have a problem when using fixed IP addresses. I realize that this > question has been tagged as a "newbie question" and is part the list's > "mini FAQ", but the given answer (using Framed-IP-Address in the user's > RADIUS entry), unfortunately, did not solve our problem... And the > comments in the HiperARC manual (appendix E, using RADIUS) even seems > to contradict the proposed solution: > > "Framed-IP-Address specifies the IP address that is assigned to the user > for the duration of the connection. If HiperARC is configured to use > assigned addresses, this field is not applicable." > > Using assigned addresses is mandatory for us, because if one uses > "negociate", the client end has to have at least one valid address to > propose. Otherwise, the connection is terminated. And on the other hand, > when using RADIUS, one has no means to specify a per-user address > selection scheme ! > > Our configuration: TC chassis with NMC, 8 QuadModem cards, HiperARC > running 4.1.11 (I read that some recent versions DO have problems with > fixed IPs), Dual E1/PRI. Users are authenticated via RADIUS. We're > using the Merit 3.6B version. > > We've got one ip pool form 61 to 92: > > IP ADDRESS POOLS > Name Address Size InUse State Route Status > ippool 212.208.100.61/C 32 14 PUBLIC NO_AGGREGATE ACTIVE > > Whenever a user with a "Framed-IP-Address" tries to log in, he gets > bumped. > > Here is my entry in the RADIUS users file: > > treguier Authentication-Type = UNIX-PW > Service-Type = Framed, > Framed-Protocol = PPP, > Framed-IP-Netmask = 255.255.255.0 > The user is getting bumbed because he is trying to use the netmask which is equal or lower then the ethernet. If you need to give the user a netmask give him a netmask greater than the ethernet or a 32 bit netmask. Meaning if your ethernet is say /24 give the user /25 or above if available else give the user /32 krish > > (to get the errors, I just added a > > Framed-IP-Address = 212.208.100.142, > > line to my own entry, just below the "Framed-Protocol" line. The other > lines remain unchanged. > > > Here are the errors we get in our log files: > > In the RADIUS accounting file (detail): > > >Wed Dec 30 00:29:08 1998 > > User-Name = "treguier" > > NAS-IP-Address = 212.208.100.10 > > Acct-Status-Type = Stop > > Acct-Session-Id = "4783" > > Acct-Delay-Time = 0 > > Acct-Authentic = RADIUS > > Service-Type = Framed > > NAS-Port-Type = Async > > NAS-Port = 1 > > USR-Modem-Training-Time = 13 > > USR-Interface-Index = 2026 > > USR-Chassis-Call-Slot = 4 > > USR-Chassis-Call-Span = 1 > > USR-Chassis-Call-Channel = 2 > > USR-Unauthenticated-Time = 4 > > Calling-Station-Id = "" > > Called-Station-Id = "" > > USR-Modulation-Type = x2 > > USR-Simplified-MNP-Levels = ccittV42SREJ > > USR-Simplified-V42bis-Usage = ccittV42bis > > USR-Connect-Speed = 29333-BPS > > Framed-Protocol = PPP > > Framed-IP-Address = 0.0.0.0 > > USR-MP-MRRU = 0 > > Acct-Link-Count = 1 > > Acct-Multi-Session-Id = "e08" > > Acct-Session-Time = 4 > > Acct-Terminate-Cause = NAS-Error > > Acct-Input-Octets = 125 > > Acct-Output-Octets = 280 > > Acct-Input-Packets = 9 > > Acct-Output-Packets = 11 > > The two interesting things here are the terminate cause (NAS-Error) and > the IP address (0.0.0.0). :-( > > In the syslog logs, among other things, we've got these 2 lines: > > >At 23:29:07, Facility "IP", Level "CRITICAL":: ip_fwd_get_ opt(): Invalid Configuration, Address range overlap - IP address (212.208.100.142) > >At 23:29:07, Facility "PPP", Level "UNUSUAL":: ../../src/ppp_main.c: PPP Get Option Rejected, (bad status). > > Where are those "overlapping addresses" in our configuration ? > > The only remedy so far (apart from managing those particular users via the > internal HiperARC table, and not via RADIUS) has been for me to declare a > pool with only 1 address in it for each fixed IP address. I know, it's > an horrible hack. :-) > > Is there a simpler solution ? Am I missing something ? Should I go to > bed ? Yes ? Oh, Ok then... ;-) > > Thanks for any info/pointer. > > Regards, > > Bruno > > -- > Bruno TREGUIER <treguier@infini.fr> | " Il y a 3 sortes de personnes: > FreeBSD 2.2.5, XFree86 3.3.1 | celles qui savent compter, > Association INFINI, Brest, FRANCE | et celles qui ne savent pas..." > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Compression
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-30 08:29:06

Show ppp on inter slot:x/mod:y Where slog:x/mod:y is the port where the user is connected to. 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 Dec 1998, Brian K McIntire wrote: > Is there a way to show what compression a user is using with the HiPer ARC > CLI? > I've tried to use sh session <user name>. It always reports none for > everybody. > 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. >

Subject: (usr-tc) Compression
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-30 08:48:48

Is there a way to show what compression a user is using with the HiPer ARC CLI? I've tried to use sh session <user name>. It always reports none for everybody. Thanks

Subject: Re: (usr-tc) Radius
From: Brian <signal@shreve.net>
Date: 1998-12-30 09:25:14

On Wed, 30 Dec 1998, Brian Gordon wrote: > I have 3 different Chassis running all Hiper Arc. Running all TOTAL > CONTROL/USR. > > What would you guys suggest as the best robust Radius software to run? > > Currently running Microsoft Radius w/option pack 4. > I would say Radiator http://www.open.com.au/radiator, good price, the best support I have seen from a software developer, unmatched feature set especially for hooking into 3Com Total Controls, and cross platform scalibility (will run on Nt, Unix, etc). Brian > Advice is appreciated. > > Brian Gordon, MCP > Network Administrator > Westelcom Internet > 518-566-8376 Voice > 518-566-8348 Fax > http://home.westelcom.com > administrator@westelcom.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. > 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

Subject: RE: (usr-tc) Cannot dial out on Quad modem connected to E1/PRI
From: MED, Wipro Systems, Inc <"nair, shibu (med, wipro systems, inc)">
Date: 1998-12-30 09:50:35

Hi You may try Telnet dialout service .... Create a network service for telnet dial out with a specific port. Telnet to ARC with the same port and login as the dialout user which u have created before. Now you supposed to get the modem access(You may have to type ATE1Q0V1 to see the OK prompt and mesg).Try dial out using "atdt" command... If u r trying to dial out from the console of modem card directly, all responses will go back to Access Router Card and hence you will not be able to get through.... (Before all these u have to confirm the E1 connectivity. For this you may try dialing out (atdt command) from the modem card console to a telephone number and confirm the ring on the telephone) Regards Shibu Hello again, Another question: it seems impossible for us to dial out (even manually after having declared a dialout user, and typed in the AT commands on the Quad Modems...). We're connected to our TELCO via an E1/PRI card. Here is the configuration (ATI4): USRobotics Digital Quad Settings... Copyright, 1988-97, U.S. Robotics. All rights reserved. B0 C1 E0 F1 Q0 V0 X0 BAUD=38400 PARITY=N WORDLEN=8 DTE=GATEWAY NAC DIAL=TONE ON HOOK TIMER LINE=ISDN PRI &A0 &B1 &C1 &D2 &G2 &H1 &I0 &K1 &L0 &M4 &N0 &P1 &R2 &S0 &T4 &U0 &X0 &Y1 %N6 *U1=0 *U2=0 *U3=1 *V2=0 *X0=2048 *X1=2 S00=000 S01=000 S02=255 S03=013 S04=010 S05=008 S06=002 S07=060 S08=002 S09=006 S10=007 S11=070 S12=050 S13=000 S14=000 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=001 S28=008 S29=020 S30=000 S31=000 S32=009 S33=000 S34=000 S35=000 S36=000 S37=000 S38=000 S39=011 S40=000 S41=000 S42=126 S43=200 S44=015 S45=000 S46=255 S47=032 S48=000 S49=016 S50=100 S51=000 S52=005 S53=000 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 S70=000 S71=084 S72=001 S73=001 S74=000 S75=000 S76=000 S77=000 S78=000 S79=000 S80=000 S81=002 S82=012 ATI7 gives back: USRobotics Digital Quad Configuration Profile... Copyright, 1988-97, U.S. Robotics. All rights reserved. Product type International Rackmount Slot/Channel 2/1 Options HST,V32bis,Terbo,V.FC,V34+,x2,V90 ISDN Options V.110, V.120, SYNC, PPP, & X.75 Fax Options Class 1/Class 2.0 Clock Freq 20.16Mhz Flash Rom 512K Ram 384K Supervisor date 03/18/98 DSP date 03/18/98 Supervisor rev 5.9.9 DSP rev 5.9.9 Whenever we try to dial out, we invariably get a "NO DIAL TONE" answer (code 6)... I read in the Quad docs that on some versions, dialout was not possible. Is version 5.9.9 affected ? Thanks ! Bruno -- Bruno TREGUIER <treguier@infini.fr> | " Il y a 3 sortes de personnes: FreeBSD 2.2.5, XFree86 3.3.1 | celles qui savent compter, Association INFINI, Brest, FRANCE | et celles qui ne savent pas..." - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) Radius
From: Brian Gordon <administrator@westelcom.com>
Date: 1998-12-30 10:18:19

I have 3 different Chassis running all Hiper Arc. Running all TOTAL CONTROL/USR. What would you guys suggest as the best robust Radius software to run? Currently running Microsoft Radius w/option pack 4. Advice is appreciated. Brian Gordon, MCP Network Administrator Westelcom Internet 518-566-8376 Voice 518-566-8348 Fax http://home.westelcom.com administrator@westelcom.com

Subject: Re: (usr-tc) Strange problem with assigned IP addresses on TC
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-12-30 10:38:47

Thus spake Bruno.Treguier@infini.fr >Ahem, in fact, yes... But efficiently egrep-ing about 22 megs isn't so >easy. :-) Heh...no doubt....believe me...I don't mind answering questions like yours. :) >Ok, I should have gone to bed even earlier, I think... ;-) Therefore I >could have RTFM better than I did... In fact I thought that Framed-IP-Netmask >was related to the netmask used on the LAN the TC rack was connected to >(class C for us). Quite a common error I guess... Nope...really the best way to think of it is that the PPP connection is its own network, so the LAN side of the TC rack doesn't affect what's going on in the PPP connection. >And unfortunately this is usually the case for sysadmins ! No doubt. Have a nice sleep. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) Jason Kelton/AU/3Com is out of the office.
From: K Mitchell <mitch@keyconn.net>
Date: 1998-12-30 10:43:15

Can this guy be temporarily removed from the list? We shouldn't have to put up with this for another 12 or so days. >From: Jason_Kelton@3com.com >X-Lotus-FromDomain: 3COM >To: K Mitchell <mitch@keyconn.net> >Date: Thu, 31 Dec 1998 01:00:46 +1000 >Subject: Jason Kelton/AU/3Com is out of the office. > >I will be out of the office from 12/24/98 until 01/11/99. > >I will respond to your message when I return. > > > > Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

Subject: (usr-tc) Any word on code release?
From: Chad J. LaFrenz <clafrenz@rof.net>
Date: 1998-12-30 11:30:56

Hi All-- I was wondering if there was any word on when a new code release is comin= g out for the Total Control (old style) with NetServer, NMC and Quads. We = are still experience a high number of disconnects and strange connection problems with v.90 and non-v.90 modems and was hoping that some new code stabilizing these problems would be coming out soon. Also, any websites or documents around that explain setting up the new Hy= per chassis? We got our first on and would like to study up on configuring o= ne before putting it into service. Any information would be greatly appreciated. Many thanks in advance. Regards, =A0 Chad J. LaFrenz Senior System Administrator RoFIntUG =A0 V: 970-945-4920=A0=A0=A0=A0=A0 F: 970-947-1923 =A0 Proudly serving the Aspen, Glenwood Springs, Rifle, and Vail Valleys. =A0 http://www.rof.net

Subject: Re: (usr-tc) HiperDSP 1.2.60 code
From: Curt Shambeau <curt@execpc.com>
Date: 1998-12-30 13:00:27

> Has anyone yet implemented the new revision (1.2.60) of the > HiperDSP code in a production environment? How does it seem to impact v.90 > performance? Good or bad experiences? I've been using 1.2.60 for quite some time, and it has been working fine. I don't really have anything good or bad to say about it, other than it fixed several bugs in 1.2.68 related to using a T3 mux. I have it flashed into around 80+ HDM's, and haven't had any more complaints than usual... <grin> | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Executive Vice President - Exec-PC, Inc. |

Subject: (usr-tc) 1.2.60 DSP code
From: Brian Biggs <bb@sonic.net>
Date: 1998-12-30 13:12:59

Hey, Can anyone get me a copy of this code? I just registered one of our DSP's online and they say it'll take them 48 hours (+ holiday = next week) to give me access to the code. -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 #

Subject: (usr-tc) HiperDSP 1.2.60 code
From: John Rockwell <jrockwel@clarityconnect.com>
Date: 1998-12-30 13:55:09

Has anyone yet implemented the new revision (1.2.60) of the HiperDSP code in a production environment? How does it seem to impact v.90 performance? Good or bad experiences? John Rockwell e-mail: jrockwel@clarityconnect.com Network Engineer Clarityconnect, Inc. Ithaca Area: (607)257-8268 Outside Ithaca Area: (888)322-4900 Try us: http://www.clarityconnect.com

Subject: RE: (usr-tc) HiperDSP 1.2.60 code
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-30 14:02:13

I've installed it on roughly 70-80 DSP's. Seems to improve a few things a bit. By no means does it resolve everything. There are still allot of issues out there relating to the client modems. On the other side of it I have seen no new problems come up so it seems like it's a stable release. Worth trying! >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of John Rockwell >Sent: Wednesday, December 30, 1998 12:55 PM >To: usr-tc@lists.xmission.com >Subject: (usr-tc) HiperDSP 1.2.60 code > > > > Has anyone yet implemented the new revision (1.2.60) of the >HiperDSP code in a production environment? How does it seem to impact v.90 >performance? Good or bad experiences? > >------------------------------------- >John Rockwell >e-mail: jrockwel@clarityconnect.com >Network Engineer >Clarityconnect, Inc. >Ithaca Area: (607)257-8268 >Outside Ithaca Area: (888)322-4900 >Try us: http://www.clarityconnect.com >------------------------------------- > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) HiperDSP 1.2.60 code
From: Dale Hege <fhege@sover.net>
Date: 1998-12-30 14:11:54

Has anyone else noticed that usr winmodems and gateway telepaths have lots of trouble connecting? -Dale On Wed, 30 Dec 1998, Brian K McIntire wrote: > Date: Wed, 30 Dec 1998 14:02:13 -0600 > From: Brian K McIntire <bmcintire@commnet.com> > Reply-To: usr-tc@lists.xmission.com > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) HiperDSP 1.2.60 code > > I've installed it on roughly 70-80 DSP's. Seems to improve a few things a > bit. By no means does it resolve everything. There are still allot of > issues out there relating to the client modems. On the other side of it I > have seen no new problems come up so it seems like it's a stable release. > Worth trying! > > >-----Original Message----- > >From: owner-usr-tc@lists.xmission.com > >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of John Rockwell > >Sent: Wednesday, December 30, 1998 12:55 PM > >To: usr-tc@lists.xmission.com > >Subject: (usr-tc) HiperDSP 1.2.60 code > > > > > > > > Has anyone yet implemented the new revision (1.2.60) of the > >HiperDSP code in a production environment? How does it seem to impact v.90 > >performance? Good or bad experiences? > > > >------------------------------------- > >John Rockwell > >e-mail: jrockwel@clarityconnect.com > >Network Engineer > >Clarityconnect, Inc. > >Ithaca Area: (607)257-8268 > >Outside Ithaca Area: (888)322-4900 > >Try us: http://www.clarityconnect.com > >------------------------------------- > > > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) HiperDSP 1.2.60 code
From: Brian <signal@shreve.net>
Date: 1998-12-30 14:13:02

On Wed, 30 Dec 1998, John Rockwell wrote: > > Has anyone yet implemented the new revision (1.2.60) of the > HiperDSP code in a production environment? How does it seem to impact v.90 > performance? Good or bad experiences? We are running it with no problems. I would say we have had fewer problems with it than its predecessors. Brian > > ------------------------------------- > John Rockwell > e-mail: jrockwel@clarityconnect.com > Network Engineer > Clarityconnect, Inc. > Ithaca Area: (607)257-8268 > Outside Ithaca Area: (888)322-4900 > Try us: http://www.clarityconnect.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. > 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

Subject: RE: (usr-tc) HiperDSP 1.2.60 code
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-30 14:21:01

>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Dale Hege >Sent: Wednesday, December 30, 1998 1:12 PM >To: usr-tc@lists.xmission.com >Subject: RE: (usr-tc) HiperDSP 1.2.60 code > > >Has anyone else noticed that usr winmodems and gateway telepaths have lots >of trouble connecting? All winmodems suck and the gateway telepaths are now being made in Korea. They bite. The original ones were based on a USR modem and work much better. > >-Dale > >On Wed, 30 Dec 1998, Brian K McIntire wrote: > >> Date: Wed, 30 Dec 1998 14:02:13 -0600 >> From: Brian K McIntire <bmcintire@commnet.com> >> Reply-To: usr-tc@lists.xmission.com >> To: usr-tc@lists.xmission.com >> Subject: RE: (usr-tc) HiperDSP 1.2.60 code >> >> I've installed it on roughly 70-80 DSP's. Seems to improve a >few things a >> bit. By no means does it resolve everything. There are still allot of >> issues out there relating to the client modems. On the other >side of it I >> have seen no new problems come up so it seems like it's a stable release. >> Worth trying! >> >> >-----Original Message----- >> >From: owner-usr-tc@lists.xmission.com >> >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of John Rockwell >> >Sent: Wednesday, December 30, 1998 12:55 PM >> >To: usr-tc@lists.xmission.com >> >Subject: (usr-tc) HiperDSP 1.2.60 code >> > >> > >> > >> > Has anyone yet implemented the new revision (1.2.60) of the >> >HiperDSP code in a production environment? How does it seem to >impact v.90 >> >performance? Good or bad experiences? >> > >> >------------------------------------- >> >John Rockwell >> >e-mail: jrockwel@clarityconnect.com >> >Network Engineer >> >Clarityconnect, Inc. >> >Ithaca Area: (607)257-8268 >> >Outside Ithaca Area: (888)322-4900 >> >Try us: http://www.clarityconnect.com >> >------------------------------------- >> > >> > >> > >> >- >> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> > with "unsubscribe usr-tc" in the body of the message. >> > For information on digests or retrieving files and old messages send >> > "help" to the same address. Do not use quotes in your message. >> > >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) 1.2.60 DSP code
From: Brian Biggs <bb@sonic.net>
Date: 1998-12-30 14:51:38

> On Wed, 30 Dec 1998, Brian K McIntire wrote: > Yes, use the online warranty deal at totalservice.com, and it will > instantly unlock the parts of the site you need access for. Hmm, but I am > wondering if what he meant was that he didn't have a totalservice login, > can you get a total service login instantly? Actually what I meant was: I registered my DSP through totalservice.usr.com (I do have a login), then the code showed that it was unlocked. When I tried to d/l it, an error message popped up saying it couldn't locate the file. I called USR tech support and was told that it takes 48 hours from the time you register a product 'till you get access to the files. The tech also told me that since it was a holiday (Friday), I probably would not be able to get the code until Monday. Anyway, someone on the list did send it to me and I now have the code. 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 #

Subject: Re: (usr-tc) Any word on code release?
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-12-30 15:04:23

What version of netserver and quad code are you using right now? 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 Wed, 30 Dec 1998, Chad J. LaFrenz wrote: > Hi All-- >=20 > I was wondering if there was any word on when a new code release is comin= g > out for the Total Control (old style) with NetServer, NMC and Quads. We = are > still experience a high number of disconnects and strange connection > problems with v.90 and non-v.90 modems and was hoping that some new code > stabilizing these problems would be coming out soon. >=20 > Also, any websites or documents around that explain setting up the new Hy= per > chassis? We got our first on and would like to study up on configuring o= ne > before putting it into service. >=20 > Any information would be greatly appreciated. >=20 > Many thanks in advance. >=20 > Regards, > =A0 > Chad J. LaFrenz > Senior System Administrator > RoFIntUG > =A0 > V: 970-945-4920=A0=A0=A0=A0=A0 F: 970-947-1923 > =A0 > Proudly serving the Aspen, Glenwood Springs, Rifle, and Vail Valleys. > =A0 > http://www.rof.net >=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

Subject: Re: (usr-tc) Strange problem with assigned IP addresses on TC
From: bruno.treguier@infini.fr
Date: 1998-12-30 15:29:55

Dans son message post� le 30/12/98 � 21:59, Jeff Mcadams �crivait: > Thus spake Bruno.Treguier@infini.fr > >I'm new to this list, so I might be asking a "newbie question" (even > >though I took the time to browse thru the entire archive seeking an > >answer :-) ). > > Well...this hasn't been asked as a whole, but individual parts have > been...maybe even all the individual parts. :) Ahem, in fact, yes... But efficiently egrep-ing about 22 megs isn't so easy. :-) > > Framed-IP-Netmask = 255.255.255.0 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Here's your problem I suspect...do you *really* want to give this user > the whole /24? I don't think so since you have parts of it allocated > elsewhere (the ippool for one). Ok, I should have gone to bed even earlier, I think... ;-) Therefore I could have RTFM better than I did... In fact I thought that Framed-IP-Netmask was related to the netmask used on the LAN the TC rack was connected to (class C for us). Quite a common error I guess... > I'm surprised you're not getting errors even without the > Framed-IP-Address entry since you'd be trying to assign the whole /24 We are getting other errors, but I dont't think they are related to this config problem, as we're still getting them after applying the correction... But that's another story. I promise I'll reread the manual carefully before asking about those. > Bed is always nice when you've been banging your head against a problem > for quite some times...but there are some problems that just *have* to > be fixed before you can go to bed. :) And unfortunately this is usually the case for sysadmins ! > Hope I've helped....hope I'm right. :) You solved it, thanks a lot ! I can go to bed now, and have a little rest before the last happy new year's eve party sysadmins will have (without the Big Bug inviting itself) ! :-) Happy New Year from France to you all USR/3COM victims ! ;-) Bruno -- Bruno TREGUIER <treguier@infini.fr> | " Il y a 3 sortes de personnes: FreeBSD 2.2.5, XFree86 3.3.1 | celles qui savent compter, Association INFINI, Brest, FRANCE | et celles qui ne savent pas..."

Subject: RE: (usr-tc) 1.2.60 DSP code
From: Brian <signal@shreve.net>
Date: 1998-12-30 15:32:04

On Wed, 30 Dec 1998, Brian K McIntire wrote: > >-----Original Message----- > >From: owner-usr-tc@lists.xmission.com > >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian Biggs > >Sent: Wednesday, December 30, 1998 3:13 PM > >To: usr-tc@lists.xmission.com > >Subject: (usr-tc) 1.2.60 DSP code > > > > > >Hey, > > Can anyone get me a copy of this code? I just registered one of our > >DSP's online and they say it'll take them 48 hours (+ holiday = next week) > >to give me access to the code. > > That sounds strange. Why don't you register a chassis that came with a > Hiper DSP. You should get instant access. Use the serial number next to > the power supply on the right hand side of the chassis Yes, use the online warranty deal at totalservice.com, and it will instantly unlock the parts of the site you need access for. Hmm, but I am wondering if what he meant was that he didn't have a totalservice login, can you get a total service login instantly? > > > > -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 # > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and 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

Subject: RE: (usr-tc) 1.2.60 DSP code
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-30 16:20:51

Subject: RE: (usr-tc) 1.2.60 DSP code
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-30 17:55:55

>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian Biggs >Sent: Wednesday, December 30, 1998 4:52 PM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) 1.2.60 DSP code > > >> On Wed, 30 Dec 1998, Brian K McIntire wrote: >> Yes, use the online warranty deal at totalservice.com, and it will >> instantly unlock the parts of the site you need access for. >Hmm, but I am >> wondering if what he meant was that he didn't have a totalservice login, >> can you get a total service login instantly? > >Actually what I meant was: I registered my DSP through totalservice.usr.com >(I do have a login), then the code showed that it was unlocked. >When I tried >to d/l it, an error message popped up saying it couldn't locate the file. I >called USR tech support and was told that it takes 48 hours from the time >you register a product 'till you get access to the files. The tech >also told >me that since it was a holiday (Friday), I probably would not be >able to get >the code until Monday. Try registering the whole chassis under your existing account. The tech that told you that was wrong. Under most circumstances the files can be unlocked immediately. > >Anyway, someone on the list did send it to me and I now have the code. >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 # - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) HiperDSP 1.2.60 code
From: Matthew Opoka <phantom@magnolia.net>
Date: 1998-12-30 19:48:01

YES YES YES Dale Hege wrote: > > Has anyone else noticed that usr winmodems and gateway telepaths have lots > of trouble connecting? > > -Dale > > On Wed, 30 Dec 1998, Brian K McIntire wrote: > > > Date: Wed, 30 Dec 1998 14:02:13 -0600 > > From: Brian K McIntire <bmcintire@commnet.com> > > Reply-To: usr-tc@lists.xmission.com > > To: usr-tc@lists.xmission.com > > Subject: RE: (usr-tc) HiperDSP 1.2.60 code > > > > I've installed it on roughly 70-80 DSP's. Seems to improve a few things a > > bit. By no means does it resolve everything. There are still allot of > > issues out there relating to the client modems. On the other side of it I > > have seen no new problems come up so it seems like it's a stable release. > > Worth trying! > > > > >-----Original Message----- > > >From: owner-usr-tc@lists.xmission.com > > >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of John Rockwell > > >Sent: Wednesday, December 30, 1998 12:55 PM > > >To: usr-tc@lists.xmission.com > > >Subject: (usr-tc) HiperDSP 1.2.60 code > > > > > > > > > > > > Has anyone yet implemented the new revision (1.2.60) of the > > >HiperDSP code in a production environment? How does it seem to impact v.90 > > >performance? Good or bad experiences? > > > > > >------------------------------------- > > >John Rockwell > > >e-mail: jrockwel@clarityconnect.com > > >Network Engineer > > >Clarityconnect, Inc. > > >Ithaca Area: (607)257-8268 > > >Outside Ithaca Area: (888)322-4900 > > >Try us: http://www.clarityconnect.com > > >------------------------------------- > > > > > > > > > > > >- > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) HiperDSP 1.2.60 code
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-12-30 21:15:53

This is a good a time as any to post the question I was going to post yesterday... We have had a lot of problems lately with Gateway Telepaths connecting without error correction. The users always have the error correction stuff checked on in the Modems control panel, and the modem type is correct (sometimes the "generic" ones turn error correction off). So far it seems that they're all USR Winmodem-based Telepaths (not the newer LT Winmodem ones)... most in areas that are known not to support v.90 (thanks to Bellsouth's SLC programming), so these are all 26400/v.34. It's not specific to Quad or DSP; it happens on both. I haven't yet tried fiddling with any settings yet; I've got two customers to call back tomorrow and I'll probably try things like turning v.42 off (leaving MNP 4 on) and see if that helps. We've seen a few LT Winmodem users have this problem too, but giving them new firmware has helped them all so far. Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ # view;touch;unzip;finger;mount;mv;mv;mv;yes;mv;yes;mv;yes;umount;sleep On Wed, 30 Dec 1998, Dale Hege wrote: > Has anyone else noticed that usr winmodems and gateway telepaths have lots > of trouble connecting?

Subject: (usr-tc) Winmodems/Telepaths: Maybe it's not us
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1998-12-30 22:15:58

Does anyone have any lab data that shows that USR/3Com WinModems and Gateway's Telepaths actually do v.34 and v.90 properly under real-world loads? Just because a giant company sells a modem doesn't mean it really works. It seems as if all ISPs -- regardless of the equipment they use -- have customers that have trouble with these modems. At this point, I'd be more interested to see some evidence that they *ever* work. : YES YES YES : : Dale Hege wrote: : > : > Has anyone else noticed that usr winmodems and gateway telepaths have lots : > of trouble connecting?

Subject: Re: (usr-tc) Winmodems/Telepaths: Maybe it's not us
From: pferraro@wna-linknet.com
Date: 1998-12-30 22:30:49

We too have problems with any WINModem... Just had a customer call today.. USR v.90 WinModem... Disconnects every 10 -15 minutes! Only gets 37,000 but DOES report v.90 Had him turn off software compression... Not sure how long it will stay connected, but more and more people are buying these MORE AFFORDABLE modems and WE suffer from the COMPLAINTS! Something needs to be done to "stretch" the parameters on the modems. THis is the 28.8 to 33.6 problems we had... Same thing until they "adjusted the code to be more "tolerant" of the noise! Just my .02 worth! ============================================================================== 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, 30 Dec 1998, Mark R. Lindsey wrote: > Does anyone have any lab data that shows that USR/3Com WinModems > and Gateway's Telepaths actually do v.34 and v.90 properly under > real-world loads? > > Just because a giant company sells a modem doesn't mean it really works. > It seems as if all ISPs -- regardless of the equipment they use -- > have customers that have trouble with these modems. At this point, > I'd be more interested to see some evidence that they *ever* work. > > : YES YES YES > : > : Dale Hege wrote: > : > > : > Has anyone else noticed that usr winmodems and gateway telepaths have lots > : > of trouble connecting? > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Remote managment of S&A
From: Yevgeniy Kruglov <shar@cifnet.com>
Date: 1998-12-30 22:34:11

On Wed, Dec 30, 1998 at 11:14:19PM -0500, Ricky wrote: > Can anyone post options for remotely managing a server running USR's Security and Accounting...such as being able to add a user, delete a user etc... Figure something like PC Anywhere for sure, but is that about the only option? If security is not an issue for Security server managing <g> try VNC, www.orl.co.uk, it's free and runs on almost every platform. If you are ready to spend *some* money, get Citrix or even make your 3Com sales rep happy by buying Edge Server Pro with Thin client/server :) Yevgeniy Kruglov, email: yk@cifnet.com System Administrator phone: (773)989-0442 CIFNet, Inc. fax: (773)989-8477

Subject: RE: (usr-tc) 1.2.60 DSP code
From: Laszlo Vecsey <master@internexus.net>
Date: 1998-12-30 23:04:44

On Wed, 30 Dec 1998, Brian K McIntire wrote: > >When I tried > >to d/l it, an error message popped up saying it couldn't locate the file. I > >called USR tech support and was told that it takes 48 hours from the time > >you register a product 'till you get access to the files. The tech > >also told > >me that since it was a holiday (Friday), I probably would not be > >able to get > >the code until Monday. > > Try registering the whole chassis under your existing account. The tech > that told you that was wrong. Under most circumstances the files can be > unlocked immediately. Could it be that what the tech said was another way of saying the accounts on the ftp server are delayed by 48 hours? Its worth a try anyway, ftp to totalservice.usr.com manually and try to log in with your totalservice login that works fine an the web. If you get through it should be straightforward to locate the directory with the code you need. - lv

Subject: (usr-tc) Remote managment of S&A
From: Ricky <rickyz@mindspring.com>
Date: 1998-12-30 23:14:19

Can anyone post options for remotely managing a server running USR's = Security and Accounting...such as being able to add a user, delete a = user etc... Figure something like PC Anywhere for sure, but is that = about the only option? Anyone? o o =20 \_ _/=20 <(@@)> ----------------000----()----000------------------- RickyZ@mindspring.com THE TRUTH IS OUT THERE 00O O00 =A9

Subject: Re: (usr-tc) Cannot dial out on Quad modem connected to E1/PRI
From: bruno.treguier@infini.fr
Date: 1998-12-30 23:15:28

> Hi Hi, > You may try Telnet dialout service .... I did... That's how I managed to get connected to my QuadModems in fact. > Create a network service for telnet dial out with a specific > port. Telnet to > ARC with the same port and login as the dialout user which u > have created before. > Now you supposed to get the modem access(You may have to type > ATE1Q0V1 to > see the OK prompt and mesg).Try dial out using "atdt" command... That's what I did, in fact. Here's what I obtain (whatever the number is): ATDT0298461234 NO DIAL TONE > (Before all these u have to confirm the E1 connectivity. For > this you may try dialing > out (atdt command) from the modem card console to a telephone > number and > confirm the ring on the telephone) Hmmm. I don't even reach that point... Excerpt from "Quad V34 modem card" release notes for version 3.0: "Modems support PRI in answer mode only. They cannot originate calls across PRI lines." Is this still true as of V 5.9.9 ? I guess not, as there are entire paragraphs about dialling out on PRI, and multiple PRIs are even supported... Thanks anyway ! Regards, Bruno -- Bruno TREGUIER <treguier@infini.fr> | " Il y a 3 sortes de personnes: FreeBSD 2.2.5, XFree86 3.3.1 | celles qui savent compter, Association INFINI, Brest, FRANCE | et celles qui ne savent pas..."

Subject: Re: (usr-tc) Remote managment of S&A
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-12-30 23:43:30

I'll second that -- VNC rules :) Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ # view;touch;unzip;finger;mount;mv;mv;mv;yes;mv;yes;mv;yes;umount;sleep On Wed, 30 Dec 1998, Yevgeniy Kruglov wrote: > On Wed, Dec 30, 1998 at 11:14:19PM -0500, Ricky wrote: > > > Can anyone post options for remotely managing a server running USR's Security and Accounting...such as being able to add a user, delete a user etc... Figure something like PC Anywhere for sure, but is that about the only option? > > If security is not an issue for Security server managing <g> try VNC, > www.orl.co.uk, it's free and runs on almost every platform. If you are > ready to spend *some* money, get Citrix or even make your 3Com sales rep > happy by buying Edge Server Pro with Thin client/server :) > > > 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. >

Subject: RE: (usr-tc) Remote managment of S&A
From: Ricky <rickyz@mindspring.com>
Date: 1998-12-31 06:45:39

------ =_NextPart_000_01BE3489.32F47CC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks. Big help. o o =20 \_ _/=20 <(@@)> ----------------000----()----000------------------- RickyZ@mindspring.com THE TRUTH IS OUT THERE 00O O00 =A9 -----Original Message----- Sent: Wednesday, December 30, 1998 11:34 PM On Wed, Dec 30, 1998 at 11:14:19PM -0500, Ricky wrote: > Can anyone post options for remotely managing a server running USR's = Security and Accounting...such as being able to add a user, delete a = user etc... Figure something like PC Anywhere for sure, but is that = about the only option? If security is not an issue for Security server managing <g> try VNC, www.orl.co.uk, it's free and runs on almost every platform. If you are ready to spend *some* money, get Citrix or even make your 3Com sales rep happy by buying Edge Server Pro with Thin client/server :)=20 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. ------ =_NextPart_000_01BE3489.32F47CC0 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IjALAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYA0AEAAAEAAAAQAAAAAwAAMAIAAAAL AA8OAAAAAAIB/w8BAAAAUQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHVzci10Y0BsaXN0cy54 bWlzc2lvbi5jb20AU01UUAB1c3ItdGNAbGlzdHMueG1pc3Npb24uY29tAAAAAB4AAjABAAAABQAA AFNNVFAAAAAAHgADMAEAAAAaAAAAdXNyLXRjQGxpc3RzLnhtaXNzaW9uLmNvbQAAAAMAFQwBAAAA AwD+DwYAAAAeAAEwAQAAABwAAAAndXNyLXRjQGxpc3RzLnhtaXNzaW9uLmNvbScAAgELMAEAAAAf AAAAU01UUDpVU1ItVENATElTVFMuWE1JU1NJT04uQ09NAAADAAA5AAAAAAsAQDoBAAAAHgD2XwEA AAAaAAAAdXNyLXRjQGxpc3RzLnhtaXNzaW9uLmNvbQAAAAIB918BAAAAUQAAAAAAAACBKx+kvqMQ GZ1uAN0BD1QCAAAAAHVzci10Y0BsaXN0cy54bWlzc2lvbi5jb20AU01UUAB1c3ItdGNAbGlzdHMu eG1pc3Npb24uY29tAAAAAAMA/V8BAAAAAwD/XwAAAAACAfYPAQAAAAQAAAAAAAAC+WgBBIABACUA AABSRTogKHVzci10YykgUmVtb3RlIG1hbmFnbWVudCBvZiBTJkEA0wsBBYADAA4AAADOBwwAHwAG AC0AJwAEAF4BASCAAwAOAAAAzgcMAB8ABgAsADUABABrAQEJgAEAIQAAADI5N0UyNDNFMTJBMEQy MTE4NDFFNDQ0NTUzNTQwMDAwALUGAQOQBgCcCAAAIQAAAAsAAgABAAAACwAjAAAAAAADACYAAAAA AAsAKQAAAAAAAwAuAAAAAAADADYAAAAAAEAAOQAAoL8WszS+AR4AcAABAAAAJQAAAFJFOiAodXNy LXRjKSBSZW1vdGUgbWFuYWdtZW50IG9mIFMmQQAAAAACAXEAAQAAABYAAAABvjSzFrc+JH4qoBIR 0oQeREVTVAAAAAAeAB4MAQAAAAUAAABTTVRQAAAAAB4AHwwBAAAABwAAAHJpY2t5egAAAwAGELnT 1nMDAAcQRAQAAB4ACBABAAAAZQAAAFRIQU5LU0JJR0hFTFBPTy88KEBAKS0tLS0tLS0tLS0tLS0t LS0wMDAtLS0tKCktLS0tMDAwLS0tLS0tLS0tLS0tLS0tLS0tLVJJQ0tZWkBNSU5EU1BSSU5HQ09N VEhFVFJVVEgAAAAAAgEJEAEAAAB/BQAAewUAAG4JAABMWkZ1RvBI2ncACgEDAfcgAqQD4wIAY4Jo CsBzZXQwIAcThwKDAFAO9nBycTIPX78CkhFxEN8PswXrAoMzAuOxEYlUYWgDcQKDNBLrTQ/2fQqA CMggOwlvMsQ1NRmKMTI4CiQZj7ccARihDGBjAFALA2MAQcELYG5nMTAzFYELxAMWgBGwbmtzLiBC AGlnIGhlbHAunwqiCoQKhB4SAtExIAMwfR4yYiIQIq8jJR4hGBBv/SMkbx4iJAUglSUUJn8j2cki EVxfIhBfLyIkIKMzJu8jyjwoCiAP4EBAGSJxKT4o6Ar0ZmktyDE0NAFAbGktUwzQxy1THjAVgGkg LS7tJXM6aQ/gMDBgLnkv5igpfzCfME4u/iXPIhMC0RgQUoBpY2t5WkBtC4BMZHMRQAuAZy4FoG0/ K3Ey0SCVIocylCHiVEiSRRaAUlU58CBJBfCmTzpQOeJSRTTnMzOvfzz/Pg80qR3mKf846zBCT8c6 sDBgNfYnYTk38iCkZxVxLHoXQjE2IPotoDN2NjhBA2B0BZAFQD5jTz0FEGcLgAdABdAHkHNh/Gdl PxtGlDhDCzFGlC0arjgwcS4VIoBGA2E6DIMxK4FZZXZIMAMAeSAQS3J1ZwkAdiBbQFNNVFA6cxGx QNpjBpBuD8A3sl04VwZgGwIwTDdXCYBOsHNkYdB5LCBEBZBlBtAEkAggMzBRIDE5OTgBUgAxOjM0 IFBNCThXVG9MN3Vzci1IdGNALaBzdB/QeDs3EAQQaQIgN7NPR3VixmpGwUw3UmU6MbBUJO4pVzEE YEawIAOBSCAHgMsCMCRwZgYAJkFIr0m690YkC7Ygo08DoFCRUSNRyN5hBUBSYS1QXiA5UsA78Jww NTBgUSA2oyB3RpJjTDAgqT4gQwORAHB58wIgWGBwb1SwJHAFMFVB3wQgAhAFwBxAWDJsTTBYg8s3 gV3AIA+wcnZRoU1ghm4DAGNxVVNSJwZCWmMIcXRNMABwZA/wY18FoGRAYeA3kWaAcx2gaL9dwAQg UZBjYwJgWGB0JID8YWRlwGOgVCAEkFEgAQDXZ7BYUWhUIA/AY2aBS+C3IBAIcFhgcwNwD8BoY2Jl LaBrWGBQQw/wYRB3PyBAamFiQmawHEBRIGJ1/wVABABn0BGwBUABoAhgBUBfatBYYAIgYuFhxD8g mknvWTAPsGU1bSFuRqBg8W0Rn2awbCRlF2PFYxc8Z2CghHRyTTBWTkMsIJQqd3RwLgWwbDexLnX+ a1EgZWBk4QNQCeBlk2Qx9wQgAiBdwGwEYGGRTNAEkO9NMAtRADAFsG0f4G/BYSD+dV3AHEAglBxA aBBNMGfh1zdQCfBlwCpqkipYcGExt1ERSDAFQENlYAUQeCRw/2mRY/ADoADAa1F4YVGxCFDebWOw B0AHkRxAcCCUEbCUcHBNMGJ+UXV5Y2LcRWRIMAZSY/JQA2BfcM9lYGbgH4ALgCBjLaBP0fovY8U6 V/AgngqATM5RIG+D/4TbUXALcGxXYHhQa79OeSCUBrBUsFFwD/BkNxG9VKFyXdAFsYjfiYhwFrCD TrCGMSg3NzMpUjCOOV6wLWAlpUNJRgfA8nRRIEluadCJj44PIhCYZmF4hjGK+Tg0iyD9gc8KNNVT YVQQAIBWUATy/1GQZ9JUJFEgD7BlsQORheNVZ9IiAMBqBbBkA3Bv2kBU+iIpJYATIpJqVCT+Im0Q A6BuAgbgeWFZIW4C/weBSBIghUvgBbELgHfSXdD7VUF2gmQgEAeQVMB7ohxA/3thTNBjYi0gfUJl ogbwZcDvmaUEIJPSKSUiIEKYUGfhf24CSBAHgGgCHEAEEIzxRMckgHCyaHEgcXVGoQQgL4CBfIOZ rBihAKPQAAMAEBAAAAAAAwAREAEAAAADAIAQ/////0AABzAgLR/7sjS+AUAACDAgLR/7sjS+AQsA JIAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwAlgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUA AAAAAAADACaACCAGAAAAAADAAAAAAAAARgAAAABShQAAtw0AAB4AJ4AIIAYAAAAAAMAAAAAAAABG AAAAAFSFAAABAAAABAAAADguMAADACiACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAAsAKYAI IAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAqgAggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAA AAADACuACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAB4ALIAIIAYAAAAAAMAAAAAAAABGAAAA ADaFAAABAAAAAQAAAAAAAAAeAC2ACCAGAAAAAADAAAAAAAAARgAAAAA3hQAAAQAAAAEAAAAAAAAA HgAugAggBgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEAAAABAAAAAAAAAB4APQABAAAABQAAAFJFOiAA AAAAAwANNP03AACLVA== ------ =_NextPart_000_01BE3489.32F47CC0--

Subject: (usr-tc) (USR-TC) ANY WORD ON CODE
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1998-12-31 10:26:00

Chad, We have too but in each and every case it has been Lucent based LT Winmodems with down revision code. We have them load 5.32 and life is good. We had one guy go from 5.23 to 5.32 and his cpnnect rates went from 36kbs to 50.6kbs solid... Jeff Binkley ASA Network Computing U>Hi All-- U>I was wondering if there was any word on when a new code release is U>comin= g U>out for the Total Control (old style) with NetServer, NMC and Quads. U>We = are U>still experience a high number of disconnects and strange connection U>problems with v.90 and non-v.90 modems and was hoping that some new U>code stabilizing these problems would be coming out soon. U>Also, any websites or documents around that explain setting up the new U>Hy= per U>chassis? We got our first on and would like to study up on U>configuring o= ne U>before putting it into service. U>Any information would be greatly appreciated. U>Many thanks in advance. U>Regards, U>=A0 U>Chad J. LaFrenz U>Senior System Administrator U>RoFIntUG CMPQwk 1.42 9999

Subject: (usr-tc) (USR-TC) REMOTE MANAGMENT
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1998-12-31 10:26:00

We run McAfee's remote desktop and it works fine for NT. We are in the process of writing a webpage with an ODBC backend to do this but time hasn't been aplenty right now. This too would be for an MSACCESS backend... Jeff Binkley ASA Network Computing U>Can anyone post options for remotely managing a server running USR's = U>Security and Accounting...such as being able to add a user, delete a = U>user etc... Figure something like PC Anywhere for sure, but is that = U>about the only option? U>Anyone? U> o o =20 U> \_ _/=20 U> <(@@)> U>----------------000----()----000------------------- U> RickyZ@mindspring.com U> THE TRUTH IS OUT THERE U>------------------------------------------------------ CMPQwk 1.42 9999

Subject: RE: (usr-tc) Remote managment of S&A
From: Clayton Zekelman <clayton@mnsi.net>
Date: 1998-12-31 10:40:16

You don't need Citrix - just get Windows NT Terminal Server Edition - alot cheaper than Citrix, and if you don't need load balancing and some of the other advanced features of Citirx, you can get away with it. At 06:45 AM 12/31/98 -0500, you wrote: >Thanks. Big help. > > o o =20 > \_ _/=20 > <(@@)> >----------------000----()----000------------------- > RickyZ@mindspring.com > THE TRUTH IS OUT THERE >------------------------------------------------------ > 00O O00 =A9 > > >-----Original Message----- >From: Yevgeniy Kruglov [SMTP:shar@cifnet.com] >Sent: Wednesday, December 30, 1998 11:34 PM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) Remote managment of S&A > >On Wed, Dec 30, 1998 at 11:14:19PM -0500, Ricky wrote: > >> Can anyone post options for remotely managing a server running USR's Security and Accounting...such as being able to add a user, delete a user etc... Figure something like PC Anywhere for sure, but is that about the only option? > >If security is not an issue for Security server managing <g> try VNC, >www.orl.co.uk, it's free and runs on almost every platform. If you are >ready to spend *some* money, get Citrix or even make your 3Com sales rep >happy by buying Edge Server Pro with Thin client/server :)=20 > > >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. >=20 --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 875 Ouellette Avenue Windsor, Ontario N9A 4J6 tel. 519-985-8410 fax. 519-258-3009

Subject: (usr-tc) sql backed snmp logger/report generator
From: Brian <signal@shreve.net>
Date: 1998-12-31 11:38:07

I am interested in a project and was wondering if anyone else is interested or has something like this. I am sure some of you have something like this which is in place and private, but I would be interested in making something public. It would basically log traps and query snmp stats from USR TC gear. Things like PRI card, hdm's, arc's, nmc's. It would plug all of the information into a free database, like postgresql (using a different database would be trivial, especially if this were done using DBI::DBD stuff in perl). Things like errors, and resets, and connect speeds etc could all be logged. The real power would come in its reporting. Where you could run a report of average connect speed per chassis, or per hdm, or per modem even. Have it "look" for problems for you, such as hi error ratios inconsistancies etc. I have alot of snmp tools, we all probably do, but I am looking for a centralized trapper and query system that just grabs it all, everything, and plugs it into a database. I would probably use perl/php/postgresql but I mean anything is possible. 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

Subject: (usr-tc)
From: Brian Gordon <administrator@westelcom.com>
Date: 1998-12-31 12:01:04

Anyone have any luck getting Wisecom 56k Accelerator Pro Voice Modems to work? With USR Total Control modems. Help Appreciated. Brian Gordon, MCP Network Administrator Westelcom Internet 518-566-8376 Voice 518-566-8348 Fax http://home.westelcom.com administrator@westelcom.com

Subject: (usr-tc) found a bug...not a biggie
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-12-31 12:13:09

Interesting one found....running 3.8.76 currently...had an MPIP server configured that wasn't running as an MPIP server (was testing out unix based MPIP server and it wasn't running at all...nothing listening on the port at all for it)...NETServer would take a few calls and then totally reboot! :/ Apparently, trying to access an MPIP server that wasn't there is rather catastrophic for the NETServer. I can understand having some problems with it...but rebooting? That needs to be fixed. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) Remote managment of S&A
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-12-31 15:05:49

>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Clayton Zekelman >Sent: Thursday, December 31, 1998 4:40 AM >To: usr-tc@lists.xmission.com >Subject: RE: (usr-tc) Remote managment of S&A > > >You don't need Citrix - just get Windows NT Terminal Server Edition - al= ot >cheaper than Citrix, and if you don't need load balancing and some of th= e >other advanced features of Citirx, you can get away with it. If you are going to do allot of it though I would recommend the investmen= t into metaframe > > >At 06:45 AM 12/31/98 -0500, you wrote: >>Thanks. Big help. >> >> o o >> \_ _/ >> <(@@)> >>----------------000----()----000------------------- >> RickyZ@mindspring.com >> THE TRUTH IS OUT THERE >>------------------------------------------------------ >> 00O O00 =A9 >> >> >>-----Original Message----- >>From: Yevgeniy Kruglov [SMTP:shar@cifnet.com] >>Sent: Wednesday, December 30, 1998 11:34 PM >>To: usr-tc@lists.xmission.com >>Subject: Re: (usr-tc) Remote managment of S&A >> >>On Wed, Dec 30, 1998 at 11:14:19PM -0500, Ricky wrote: >> >>> Can anyone post options for remotely managing a server running USR's >Security and Accounting...such as being able to add a user, delete a use= r >etc... Figure something like PC Anywhere for sure, but is that about the >only option? >> >>If security is not an issue for Security server managing <g> try VNC, >>www.orl.co.uk, it's free and runs on almost every platform. If you are >>ready to spend *some* money, get Citrix or even make your 3Com sales re= p >>happy by buying Edge Server Pro with Thin client/server :) >> >> >>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. >> >--- >Clayton Zekelman >Managed Network Systems Inc. (MNSi) >875 Ouellette Avenue >Windsor, Ontario >N9A 4J6 > >tel. 519-985-8410 >fax. 519-258-3009 > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Messages