October 1997

Subject: RE: (usr-tc) PRI & NMC problems
From: Colin_McFadyen <colinmcfadyen@pigeon.carleton.ca>
Date: 1997-10-02 14:10:21

I power-cycled the rack as a last resort. You mention checking the configuration from the console. What exactly should I be looking for? > Colin McFadyen > Carleton University CCS > 409 Robertson Hall > voice: 613-520-2600 ext. 3721 fax: 613-520-4448 > > > ---------- > From: Pete Ashdown[SMTP:pashdown@xmission.com] > Reply To: usr-tc@mail.xmission.com > Sent: Thursday, October 02, 1997 1:56 PM > To: usr-tc@mail.xmission.com > Subject: Re: (usr-tc) PRI & NMC problems > > Colin_McFadyen said once upon a time: > > >Bell finally installed my second PRI line. After connecting it and > >seeing that it was not passing calls, I checked the config using TCM > and > >saw it was configured as priSw5ESS. I changed it to priSwDMS100, > >clicked SET and OK. I had an operator reset the card early in the > >morning. When I checked the next day, I noticed that the PRI setting > >was still 5ESS. I connected up my laptop to the console port and set > it > >to DMS100, saved it to nvram and power-cycled the hub! Still no > good. > >PRI still show 5ESS. > > > >How do I change the PRI primary switch type to DMS100 and make it > stick? > > Try using TCM to save the NVRAM via "Actions". > > >To make matters worse, after power-cycling the hub, the NMC 10baseT > port > >has gone and died. I can't use TCM any more. > > Did you check the configuration from the console? You may have to do > it > again. > > Generally speaking, I never power cycle the entire hub. I either do a > hardware reset on the card in question via TCM, or pop it out and back > in. >

Subject: Re: (usr-tc) PRI & NMC problems
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1997-10-02 14:27:19

Thus spake Charles Hill >On Thu, 2 Oct 1997, Colin_McFadyen wrote: >> To make matters worse, after power-cycling the hub, the NMC 10baseT port >> has gone and died. I can't use TCM any more. >> Anyone got any ideas? >I use an old portmaster to securely reverse telnet to console ports >remotely. You can flip dip switch 6 on the netserver card and connect the >console ports to access the NMC console via the netserver RS-232 port. Wow, you mean we're not the only ones to come up with this solution? Cool! :) Actually, we haven't done that with our netservers (yet), but do it with some other systems. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) PRI & NMC problems
From: eric@dol.net
Date: 1997-10-02 20:58:02

At 01:37 PM 10/2/97 -0400, you wrote: >Hi all. > >Bell finally installed my second PRI line. After connecting it and >seeing that it was not passing calls, I checked the config using TCM and >saw it was configured as priSw5ESS. I changed it to priSwDMS100, >clicked SET and OK. I had an operator reset the card early in the >morning. When I checked the next day, I noticed that the PRI setting >was still 5ESS. I connected up my laptop to the console port and set it >to DMS100, saved it to nvram and power-cycled the hub! Still no good. >PRI still show 5ESS. > >How do I change the PRI primary switch type to DMS100 and make it stick? Sounds like you may have a bad chassis. I had some problems with modems not holding settings. Replacing the chassis solved the problems. eric > >To make matters worse, after power-cycling the hub, the NMC 10baseT port >has gone and died. I can't use TCM any more. > >Anyone got any ideas? > >Thanks. > > >> Colin McFadyen >> Carleton University CCS >> 409 Robertson Hall >> voice: 613-520-2600 ext. 3721 fax: 613-520-4448 >> > > Delaware Online!.........The SMART Choice! With 56K X2 Modems Phone : 302-762-0375 Fax: 302-762-3462 WWW: www.dol.net Eight out of five people have a problem understanding statistics! ****************Customer support is our bottom line!*********************

Subject: (usr-tc) isdn connections
From: eric@dol.net
Date: 1997-10-02 21:18:05

I have a customer with a zyxel prestige 128 u isdn router. When he connects to one usr box the connection is made no problem and shows up on the isdn sessions. That call is a toll call. When he connects to the local usr box the call shows up on the modem port when i do a show sess. What the heck is that. I have the isdn-gw slot identified as 16. I just updated all my boxes to the latest modem, pri, ns nmc code version 2.5.1 . We had to do some extra things to get all the chassis back on line that were not documented like changing the modems to hardware flow control and such. I only have two chassi out of 4 that are taking isdn calls even though all are fed with pris. Any suggestions? We also seem to be experiencing some new ppp negotiation failures on this chassis that is interpreting isdn as modem calls. All was fine till we upgraded to the new software. Any suggestions? Thanks Eric Delaware Online!.........The SMART Choice! With 56K X2 Modems Phone : 302-762-0375 Fax: 302-762-3462 WWW: www.dol.net Eight out of five people have a problem understanding statistics! ****************Customer support is our bottom line!*********************

Subject: Re: (usr-tc) isdn connections
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-10-02 21:23:39

Check your Pri Settings, Check to see your Reserved modem pool settings. See if your have configured this pool to accept both isdn and analog calls based on DNIS. Check the settings 6 and 8 in your option 3 from the pri console krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Fri, 3 Oct 1997, Brian Elfert wrote: > > > On Thu, 2 Oct 1997 eric@dol.net wrote: > > > I have a customer with a zyxel prestige 128 u isdn router. > > When he connects to one usr box the connection is made no problem and shows > > up on the isdn sessions. That call is a toll call. When he connects to > > the local usr box the call shows up on the modem port when i do a show sess. > > What the heck is that. I have the isdn-gw slot identified as 16. I just > > updated > > all my boxes to the latest modem, pri, ns nmc code version 2.5.1 . > > The latest modem code added a feature called Imodem. > > Basically, a modem DSP handles the ISDN call, rather than the Netserver > ISDN daughterboard. > > This is probably why you see an ISDN user on a modem. I believe there is > a way to turn this feature off, but I'm not sure how you do it. > > Brian > > >

Subject: Re: (usr-tc) isdn connections
From: Brian Elfert <brian@citilink.com>
Date: 1997-10-03 09:10:28

On Thu, 2 Oct 1997 eric@dol.net wrote: > I have a customer with a zyxel prestige 128 u isdn router. > When he connects to one usr box the connection is made no problem and shows > up on the isdn sessions. That call is a toll call. When he connects to > the local usr box the call shows up on the modem port when i do a show sess. > What the heck is that. I have the isdn-gw slot identified as 16. I just > updated > all my boxes to the latest modem, pri, ns nmc code version 2.5.1 . The latest modem code added a feature called Imodem. Basically, a modem DSP handles the ISDN call, rather than the Netserver ISDN daughterboard. This is probably why you see an ISDN user on a modem. I believe there is a way to turn this feature off, but I'm not sure how you do it. Brian

Subject: Re: (usr-tc) Confirmation Needed..
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-10-03 20:26:54

On Fri, 3 Oct 1997, John Campbell wrote: > I have a new installation on the USR Total Control package, and I think > that I have 3 bad QUAD Cards... The DUAL PRI Card only recongnizes the > cards in slot 2, 3 and 4, where as slots 5, 6, & 7 are shown as > unavailable. If I swap the cards from 234 to 567 and 567 to 123, then slots > 123 show unavailable and 567 work ok... To me, this would appear to have 3 > bad cards, and it has never been used before! Opinions please? Just check to see if the cards 123 are just plain analog cards. The PRI will recognize only Analog/Digital and Digital cards. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec > > 73's > John Campbell - KC4LWI > http://www.intrlink.com/~sparky > mailto:sparky@intrlink.com >

Subject: (usr-tc) Confirmation Needed..
From: John Campbell <sparky@intrlink.com>
Date: 1997-10-03 22:27:33

I have a new installation on the USR Total Control package, and I think that I have 3 bad QUAD Cards... The DUAL PRI Card only recongnizes the cards in slot 2, 3 and 4, where as slots 5, 6, & 7 are shown as unavailable. If I swap the cards from 234 to 567 and 567 to 123, then slots 123 show unavailable and 567 work ok... To me, this would appear to have 3 bad cards, and it has never been used before! Opinions please? 73's John Campbell - KC4LWI http://www.intrlink.com/~sparky mailto:sparky@intrlink.com

Subject: (usr-tc) Interpreting traps
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1997-10-04 10:31:33

Does anyone know of a way, under Unix, to receive traps and interpret them just a tad? I can't figure out how to make the snmptrapd do anything more than ``Enterprise specific trap (29)'' when I'd like it to say DTERingNoAns, and maybe even give an indication of the port having the problem. Much thanks. --- Mark R. Lindsey, mark@datasys.net Network Engineer, DSS Online Voice: +1 912 241 0607; Fax: +1 912 241 0190

Subject: (usr-tc) Another Radius Question
From: Billy X <charon@wizard.net>
Date: 1997-10-04 12:02:33

I am using Livingston Radius 2.0 on Linux and would like any tips on getting an idle timeout to work. It seems that an idle timeout can be set on each port on the TC unit, but I would like to do this on a per user basis using the Radius attributes. Also, the session timeout setting is not working. If anyone knows how to allow the settings to operate with the TC unit, that information would be much appreciated. Thanks. Scott Smith WizardNet

Subject: (usr-tc) TCP Maximum Segment Size
From: Brian <signal@shreve.net>
Date: 1997-10-04 13:33:52

Subject: (usr-tc) All Kinds of Setup Problems.
From: John Campbell <sparky@intrlink.com>
Date: 1997-10-04 16:04:48

I am having major problems in setting up my USR Total Control box. I am trying to get into the total control manager, and throught the local console (RS232) I have set the following: set sysname usrsvr0 set password xxxxxx set net0 address 209.54.158.8 set net0 netmask 255.255.255.0 set net0 broadcast high set net0 ipxnet 6A4 <This I am not sure about... I am running std ethernet 10 Mb 10Base2) set net0 ipxframe ethernet_ii save all reboot When the system comes back up, I cannot ping it on the network and when I run the TC Manager, it gives me "Device not responding" error. I am also having problems with 3 other cards in the sytem that I hope to reset through TC. I hope that I do not have to send this box back for repair... It still has not had a chance to answer the first call! 73's John Campbell - KC4LWI http://www.intrlink.com/~sparky mailto:sparky@intrlink.com

Subject: Re: (usr-tc) Another Radius Question
From: Laszlo Vecsey <master@internexus.net>
Date: 1997-10-04 17:57:46

On Sat, 4 Oct 1997, Billy X wrote: > I am using Livingston Radius 2.0 on Linux and would like any tips on getting > an idle timeout to work. It seems that an idle timeout can be set on each > port on the TC unit, but I would like to do this on a per user basis using > the Radius attributes. Also, the session timeout setting is not working. > If anyone knows how to allow the settings to operate with the TC unit, that > information would be much appreciated. > I've had success with using the following for pppuser: Session-Timeout = 86400, Idle-Timeout = 1080, Of course, check your dictionary file to make sure they are listed. The most common mistake is entering the values in minutes.. you must use seconds! For users that I allow to stay on 24/7, I set these to zero. - lv

Subject: Re: (usr-tc) All Kinds of Setup Problems.
From: Brian Elfert <brian@citilink.com>
Date: 1997-10-04 19:58:56

On Sat, 4 Oct 1997, John Campbell wrote: > I am having major problems in setting up my USR Total Control box. I am > trying to get into the total control manager, and throught the local > console (RS232) I have set the following: > > set sysname usrsvr0 > set password xxxxxx > set net0 address 209.54.158.8 > set net0 netmask 255.255.255.0 > set net0 broadcast high > set net0 ipxnet 6A4 <This I am not sure about... I am running std > ethernet 10 Mb 10Base2) > set net0 ipxframe ethernet_ii > save all > reboot > > When the system comes back up, I cannot ping it on the network and when I > run the TC Manager, it gives me "Device not responding" error. You've setup the Netserver, not the NMC card. Total Control Manager only interacts with the NMC card, and does not do anything with the Netserver. You need to hook your console to CH1 on the NMC card and set that up. Brian

Subject: Re: (usr-tc) All Kinds of Setup Problems.
From: Charles Hill <chill@ionet.net>
Date: 1997-10-04 20:24:53

On Sat, 4 Oct 1997, John Campbell wrote: > I am having major problems in setting up my USR Total Control box. I am > trying to get into the total control manager, and throught the local > console (RS232) I have set the following: > > set sysname usrsvr0 > set password xxxxxx > set net0 address 209.54.158.8 > set net0 netmask 255.255.255.0 > set net0 broadcast high > set net0 ipxnet 6A4 <This I am not sure about... I am running std > ethernet 10 Mb 10Base2) > set net0 ipxframe ethernet_ii > save all > reboot > > When the system comes back up, I cannot ping it on the network and when I > run the TC Manager, it gives me "Device not responding" error. You need to set a gateway in this netserver in order to ping it. You need to set yet another IP address, netmask, and gateway in your NMC for use with TCM. -CH

Subject: Re: (usr-tc) All Kinds of Setup Problems.
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-10-04 22:28:01

All you are missing is set gateway <ipaddress of the gateway > krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Sat, 4 Oct 1997, John Campbell wrote: > I am having major problems in setting up my USR Total Control box. I am > trying to get into the total control manager, and throught the local > console (RS232) I have set the following: > > set sysname usrsvr0 > set password xxxxxx > set net0 address 209.54.158.8 > set net0 netmask 255.255.255.0 > set net0 broadcast high > set net0 ipxnet 6A4 <This I am not sure about... I am running std > ethernet 10 Mb 10Base2) > set net0 ipxframe ethernet_ii > save all > reboot > > When the system comes back up, I cannot ping it on the network and when I > run the TC Manager, it gives me "Device not responding" error. > > I am also having problems with 3 other cards in the sytem that I hope to > reset through TC. I hope that I do not have to send this box back for > repair... It still has not had a chance to answer the first call! > > 73's > John Campbell - KC4LWI > http://www.intrlink.com/~sparky > mailto:sparky@intrlink.com >

Subject: Re: (usr-tc) Another Radius Question
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-10-04 22:30:54

Attribute 28 is Idle_Timeout If you have this in you dictionary then you can supply this value to every user. so a user setup will be like joe Password="joe" Idle_Timeout = 700 \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Sat, 4 Oct 1997, Billy X wrote: > I am using Livingston Radius 2.0 on Linux and would like any tips on getting > an idle timeout to work. It seems that an idle timeout can be set on each > port on the TC unit, but I would like to do this on a per user basis using > the Radius attributes. Also, the session timeout setting is not working. > If anyone knows how to allow the settings to operate with the TC unit, that > information would be much appreciated. > > > Thanks. > > Scott Smith > WizardNet > >

Subject: Re: (usr-tc) Another Radius Question
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-10-04 22:57:27

On Sun, 5 Oct 1997, Brad Wilson wrote: > > Session-Timeout = 86400, > > Idle-Timeout = 1080, > > We're using Livingston Radius 2.0, for both a USR TC rack and two PM2Es. > Which version of software (for each) is required to support this? Session-Timeout and Idle-timeout is supported by all version of radius. They are attributes 27 and 28. You can use your radius 2.0 and in this case. All you want to do is the check if these attributes are present in the dictionary file - If yes you are good, else include them and use them krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec > > -- > Brad Wilson KA8RJS bradw @ pobox.com http://www.thebrads.com > Objectivist, Software Engineer (Win32, STL, MFC, and sockets spoken here) > > >

Subject: Re: (usr-tc) Another Radius Question
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-10-05 03:10:13

On Sun, 5 Oct 1997, Brad Wilson wrote: > >Session-Timeout and Idle-timeout is supported by all version of radius. > >They are attributes 27 and 28. You can use your radius 2.0 and in this > >case. All you want to do is the check if these attributes are present in > >the dictionary file - If yes you are good, else include them and use them > > Actually, I was asking what versions of ComOS (PM2E) and USR NetServer > software (TC rack) were required. :-) USR NETServer version 3.0.x, The current version 3.5.34 does work with livingston, merit and other radius server. krish > > -- > Brad Wilson KA8RJS bradw @ pobox.com http://www.thebrads.com > Objectivist, Software Engineer (Win32, STL, MFC, and sockets spoken here) > > >

Subject: Re: (usr-tc) Another Radius Question
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-10-05 05:42:41

On Sun, 5 Oct 1997, Scott wrote: > Thanks for the information. However, I have checked to make sure that > theses two attributes are in the dictionary file, and they are, listed as > number 27 and 28 (see example included). > > ATTRIBUTE Session-Timeout 27 integer > ATTRIBUTE Idle-Timeout 28 integer > > I also have these attributes set for each user in the Radius users file. > Each setting is specified in units of seconds. Here is an example Radius > user entry in the users file (/etc/raddb/users). > > tulenko Password = "UNIX" > User-Service-Type = Framed-User, > Framed-Protocol = PPP, > Framed-Address = 255.255.255.254, > Framed-Netmask = 255.255.255.255, > Framed-Routing = None, > Framed-Compression = Van-Jacobsen-TCP-IP, > # Framed-Filter-Id = "std.ppp.in", > Framed-MTU = 1500, > Idle-Timeout = 1200, > Session-Timeout = 28800, > Port-Limit = 1 > > The Framed-Filter has been commented out because it was not working with > this attribute specified (will fix this later). However, I am confused > as to why the Timeouts are not working. They are present in this file and > in the dictionary file. If anyone would be willing to post an example > entry from Livingston Radius users file and dictionary file as I have done > above, maybe that would show any differences. Thanks in advance. Here is my take on this To make use of the filter std.ppp.in or just the Framed-Filter-Id attribute, create a filter on the NETServer and call it as std.ppp You can then use this statement in your users file. Idle time does work, if the user in your case is idle for 1200 min then he will be disconnected. Session timeout is basically used when the client and server are in the challege state - basically for access-accept or access challenge, In this configuration you are setting up the user access challenge/accept timeout to be 28800. This will work if you are setting the users in a challenge state, which I believe you are not doing. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec > > Scott Smith > WizardNet > > > On Sat, 4 Oct 1997, Laszlo Vecsey wrote: > > > On Sat, 4 Oct 1997, Billy X wrote: > > > > > I am using Livingston Radius 2.0 on Linux and would like any tips on getting > > > an idle timeout to work. It seems that an idle timeout can be set on each > > > port on the TC unit, but I would like to do this on a per user basis using > > > the Radius attributes. Also, the session timeout setting is not working. > > > If anyone knows how to allow the settings to operate with the TC unit, that > > > information would be much appreciated. > > > > > > > I've had success with using the following for pppuser: > > > > Session-Timeout = 86400, > > Idle-Timeout = 1080, > > > > Of course, check your dictionary file to make sure they are listed. The > > most common mistake is entering the values in minutes.. you must use > > seconds! For users that I allow to stay on 24/7, I set these to zero. > > > > - lv > > > > > >

Subject: Re: (usr-tc) Another Radius Question
From: Brad Wilson <bradw@thebrads.com>
Date: 1997-10-05 11:51:49

> Session-Timeout = 86400, > Idle-Timeout = 1080, We're using Livingston Radius 2.0, for both a USR TC rack and two PM2Es. Which version of software (for each) is required to support this? -- Brad Wilson KA8RJS bradw @ pobox.com http://www.thebrads.com Objectivist, Software Engineer (Win32, STL, MFC, and sockets spoken here)

Subject: (usr-tc) Connect speed
From: Brian <signal@shreve.net>
Date: 1997-10-05 13:38:18

Subject: Re: (usr-tc) All Kinds of Setup Problems.
From: eric@dol.net
Date: 1997-10-05 14:52:03

It may be that the ip address of the tc box is not from the same class c as the router. When this happens the box is unreachable unless there is some sort of route statement in the router that allow the two boxes to communicate. Eric At 10:28 PM 10/4/97 -0500, you wrote: >All you are missing is set gateway <ipaddress of the gateway > > > >krish > > >----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ >tkrishna@bubba.ae.usr.com >----------------------------/ http://interproc.ae.usr.com ----/ >-------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec >-------------------------------------------------------------------------/ > >On Sat, 4 Oct 1997, John Campbell wrote: > >> I am having major problems in setting up my USR Total Control box. I am >> trying to get into the total control manager, and throught the local >> console (RS232) I have set the following: >> >> set sysname usrsvr0 >> set password xxxxxx >> set net0 address 209.54.158.8 >> set net0 netmask 255.255.255.0 >> set net0 broadcast high >> set net0 ipxnet 6A4 <This I am not sure about... I am running std >> ethernet 10 Mb 10Base2) >> set net0 ipxframe ethernet_ii >> save all >> reboot >> >> When the system comes back up, I cannot ping it on the network and when I >> run the TC Manager, it gives me "Device not responding" error. >> >> I am also having problems with 3 other cards in the sytem that I hope to >> reset through TC. I hope that I do not have to send this box back for >> repair... It still has not had a chance to answer the first call! >> >> 73's >> John Campbell - KC4LWI >> http://www.intrlink.com/~sparky >> mailto:sparky@intrlink.com >> > > Delaware Online!.........The SMART Choice! With 56K X2 Modems Phone : 302-762-0375 Fax: 302-762-3462 WWW: www.dol.net Eight out of five people have a problem understanding statistics! ****************Customer support is our bottom line!*********************

Subject: Re: (usr-tc) Another Radius Question
From: Brad Wilson <bradw@thebrads.com>
Date: 1997-10-05 15:17:07

>Session-Timeout and Idle-timeout is supported by all version of radius. >They are attributes 27 and 28. You can use your radius 2.0 and in this >case. All you want to do is the check if these attributes are present in >the dictionary file - If yes you are good, else include them and use them Actually, I was asking what versions of ComOS (PM2E) and USR NetServer software (TC rack) were required. :-) -- Brad Wilson KA8RJS bradw @ pobox.com http://www.thebrads.com Objectivist, Software Engineer (Win32, STL, MFC, and sockets spoken here)

Subject: Re: (usr-tc) Another Radius Question
From: Scott <charon@wizard.net>
Date: 1997-10-05 18:26:33

Thanks for the information. However, I have checked to make sure that theses two attributes are in the dictionary file, and they are, listed as number 27 and 28 (see example included). ATTRIBUTE Session-Timeout 27 integer ATTRIBUTE Idle-Timeout 28 integer I also have these attributes set for each user in the Radius users file. Each setting is specified in units of seconds. Here is an example Radius user entry in the users file (/etc/raddb/users). tulenko Password = "UNIX" User-Service-Type = Framed-User, Framed-Protocol = PPP, Framed-Address = 255.255.255.254, Framed-Netmask = 255.255.255.255, Framed-Routing = None, Framed-Compression = Van-Jacobsen-TCP-IP, # Framed-Filter-Id = "std.ppp.in", Framed-MTU = 1500, Idle-Timeout = 1200, Session-Timeout = 28800, Port-Limit = 1 The Framed-Filter has been commented out because it was not working with this attribute specified (will fix this later). However, I am confused as to why the Timeouts are not working. They are present in this file and in the dictionary file. If anyone would be willing to post an example entry from Livingston Radius users file and dictionary file as I have done above, maybe that would show any differences. Thanks in advance. Scott Smith WizardNet On Sat, 4 Oct 1997, Laszlo Vecsey wrote: > On Sat, 4 Oct 1997, Billy X wrote: > > > I am using Livingston Radius 2.0 on Linux and would like any tips on getting > > an idle timeout to work. It seems that an idle timeout can be set on each > > port on the TC unit, but I would like to do this on a per user basis using > > the Radius attributes. Also, the session timeout setting is not working. > > If anyone knows how to allow the settings to operate with the TC unit, that > > information would be much appreciated. > > > > I've had success with using the following for pppuser: > > Session-Timeout = 86400, > Idle-Timeout = 1080, > > Of course, check your dictionary file to make sure they are listed. The > most common mistake is entering the values in minutes.. you must use > seconds! For users that I allow to stay on 24/7, I set these to zero. > > - lv > >

Subject: (usr-tc) usr-tc archives updated
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1997-10-05 19:07:22

I've updated the usr-tc archives at http://usr-tc.datasys.net/ through September. These are identical in content to the archives on XMission's FTP server, but webified and searchable by regular expression. --- Mark R. Lindsey, mark@datasys.net Network Engineer, DSS Online Voice: +1 912 241 0607; Fax: +1 912 241 0190

Subject: Re: (usr-tc) Connect speed
From: Mike Wronski <mwronski@coredump.ae.usr.com>
Date: 1997-10-05 20:42:50

On Sun, 5 Oct 1997, Brian wrote: > What variables on the modems in TCM affect modem connect speed the most > when using PRI's? > > Is Default DTE data rate even used? > Default DTE is only used if you are using rs-232 NIC's ..If your modems are on the packet bus this value has no real meaning.. -M `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' Mike Wronski(mwronski@coredump.ae.usr.com) 3Com/U.S. Robotics Network Systems Engineer PGP: http://coredump.ae.usr.com/pgp

Subject: Re: (usr-tc) Connect speed
From: Brian <signal@shreve.net>
Date: 1997-10-05 20:57:49

On Sun, 5 Oct 1997, Mike Wronski wrote: > On Sun, 5 Oct 1997, Brian wrote: > > > What variables on the modems in TCM affect modem connect speed the most > > when using PRI's? > > > > Is Default DTE data rate even used? > > > Default DTE is only used if you are using rs-232 NIC's ..If your modems > are on the packet bus this value has no real meaning.. > > -M Ok, so what variables set the speed of the modem when using the packet bus? Brian > > `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' > Mike Wronski(mwronski@coredump.ae.usr.com) 3Com/U.S. Robotics > Network Systems Engineer > PGP: http://coredump.ae.usr.com/pgp > > > > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: (usr-tc) bug/problem with nmc cards?
From: Brett Hawn <blh@texas.net>
Date: 1997-10-05 21:41:49

Whilst snmpwalking our nmc cards today we found a problem. When a TC rack has more than about 50% of its available modems in use the NMC cards stops responding to SNMP requests. Even TCM was screwing off and not getting there, I snooped the output and they just don't respond at all. Each of the NMC cards has 4mb DRAM and the unloaded tc racks would respond just fine, up until they got about 25+ calls. This smacks of either piss poor cpu performance (unlikely since it responded to ICMP if slowly (82ms pings? on local 10bT switched ethernet, thats ludicrous)) or a problem with USR's SNMP implementation. Anyone have any usable information on this? -- The UNIX Guru's View of Sex: # unzip ; strip ; touch ; finger ; mount ; fsck ; more ; yes ; umount ; sleep

Subject: Re: (usr-tc) bug/problem with nmc cards?
From: J. Nakamura <jnakamur@kiva.net>
Date: 1997-10-05 22:11:41

On Sun, 5 Oct 1997, Brett Hawn wrote: > Whilst snmpwalking our nmc cards today we found a problem. When a TC rack > has more than about 50% of its available modems in use the NMC cards stops > responding to SNMP requests. Even TCM was screwing off and not getting > there, I snooped the output and they just don't respond at all. Each of the > NMC cards has 4mb DRAM and the unloaded tc racks would respond just fine, up > until they got about 25+ calls. This smacks of either piss poor cpu > performance (unlikely since it responded to ICMP if slowly (82ms pings? on > local 10bT switched ethernet, thats ludicrous)) or a problem with USR's SNMP > implementation. Anyone have any usable information on this? We have racks with 15 A/D card hooked up to POTS lines and those work fine even if all of the ports are filled up. (60 calls) Is this happening with only one rack? Can one modem be screwing up the management bus when it gets a call and confusing the NMC card? Jay Nakamura --- Kiva Networking --- Local Phone (812) 337-5070 jnakamur@kiva.net Toll Free (800) 819-8143 Fax (812) 337-5082

Subject: Re: (usr-tc) Another Radius Question
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-10-05 23:05:37

On Mon, 6 Oct 1997, Billy X wrote: > Thanks for responding. I am not really concerned with the filter right now. > As far as I can tell I can get by without it. The idle timeout is not > working (although I suppose it should be). I understand that the idle > timeout should politely disconnect someone who has generated no network > activity for 20 minutes and that the session timeout will actually > disconnect someone after 28800 seconds (8 hours) regardless of the presence > of network activity. I wasn't aware that the session timeout had anything > to do with the challenge/accept negotiation. Anyways, neither of these > settings are working (I have had people online for 24 hours + and idle for 2 > or 3 hours). It has to be one of two things...something in Radius (an > attribute setting or similar) or something in the Total Control unit. I > cannot figure which. Any more thoughts? > Again Session time out is only in access/challenge so you will never get it working the way you are doing check the RFC 2138 for explanations on session-timeout 5.27. Session-Timeout Description This Attribute sets the maximum number of seconds of service to be provided to the user before termination of the session or prompt. This Attribute is available to be sent by the server to the client in an Access-Accept or Access-Challenge. A summary of the Session-Timeout Attribute format is shown below. The fields are transmitted from left to right. Now in order to see if idle time is working or not - set the users idletimeout to something like 200 - dial waith for 3 min idle and you will be droped out. krish > > Thanks. > Scott Smith > WizardNet > > > At 05:42 AM 10/5/97 -0500, you wrote: > >On Sun, 5 Oct 1997, Scott wrote: > > > >> Thanks for the information. However, I have checked to make sure that > >> theses two attributes are in the dictionary file, and they are, listed as > >> number 27 and 28 (see example included). > >> > >> ATTRIBUTE Session-Timeout 27 integer > >> ATTRIBUTE Idle-Timeout 28 integer > >> > >> I also have these attributes set for each user in the Radius users file. > >> Each setting is specified in units of seconds. Here is an example Radius > >> user entry in the users file (/etc/raddb/users). > >> > >> tulenko Password = "UNIX" > >> User-Service-Type = Framed-User, > >> Framed-Protocol = PPP, > >> Framed-Address = 255.255.255.254, > >> Framed-Netmask = 255.255.255.255, > >> Framed-Routing = None, > >> Framed-Compression = Van-Jacobsen-TCP-IP, > >> # Framed-Filter-Id = "std.ppp.in", > >> Framed-MTU = 1500, > >> Idle-Timeout = 1200, > >> Session-Timeout = 28800, > >> Port-Limit = 1 > >> > >> The Framed-Filter has been commented out because it was not working with > >> this attribute specified (will fix this later). However, I am confused > >> as to why the Timeouts are not working. They are present in this file and > >> in the dictionary file. If anyone would be willing to post an example > >> entry from Livingston Radius users file and dictionary file as I have done > >> above, maybe that would show any differences. Thanks in advance. > > > >Here is my take on this > > > >To make use of the filter std.ppp.in or just the Framed-Filter-Id > >attribute, create a filter on the NETServer and call it as std.ppp > >You can then use this statement in your users file. > > > >Idle time does work, if the user in your case is idle for 1200 min then > >he will be disconnected. > >Session timeout is basically used when the client and server are in the > >challege state - basically for access-accept or access challenge, In this > >configuration you are setting up the user access challenge/accept timeout > >to be 28800. This will work if you are setting the users in a challenge > >state, which I believe you are not doing. > > > >krish > > > >----------------------------------------- > > \ T.S.V. Krishnan \ > > \ Network System Engineer \ ( : - : ) > > \ 3Com ............ \ > > ----------------------------------------------/ > >tkrishna@bubba.ae.usr.com > >----------------------------/ http://interproc.ae.usr.com ----/ > >-------------------------------------------------------------------------\ > > Any Sufficiently advanced bug is indistinguishable for a feature. > > - Rick Kulawiec > >-------------------------------------------------------------------------/ > > > > > >> > >> Scott Smith > >> WizardNet > >> > >> > >> On Sat, 4 Oct 1997, Laszlo Vecsey wrote: > >> > >> > On Sat, 4 Oct 1997, Billy X wrote: > >> > > >> > > I am using Livingston Radius 2.0 on Linux and would like any tips on > getting > >> > > an idle timeout to work. It seems that an idle timeout can be set on > each > >> > > port on the TC unit, but I would like to do this on a per user basis > using > >> > > the Radius attributes. Also, the session timeout setting is not working. > >> > > If anyone knows how to allow the settings to operate with the TC > unit, that > >> > > information would be much appreciated. > >> > > > >> > > >> > I've had success with using the following for pppuser: > >> > > >> > Session-Timeout = 86400, > >> > Idle-Timeout = 1080, > >> > > >> > Of course, check your dictionary file to make sure they are listed. The > >> > most common mistake is entering the values in minutes.. you must use > >> > seconds! For users that I allow to stay on 24/7, I set these to zero. > >> > > >> > - lv > >> > > >> > > >> > >> > > > >

Subject: Re: (usr-tc) bug/problem with nmc cards?
From: Brett Hawn <blh@texas.net>
Date: 1997-10-06 08:01:07

On Sun, Oct 05, 1997 at 10:11:41PM -0500, J. Nakamura made some electrons appear in the following form: > On Sun, 5 Oct 1997, Brett Hawn wrote: > > > Whilst snmpwalking our nmc cards today we found a problem. When a TC rack > > has more than about 50% of its available modems in use the NMC cards stops > > responding to SNMP requests. Even TCM was screwing off and not getting > > there, I snooped the output and they just don't respond at all. Each of the > > NMC cards has 4mb DRAM and the unloaded tc racks would respond just fine, up > > until they got about 25+ calls. This smacks of either piss poor cpu > > performance (unlikely since it responded to ICMP if slowly (82ms pings? on > > local 10bT switched ethernet, thats ludicrous)) or a problem with USR's SNMP > > implementation. Anyone have any usable information on this? > > We have racks with 15 A/D card hooked up to POTS lines and those work fine > even if all of the ports are filled up. (60 calls) Is this happening > with only one rack? Can one modem be screwing up the management bus when > it gets a call and confusing the NMC card? Nope it appears to be happening on all of our TC racks once they start taking calls. The netserver cards respond just fine but the NMC cards... they're giving up the ghost. After last nights debacle I came in this morning and checked them. Less than 10 callers on a rack that wouldn't respond last night.. still won't respond. I have 0 doubts now that this is a memory leak in their SNMP implementation. I'm guessing we never noticed it before because we kept having to reboot the silly things. Now that they've got what appears to be a pretty rock solid firmware... the SNMP is borked. > > > Jay Nakamura --- Kiva Networking --- Local Phone (812) 337-5070 > jnakamur@kiva.net Toll Free (800) 819-8143 > Fax (812) 337-5082 > -- if I set my background color to ultravoilet will I get a tan?

Subject: Re: (usr-tc) bug/problem with nmc cards?
From: Michael Wronski <mwronski@coredump.ae.usr.com>
Date: 1997-10-06 08:55:34

At 09:41 PM 10/5/97 -0500, you wrote: >Whilst snmpwalking our nmc cards today we found a problem. When a TC rack >has more than about 50% of its available modems in use the NMC cards stops >responding to SNMP requests. Even TCM was screwing off and not getting >there, I snooped the output and they just don't respond at all. Each of the >NMC cards has 4mb DRAM and the unloaded tc racks would respond just fine, up >until they got about 25+ calls. This smacks of either piss poor cpu >performance (unlikely since it responded to ICMP if slowly (82ms pings? on >local 10bT switched ethernet, thats ludicrous)) or a problem with USR's SNMP >implementation. Anyone have any usable information on this? What software versions are you using?? -M `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' Mike Wronski(mwronski@coredump.ae.usr.com) 3Com/U.S.Robotics Network Systems Engineer (Level 3) PGP: http://coredump.ae.usr.com/pgp

Subject: Re: (usr-tc) bug/problem with nmc cards?
From: Brett Hawn <blh@texas.net>
Date: 1997-10-06 09:48:02

This fits EXACTLY with what we're seeing, one of our engineers was doing something akin to what you are/were and this caused them to stop responding entirely. A reboot of the NMC card fixes it but it shouldn't NEED to be rebooted. On Mon, Oct 06, 1997 at 10:25:33AM -0400, Mike Andrews made some electrons appear in the following form: > I haven't seen SNMP problems related to the number of calls, but I can > consistently kill my NMC card by asking it for too many SNMP variables at > once. > > When I was writing a CGI to pull all the connect speeds and line > statistics off the modems, I was using ucd-snmp's "snmpget" tool to poll > the rack. (The fact that I haven't rewritten this completely in Perl is > what's stopping me from releasing the code.) Doing one value at a time > was excruciatingly slow, so I tried to speed things up by bundling several > variables into one snmpget request, like so: > > snmpget -v 1 $NMCHOSTNAME $COMMUNITY .1.3.6.1.4.1.429.1.6.9.1.1.2.2001 \ > .1.3.6.1.4.1.429.1.6.9.1.1.2.2002 .1.3.6.1.4.1.429.1.6.9.1.1.2.2003 \ > .1.3.6.1.4.1.429.1.6.9.1.1.2.2004 .1.3.6.1.4.1.429.1.6.9.1.1.8.2001 \ > .1.3.6.1.4.1.429.1.6.9.1.1.8.2002 .1.3.6.1.4.1.429.1.6.9.1.1.8.2003 \ > .1.3.6.1.4.1.429.1.6.9.1.1.8.2004 .1.3.6.1.4.1.429.1.6.9.1.1.9.2001 \ > .1.3.6.1.4.1.429.1.6.9.1.1.9.2002 .1.3.6.1.4.1.429.1.6.9.1.1.9.2003 \ > .1.3.6.1.4.1.429.1.6.9.1.1.9.2004 > > ...which speeds things up a LOT, however, if you overdo it and put too > many requests on one command line, the card will croak and stop answering > SNMP requests. You can still ping the card, and use the serial port menu, > but SNMP is dead from there on out. The breaking point was around 25. > The only thing I could think of to revive it was to reboot the NMC card > via the serial port. > > snmpwalk wouldn't ever cause this lockup for me, so I don't know if we're > talking about the same problem. But there is something screwy with the > SNMP code in the NMC. This is on two PRI racks with all digital modems > and the latest released firmware in every card. > > > -- > Mike Andrews (MA12) "Oh my god, they killed Kenny!" > mandrews@dcr.net -- mandrews@termfrost.org -- http://www.termfrost.org/ > Senior Systems & Network Administrator, Digital Crescent, Frankfort, KY > Providing x2 Internet Access in Franklin, Anderson, and Shelby Counties > > On Mon, 6 Oct 1997, Brett Hawn wrote: > > > On Sun, Oct 05, 1997 at 10:11:41PM -0500, J. Nakamura made some electrons appear in the following form: > > > On Sun, 5 Oct 1997, Brett Hawn wrote: > > > > > > > Whilst snmpwalking our nmc cards today we found a problem. When a TC rack > > > > has more than about 50% of its available modems in use the NMC cards stops > > > > responding to SNMP requests. Even TCM was screwing off and not getting > > > > there, I snooped the output and they just don't respond at all. Each of the > > > > NMC cards has 4mb DRAM and the unloaded tc racks would respond just fine, up > > > > until they got about 25+ calls. This smacks of either piss poor cpu > > > > performance (unlikely since it responded to ICMP if slowly (82ms pings? on > > > > local 10bT switched ethernet, thats ludicrous)) or a problem with USR's SNMP > > > > implementation. Anyone have any usable information on this? > > > > > > We have racks with 15 A/D card hooked up to POTS lines and those work fine > > > even if all of the ports are filled up. (60 calls) Is this happening > > > with only one rack? Can one modem be screwing up the management bus when > > > it gets a call and confusing the NMC card? > > > > Nope it appears to be happening on all of our TC racks once they start > > taking calls. The netserver cards respond just fine but the NMC cards... > > they're giving up the ghost. After last nights debacle I came in this > > morning and checked them. Less than 10 callers on a rack that wouldn't > > respond last night.. still won't respond. I have 0 doubts now that this is a > > memory leak in their SNMP implementation. I'm guessing we never noticed it > > before because we kept having to reboot the silly things. Now that they've > > got what appears to be a pretty rock solid firmware... the SNMP is borked. > > > > > > > > > > > Jay Nakamura --- Kiva Networking --- Local Phone (812) 337-5070 > > > jnakamur@kiva.net Toll Free (800) 819-8143 > > > Fax (812) 337-5082 > > > > > > > -- > > if I set my background color to ultravoilet will I get a tan? > > > --

Subject: Re: (usr-tc) Another Radius Question
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-06 10:16:33

Billy X said once upon a time: >Thanks for responding. I am not really concerned with the filter right now. >As far as I can tell I can get by without it. The idle timeout is not >working (although I suppose it should be). I understand that the idle >timeout should politely disconnect someone who has generated no network >activity for 20 minutes and that the session timeout will actually >disconnect someone after 28800 seconds (8 hours) regardless of the presence >of network activity. I wasn't aware that the session timeout had anything >to do with the challenge/accept negotiation. Anyways, neither of these >settings are working (I have had people online for 24 hours + and idle for 2 >or 3 hours). It has to be one of two things...something in Radius (an >attribute setting or similar) or something in the Total Control unit. I >cannot figure which. Any more thoughts? You need to set this in RADIUS, otherwise what the TC uses is a random value. Keep in mind that the setting in RADIUS is in seconds, not minutes. I think it would be great if USR could make the idle filter configurable. I'm not sure exactly what constitutes activity in USR's mind, but I know what I consider activity.

Subject: Re: (usr-tc) bug/problem with nmc cards?
From: Mike Andrews <mandrews@termfrost.org>
Date: 1997-10-06 10:25:33

I haven't seen SNMP problems related to the number of calls, but I can consistently kill my NMC card by asking it for too many SNMP variables at once. When I was writing a CGI to pull all the connect speeds and line statistics off the modems, I was using ucd-snmp's "snmpget" tool to poll the rack. (The fact that I haven't rewritten this completely in Perl is what's stopping me from releasing the code.) Doing one value at a time was excruciatingly slow, so I tried to speed things up by bundling several variables into one snmpget request, like so: snmpget -v 1 $NMCHOSTNAME $COMMUNITY .1.3.6.1.4.1.429.1.6.9.1.1.2.2001 \ .1.3.6.1.4.1.429.1.6.9.1.1.2.2002 .1.3.6.1.4.1.429.1.6.9.1.1.2.2003 \ .1.3.6.1.4.1.429.1.6.9.1.1.2.2004 .1.3.6.1.4.1.429.1.6.9.1.1.8.2001 \ .1.3.6.1.4.1.429.1.6.9.1.1.8.2002 .1.3.6.1.4.1.429.1.6.9.1.1.8.2003 \ .1.3.6.1.4.1.429.1.6.9.1.1.8.2004 .1.3.6.1.4.1.429.1.6.9.1.1.9.2001 \ .1.3.6.1.4.1.429.1.6.9.1.1.9.2002 .1.3.6.1.4.1.429.1.6.9.1.1.9.2003 \ .1.3.6.1.4.1.429.1.6.9.1.1.9.2004 ...which speeds things up a LOT, however, if you overdo it and put too many requests on one command line, the card will croak and stop answering SNMP requests. You can still ping the card, and use the serial port menu, but SNMP is dead from there on out. The breaking point was around 25. The only thing I could think of to revive it was to reboot the NMC card via the serial port. snmpwalk wouldn't ever cause this lockup for me, so I don't know if we're talking about the same problem. But there is something screwy with the SNMP code in the NMC. This is on two PRI racks with all digital modems and the latest released firmware in every card. -- Mike Andrews (MA12) "Oh my god, they killed Kenny!" mandrews@dcr.net -- mandrews@termfrost.org -- http://www.termfrost.org/ Senior Systems & Network Administrator, Digital Crescent, Frankfort, KY Providing x2 Internet Access in Franklin, Anderson, and Shelby Counties On Mon, 6 Oct 1997, Brett Hawn wrote: > On Sun, Oct 05, 1997 at 10:11:41PM -0500, J. Nakamura made some electrons appear in the following form: > > On Sun, 5 Oct 1997, Brett Hawn wrote: > > > > > Whilst snmpwalking our nmc cards today we found a problem. When a TC rack > > > has more than about 50% of its available modems in use the NMC cards stops > > > responding to SNMP requests. Even TCM was screwing off and not getting > > > there, I snooped the output and they just don't respond at all. Each of the > > > NMC cards has 4mb DRAM and the unloaded tc racks would respond just fine, up > > > until they got about 25+ calls. This smacks of either piss poor cpu > > > performance (unlikely since it responded to ICMP if slowly (82ms pings? on > > > local 10bT switched ethernet, thats ludicrous)) or a problem with USR's SNMP > > > implementation. Anyone have any usable information on this? > > > > We have racks with 15 A/D card hooked up to POTS lines and those work fine > > even if all of the ports are filled up. (60 calls) Is this happening > > with only one rack? Can one modem be screwing up the management bus when > > it gets a call and confusing the NMC card? > > Nope it appears to be happening on all of our TC racks once they start > taking calls. The netserver cards respond just fine but the NMC cards... > they're giving up the ghost. After last nights debacle I came in this > morning and checked them. Less than 10 callers on a rack that wouldn't > respond last night.. still won't respond. I have 0 doubts now that this is a > memory leak in their SNMP implementation. I'm guessing we never noticed it > before because we kept having to reboot the silly things. Now that they've > got what appears to be a pretty rock solid firmware... the SNMP is borked. > > > > > > > Jay Nakamura --- Kiva Networking --- Local Phone (812) 337-5070 > > jnakamur@kiva.net Toll Free (800) 819-8143 > > Fax (812) 337-5082 > > > > -- > if I set my background color to ultravoilet will I get a tan? >

Subject: Re: (usr-tc) bug/problem with nmc cards?
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-06 10:34:25

Brett Hawn said once upon a time: > >Whilst snmpwalking our nmc cards today we found a problem. When a TC rack >has more than about 50% of its available modems in use the NMC cards stops >responding to SNMP requests. Even TCM was screwing off and not getting >there, I snooped the output and they just don't respond at all. Each of the >NMC cards has 4mb DRAM and the unloaded tc racks would respond just fine, up >until they got about 25+ calls. This smacks of either piss poor cpu >performance (unlikely since it responded to ICMP if slowly (82ms pings? on >local 10bT switched ethernet, thats ludicrous)) or a problem with USR's SNMP >implementation. Anyone have any usable information on this? I repeatedly have my racks full and TCM responds just fine. Are you using the latest software version?

Subject: Re: (usr-tc) Another Radius Question
From: Michael Wronski <mwronski@coredump.ae.usr.com>
Date: 1997-10-06 10:48:01

At 11:04 AM 10/6/97 -0400, you wrote: >Thanks for responding. I am not really concerned with the filter right now. >As far as I can tell I can get by without it. The idle timeout is not >working (although I suppose it should be). I understand that the idle >timeout should politely disconnect someone who has generated no network >activity for 20 minutes and that the session timeout will actually >disconnect someone after 28800 seconds (8 hours) regardless of the presence >of network activity. I wasn't aware that the session timeout had anything >to do with the challenge/accept negotiation. Anyways, neither of these >settings are working (I have had people online for 24 hours + and idle for 2 >or 3 hours). It has to be one of two things...something in Radius (an >attribute setting or similar) or something in the Total Control unit. I >cannot figure which. Any more thoughts? > > What version of NS code are you using? -M `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' Mike Wronski(mwronski@coredump.ae.usr.com) 3Com/U.S.Robotics Network Systems Engineer (Level 3) PGP: http://coredump.ae.usr.com/pgp

Subject: Re: (usr-tc) Another Radius Question
From: Billy X <charon@wizard.net>
Date: 1997-10-06 11:04:59

Thanks for responding. I am not really concerned with the filter right now. As far as I can tell I can get by without it. The idle timeout is not working (although I suppose it should be). I understand that the idle timeout should politely disconnect someone who has generated no network activity for 20 minutes and that the session timeout will actually disconnect someone after 28800 seconds (8 hours) regardless of the presence of network activity. I wasn't aware that the session timeout had anything to do with the challenge/accept negotiation. Anyways, neither of these settings are working (I have had people online for 24 hours + and idle for 2 or 3 hours). It has to be one of two things...something in Radius (an attribute setting or similar) or something in the Total Control unit. I cannot figure which. Any more thoughts? Thanks. Scott Smith WizardNet At 05:42 AM 10/5/97 -0500, you wrote: >On Sun, 5 Oct 1997, Scott wrote: > >> Thanks for the information. However, I have checked to make sure that >> theses two attributes are in the dictionary file, and they are, listed as >> number 27 and 28 (see example included). >> >> ATTRIBUTE Session-Timeout 27 integer >> ATTRIBUTE Idle-Timeout 28 integer >> >> I also have these attributes set for each user in the Radius users file. >> Each setting is specified in units of seconds. Here is an example Radius >> user entry in the users file (/etc/raddb/users). >> >> tulenko Password = "UNIX" >> User-Service-Type = Framed-User, >> Framed-Protocol = PPP, >> Framed-Address = 255.255.255.254, >> Framed-Netmask = 255.255.255.255, >> Framed-Routing = None, >> Framed-Compression = Van-Jacobsen-TCP-IP, >> # Framed-Filter-Id = "std.ppp.in", >> Framed-MTU = 1500, >> Idle-Timeout = 1200, >> Session-Timeout = 28800, >> Port-Limit = 1 >> >> The Framed-Filter has been commented out because it was not working with >> this attribute specified (will fix this later). However, I am confused >> as to why the Timeouts are not working. They are present in this file and >> in the dictionary file. If anyone would be willing to post an example >> entry from Livingston Radius users file and dictionary file as I have done >> above, maybe that would show any differences. Thanks in advance. > >Here is my take on this > >To make use of the filter std.ppp.in or just the Framed-Filter-Id >attribute, create a filter on the NETServer and call it as std.ppp >You can then use this statement in your users file. > >Idle time does work, if the user in your case is idle for 1200 min then >he will be disconnected. >Session timeout is basically used when the client and server are in the >challege state - basically for access-accept or access challenge, In this >configuration you are setting up the user access challenge/accept timeout >to be 28800. This will work if you are setting the users in a challenge >state, which I believe you are not doing. > >krish > >----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ >tkrishna@bubba.ae.usr.com >----------------------------/ http://interproc.ae.usr.com ----/ >-------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec >-------------------------------------------------------------------------/ > > >> >> Scott Smith >> WizardNet >> >> >> On Sat, 4 Oct 1997, Laszlo Vecsey wrote: >> >> > On Sat, 4 Oct 1997, Billy X wrote: >> > >> > > I am using Livingston Radius 2.0 on Linux and would like any tips on getting >> > > an idle timeout to work. It seems that an idle timeout can be set on each >> > > port on the TC unit, but I would like to do this on a per user basis using >> > > the Radius attributes. Also, the session timeout setting is not working. >> > > If anyone knows how to allow the settings to operate with the TC unit, that >> > > information would be much appreciated. >> > > >> > >> > I've had success with using the following for pppuser: >> > >> > Session-Timeout = 86400, >> > Idle-Timeout = 1080, >> > >> > Of course, check your dictionary file to make sure they are listed. The >> > most common mistake is entering the values in minutes.. you must use >> > seconds! For users that I allow to stay on 24/7, I set these to zero. >> > >> > - lv >> > >> > >> >> >

Subject: Re: (usr-tc) Another Radius Question
From: Jay Nakamura <jnakamur@kiva.net>
Date: 1997-10-06 11:37:41

I believe, and I could be wrong, livingston RADIUS will stop reading the reply items when it hits the comment line. Instead of putting a comment on the filter line, try taking it completely out and test it. At 06:26 PM 10/5/97 -0400, you wrote: >Thanks for the information. However, I have checked to make sure that >theses two attributes are in the dictionary file, and they are, listed as >number 27 and 28 (see example included). > >ATTRIBUTE Session-Timeout 27 integer >ATTRIBUTE Idle-Timeout 28 integer > >I also have these attributes set for each user in the Radius users file. >Each setting is specified in units of seconds. Here is an example Radius >user entry in the users file (/etc/raddb/users). > >tulenko Password = "UNIX" > User-Service-Type = Framed-User, > Framed-Protocol = PPP, > Framed-Address = 255.255.255.254, > Framed-Netmask = 255.255.255.255, > Framed-Routing = None, > Framed-Compression = Van-Jacobsen-TCP-IP, ># Framed-Filter-Id = "std.ppp.in", > Framed-MTU = 1500, > Idle-Timeout = 1200, > Session-Timeout = 28800, > Port-Limit = 1 > >The Framed-Filter has been commented out because it was not working with >this attribute specified (will fix this later). However, I am confused >as to why the Timeouts are not working. They are present in this file and >in the dictionary file. If anyone would be willing to post an example >entry from Livingston Radius users file and dictionary file as I have done >above, maybe that would show any differences. Thanks in advance. > >Scott Smith >WizardNet > > >On Sat, 4 Oct 1997, Laszlo Vecsey wrote: > >> On Sat, 4 Oct 1997, Billy X wrote: >> >> > I am using Livingston Radius 2.0 on Linux and would like any tips on getting >> > an idle timeout to work. It seems that an idle timeout can be set on each >> > port on the TC unit, but I would like to do this on a per user basis using >> > the Radius attributes. Also, the session timeout setting is not working. >> > If anyone knows how to allow the settings to operate with the TC unit, that >> > information would be much appreciated. >> > >> >> I've had success with using the following for pppuser: >> >> Session-Timeout = 86400, >> Idle-Timeout = 1080, >> >> Of course, check your dictionary file to make sure they are listed. The >> most common mistake is entering the values in minutes.. you must use >> seconds! For users that I allow to stay on 24/7, I set these to zero. >> >> - lv >> >> > > > J.S. Nakamura -- Kiva Networking -- Phone (812)337-5070 -- Fax (812)337-5082 jnakamur@kiva.net

Subject: Re: (usr-tc) bug/problem with nmc cards?
From: Brett Hawn <blh@texas.net>
Date: 1997-10-06 13:24:08

Straight from TCM: Hardware Revision: 4.0 Software Revision: 3.4.9 Software Compatibility Version: 4.3.5 On Mon, Oct 06, 1997 at 10:34:25AM -0600, Pete Ashdown made some electrons appear in the following form: > Brett Hawn said once upon a time: > > > >Whilst snmpwalking our nmc cards today we found a problem. When a TC rack > >has more than about 50% of its available modems in use the NMC cards stops > >responding to SNMP requests. Even TCM was screwing off and not getting > >there, I snooped the output and they just don't respond at all. Each of the > >NMC cards has 4mb DRAM and the unloaded tc racks would respond just fine, up > >until they got about 25+ calls. This smacks of either piss poor cpu > >performance (unlikely since it responded to ICMP if slowly (82ms pings? on > >local 10bT switched ethernet, thats ludicrous)) or a problem with USR's SNMP > >implementation. Anyone have any usable information on this? > > I repeatedly have my racks full and TCM responds just fine. Are you using > the latest software version? -- and the Number 1 Sign You've Hired the Wrong Clown for Your Child's Party... All the balloon animals are ribbed and lubricated.

Subject: Re: (usr-tc) bug/problem with nmc cards?
From: David Bolen <db3l@ans.net>
Date: 1997-10-06 14:36:37

Mike Andrews <mandrews@termfrost.org> writes: > ...which speeds things up a LOT, however, if you overdo it and put too > many requests on one command line, the card will croak and stop answering > SNMP requests. You can still ping the card, and use the serial port menu, > but SNMP is dead from there on out. The breaking point was around 25. > The only thing I could think of to revive it was to reboot the NMC card > via the serial port. This sounds like an older bug that perhaps has gotten reintroduced in recent versions. If you try to stick too many variables into a request, then although your request PDU can fit within the MTU of the ethernet, the NMC's response (since it has to have both the variable ids as well as values) exceeds that MTU and freezes things up for the SNMP task on the NMC. Technically, you should be able to fragment a PDU up to a maximum UDP size of around 8K, but I don't believe the NMC handles fragmented requests properly, so you need to stick within your ethernet MTU of around 1500 bytes. What's supposed to happen in such a case is that the NMC should return an SNMP error of "toobig". I had originally reported the problem as part of NMC 3.1.1 back in 1/96, and I think it got fixed in the later 3.x releases but maybe it broke again in the 4.x series. In terms of working around it, you can certainly add multiple variables into a single PDU (we do it all the time and we do a _LOT_ of SNMP queries of the NMCs under very heavily loaded conditions), but just stick to a reasonably small number to keep a safety margin on the return packet. So if you're computing how many to put in a PDU, remember to leave room for the variable value in the response, and don't just count based on your query which only needs the OIDs. -- 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) High weirdness
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-06 17:47:37

I just had three Netservers located next to each other (IP wise) lock up within 30 minutes. One of them was running on the swapped out ethernet cards I got from USR. I threw in a filter in my Cisco to keep outside people from doing anything to the Netservers, but got no hits. The whole thing smells though. Has anyone heard of any security advisories?

Subject: Re: (usr-tc) Problems
From: eric@dol.net
Date: 1997-10-06 18:16:52

I think it must be a solar flare. We had some of the same problems this weekend reported by customers. We seem to be fine right now. A friend with one tc system had to reflash his entire chassis on Sunday and then everything was fine but he experienced custoemrs not connecting and failing with the famous dun error. eric At 06:39 PM 10/6/97 -0500, you wrote: >All of the sudden, since Friday, we have had alot of users call and say >they are having problems connecting. It drops them after a few minutes. > >Some users said there dialup networking says "Cannot negotiate compatible >protocols", Others get wierd numeric errors. > >Are any of you seeing any of this? I am thinking MSIE 4.0 hosed there >systems, but havent ruled out my end of the link just yet. > >Brian > > >/-------------------------- signal@shreve.net -----------------------------\ >| Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | >| Systems Administrator | Perl, Linux | Web hosting, online stores, | >| ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | >| 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | >| headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | >\-------------------------- 318-222-2638 x109 -----------------------------/ > > > > Delaware Online!.........The SMART Choice! With 56K X2 Modems Phone : 302-762-0375 Fax: 302-762-3462 WWW: www.dol.net Eight out of five people have a problem understanding statistics! ****************Customer support is our bottom line!*********************

Subject: (usr-tc) Problems
From: Brian <signal@shreve.net>
Date: 1997-10-06 18:39:09

All of the sudden, since Friday, we have had alot of users call and say they are having problems connecting. It drops them after a few minutes. Some users said there dialup networking says "Cannot negotiate compatible protocols", Others get wierd numeric errors. Are any of you seeing any of this? I am thinking MSIE 4.0 hosed there systems, but havent ruled out my end of the link just yet. Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: Re: (usr-tc) Problems
From: Brian <signal@shreve.net>
Date: 1997-10-06 19:25:09

On Mon, 6 Oct 1997 eric@dol.net wrote: > I think it must be a solar flare. We had some of the same problems this > weekend reported by customers. We seem to be fine right now. A friend with > one tc system had to reflash his entire chassis on Sunday and then > everything was fine but he experienced custoemrs not connecting and failing > with the famous dun error. > eric > Anyone else see these problems, or just us? Brian > > At 06:39 PM 10/6/97 -0500, you wrote: > >All of the sudden, since Friday, we have had alot of users call and say > >they are having problems connecting. It drops them after a few minutes. > > > >Some users said there dialup networking says "Cannot negotiate compatible > >protocols", Others get wierd numeric errors. > > > >Are any of you seeing any of this? I am thinking MSIE 4.0 hosed there > >systems, but havent ruled out my end of the link just yet. > > > >Brian > > > > > >/-------------------------- signal@shreve.net -----------------------------\ > >| Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > >| Systems Administrator | Perl, Linux | Web hosting, online stores, | > >| ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > >| 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | > >| headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | > >\-------------------------- 318-222-2638 x109 -----------------------------/ > > > > > > > > > Delaware Online!.........The SMART Choice! With 56K X2 Modems > Phone : 302-762-0375 Fax: 302-762-3462 WWW: www.dol.net > Eight out of five people have a problem understanding statistics! > ****************Customer support is our bottom line!********************* > > > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: (usr-tc) errors
From: Brian <signal@shreve.net>
Date: 1997-10-06 19:35:30

These are the types of errors I am seeing: Hi Brian, My connections were better, however I did receive the same error once today. It says "Error 731: error protocol not configured" then it tells me to edit my dial up connection. If I try again it says "disconnected by server" But I shut down my sytem and was then able to log on. Robbie Sepulvado rsepul@shreve.net Anyone know what this could be........ /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: Re: (usr-tc) Problems
From: Philip Kippen <kippen1@smartlink.net>
Date: 1997-10-06 19:57:16

Hey Brian, We are seeing the same type of stuff going on here but with a few variations. We have found several strange problems in not only the modem code but also the PRI code. What you might want to try is to re-flash your modems however, flash them 4 at a time instead of flashing half or even the whole chassis. You might also try to make sure you take a working group of modems (either 1 or the whole 4) and copy the config to the others a few at a time. This has eleviated the problems so far in about 3 of our 10 chassis. The other seven haven't shown any problems as of yet (knock on wood !!). Take care. phil

Subject: Re: (usr-tc) Problems
From: Philip Kippen <kippen1@smartlink.net>
Date: 1997-10-06 19:57:16

Subject: Re: (usr-tc) Problems
From: Philip Kippen <kippen1@smartlink.net>
Date: 1997-10-06 20:42:35

Brian, No Particular rational for flashing only 4 at a time however, at times the code can corrupt itself when uploading several modems at once. Just a usefull little trick I learned through fine tuning a few chassis. Take care

Subject: Re: (usr-tc) 24port modem cards
From: Philip Kippen <kippen1@smartlink.net>
Date: 1997-10-06 20:48:48

Be carefull with those HD modems. Wait until they fine tune the code a bit. Also, look into the USR Trade Up / Trade In program. You can buy some old 14.4 modems and 48 ports of (approx 1 and 1/2) ancient Portmaster from a garage sale for around $5,000 and trade that in for a new loaded Chassis for free when you buy one. Great deal. For $5,000.00 extra you will get a new totally loaded chassis. Take care Phil

Subject: Re: (usr-tc) Problems
From: Brian <signal@shreve.net>
Date: 1997-10-06 22:19:08

On Mon, 6 Oct 1997, Philip Kippen wrote: > Hey Brian, > We are seeing the same type of stuff going on here but with a few > variations. We have found several strange problems in not only the modem > code but also the PRI code. What you might want to try is to re-flash your > modems however, flash them 4 at a time instead of flashing half or even the > whole chassis. You might also try to make sure you take a working group of > modems (either 1 or the whole 4) and copy the config to the others a few at > a time. This has eleviated the problems so far in about 3 of our 10 > chassis. The other seven haven't shown any problems as of yet (knock on > wood !!). Take care. > phil What do you suppose causes this? I see configurations in the modems change over time. I have had usr software corrupt over time also. What is your rational for flashing 4 modems at a time? I think I am going to do a re-flash, and upgrade to the new modem code while I am at it. Here is a question for you all, what do you all normally change in a fresh modem config. That is from the factory default? We do: packet bus answer only enable priTdm > > ---------- > > From: Brian <signal@shreve.net> > > To: usr-tc@mail.xmission.com > > Subject: Re: (usr-tc) Problems > > Date: Monday, October 06, 1997 5:25 PM > > > > On Mon, 6 Oct 1997 eric@dol.net wrote: > > > > > I think it must be a solar flare. We had some of the same problems > this > > > weekend reported by customers. We seem to be fine right now. A friend > with > > > one tc system had to reflash his entire chassis on Sunday and then > > > everything was fine but he experienced custoemrs not connecting and > failing > > > with the famous dun error. > > > eric > > > > > > > > > > > > > > > Anyone else see these problems, or just us? > > > > Brian > > > > > > > > > > > > > > > > > > > > At 06:39 PM 10/6/97 -0500, you wrote: > > > >All of the sudden, since Friday, we have had alot of users call and > say > > > >they are having problems connecting. It drops them after a few > minutes. > > > > > > > >Some users said there dialup networking says "Cannot negotiate > compatible > > > >protocols", Others get wierd numeric errors. > > > > > > > >Are any of you seeing any of this? I am thinking MSIE 4.0 hosed there > > > >systems, but havent ruled out my end of the link just yet. > > > > > > > >Brian > > > > > > > > > > > >/-------------------------- signal@shreve.net > -----------------------------\ > > > >| Brian Feeny | USR TC Hubs | ShreveNet Inc. > (318)222-2638 | > > > >| Systems Administrator | Perl, Linux | Web hosting, online > stores, | > > > >| ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & > LANs | > > > >| 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ > | > > > >| headers, Eurosport exhaust |LordSignal/SN| Quake server: > 208.206.76.3 | > > > >\-------------------------- 318-222-2638 x109 > -----------------------------/ > > > > > > > > > > > > > > > > > > > Delaware Online!.........The SMART Choice! With 56K X2 Modems > > > Phone : 302-762-0375 Fax: 302-762-3462 WWW: www.dol.net > > > > Eight out of five people have a problem understanding statistics! > > > ****************Customer support is our bottom > line!********************* > > > > > > > > > > > > > /-------------------------- signal@shreve.net > -----------------------------\ > > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 > | > > | Systems Administrator | Perl, Linux | Web hosting, online stores, > | > > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & > LANs | > > | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ > | > > | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 > | > > \-------------------------- 318-222-2638 x109 > -----------------------------/ > > > > > > > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: (usr-tc) 24port modem cards
From: Brian <signal@shreve.net>
Date: 1997-10-06 22:26:35

Subject: Re: (usr-tc) 24port modem cards
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-07 01:03:42

Brian said once upon a time: >Any word on a release date for the new 24port modem cards? Its about time >to purchase another hub, and I would sure rather purchase some of the >24port modem cards instead. The latest word is October 10th. I'm biting my nails.

Subject: Re: (usr-tc) 24port modem cards
From: John Campbell <sparky@intrlink.com>
Date: 1997-10-07 07:16:21

I talked to my Distributor yesterday, and still no word... I have been asking the same questions. I have to talk to USR today, I will be sure to ask and let you know here what they are saying! At 10:26 PM 10/6/97 -0500, you wrote: > >Any word on a release date for the new 24port modem cards? Its about time >to purchase another hub, and I would sure rather purchase some of the >24port modem cards instead. > >Brian > > >/-------------------------- signal@shreve.net -----------------------------\ >| Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | >| Systems Administrator | Perl, Linux | Web hosting, online stores, | >| ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | >| 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | >| headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | >\-------------------------- 318-222-2638 x109 -----------------------------/ > > > > 73's John Campbell - KC4LWI http://www.intrlink.com/~sparky mailto:sparky@intrlink.com

Subject: (usr-tc) 24-port cards
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1997-10-07 07:49:13

Do you all really want to put your customers through USR's first try at anything? The 24-port cards sound really neat, but, given that they've been through dozens of revisions of their firmware for the netservers and modems and T1 cards, and given that this is all new code, and given that ISP customers are often among the most fickle customers there are, I'm not sure it's such a good idea to be USR's guinea pig, IMHO. (I'm sure they'll work it all out in short order, but I'm planning to let somebody else suffer through the betas.) --- Mark R. Lindsey, mark@datasys.net Network Engineer, DSS Online Voice: +1 912 241 0607; Fax: +1 912 241 0190

Subject: RE: (usr-tc) Problems
From: Tom Bilan <tom@tdi.net>
Date: 1997-10-07 08:19:00

Cannot negotiate... etc. This message is generated when you have "Use DHCP for WINS resolution" checked in the TCP/IP settings. Use Disable WINS instead. Tom On Monday, October 06, 1997 7:39 PM, Brian [SMTP:signal@shreve.net] wrote: > All of the sudden, since Friday, we have had alot of users call and say > they are having problems connecting. It drops them after a few minutes. > > Some users said there dialup networking says "Cannot negotiate compatible > protocols", Others get wierd numeric errors. > > Are any of you seeing any of this? I am thinking MSIE 4.0 hosed there > systems, but havent ruled out my end of the link just yet. > > Brian > > > /-------------------------- signal@shreve.net -----------------------------\ > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > | Systems Administrator | Perl, Linux | Web hosting, online stores, | > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | > | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | > \-------------------------- 318-222-2638 x109 -----------------------------/ > >

Subject: Re: (usr-tc) Problems
From: pris sears <sears@vt.edu>
Date: 1997-10-07 08:44:19

>On Mon, 6 Oct 1997 eric@dol.net wrote: > >> I think it must be a solar flare. We had some of the same problems this >> weekend reported by customers. We seem to be fine right now. A friend with >> one tc system had to reflash his entire chassis on Sunday and then >> everything was fine but he experienced custoemrs not connecting and failing >> with the famous dun error. >> eric >> > >Anyone else see these problems, or just us? > >Brian > I got specific complaints about lower than usual connect speeds and unexpected drops over the weekend. (We're in Virginia). Seems to be ok now...Solar flares, huh? __________________________________________________________ Pris Sears | sears@vt.edu | http://sears.cns.vt.edu/ | 231-2305

Subject: Re: (usr-tc) Problems
From: David Crabtree <wolfcub@wsnet.com>
Date: 1997-10-07 08:54:30

So we were not the only ones. Our TC also spontanously had problems this weekend, a quick reboot fixed it though. I am wondering if last weekend had any special meaning and if other TC owners found themselves with a problem over the weekend. On Mon, 6 Oct 1997 eric@dol.net wrote: > I think it must be a solar flare. We had some of the same problems this > weekend reported by customers. We seem to be fine right now. A friend with > one tc system had to reflash his entire chassis on Sunday and then > everything was fine but he experienced custoemrs not connecting and failing > with the famous dun error. > eric > > > At 06:39 PM 10/6/97 -0500, you wrote: > >All of the sudden, since Friday, we have had alot of users call and say > >they are having problems connecting. It drops them after a few minutes. > > > >Some users said there dialup networking says "Cannot negotiate compatible > >protocols", Others get wierd numeric errors. > > > >Are any of you seeing any of this? I am thinking MSIE 4.0 hosed there > >systems, but havent ruled out my end of the link just yet. > > > >Brian *--------------------------- David Crabtree -------------------------------* | Vice Pres/Sys Admin | Dialup 56K | Quake - [GI] Scream | | WSNetworxx Inc. | Dialup ISDN | http://www.wsnet.com/quake | | 448 South Lawrence Street | Ded. ISDN/T1 |-------------------------------| | Montgomery, AL, 36104 | Web Hosting | SysAdmin - WebMaster/Designer | | http://www.wsnet.com | Web Design | Graphics - Programmer | *------- mailto:wolfcub@wsnet.com -- http://www.wsnet.com/~wolfcub --------*

Subject: Re: (usr-tc) 24-port cards
From: Michael Wronski <mwronski@coredump.ae.usr.com>
Date: 1997-10-07 09:08:53

At 07:49 AM 10/7/97 -0400, Mark R. Lindsey wrote: >(I'm sure they'll work it all out in short order, but I'm planning to let >somebody else suffer through the betas.) > They've been in Beta.. The conversation is about first full release.. And No, I dont have an exact date. (Before someone asks).. It should be soon though.. The teams are working hard with beta sites to make sure the product performs well.. -M `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' Mike Wronski(mwronski@coredump.ae.usr.com) 3Com/U.S.Robotics Network Systems Engineer (Level 3) PGP: http://coredump.ae.usr.com/pgp

Subject: Re: (usr-tc) PRI questions
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-07 10:16:02

pris sears said once upon a time: > >Hi, folks - we are having trouble with our telco on configuring some new >PRI lines on our USR eq - the problem is National vs. custom configuration, >our current config is not right and it is almost impossible to manage these >modems. Can someone point me to docs on the differences between these types >of configs? I'm not having any luck finding stuff since USR's web site got >eaten by 3COM. TIA - Pris I think you'll have more successs if you send more specific questions. What exactly are the problems you are having?

Subject: Re: (usr-tc) Problems
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-07 10:20:14

David Crabtree said once upon a time: > > >So we were not the only ones. Our TC also spontanously had problems this >weekend, a quick reboot fixed it though. I am wondering if last weekend >had any special meaning and if other TC owners found themselves with a >problem over the weekend. Maybe the internal "force hardware upgrade" timer is nearing expiration.

Subject: Re: (usr-tc) 24-port cards
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-07 10:22:12

Mark R. Lindsey said once upon a time: > >Do you all really want to put your customers through USR's first try at >anything? The 24-port cards sound really neat, but, given that they've >been through dozens of revisions of their firmware for the netservers and >modems and T1 cards, and given that this is all new code, and given that >ISP customers are often among the most fickle customers there are, I'm >not sure it's such a good idea to be USR's guinea pig, IMHO. > >(I'm sure they'll work it all out in short order, but I'm planning to let >somebody else suffer through the betas.) Haven't they been running it through beta for the past few months anyway? Who has been the beta testers? Bolen?

Subject: Re: (usr-tc) 24port modem cards
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-07 10:41:25

Philip Kippen said once upon a time: > >Be carefull with those HD modems. Wait until they fine tune the code a bit. >Also, look into the USR Trade Up / Trade In program. You can buy some old >14.4 modems and 48 ports of (approx 1 and 1/2) ancient Portmaster from a >garage sale for around $5,000 and trade that in for a new loaded Chassis >for free when you buy one. Great deal. For $5,000.00 extra you will get a >new totally loaded chassis. Take care Are these the "new" chassis that can support the high-density cards, or are they USR's backstock of the "old" chassis?

Subject: (usr-tc) PRI questions
From: pris sears <sears@vt.edu>
Date: 1997-10-07 11:04:32

Hi, folks - we are having trouble with our telco on configuring some new PRI lines on our USR eq - the problem is National vs. custom configuration, our current config is not right and it is almost impossible to manage these modems. Can someone point me to docs on the differences between these types of configs? I'm not having any luck finding stuff since USR's web site got eaten by 3COM. TIA - Pris __________________________________________________________ Pris Sears | sears@vt.edu | http://sears.cns.vt.edu/ | 231-2305

Subject: (usr-tc) 24 Port Card
From: John Campbell <sparky@intrlink.com>
Date: 1997-10-07 11:48:33

Rumor from USR says that they are supposed to ship Friday, but he says that they were also supposed to ship last Friday. 73's John Campbell - KC4LWI http://www.intrlink.com/~sparky mailto:sparky@intrlink.com

Subject: Re: (usr-tc) 24-port cards
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1997-10-07 12:18:48

Thus spake Michael Wronski >At 07:49 AM 10/7/97 -0400, Mark R. Lindsey wrote: >>(I'm sure they'll work it all out in short order, but I'm planning to let >>somebody else suffer through the betas.) >They've been in Beta.. The conversation is about first full release.. And >No, I dont have >an exact date. (Before someone asks).. It should be soon though.. The teams >are working >hard with beta sites to make sure the product performs well.. Yeah, well, I guess your definition of beta is different from ours then. :) -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) 24-port cards
From: Brian Trader -- WAN Technician <brian@netins.net>
Date: 1997-10-07 12:24:15

>At 07:49 AM 10/7/97 -0400, Mark R. Lindsey wrote: > >>(I'm sure they'll work it all out in short order, but I'm planning to let >>somebody else suffer through the betas.) >> > >They've been in Beta.. The conversation is about first full release.. And >No, I dont have >an exact date. (Before someone asks).. It should be soon though.. The teams >are working >hard with beta sites to make sure the product performs well.. > >-M > >`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' >Mike Wronski(mwronski@coredump.ae.usr.com) 3Com/U.S.Robotics >Network Systems Engineer (Level 3) >PGP: http://coredump.ae.usr.com/pgp > > > > If there is no release date yet for the 24 port card then how can you be offering them in bundles??? Brian Trader Iowa Network Services WAN Technician 515-830-0494

Subject: Re: (usr-tc) 24-port cards
From: Brian Trader -- WAN Technician <brian@netins.net>
Date: 1997-10-07 12:24:15

Subject: Re: (usr-tc) 24-port cards
From: Michael Wronski <mwronski@coredump.ae.usr.com>
Date: 1997-10-07 13:00:58

At 12:24 PM 10/7/97 -0500, you wrote: > >>At 07:49 AM 10/7/97 -0400, Mark R. Lindsey wrote: >> >>>(I'm sure they'll work it all out in short order, but I'm planning to let >>>somebody else suffer through the betas.) >>> >> >>They've been in Beta.. The conversation is about first full release.. And >>No, I dont have >>an exact date. (Before someone asks).. It should be soon though.. The teams >>are working >>hard with beta sites to make sure the product performs well.. >> >>-M >> >>`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' >>Mike Wronski(mwronski@coredump.ae.usr.com) 3Com/U.S.Robotics >>Network Systems Engineer (Level 3) >>PGP: http://coredump.ae.usr.com/pgp >> >> >> >> > >If there is no release date yet for the 24 port card then how can you be >offering them in bundles??? > I said "I don't have an exact date.". I dint not say that sales or marketing doesnt have a "target" date. And with a target it is possible to presell a chassis with said cards.. Of cource if the product is not ready for release, dont expect delivery of the HDM cards.. -M

Subject: Re: (usr-tc) 24port modem cards
From: Michael Wronski <mwronski@coredump.ae.usr.com>
Date: 1997-10-07 13:02:04

At 10:41 AM 10/7/97 -0600, you wrote: >Philip Kippen said once upon a time: >> >>Be carefull with those HD modems. Wait until they fine tune the code a bit. >>Also, look into the USR Trade Up / Trade In program. You can buy some old >>14.4 modems and 48 ports of (approx 1 and 1/2) ancient Portmaster from a >>garage sale for around $5,000 and trade that in for a new loaded Chassis >>for free when you buy one. Great deal. For $5,000.00 extra you will get a >>new totally loaded chassis. Take care > >Are these the "new" chassis that can support the high-density cards, or are >they USR's backstock of the "old" chassis? > We dont sell any chassis that do not support the HiPer DSP... -M

Subject: Re: (usr-tc) 24port modem cards
From: Brian Elfert <brian@citilink.com>
Date: 1997-10-07 13:50:49

On Tue, 7 Oct 1997, Pete Ashdown wrote: > >Also, look into the USR Trade Up / Trade In program. You can buy some old > >14.4 modems and 48 ports of (approx 1 and 1/2) ancient Portmaster from a > >garage sale for around $5,000 and trade that in for a new loaded Chassis > >for free when you buy one. Great deal. For $5,000.00 extra you will get a > >new totally loaded chassis. Take care > > Are these the "new" chassis that can support the high-density cards, or are > they USR's backstock of the "old" chassis? I'm pretty sure those are the new chassis. The 2059s are the old chassis. Both the old and new chassis will support the new HyperDSP cards, according to sources at USR. The old chassis will support up to 6 of the HyperDSP cards and the new terminal server card, whatever it's called. The new chassis can be fully loaded with HyperDSP cards. The power supplies are the limitation here. Either of the chassis with the old cards can have two HyperDSP cards installed and still use the old Netserver cards. Brian

Subject: Re: (usr-tc) PRI questions
From: Ray Stell <stellr@stell.cns.vt.edu>
Date: 1997-10-07 15:33:43

> > Hi, Ray, have you got a better way of phrasing this? I am not sure how > better to explain the problems......... > > > >From: Pete Ashdown <pashdown@xmission.com> > >Subject: Re: (usr-tc) PRI questions > >To: usr-tc@mail.xmission.com > >Date: Tue, 7 Oct 1997 10:16:02 -0600 (MDT) > >MIME-Version: 1.0 > >Sender: owner-usr-tc@xmission.com > >Precedence: bulk > >Reply-To: usr-tc@mail.xmission.com > > > >pris sears said once upon a time: > >> > >>Hi, folks - we are having trouble with our telco on configuring some new > >>PRI lines on our USR eq - the problem is National vs. custom configuration, > >>our current config is not right and it is almost impossible to manage these > >>modems. Can someone point me to docs on the differences between these types > >>of configs? I'm not having any luck finding stuff since USR's web site got > >>eaten by 3COM. TIA - Pris > > > >I think you'll have more successs if you send more specific questions. What > >exactly are the problems you are having? > > > > __________________________________________________________ > Pris Sears | sears@vt.edu | http://sears.cns.vt.edu/ | 231-2305 > > > How should the t1/pri be provisioned on a 5ESS switch. AT&T 5ESS switches can run in custom mode in addition to NI-1 (national) mode. Some references say custom: http://www.3com.com/carrier/nsd/products/30424.html but that is just a sales glossy. The document that USR faxed me some pages from, subtitle, Ordering T!/PRI Service does not specify. I'd like to know 1. is there is an installation guide that we should have received on the purchase of the dual t1/pri controller that addresses the technical specs of how the t1 should be provisioned, specifically, 5ESS mode, national or custom? BTW, I have a USR tech support on the line and he is saying it doesn't matter, in that the switch tells the rack what it is. I do not believe him, but you never know. I need to go buy a protocal analyser. 2. could someone be so kind as to tell us how the circuit is documented to be provisioned. We do not have a service contract and so the docs on the web are locked to us. 3. the troubles we were seeing is that when we put a ds0 into local-oos (local out of service) mode the command to put the ds0 back into service puts it into a mode oos (out of service) instead of in-service. We began to suspect config problems when we experienced this behavior. At that point we found that no one on site had looked into the spec before ordering. Duh... =============================================================== Ray Stell stellr@vt.edu (540) 231-4109 KE4TJC 28^D

Subject: Re: (usr-tc) 24-port cards
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-07 15:55:02

Mark R. Lindsey said once upon a time: > >: >(I'm sure they'll work it all out in short order, but I'm planning to >: >let somebody else suffer through the betas.) >: >: They've been in Beta.. The conversation is about first full release.. >: And No, I dont have an exact date. (Before someone asks).. It should >: be soon though.. The teams are working hard with beta sites to make >: sure the product performs well.. > >No offense is intended, but what happened to the Netserver firmware >code 1.0.0? I'm sure it was much more stable than the beta versions, but >it's required significant improvement to make it as functional as it is >now. My understanding is that it is based on Livingston code. They wanted to throw that out and start over from scratch for legal reasons. Someone from USR has mentioned that this will eventually be ported over to the 486 based Netservers.

Subject: Re: (usr-tc) Problems
From: eric@dol.net
Date: 1997-10-07 16:07:00

>> >So we were not the only ones. Our TC also spontanously had problems this >> >weekend, a quick reboot fixed it though. I am wondering if last weekend >> >had any special meaning and if other TC owners found themselves with a >> >problem over the weekend. >> >> Maybe the internal "force hardware upgrade" timer is nearing expiration. >> > >You know thats a thought.................. > What the heck is that? Delaware Online!.........The SMART Choice! With 56K X2 Modems Phone : 302-762-0375 Fax: 302-762-3462 WWW: www.dol.net Eight out of five people have a problem understanding statistics! ****************Customer support is our bottom line!*********************

Subject: Re: (usr-tc) Problems
From: Brian <signal@shreve.net>
Date: 1997-10-07 16:30:15

On Tue, 7 Oct 1997, Pete Ashdown wrote: > David Crabtree said once upon a time: > > > > > >So we were not the only ones. Our TC also spontanously had problems this > >weekend, a quick reboot fixed it though. I am wondering if last weekend > >had any special meaning and if other TC owners found themselves with a > >problem over the weekend. > > Maybe the internal "force hardware upgrade" timer is nearing expiration. > You know thats a thought.................. Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: Re: (usr-tc) 24port modem cards
From: Brian <signal@shreve.net>
Date: 1997-10-07 16:31:41

On Tue, 7 Oct 1997, Pete Ashdown wrote: > Philip Kippen said once upon a time: > > > >Be carefull with those HD modems. Wait until they fine tune the code a bit. > >Also, look into the USR Trade Up / Trade In program. You can buy some old > >14.4 modems and 48 ports of (approx 1 and 1/2) ancient Portmaster from a > >garage sale for around $5,000 and trade that in for a new loaded Chassis > >for free when you buy one. Great deal. For $5,000.00 extra you will get a > >new totally loaded chassis. Take care > > Are these the "new" chassis that can support the high-density cards, or are > they USR's backstock of the "old" chassis? > These are high-density chassis, here is an ad I had...........i have NO affiliation with these people, I just got it in my box: From gdunn@source.1st.net Tue Sep 30 17:07:23 1997 I am re-sending this message because my mail server has been inaccessible. This message contains an alternate reply-to address which IS accessible. If you have already replied, could you please reply once again with any inquiries. I apologies for any inconvenience. My new email address is gdunn@source.1st.net. This memo is intended to reach the person responsible for maintaining and purchasing communications products. If it has not, could you kindly forward it to the appropriate person. I am contacting you from Source Technology. We are a National Platinum reseller for US Robotics. For a Limited Time, for an AMAZING $18,660 you can now purchase a USR 48 Port High Density Total Control Unit, Trade-in your approved Terminal Server with 48 Modems, and USR will ship you 48 More ports for FREE!! That's an INCREDIBLE $9,330 per 48 ports or $194 per port!! Please call me for details. We still have some inventory on the USR 002059-0 Total Control Unit limited time offer, 48 port, ISP T1/PRI Bundles for an AMAZING $12,294 or $256 per port WHILE SUPPLIES LAST. ALL ISPs WHO ORDER before September 30th will receive a FREE copy of our exclusive OPEN ME FIRST ISP installation guide! This packet saves time and money by helping to step an ISP through the proper preparation and installation of the USR Total Control Enterprise Network Hub. We also have aggressive special LEASE approval for ISPs in business less than two years. Most LEASES are approved within 48 hours. Now you can lease a USR 48 port PRI or T1 Total Control Chassis for $6.58 per port per month and provide your customers with 56K X2 capability. If you are considering purchasing US Robotics products anytime soon or if you are interested in pricing, LEASING, or the X2 transmission technology, please contact me at your earliest convenience. Gary Dunn gdunn@source.1st.net (617) 890-4455 /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: Re: (usr-tc) 24-port cards
From: Charles Hill <chill@ionet.net>
Date: 1997-10-07 17:37:19

> No offense is intended, but what happened to the Netserver firmware > code 1.0.0? I'm sure it was much more stable than the beta versions, but > it's required significant improvement to make it as functional as it is > now. Actually, there was no 1.0.0 version. I think the first release was 3.1.23, based on 3.1 ComOS by Livingston. I got one of the earliest Netservers. It didn't include the ISDN daughter card. It ran for nearly 200 days without a single reboot, and then I HAD to take it down to upgrade from analog to digital. There have been maybe a dozen releases since then, but many, many more features added. -CH

Subject: Re: (usr-tc) 24-port cards
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1997-10-07 17:41:32

: >(I'm sure they'll work it all out in short order, but I'm planning to : >let somebody else suffer through the betas.) : : They've been in Beta.. The conversation is about first full release.. : And No, I dont have an exact date. (Before someone asks).. It should : be soon though.. The teams are working hard with beta sites to make : sure the product performs well.. No offense is intended, but what happened to the Netserver firmware code 1.0.0? I'm sure it was much more stable than the beta versions, but it's required significant improvement to make it as functional as it is now. --- Mark R. Lindsey, mark@datasys.net Network Engineer, DSS Online Voice: +1 912 241 0607; Fax: +1 912 241 0190

Subject: (usr-tc) ICMP destination unreachables..
From: Laszlo Vecsey <master@internexus.net>
Date: 1997-10-07 17:57:04

I'm getting these messages again in my syslog, and I can't seem to fix the problem. I've tinkered with ripv2, local_routing, lanwan_routing, etc (all off) but nothing works. default route is also set to 'Quiet (Off)'. Oct 7 17:49:48 Total-Control ICMP destination unreachable. src=[dialupIP] original_src=[netserverIP] original_dst=[dialupIP] code=3 (port unreachable) They come in about one every second, from a different online dialupIP. I had this problem before, but I forget how I resolved it.. I thought I had just set ripv2 off to correct it. Its affecting quake performance so I could use some help here! - lv

Subject: Re: (usr-tc) 24-port cards
From: David Bolen <db3l@ans.net>
Date: 1997-10-07 18:07:53

mark@vielle.datasys.net (Mark R. Lindsey) writes: > No offense is intended, but what happened to the Netserver firmware > code 1.0.0? I'm sure it was much more stable than the beta versions, but > it's required significant improvement to make it as functional as it is > now. Actually, there never was a 1.0.0 - if I recall correctly, the first release of NETServer code started right at 3.0... (probably picking up off of where they started with ComOS I think, but that was a long time ago). But yeah, you really didn't want to be using the packet bus under heavy load in that release - the early driver was inherited from their X.25 gateway card but slimmed down and there were definitely some significant packet bus protocol issues to work out over the first few months after release :-) However, I will say that while later code releases have certainly made bug fixes, more often than not it is to introduce new features and then clean up those features, than just to fix existing problems. I think there have been intermediate releases along the way that were worse than earlier releases without the new features, as is true in any development effort. As with most significant development issues, I've often found that a major release introduces at least as many problems as it adds new features, and that the subsequent maintenance release is "cleaner". (This is certainly not specific to dialup gear either - the number of "special" or non-standard router releases we've run over the years on all our router equipment from various vendors is impressive - or depressing, pick your term) However, that hasn't stopped us from using major releases when the functionality (software or hardware) was important, and in this case the density of the HDM cards (and the clean upgrade path for existing configurations) is extremely attractive, so that's something to consider. Also, depending on the service model and the functionality put to use, as with any release, any issues may or may not apply to a particular configuration. Of course, whether to risk potential first release issues to get the benefits is an individual choice, as the weight to give to the different pros and cons can be different in different circumstances. -- David PS: In response to an earlier message, I wouldn't feel comfortable commenting on any specifics regarding an as of yet unreleased product. I think it is fair to agree with other comments from 3Com that various parties are working closely with 3Com to stress the new platform in their respective environments. Read into that what you will :-)

Subject: Re: (usr-tc) 24-port cards
From: David Bolen <db3l@ans.net>
Date: 1997-10-07 19:19:33

Charles Hill <chill@ionet.net> writes: > Actually, there was no 1.0.0 version. I think the first release was > 3.1.23, based on 3.1 ComOS by Livingston. At the risk of sliding back too far, but for the history buffs out there (feel free to skip by if you don't care), I believe that 3.1.x was almost a year after introduction of the NETServer (our first trial site went live in 9/94 with a 3.0.x base, but I don't know the actual date for product announcement) I'd call the first stable NETServer release (one I didn't have to babysit each night during prime time for packet bus failures, although to be fair that was as much a function of the modems and protocol as the NETServer) to be 3.0.10 which in our case was deployed generally in 2/95. And (just having checked my archive directory) they did start with 3.0.0, although some of the 10 releases between 3.0.0 and 3.0.10 were internal to USR. Our next update was to 3.0.20 in 9/95. This was before they established the convention of using builds >=20 for 8MB cards and <20 for 4MB cards - everything was 4MB back then. Personally, we didn't deploy a 3.1.x release (3.1.7) until 1/96, although that was probably a bit behind the general availability since we tended to be behind due to internal testing and overhead associated with preparation for general rollout. > I got one of the earliest > Netservers. It didn't include the ISDN daughter card. You know you've got an early NETServer if it's a 386 rather than a 486sx, and bonus points if it's etched as "API Card" rather than "NETServer". I actually also had one with some nice yellow circuit board "correction" jumper wires on the back, but USR grabbed that back at some point since it wasn't supposed to have gotten out the lab :-) -- David

Subject: (usr-tc) UPS for Enterprise Hubs
From: Jeff Lynch <jeff@mercury.jorsm.com>
Date: 1997-10-07 20:32:56

Being new to the Enterprise Hub game, a quick question please. Just received two enterprise hubs, each with: 70A power supply 12 quad dig modem cards dual pri/t1 card netserver card nmc card What kind of battery backup are you guys putting on these in practice? Since the docs are already out of date, I don't really trust the 670W typical power dissipation figure stated. Engineering for Max seems like overkill, too. We usually don't loose power for more that about 30 seconds a few times each year. ========================================================================= Jeffrey A. Lynch, President 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) 24port modem cards
From: Rick <rallan@monmouth.com>
Date: 1997-10-07 20:35:53

Pete Ashdown wrote: > Philip Kippen said once upon a time: > > > >Be carefull with those HD modems. Wait until they fine tune the code a bit. > >Also, look into the USR Trade Up / Trade In program. You can buy some old > >14.4 modems and 48 ports of (approx 1 and 1/2) ancient Portmaster from a > >garage sale for around $5,000 and trade that in for a new loaded Chassis > >for free when you buy one. Great deal. For $5,000.00 extra you will get a > >new totally loaded chassis. Take care > > Are these the "new" chassis that can support the high-density cards, or are > they USR's backstock of the "old" chassis? The X2 tradeup/tradein program for new TC chassis expired on 9/30/97. The new program offers 2-24 modem hyper cards along with NMC memory for any competing tradup/tradein. Also the previous program included new TC chassis's.. -- Rick Monmouth Internet

Subject: Re: (usr-tc) PRI questions
From: John Arden <jarden@server.delrio.com>
Date: 1997-10-07 20:43:54

> Hi, folks - we are having trouble with our telco on configuring some new > PRI lines on our USR eq - the problem is National vs. custom configuration, > our current config is not right and it is almost impossible to manage these > modems. Can someone point me to docs on the differences between these types > of configs? I'm not having any luck finding stuff since USR's web site got > eaten by 3COM. TIA - Pris > > __________________________________________________________ > Pris Sears | sears@vt.edu | http://sears.cns.vt.edu/ | 231-2305 > > > Who is your telco? I had all kinds of fun getting my PRI lines up with GTE, my local telco. What kind of switch are you connecting to? I am connecting to a GTD-5. If this sounds similar to your situation I can shoot you a copy of my configuration. jarden@mail.delrio.com

Subject: Re: (usr-tc) UPS for Enterprise Hubs
From: David Bolen <db3l@ans.net>
Date: 1997-10-07 22:16:32

Jeff Lynch <jeff@mercury.jorsm.com> writes: > What kind of battery backup are you guys putting on these in > practice? Since the docs are already out of date, I don't really > trust the 670W typical power dissipation figure stated. Engineering > for Max seems like overkill, too. We usually don't loose power for > more that about 30 seconds a few times each year. Well, while maximum worst case is reasonably heavy (technically the worst case draw within the chassis is all modems training simultaneously and we do encounter it in real life), here's some data from our environment. We operate with racks of 4 traffic carrying hubs or 192 modems, along with some management gear and find that when fully loaded it tends to draw about 2.1-2.2KVA (1.8KVA at a power factor of .83). This is with all modems loaded and a small percentage cycling with new calls. Dividing by 4 is probably a good estimate of per-hub load. This is average - I don't have good data for any instantaneous peaks. This is with the older chassis - I don't have hard data on the newer chassis (we skipped per-rack UPS units in favor of site-level stuff, both due to the management overhead of all the UPS units as well as expected draw for newer equipment overloading anything we could provision in our per-rack space), but the newer 70A supplies perform power factor correction so I'd expect your load to be closer to the 1.8KVA level. I'd still probably be hesitant to use something too close to that average case (a lot of vendors seem to have units in the 2-2.1KVA range) in case you added other hardware or had a burst draw due to sudden training of lots of users (like after a problem clears). The modems have a very wide range of power consumption from down perhaps as low as 1A or so when idle up to perhaps 4A when all modems on the quad are training. (That's internal draw, mostly on the 5VDC PS output). For our purposes in these racks where we do outfit a local UPS, we use 3.1KVA units for the 4 hubs, although we undercut the units slightly on the input side by having a 30A input circuit, since it is easier to outfit at a colo site. I think the units we used (Best) have an efficiency of around 83%, so we'd technically max out between 2.9-3.0KVA. 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 \ \-----------------------------------------------------------------------/

Subject: Re: (usr-tc) UPS for Enterprise Hubs
From: John Campbell <sparky@intrlink.com>
Date: 1997-10-08 07:48:39

I put my whole rack on a APC 2200 Smart UPS. 1/2 Loaded USR TC with 4 computers (with monitors), Cisco 2524 Router, and 2 lan network hubs is drawing at 34% load average. I have simulated power failure (unplugged UPS) for 30 minutes and still had plenty of battery to spare! At 08:32 PM 10/7/97 -0500, you wrote: >Being new to the Enterprise Hub game, a quick question please. > >Just received two enterprise hubs, each with: > 70A power supply > 12 quad dig modem cards > dual pri/t1 card > netserver card > nmc card > >What kind of battery backup are you guys putting on these in >practice? Since the docs are already out of date, I don't really >trust the 670W typical power dissipation figure stated. Engineering >for Max seems like overkill, too. We usually don't loose power for >more that about 30 seconds a few times each year. > >========================================================================= >Jeffrey A. Lynch, President 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 > > > 73's John Campbell - KC4LWI http://www.intrlink.com/~sparky mailto:sparky@intrlink.com

Subject: Re: (usr-tc) 24port modem cards
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-08 08:25:14

Rick said once upon a time: > The X2 tradeup/tradein program for new TC chassis expired on 9/30/97. The >new program offers 2-24 modem hyper cards along with NMC memory for any >competing tradup/tradein. Also the previous program included new TC chassis's.. We need more memory for the NMC in order to support HiPer!?!?

Subject: Re: (usr-tc) UPS for Enterprise Hubs
From: Jeff Lynch <jeff@mercury.jorsm.com>
Date: 1997-10-08 09:34:55

Thanks. --jeff On Tue, 7 Oct 1997, David Bolen wrote: > Jeff Lynch <jeff@mercury.jorsm.com> writes: > > > What kind of battery backup are you guys putting on these in > > practice? Since the docs are already out of date, I don't really > > trust the 670W typical power dissipation figure stated. Engineering > > for Max seems like overkill, too. We usually don't loose power for > > more that about 30 seconds a few times each year. > > Well, while maximum worst case is reasonably heavy (technically the > worst case draw within the chassis is all modems training > simultaneously and we do encounter it in real life), here's some data > from our environment. We operate with racks of 4 traffic carrying > hubs or 192 modems, along with some management gear and find that when > fully loaded it tends to draw about 2.1-2.2KVA (1.8KVA at a power > factor of .83). This is with all modems loaded and a small percentage > cycling with new calls. Dividing by 4 is probably a good estimate of > per-hub load. This is average - I don't have good data for any > instantaneous peaks. > > This is with the older chassis - I don't have hard data on the newer > chassis (we skipped per-rack UPS units in favor of site-level stuff, > both due to the management overhead of all the UPS units as well as > expected draw for newer equipment overloading anything we could > provision in our per-rack space), but the newer 70A supplies perform > power factor correction so I'd expect your load to be closer to the > 1.8KVA level. > > I'd still probably be hesitant to use something too close to that > average case (a lot of vendors seem to have units in the 2-2.1KVA > range) in case you added other hardware or had a burst draw due to > sudden training of lots of users (like after a problem clears). The > modems have a very wide range of power consumption from down perhaps > as low as 1A or so when idle up to perhaps 4A when all modems on the > quad are training. (That's internal draw, mostly on the 5VDC PS > output). > > For our purposes in these racks where we do outfit a local UPS, we use > 3.1KVA units for the 4 hubs, although we undercut the units slightly > on the input side by having a 30A input circuit, since it is easier to > outfit at a colo site. I think the units we used (Best) have an > efficiency of around 83%, so we'd technically max out between 2.9-3.0KVA. > > 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 \ > \-----------------------------------------------------------------------/ > ========================================================================= Jeffrey A. Lynch, President 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) UPS for Enterprise Hubs
From: Jeff Lynch <jeff@mercury.jorsm.com>
Date: 1997-10-08 09:37:26

Thanks. --jeff On Wed, 8 Oct 1997, John Campbell wrote: > I put my whole rack on a APC 2200 Smart UPS. 1/2 Loaded USR TC with 4 > computers (with monitors), Cisco 2524 Router, and 2 lan network hubs is > drawing at 34% load average. I have simulated power failure (unplugged UPS) > for 30 minutes and still had plenty of battery to spare! > > At 08:32 PM 10/7/97 -0500, you wrote: > >Being new to the Enterprise Hub game, a quick question please. > > > >Just received two enterprise hubs, each with: > > 70A power supply > > 12 quad dig modem cards > > dual pri/t1 card > > netserver card > > nmc card > > > >What kind of battery backup are you guys putting on these in > >practice? Since the docs are already out of date, I don't really > >trust the 670W typical power dissipation figure stated. Engineering > >for Max seems like overkill, too. We usually don't loose power for > >more that about 30 seconds a few times each year. > > > >========================================================================= > >Jeffrey A. Lynch, President 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 > > > > > > > > 73's > John Campbell - KC4LWI > http://www.intrlink.com/~sparky > mailto:sparky@intrlink.com > ========================================================================= Jeffrey A. Lynch, President 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) 24port modem cards
From: Michael Wronski <mwronski@coredump.ae.usr.com>
Date: 1997-10-08 09:41:53

At 08:25 AM 10/8/97 -0600, you wrote: >Rick said once upon a time: > >> The X2 tradeup/tradein program for new TC chassis expired on 9/30/97. The >>new program offers 2-24 modem hyper cards along with NMC memory for any >>competing tradup/tradein. Also the previous program included new TC chassis's.. > >We need more memory for the NMC in order to support HiPer!?!? > > Yes, because of squeezing 24 modem configs into one card. More RAM is required to manage a chassis with HDM's. You must also have a 486 NMC. This is a snip from our beta site: "IMPORTANT NOTE: Although there is a new 386/486 (no memory upgrade) version of NMC5.0 below, To manage an HDM your NMC must be a 486 version, requires a memory upgrade, and the HDM supported version of NMC below (hm prefix). You will need to add a 16meg of RAM SIMM to your now empty RAM SIMM slot and replace your current Flash with an 8meg Flash (flash upgrade is optional). USR P/N#1.016.971 16MB DRAM SIMM, 35-0001-00 8MB Flash Simm" -M

Subject: (usr-tc) pbReceivedLsWhileLinkUp(55)
From: Casey Cook <caseyc@gate.net>
Date: 1997-10-08 10:20:28

Anyone know what this reason for call termination means? We have a chassis that people are reporting random disconnects from, but we can't pinpoint a reason other than a high frequency of this message in the TCM performance monitor. Any thoughts appreciated. =============================== Casey Cook CyberGate Network Administrator caseyc@gate.net ===============================

Subject: Re: (usr-tc) 24port modem cards
From: Phillip Kippen <kippen1@ecom.net>
Date: 1997-10-08 10:38:00

Brian Elfert wrote: > On Tue, 7 Oct 1997, Pete Ashdown wrote: > > > >Also, look into the USR Trade Up / Trade In program. You can buy some old > > >14.4 modems and 48 ports of (approx 1 and 1/2) ancient Portmaster from a > > >garage sale for around $5,000 and trade that in for a new loaded Chassis > > >for free when you buy one. Great deal. For $5,000.00 extra you will get a > > >new totally loaded chassis. Take care > > > > Are these the "new" chassis that can support the high-density cards, or are > > they USR's backstock of the "old" chassis? > > I'm pretty sure those are the new chassis. The 2059s are the old chassis. > > Both the old and new chassis will support the new HyperDSP cards, > according to sources at USR. > > The old chassis will support up to 6 of the HyperDSP cards and the new > terminal server card, whatever it's called. > > The new chassis can be fully loaded with HyperDSP cards. > > The power supplies are the limitation here. > > Either of the chassis with the old cards can have two HyperDSP cards > installed and still use the old Netserver cards. > > Brian Hey Brian, That offer is good on the new HD chassis. I took advantage of that offer about 3 months ago and received 2 free HD chassis fully loaded with PRI, NetSvr, 12 quads and an NMC card. I will get you the name of a direct contact with USR who can help you take advantage of this offer if you need. Take care. Phil

Subject: Re: (usr-tc) Another Radius Question
From: Dave Mitton <dmitton@baynetworks.com>
Date: 1997-10-08 11:37:09

I'm sorry but the RFC does not support your conclusion. Nowhere does it say that Session-Timeout is constrainted to Access-Challenge wait time. It never mentions Acc-Challenge. It refers to "service to be provided" and in the value description "seconds the user is allowed to be connected". This is generally implemented as the total length of the on-line session, as the previous writer noted. Dave. At 11:05 PM 10/5/97 -0500, Tatai SV Krishnan wrote: >On Mon, 6 Oct 1997, Billy X wrote: > >> Thanks for responding. I am not really concerned with the filter right now. >> As far as I can tell I can get by without it. The idle timeout is not >> working (although I suppose it should be). I understand that the idle >> timeout should politely disconnect someone who has generated no network >> activity for 20 minutes and that the session timeout will actually >> disconnect someone after 28800 seconds (8 hours) regardless of the presence >> of network activity. I wasn't aware that the session timeout had anything >> to do with the challenge/accept negotiation. Anyways, neither of these >> settings are working (I have had people online for 24 hours + and idle for 2 >> or 3 hours). It has to be one of two things...something in Radius (an >> attribute setting or similar) or something in the Total Control unit. I >> cannot figure which. Any more thoughts? >> >Again Session time out is only in access/challenge so you will never get >it working the way you are doing >check the RFC 2138 for explanations on session-timeout > >5.27. Session-Timeout > > Description > > This Attribute sets the maximum number of seconds of service to be > provided to the user before termination of the session or prompt. > This Attribute is available to be sent by the server to the client > in an Access-Accept or Access-Challenge. > > A summary of the Session-Timeout Attribute format is shown below. > The fields are transmitted from left to right. > >Now in order to see if idle time is working or not - set the users >idletimeout to something like 200 - dial waith for 3 min idle and you >will be droped out. > >krish > > > > >> >> Thanks. >> Scott Smith >> WizardNet >> >> >> At 05:42 AM 10/5/97 -0500, you wrote: >> >On Sun, 5 Oct 1997, Scott wrote: >> > >> >> Thanks for the information. However, I have checked to make sure that >> >> theses two attributes are in the dictionary file, and they are, listed as >> >> number 27 and 28 (see example included). >> >> >> >> ATTRIBUTE Session-Timeout 27 integer >> >> ATTRIBUTE Idle-Timeout 28 integer >> >> >> >> I also have these attributes set for each user in the Radius users file. >> >> Each setting is specified in units of seconds. Here is an example Radius >> >> user entry in the users file (/etc/raddb/users). >> >> >> >> tulenko Password = "UNIX" >> >> User-Service-Type = Framed-User, >> >> Framed-Protocol = PPP, >> >> Framed-Address = 255.255.255.254, >> >> Framed-Netmask = 255.255.255.255, >> >> Framed-Routing = None, >> >> Framed-Compression = Van-Jacobsen-TCP-IP, >> >> # Framed-Filter-Id = "std.ppp.in", >> >> Framed-MTU = 1500, >> >> Idle-Timeout = 1200, >> >> Session-Timeout = 28800, >> >> Port-Limit = 1 >> >> >> >> The Framed-Filter has been commented out because it was not working with >> >> this attribute specified (will fix this later). However, I am confused >> >> as to why the Timeouts are not working. They are present in this file and >> >> in the dictionary file. If anyone would be willing to post an example >> >> entry from Livingston Radius users file and dictionary file as I have done >> >> above, maybe that would show any differences. Thanks in advance. >> > >> >Here is my take on this >> > >> >To make use of the filter std.ppp.in or just the Framed-Filter-Id >> >attribute, create a filter on the NETServer and call it as std.ppp >> >You can then use this statement in your users file. >> > >> >Idle time does work, if the user in your case is idle for 1200 min then >> >he will be disconnected. >> >Session timeout is basically used when the client and server are in the >> >challege state - basically for access-accept or access challenge, In this >> >configuration you are setting up the user access challenge/accept timeout >> >to be 28800. This will work if you are setting the users in a challenge >> >state, which I believe you are not doing. >> > >> >krish >> > >> >----------------------------------------- >> > \ T.S.V. Krishnan \ >> > \ Network System Engineer \ ( : - : ) >> > \ 3Com ............ \ >> > ----------------------------------------------/ >> >tkrishna@bubba.ae.usr.com >> >----------------------------/ http://interproc.ae.usr.com ----/ >> >-------------------------------------------------------------------------\ >> > Any Sufficiently advanced bug is indistinguishable for a feature. >> > - Rick Kulawiec >> >-------------------------------------------------------------------------/ >> > >> > >> >> >> >> Scott Smith >> >> WizardNet >> >> >> >> >> >> On Sat, 4 Oct 1997, Laszlo Vecsey wrote: >> >> >> >> > On Sat, 4 Oct 1997, Billy X wrote: >> >> > >> >> > > I am using Livingston Radius 2.0 on Linux and would like any tips on >> getting >> >> > > an idle timeout to work. It seems that an idle timeout can be set on >> each >> >> > > port on the TC unit, but I would like to do this on a per user basis >> using >> >> > > the Radius attributes. Also, the session timeout setting is not working. >> >> > > If anyone knows how to allow the settings to operate with the TC >> unit, that >> >> > > information would be much appreciated. >> >> > > >> >> > >> >> > I've had success with using the following for pppuser: >> >> > >> >> > Session-Timeout = 86400, >> >> > Idle-Timeout = 1080, >> >> > >> >> > Of course, check your dictionary file to make sure they are listed. The >> >> > most common mistake is entering the values in minutes.. you must use >> >> > seconds! For users that I allow to stay on 24/7, I set these to zero. >> >> > >> >> > - lv >> >> > >> >> > >> >> >> >> >> > >> >> > > > David Mitton 978-670-8888 Main Consulting Engineer 978-916-4570 Direct Bay Networks, Remote Access Srv Div 978-916-4789 FAX Billerica, MA 01821 dmitton@baynetworks.com

Subject: Re: (usr-tc) Another Radius Question
From: Robert Sanders <rsanders@mindspring.net>
Date: 1997-10-08 11:48:37

Dave Mitton <dmitton@baynetworks.com> writes: > I'm sorry but the RFC does not support your conclusion. > > Nowhere does it say that Session-Timeout is constrainted to > Access-Challenge wait time. It never mentions Acc-Challenge. It refers to > "service to be provided" and in the value description "seconds the user is > allowed to be connected". This is generally implemented as the total > length of the on-line session, as the previous writer noted. Indeed, and that is exactly the way USR/3com has implemented it in their NETserver and HiPer ARC software; we use it quite extensively. There's obviously some confusion here. regards, -- Robert

Subject: Re: (usr-tc) Problems
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-08 12:34:41

eric@dol.net said once upon a time: > >>> >So we were not the only ones. Our TC also spontanously had problems this >>> >weekend, a quick reboot fixed it though. I am wondering if last weekend >>> >had any special meaning and if other TC owners found themselves with a >>> >problem over the weekend. >>> >>> Maybe the internal "force hardware upgrade" timer is nearing expiration. >>> >> >>You know thats a thought.................. >> > >What the heck is that? A joke.

Subject: Re: (usr-tc) 24port modem cards
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-08 12:36:05

Michael Wronski said once upon a time: >prefix). You will need to add a 16meg of RAM SIMM to your now empty RAM >SIMM slot and replace your current Flash with an 8meg Flash (flash upgrade >is optional). USR P/N#1.016.971 16MB DRAM SIMM, 35-0001-00 8MB Flash Simm" What are the specs on the 8MB Flash SIMM?

Subject: Re: (usr-tc) UPS for Enterprise Hubs
From: Richard Mazur <sysop@surfnetcorp.com>
Date: 1997-10-08 13:07:27

If I may ask, what was the price on that APC 2200? Thanks.. John Campbell wrote: > I put my whole rack on a APC 2200 Smart UPS. 1/2 Loaded USR TC > with 4 > computers (with monitors), Cisco 2524 Router, and 2 lan network hubs > is > drawing at 34% load average. I have simulated power failure (unplugged > UPS) > for 30 minutes and still had plenty of battery to spare! > > At 08:32 PM 10/7/97 -0500, you wrote: > >Being new to the Enterprise Hub game, a quick question please. > > > >Just received two enterprise hubs, each with: > > 70A power supply > > 12 quad dig modem cards > > dual pri/t1 card > > netserver card > > nmc card > > > >What kind of battery backup are you guys putting on these in > >practice? Since the docs are already out of date, I don't really > >trust the 670W typical power dissipation figure stated. Engineering > >for Max seems like overkill, too. We usually don't loose power for > >more that about 30 seconds a few times each year. > > > > > ======================================================================== > > >Jeffrey A. Lynch, President 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 > > > > > > > > 73's > John Campbell - KC4LWI > http://www.intrlink.com/~sparky > mailto:sparky@intrlink.com -- Richard Mazurowski SurfNet Corporation sysop@surfnetcorp.com Voice (773) 283-9000 Fax (773) 283-9009

Subject: Re: (usr-tc) ICMP destination unreachables..
From: Laszlo Vecsey <master@internexus.net>
Date: 1997-10-08 14:10:54

Just FYI, the problem was with 'Framed-Routing=None' in the DEFAULT section of merit radius. With that line in there, a 'show Sxx' command on the netserver would state that RIPsend was active on the port.. - lv On Tue, 7 Oct 1997, Laszlo Vecsey wrote: > I'm getting these messages again in my syslog, and I can't seem to fix the > problem. I've tinkered with ripv2, local_routing, lanwan_routing, etc (all > off) but nothing works. default route is also set to 'Quiet (Off)'. > > Oct 7 17:49:48 Total-Control ICMP destination unreachable. src=[dialupIP] > original_src=[netserverIP] original_dst=[dialupIP] code=3 (port unreachable) > > They come in about one every second, from a different online dialupIP. I > had this problem before, but I forget how I resolved it.. I thought I had > just set ripv2 off to correct it. Its affecting quake performance so I > could use some help here! > > - lv > >

Subject: Re: (usr-tc) UPS for Enterprise Hubs
From: Laszlo Vecsey <master@internexus.net>
Date: 1997-10-08 14:13:00

Of course, its the fan required for a usr-tc that chews up most of the power. How long can one of these keep it going? - lv On Wed, 8 Oct 1997, Richard Mazur wrote: > If I may ask, what was the price on that APC 2200? Thanks.. > > John Campbell wrote: > > > I put my whole rack on a APC 2200 Smart UPS. 1/2 Loaded USR TC > > with 4 > > computers (with monitors), Cisco 2524 Router, and 2 lan network hubs > > is > > drawing at 34% load average. I have simulated power failure (unplugged > > UPS) > > for 30 minutes and still had plenty of battery to spare! > > > > At 08:32 PM 10/7/97 -0500, you wrote: > > >Being new to the Enterprise Hub game, a quick question please. > > > > > >Just received two enterprise hubs, each with: > > > 70A power supply > > > 12 quad dig modem cards > > > dual pri/t1 card > > > netserver card > > > nmc card > > > > > >What kind of battery backup are you guys putting on these in > > >practice? Since the docs are already out of date, I don't really > > >trust the 670W typical power dissipation figure stated. Engineering > > >for Max seems like overkill, too. We usually don't loose power for > > >more that about 30 seconds a few times each year. > > > > > > > > ======================================================================== > > > > >Jeffrey A. Lynch, President 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 > > > > > > > > > > > > > 73's > > John Campbell - KC4LWI > > http://www.intrlink.com/~sparky > > mailto:sparky@intrlink.com > > > > -- > Richard Mazurowski > SurfNet Corporation > sysop@surfnetcorp.com > Voice (773) 283-9000 > Fax (773) 283-9009 > --------------------------------------------- > > >

Subject: (usr-tc) Re: usr-tc Digest V1 #65
From: Curt Shambeau <curt@execpc.com>
Date: 1997-10-08 14:15:52

RE: UPS power to install on a chassis.... We run 2 fully loaded Total Control Chassis per 1400VA UPS, and have approx 65%-70% load on them. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Exec-PC Vice President, Information Services |

Subject: (usr-tc) get user on port?
From: Jaye Mathisen <mrcpu@cdsnet.net>
Date: 1997-10-08 14:31:54

Is there anyway to get who's logged into which port via SNMP? Livingston has this feature if you use the pmw program just released a little bit ago, and it sure is handy, and saves the hassle of pmwho and telnet, and all that crap.

Subject: Re: (usr-tc) Another Radius Question
From: Randy Doran <rtdoran@gate.net>
Date: 1997-10-08 14:40:23

If you have Idle-Timeout set in radius do you have to set the idletime on the ports to 0? If you leave an idletime on a port of say, 20 minutes and you set the Idle-Timeout in radius to 15 minutes, will the port setting override the radius or vice-versa? Or is it first come first served with the lowest time setting acting first and dropping the connection? Randy Doran CyberGate Network Operations On Sat, 4 Oct 1997, Laszlo Vecsey wrote: > On Sat, 4 Oct 1997, Billy X wrote: > > > I am using Livingston Radius 2.0 on Linux and would like any tips on getting > > an idle timeout to work. It seems that an idle timeout can be set on each > > port on the TC unit, but I would like to do this on a per user basis using > > the Radius attributes. Also, the session timeout setting is not working. > > If anyone knows how to allow the settings to operate with the TC unit, that > > information would be much appreciated. > > > > I've had success with using the following for pppuser: > > Session-Timeout = 86400, > Idle-Timeout = 1080, > > Of course, check your dictionary file to make sure they are listed. The > most common mistake is entering the values in minutes.. you must use > seconds! For users that I allow to stay on 24/7, I set these to zero. > > - lv > > > >

Subject: Re: (usr-tc) Re: usr-tc Digest V1 #65
From: Jeff Lynch <jeff@mercury.jorsm.com>
Date: 1997-10-08 14:55:10

Thanks, --jeff On Wed, 8 Oct 1997, Curt Shambeau wrote: > RE: UPS power to install on a chassis.... > > We run 2 fully loaded Total Control Chassis per 1400VA UPS, and have > approx 65%-70% load on them. > > -------------------------------------------------------------------------- > | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | > | Exec-PC Vice President, Information Services | > -------------------------------------------------------------------------- > > ========================================================================= Jeffrey A. Lynch, President 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) UPS for Enterprise Hubs
From: David Bolen <db3l@ans.net>
Date: 1997-10-08 14:58:22

Laszlo Vecsey <master@internexus.net> writes: > Of course, its the fan required for a usr-tc that chews up most of the > power. How long can one of these keep it going? The fan tray, while not insignificant, really isn't the bulk of the power draw. The data I have shows the integrated fan tray pulls about 3.57A (85.68W) internally. By comparison, the rest of a fully loaded chassis (backplane+NMC/NIC+PRI/NIC+12Quad+NETServer/NIC) in worst case (all modems training) totals about 62.68A (325W). These are internal chassis power figures (the supplies are PF correcting, but I normally assume a 70% switched supply efficiency for external draw). Of course, this is worst case - I normally use an estimate of typical high load as being all modems online with ~15% (2 quad cards) training, which is reasonably conservative, which would reduce the chassis load to 42.68A, but still more than 10x the fan tray load. This seems to jive with real world data reasonably well. Using figures such as this I arrive at an expected worst case external load for a rack of 4 of these chassis (along with our management chassis and some other various gear) of about 2200-2300W, which is in the right ballpark for what we've seen in the field. -- 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) pbReceivedLsWhileLinkUp(55)
From: David Bolen <db3l@ans.net>
Date: 1997-10-08 15:07:14

Casey Cook <caseyc@gate.net> > Anyone know what this reason for call termination means? We have a > chassis that people are reporting random disconnects from, but we can't > pinpoint a reason other than a high frequency of this message in the TCM > performance monitor. Any thoughts appreciated. It means that something got corrupted with packet bus communications, since a link status (Ls) frame was received while the link was already up. The packet bus works kind of like a connected datagram socket, and link control messages handle general setup of the communication path which once up, then transfers data frames. Or something close to that. There are a bunch of failure reasons like this (check the MIB for the "pb" prefix) related to a variety of packet bus communication faults. Having an occasional message like this isn't necessarily anything to worry about (like any datagram system, sometimes things get slightly out of sync, and they clean themselves up). But it should be pretty rare (as an example, my data from yesterday shows 183 of these specific failures, and 544 packet bus failures of any type which is only about 1/100 of a percent of our total calls). So if you've got a noticeably higher frequency you might want to try to track it down to a specific card. If it's generally across the chassis, you might check into the NETServer, but if it tends to be a single quad card look into that. Sometimes the software gets into a bad state and a remote slot reset can clear it - sometimes it's a physical problem and just reseating the card can help, or sometimes its a hardware failure and you need to replace something. Note also that the packet bus is a shared bus that all cards have electrical contact with. So it's also possible for one card to be messing things up but for errors to show up generally within the chassis. Sometimes it takes a little detective work to track down the root culprit. -- 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) Static IP's and TC's
From: WizardNet Staff <usr@wizard.net>
Date: 1997-10-08 15:07:45

Hi-- We've just setup a couple of boxes last week, traded in our old Portmaster 2e's. We are having some strange problems with our Static IP users now, problems that weren't around with the Portmasters... It seems that a user with a static IP can connect to tc1, disconnect, then connect again 5 minutes later to tc2. He is able to surf our website and outside of our network while on tc1, but can only surf our own internal network while on tc2. The problem seems to be time related, because if the user disconnects, goes to bed and wakes up the next morning, a connection to tc2 gets him out to the internet. There seems to be some non-communication between the 2 servers and the routes setup for these Static IP addresses - we never had to setup anything for the portmaster, they just knew what to do. I couldn't find any docs on the totalservice site regarding this problem, has anybody else had any problems with this, or any suggestions? Do we have to, hohum, reset the box whenever a Static IP user disconnects? Or is there a configuration we are missing with setting up the routing tables between the two machines... Regards, William Vadnais usr@wizard.net WizardNet, Inc.

Subject: Re: (usr-tc) ICMP destination unreachables..
From: Brian <signal@shreve.net>
Date: 1997-10-08 16:45:16

On Wed, 8 Oct 1997, Laszlo Vecsey wrote: > Just FYI, the problem was with 'Framed-Routing=None' in the DEFAULT > section of merit radius. With that line in there, a 'show Sxx' command on > the netserver would state that RIPsend was active on the port.. > > - lv So Laszlo, I have Framed-Routing=None in MY merit radius default config. Should I turn this off? We DO get LOTS of quake lag..........what should I do? Remove the line completely? Brian > > On Tue, 7 Oct 1997, Laszlo Vecsey wrote: > > > I'm getting these messages again in my syslog, and I can't seem to fix the > > problem. I've tinkered with ripv2, local_routing, lanwan_routing, etc (all > > off) but nothing works. default route is also set to 'Quiet (Off)'. > > > > Oct 7 17:49:48 Total-Control ICMP destination unreachable. src=[dialupIP] > > original_src=[netserverIP] original_dst=[dialupIP] code=3 (port unreachable) > > > > They come in about one every second, from a different online dialupIP. I > > had this problem before, but I forget how I resolved it.. I thought I had > > just set ripv2 off to correct it. Its affecting quake performance so I > > could use some help here! > > > > - lv > > > > > > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: Re: (usr-tc) Static IP's and TC's
From: pris sears <sears@vt.edu>
Date: 1997-10-08 16:48:32

This sounds like a problem we had with some cisco servers - it has to do with the users ip + the mac address of the server that is cached in the arp table at the router - if a user logs in a second time to a different server than the first time, the mac address won't match their ip address in the arp table - they will be able to authenticate but nothing else. If using dynamic ip fixes the problem, that might be it...the arp entries time out after a while so that might explain why everything is ok again the next day. - Pris __________________________________________________________ Pris Sears | sears@vt.edu | http://sears.cns.vt.edu/ | 231-2305

Subject: Re: (usr-tc) get user on port?
From: Michael Wronski <mwronski@coredump.ae.usr.com>
Date: 1997-10-08 17:10:36

At 02:31 PM 10/8/97 -0700, you wrote: > > >Is there anyway to get who's logged into which port via SNMP? Livingston >has this feature if you use the pmw program just released a little bit >ago, and it sure is handy, and saves the hassle of pmwho and telnet, and >all that crap. > Not at this time.. Your best bet is pmwho or to use RADIUS accounting and parse the accounting for a current list of who is online.. -M `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' Mike Wronski(mwronski@coredump.ae.usr.com) 3Com/U.S.Robotics Network Systems Engineer (Level 3) PGP: http://coredump.ae.usr.com/pgp

Subject: Re: (usr-tc) UPS for Enterprise Hubs
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1997-10-08 19:34:00

-> Laszlo Vecsey <master@internexus.net> writes: -> -> > Of course, its the fan required for a usr-tc that chews up most of the > -> power. How long can one of these keep it going? -> -> The fan tray, while not insignificant, really isn't the bulk of the power -> draw. The data I have shows the integrated fan tray pulls about 3.57A -> (85.68W) internally. By comparison, the rest of a fully loaded chassis -> (backplane+NMC/NIC+PRI/NIC+12Quad+NETServer/NIC) in worst case (all modems -> training) totals about 62.68A (325W). These are internal chassis power -> figures (the supplies are PF correcting, but I normally assume a 70% -> switched supply efficiency for external draw). -> -> Of course, this is worst case - I normally use an estimate of typical high -> load as being all modems online with ~15% (2 quad cards) -> training, which is reasonably conservative, which would reduce the chassis -> load to 42.68A, but still more than 10x the fan tray load. -> This seems to jive with real world data reasonably well. Using figures such -> as this I arrive at an expected worst case external load for a rack of 4 of -> these chassis (along with our management chassis and some other various -> gear) of about 2200-2300W, which is in the right ballpark for what we've -> seen in the field. I thought APC and other highly discourage putting motorized equipment on UPS systems ? I even recall them saying it could invalidate the warranty. Of course one could argue that computer have motors but they are all DC powered motors and I believe the fan trays are AC powered. Jeff Binkley ASA Network Computing

Subject: (usr-tc) Help: Connection Problems
From: Brian <signal@shreve.net>
Date: 1997-10-08 19:41:15

For the last 5 days we have had TOTAL chaos here. Users connect with like 12k-19.2k-21k connects. Many get Win95 DUN errors such as "Cannot negotiate a compatible set of protocols", and many other errors. The modems here pick up, the connection (from the clients end) sounds TERRIBLE......the modems take forever to connect, if they even do at all. Many times they connect and the user is dropped minutes later. You have to understand, we are not new to this type of stuff, we run multiple racks, and have had pretty standup service for a while. This is driving me nuts. Tonight, I wiped out the hubs, and re-installed TCS2.5.1, with the latest code at totalservice. We use PRI's. What parameters on the Modems would most effect connect speed when using a PRI? What in all your experiences have you seen this type of stuff? I am thinking telco. Alot of users claim no problems at all. We cant see that it follows a particular hub or modem either which is odd. I really need to get this fixed. To complicate things, these latest MS DUN and IE40 releases don't help anything. When you install the new DUN it enables WINS/DHCP by default, and disable call waiting (which if you dont have call waiting, will screw you up). Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: Re: (usr-tc) UPS for Enterprise Hubs
From: David Bolen <db3l@ans.net>
Date: 1997-10-08 20:31:12

jeff.binkley@asacomp.com (Jeff Binkley) writes: > I thought APC and other highly discourage putting motorized equipment on UPS > systems ? I even recall them saying it could invalidate the warranty. Of > course one could argue that computer have motors but they are all DC powered > motors and I believe the fan trays are AC powered. I'm not really familiar with any prohibition (or suggestion) not to put motorized stuff on UPS systems (maybe they're just saying it because it isn't the best power factor or "nice" draw for the UPS so it might make their stats look worse?) but this isn't necessarily my area of expertise either... However, one thing is that in the new chassis, the fan tray is powered by the same DC power supply as the rest of the chassis, so as far as the UPS is concerned its just part of the same chassis connection. -- 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) get user on port?
From: Colin_McFadyen <colinmcfadyen@pigeon.carleton.ca>
Date: 1997-10-08 21:31:11

I always liked being able to finger the Xylogics Annex boxes to get a list of users, Colin McFadyen Carleton University CCS 613-520-2600 ext. 3721 > ---------- > From: Jaye Mathisen[SMTP:mrcpu@cdsnet.net] > Sent: Wednesday, October 08, 1997 5:31 PM > To: usr-tc@xmission.com > Subject: (usr-tc) get user on port? > > > > Is there anyway to get who's logged into which port via SNMP? > Livingston > has this feature if you use the pmw program just released a little bit > ago, and it sure is handy, and saves the hassle of pmwho and telnet, > and > all that crap. > >

Subject: Re: (usr-tc) UPS for Enterprise Hubs
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1997-10-08 21:44:00

-> > I thought APC and other highly discourage putting motorized equipment on -> UPS > systems ? I even recall them saying it could invalidate the -> warranty. Of > course one could argue that computer have motors but they -> are all DC powered > motors and I believe the fan trays are AC powered. -> -> I'm not really familiar with any prohibition (or suggestion) not to put -> motorized stuff on UPS systems (maybe they're just saying it because it -> isn't the best power factor or "nice" draw for the UPS so it might make -> their stats look worse?) but this isn't necessarily my area of expertise -> either... -> -> However, one thing is that in the new chassis, the fan tray is powered by -> the same DC power supply as the rest of the chassis, so as far as the UPS is -> concerned its just part of the same chassis connection. Ok. I have an older chassis with the AC plug and it goes into the wall. However, since I have the hub in a free standing rack, heat buildup isn't a big concern. Jeff Binkley ASA Network Computing

Subject: (usr-tc) User info program
From: Brian <signal@shreve.net>
Date: 1997-10-08 21:47:37

Has anyone made a program, that uses SNMP with the USR TC hubs that will do the following: A user hits your web page, clicks a link, and it shows you there connect speed, and all kinds of info in the "performance monitor" for there modem. This would be very cool, and really shouldnt be very hard for anyone who has a good understanding of the USR MIBS and snmp utils........... I would really like somehting like this, I just have so much on my plate right now I don't have time to make it, but if someone else has and would share it that would be very cool Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: Re: (usr-tc) UPS for Enterprise Hubs
From: David Bolen <db3l@ans.net>
Date: 1997-10-08 22:02:56

jeff.binkley@asacomp.com (Jeff Binkley) writes: > Ok. I have an older chassis with the AC plug and it goes into the > wall. However, since I have the hub in a free standing rack, heat > buildup isn't a big concern. Oh, for what it's worth the DC comment was relevant to the new chassis, but I'm certainly running the older AC fan trays in our older racks, and of those racks we've outfitted with UPSs, most are of this older configuration, with 3 fan trays per rack (of 4 hubs). It looks like we've got about 350 or so such racks, and haven't encountered any particular problem that I know of. Most of our racks are in enclosed 7' cabinets so heat is often a big issue. I couldn't operate them without the fan trays, so it wouldn't help much to have the hubs keep operating on UPS power and yet lose the fan trays if they weren't also covered by the UPS. -- 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) get user on port?
From: Laszlo Vecsey <master@internexus.net>
Date: 1997-10-08 22:31:16

> > Is there anyway to get who's logged into which port via SNMP? > > Livingston > > has this feature if you use the pmw program just released a little bit > > ago, and it sure is handy, and saves the hassle of pmwho and telnet, > > and > > all that crap. I'm not convinced that SNMP would be faster, but it might. The main thing that slows down a tool that uses the telnet port on the netserver is the initial connection, which can take more than a second before you get a login prompt. As long as you maintain one telnet connection to the netserver, the rest of the connections are instantaneous. However with SNMP you are stuck with the response time to the NMC (which is ~40ms here, just for a ping response.. though it seems to fluctuate from just a few ms to 100ms) plus the additional time to query the individual cards. And as mentioned previously on the list, you can't send more than 25 or so requests to the NMC at the same time, so this is also a limiting factor. So I'm not sure which one would win overall, SNMP or telnet. Can SNMP even provide all the information that is produced from a 'show sessions' listing? Maybe David Bolen can comment on all this .. (do your tools use a combination of SNMP and telnet to query the chassis?) Also, for those interested in this you can fetch my tcview program that does this over the telnet port. You can use a finger daemon like cfingerd on a unix host if you really want the finger functionality, too. Please send any improvements, patches, suggestions to me.. thanks. http://master.internexus.net/Projects/tcview.tar.gz - lv

Subject: Re: (usr-tc) UPS for Enterprise Hubs
From: John Campbell <sparky@intrlink.com>
Date: 1997-10-08 22:32:54

At 07:34 PM 10/8/97 -0500, you wrote: >-> Laszlo Vecsey <master@internexus.net> writes: >-> >-> > Of course, its the fan required for a usr-tc that chews up most of the > >-> power. How long can one of these keep it going? >-> >-> The fan tray, while not insignificant, really isn't the bulk of the power >-> draw. The data I have shows the integrated fan tray pulls about 3.57A >-> (85.68W) internally. By comparison, the rest of a fully loaded chassis >-> (backplane+NMC/NIC+PRI/NIC+12Quad+NETServer/NIC) in worst case (all modems >-> training) totals about 62.68A (325W). These are internal chassis power >-> figures (the supplies are PF correcting, but I normally assume a 70% >-> switched supply efficiency for external draw). >-> >-> Of course, this is worst case - I normally use an estimate of typical high >-> load as being all modems online with ~15% (2 quad cards) >-> training, which is reasonably conservative, which would reduce the chassis >-> load to 42.68A, but still more than 10x the fan tray load. >-> This seems to jive with real world data reasonably well. Using figures such >-> as this I arrive at an expected worst case external load for a rack of 4 of >-> these chassis (along with our management chassis and some other various >-> gear) of about 2200-2300W, which is in the right ballpark for what we've >-> seen in the field. > > >I thought APC and other highly discourage putting motorized equipment on UPS >systems ? I even recall them saying it could invalidate the warranty. Of >course one could argue that computer have motors but they are all DC powered >motors and I believe the fan trays are AC powered. > >Jeff Binkley >ASA Network Computing > > The Fan Tray on the USR-TC contain all 24 Volt DC Fans. Atleast that is what is in my unit! 73's John Campbell - KC4LWI http://www.intrlink.com/~sparky mailto:sparky@intrlink.com

Subject: (usr-tc) slow connects
From: Brian <signal@shreve.net>
Date: 1997-10-08 22:42:10

I am still getting alot of users who are getting 16.8k and other slow connects off 33.6+k modems. Does anyone know what setting in the Quads could be hosed so I can go fix it? We use pri's and so they answer on the packet bus. phone company comes out tommorow, I hope its bad phone lines or something explainable. Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: Re: (usr-tc) UPS for Enterprise Hubs
From: Brian Elfert <brian@citilink.com>
Date: 1997-10-08 22:46:20

On Wed, 8 Oct 1997, Laszlo Vecsey wrote: > Of course, its the fan required for a usr-tc that chews up most of the > power. How long can one of these keep it going? If the fans really chews up all the power, why not just not plug the fan into the UPS? Your UPS will probably only last an hour or two at max, and I don't think the rack will overheat in that time. Brian

Subject: RE: (usr-tc) get user on port?
From: David Bolen <db3l@ans.net>
Date: 1997-10-08 22:57:11

Laszlo Vecsey <master@internexus.net> writes: > So I'm not sure which one would win overall, SNMP or telnet. Can SNMP even > provide all the information that is produced from a 'show sessions' > listing? It could if MIBs were defined to contain the information, but until they shift to the new platform, SNMP access to the NETServer is limited to MIB-II which is less than helpful for most desirable information. But I agree it's somewhat unclear which is faster overall. I have a feeling SNMP could come out on top depending on just how much information you really needed, but it's kind of moot since that isn't available in the current NETServer. > listing? Maybe David Bolen can comment on all this .. (do your tools use a > combination of SNMP and telnet to query the chassis?) Yes, we use both access methods. The vast majority of our statistics gathering, general monitoring and management is done via the NMC and SNMP, and whenever I have a choice that is my preference if only to have a standardized approach. Obviously for the NETServer that won't work, so we have our own utility for executing arbitrary commands on any NETServer over a telnet link. It links into common system components we have for identifying passwords, and funnels any number of arbitrary commands to a NETServer, just displaying the output, which we can then post-process if we want nicer summaries or something. It's not quite the same as your tcview, but the general concept is very close. To be honest though, doing something like getting a list of users on a single NETServer just isn't that typical in our environment, since a single NETServer is too small a unit of granularity. And we have second order statistics gathering daemons that provide higher level views. Much of the information you might later want to poll the NETServer for is proactively generated in syslogs, which we stuff into our call records and gather at call setup time. So for me, the more typical method would be to do SNMP queries to our statistics daemons (which might only be a few SNMP PDUs to 25 machines to get a user count for a 5400-modem site). An earlier note of mine (should be available in the archives, it was "Re: (usr-tc) Stats?", 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 for anyone who may be interested. -- 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) overheating usr-tc's
From: Laszlo Vecsey <master@internexus.net>
Date: 1997-10-09 00:05:04

Yes, thats what I do right now.. the fan is on its own 900watt UPS. But as Bolen pointed out, it isn't even the fan that uses most of the power. I was mistaken. Also, I think the rack can overheat in less than 30 minutes :) It gets very hot, very quickly without a fan. On Wed, 8 Oct 1997, Brian Elfert wrote: > On Wed, 8 Oct 1997, Laszlo Vecsey wrote: > > > Of course, its the fan required for a usr-tc that chews up most of the > > power. How long can one of these keep it going? > > If the fans really chews up all the power, why not just not plug the fan > into the UPS? > > Your UPS will probably only last an hour or two at max, and I don't think > the rack will overheat in that time. > > Brian > >

Subject: Re: (usr-tc) overheating usr-tc's
From: David Bolen <db3l@ans.net>
Date: 1997-10-09 00:16:22

Laszlo Vecsey <master@internexus.net> writes: > Yes, thats what I do right now.. the fan is on its own 900watt UPS. But > as Bolen pointed out, it isn't even the fan that uses most of the power. > I was mistaken. Also, I think the rack can overheat in less than 30 > minutes :) It gets very hot, very quickly without a fan. Heck, in some locations we're forced to run borderline to spec under normal circumstances even with the fans (cabinets and slab flooring is not a good combination no matter how much you try to ventillate the cabinets :-(). We estimate the heat load for our racks at something around 8000BTU, which is pretty impressive :-) However, I will also say that in our case we have nowhere near that much time with individual racks where we have our own UPSs (as opposed to being run off of site battery power). Because our rack is 4 loaded chassis and management gear and represents a large percentage of the UPS rating, the best UPS we can actually mount within the cabinet (in about 10" height and ~26" depth) only gives between 7-15 minutes at full load. So it's more a clean shutdown and short burp handling than any prolonged outage support. That's part of the reason we decided to forgo individual rack UPS units over time - it just wasn't buying us all that much for the overhead (space, maintenance, etc..). And I can't wait until we start to see our batteries needing replacing in the next year or so... -- 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) get user on port?
From: Rick Payne <rickp@corp.netcom.net.uk>
Date: 1997-10-09 06:04:38

>>>>> "Michael" == Michael Wronski <mwronski@coredump.ae.usr.com> writes: Michael> Not at this time.. Your best bet is pmwho or to use RADIUS Does that mean its being considered? I'd certainly find it quite useful to be able to pull pretty much what a "show session" returns via SNMP. Rick -- Rick Payne, Senior Network Admin | Meddle not in the affairs of NETCOM Internet Ltd. | dragons - for you are crunchy & rickp@corp.netcom.net.uk | taste great dipped in chocolate.

Subject: FW: (usr-tc) overheating usr-tc's
From: buddy_venne@systax.com
Date: 1997-10-09 08:29:31

All - I have several modem chassis running too hot=2E Does anyone on the list =20 know where I can buy a 19" fan tray=2E The modem mfr can not help me=2E =20 inside our voicemail cabinet is a modifiable unit but they (Octel) want =20 $1450 for it=2E So I ask you all thanks bv ---------- Laszlo Vecsey <master@internexus=2Enet> writes: > Yes, thats what I do right now=2E=2E the fan is on its own 900watt UPS=2E= =20 But > as Bolen pointed out, it isn't even the fan that uses most of the =20 power=2E > I was mistaken=2E Also, I think the rack can overheat in less than 30 > minutes :) It gets very hot, very quickly without a fan=2E

Subject: Re: (usr-tc) slow connects
From: Michael Wronski <mwronski@coredump.ae.usr.com>
Date: 1997-10-09 08:55:51

At 10:42 PM 10/8/97 -0500, you wrote: > >I am still getting alot of users who are getting 16.8k and other slow >connects off 33.6+k modems. Does anyone know what setting in the Quads >could be hosed so I can go fix it? We use pri's and so they answer on the >packet bus. > >phone company comes out tommorow, I hope its bad phone lines or something >explainable. > >Brian > I had this problem at a previous employer with TC chassis.. It turned out to be incorrect provisioning and some extraneous AD/DA conversions at the Telco side.. -M

Subject: Re: (usr-tc) get user on port?
From: Michael Wronski <mwronski@coredump.ae.usr.com>
Date: 1997-10-09 09:01:15

At 06:04 AM 10/9/97 +0100, you wrote: >>>>>> "Michael" == Michael Wronski <mwronski@coredump.ae.usr.com> writes: > > Michael> Not at this time.. Your best bet is pmwho or to use RADIUS > >Does that mean its being considered? > >I'd certainly find it quite useful to be able to pull pretty much what a >"show session" returns via SNMP. > Its part of the NS 4.x (Non livingston based code). The new code is strongly tide to SNMP for all configuration and stat gathering. This is the code that runs on the HiPer Arc our new NS replacement. Its quite a bit more powerful than the current NS product. The NS 4.x code base is planned to be ported over to the 486 NS as well. I do not have any time lines, so please don't ask.. -M

Subject: (usr-tc) sec. & acct. version 4.3
From: Jim Faulkner II <jlf@montrose-colo.com>
Date: 1997-10-09 11:01:33

I recently upgraded?? my USR Radius security and accounting server from version 4.2 to 4.3 on my NT. Now I have periodic problems with users suddenly not being able to log on. The only fix seems to be to delete their account and re-enter it again. I talked to USR and they say they know they have a bug and will e-mail me the upgrade????? to 4.3.99 sometime today (if they can find it....I'm overwhelmed with confidence). I see that they still have the 4.3 version available on their web site to download and trash anybody else's system. Has any body else had problems with this? My primary sec & acc. server actually crashed this morning and my trusty backup rejected 318 out of less than 400 attempts. I'm really popular now. thanks, JR

Subject: (usr-tc) Need Netserver and T1 card
From: Greg Coffey <greg@coffey.com>
Date: 1997-10-09 11:02:39

I'm trying to put together a couple of scaled down TC racks and am in need of two netserver and 2 t1 cards. If you have any for sale, please email me. Greg Coffey, CoffeyNet 142 S. Center St. ** $20 local Casper USR x2 56k access ** Casper, WY 82601 Wheatland, Pinedale, Lander, Lusk http://www.coffey.com Douglas & Rawlins (307) 234-5443

Subject: Re: (usr-tc) get user on port?
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-09 11:18:36

Colin_McFadyen said once upon a time: > >I always liked being able to finger the Xylogics Annex boxes to get a >list of users, According to a USR rep, fingerd is coming with the new HiPer access servers.

Subject: Re: (usr-tc) Help: Connection Problems
From: James Cox <cox@ruby.wmesa.com>
Date: 1997-10-09 12:50:50

I've been having the same problems - identically! I've had the local telco look at, and everything is within specs, which is where I think the problem lies. Love to know what's going on. Jim At 07:41 PM 10/8/97 -0500, you wrote: >For the last 5 days we have had TOTAL chaos here. > >Users connect with like 12k-19.2k-21k connects. Many get Win95 DUN errors >such as "Cannot negotiate a compatible set of protocols", and many other >errors. > >

Subject: Re: FW: (usr-tc) overheating usr-tc's
From: Curt Shambeau <curt@execpc.com>
Date: 1997-10-09 12:55:13

> I have several modem chassis running too hot. Does anyone on the list > know where I can buy a 19" fan tray. The modem mfr can not help me. > inside our voicemail cabinet is a modifiable unit but they (Octel) want > $1450 for it. So I ask you all You can buy a US Robotics fan try alone. USR Part# 000668-0 List Price: $ 516.00 - Could probably get it for around $425 or so from a reseller of some sort. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Exec-PC Vice President, Information Services |

Subject: (usr-tc) net medic
From: pris sears <sears@vt.edu>
Date: 1997-10-09 13:24:55

Hi, folks - as predicted, net medic is bad news. I've heard from it a couple times in the last week - we had user that was not able to connect due to following net medic's advice (quote from support): "The user then revealed to me that net.medic told him to increase the port speed because 'Your modem is not working at peak efficiency'." and it sent a nice note to admin@vt.edu from a different user: > It appears that the local router I am connected into frequently experiences > heavy traffic levels. You may find the following information useful. > [snip many more lines] There was no evidence the user even knew he had generated this email. There is a fair amount of grumbling from support about this and no one is looking forward to more. We've been supporting USR user modems, but are considering changing that next year because of it. Are others seeing support issues cropping up from net medic use? - Pris _________________________________________________________ Pris Sears | sears@vt.edu | http://sears.cns.vt.edu/ | 231-2305

Subject: (usr-tc) Unusual Problem
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1997-10-09 15:24:00

We have a TC node running the supplied MS Access 7.0 version of RADIUS. The problem we are having is with static IP addresses and the NMC card. We setup a test user account and assigned a static IP address outside of the address pool for the rest of the users. Everything works fine, we can connect through the TC hub into the Internet, telnet to the netserver wtc.. However, what doesn't work is the TCM software. We tracked the cause down to the static IP address. When it is installed, the NMC will not respond to any ICMP messages, thus no SNMP, ping, TCM etc.. Removing the static IP address fixes everything. If I wasn't able to get to a certain range of devices, I'd think I had a routing problem but everything works except the NMC card. Thoughts ? Jeff Binkley ASA Network Computing

Subject: Re: (usr-tc) slow connects
From: Brian <signal@shreve.net>
Date: 1997-10-09 16:22:14

On Thu, 9 Oct 1997, Michael Wronski wrote: > At 10:42 PM 10/8/97 -0500, you wrote: > > > >I am still getting alot of users who are getting 16.8k and other slow > >connects off 33.6+k modems. Does anyone know what setting in the Quads > >could be hosed so I can go fix it? We use pri's and so they answer on the > >packet bus. > > > >phone company comes out tommorow, I hope its bad phone lines or something > >explainable. > > > >Brian > > > > I had this problem at a previous employer with TC chassis.. It turned out > to be > incorrect provisioning and some extraneous AD/DA conversions at the Telco > side.. > But these are with PRI's/spans that have always worked fine in the past.......... Brian > -M > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: Re: (usr-tc) Help: Connection Problems
From: Brian <signal@shreve.net>
Date: 1997-10-09 16:46:20

On Thu, 9 Oct 1997, James Cox wrote: > I've been having the same problems - identically! I've had the local telco > look at, and everything is within specs, which is where I think the problem > lies. Love to know what's going on. > > Jim wierd.........let me know if you find out anything. Brian > > > At 07:41 PM 10/8/97 -0500, you wrote: > >For the last 5 days we have had TOTAL chaos here. > > > >Users connect with like 12k-19.2k-21k connects. Many get Win95 DUN errors > >such as "Cannot negotiate a compatible set of protocols", and many other > >errors. > > > > > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: Re: (usr-tc) Help: Connection Problems
From: Curt Shambeau <curt@execpc.com>
Date: 1997-10-09 16:51:51

> For the last 5 days we have had TOTAL chaos here. > > Users connect with like 12k-19.2k-21k connects. Many get Win95 DUN errors > such as "Cannot negotiate a compatible set of protocols", and many other > errors. > > The modems here pick up, the connection (from the clients end) sounds > TERRIBLE......the modems take forever to connect, if they even do at all. > Many times they connect and the user is dropped minutes later. > > What in all your experiences have you seen this type of stuff? I am > thinking telco. Alot of users claim no problems at all. We cant see that > it follows a particular hub or modem either which is odd. I really need > to get this fixed. We use Channelized T1's, but I have had the exact same thing happen to me. First, do a couple of "Force receiever reframe" commands on the T1's. If that doesn't clear it up, get your TELCO on the phone - I've seen where the CSU/DSU doesn't record any errors, but the TELCO end of things are screwed up. Sometimes just having them tear down the circuit for testing, and plugging it back in works. I've also seen this when there is a TELCO interoffice trunking problem. Some users who get trunked in through a specific C.O. have problems, but no other users do. In that case, take down the phone prefix of the users who call your tech support, compile them, and give the info to your TELCO. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Exec-PC Vice President, Information Services |

Subject: Re: (usr-tc) get user on port? (fwd)
From: Michael Wronski <mwronski@coredump.ae.usr.com>
Date: 1997-10-09 17:10:00

At 12:11 PM 10/9/97 -0500, you wrote: >On Thu, 9 Oct 1997, Michael Wronski wrote: >> And as for pmwho.. on a usr-tc list.. I see no reason to write a new tool >> when one >> exists that works.. Our NS code and Liv have the same code base and look >> and feel. > >I see. I just wanted to make you aware that pmwho doesn't work with 3.6 >and certainly not 4.0. If users come to depend on that tool to get user >lists and it doesn't work with the new code. . . Well, I'll post my >version of pmwho somewhere and save the day. > >> you happy, rename the file to usrwho. Just give the author credit. > >Don't you mean 3cwho? :) Sorry. Couldn't resist. Well, since you suggested it.. Here is a candidate for 3cwho. This is a perl program I wrote that provides the same data as pmwho.. Its rough, but works and is easily extendable to show any data available on the netserver. Please do not ask for any support. Most of it is fairly straight forward and easy to understand. Comments in code should get you off and running quickly. For information on perl sockets check the O'Reilly Camel book. This is NOT a 3Com product and it carries no warranty or guaranty. Test it before turning it loose on production systems. I have done some testing and found no problems, but don't cry to me if you run into any.. -Mike ----begin perl CUT HERE---- #!/bin/perl # # perl program to show sessions on netserver # Mike Wronski (mike@coredump.ae.usr.com) # This is NOT A 3COM product! # This carries with it no warranties or guarantees. Use at your own risk. # Please do not e-mail me with questions regarding usage,features or requests # This is simple perl and can easily be modified for your tastes. # require 5.002; use Socket; $|=1; $PWD = $ENV{PWD}; #### CONFIGURE THESE #### $SCREEN_LEN = 23; #used for paging. Should work at this value for everyone $PAGING = 1; #set to 0 if you dont want program to page its output or use -p option $port = 23; #change to reflect your telnet port $PROMPT = 'Command> '; #change this if you chnaged the default prompt on your NS $SERVER_FILE = "$PWD/.servers"; #flat file containg servers and passwords (NOT SECURE!) $LOGIN_PROMPT = 'ogin:'; #last few chars of your login prompt $PASSWORD_PROMPT = 'word:'; # last few chars of your password prompt: $ROOT = '!root'; #shouldt change for NS Livingston does if you use it for NS 4.x stuff #### END CONFIGURE SECTION #### load_servers(); get_opt(); @Keys = sort (keys %SERVERS) if !$NOLOOP; foreach $server (@Keys) { print "$server\n"; connectto($server,$port) || next; #add commands here ########################################### # simple show session, could be anything. command("sh sess\n",$PROMPT,0,2,20); # ########################################### #always finsh here disconnect(); } exit; ###PROCEED BELOW ONLY IF YOUR FAMILIAR WITH PERL### # ### BEGIN SUBS ######### sub usage { print "usage: $0 |-p|-h| <hostname> <password>\n"; exit(1); } sub command { local ($SEND_STR,$TARGET,$SND_OP,$WAIT_OP,$TIMEOUT) = @_; die "$0: Invalid call to subroutine command\n" if $#_ != 4; sendit($SEND_STR,$SND_OP); waitfor($TARGET,$WAIT_OP,$TIMEOUT); } sub get_opt { #simple imp. -p -h must be first to be recognized. #get any host/password info from the command line #local($ops)=$#ARGV+1; if ($#ARGV > -1 ) { $NOLOOP = 1; #dont use data from .servers file $Keys[0] = shift @ARGV; if ($Keys[0] eq '-p' ) { $PAGING = 0; $Keys[0] = shift @ARGV; } usage() if $Keys[0] eq '-h'; if ($#ARGV > -1 ) { $password = shift @ARGV; $SERVERS{$Keys[0]} = $password if $password; if ($#ARGV > -1 ) { warn "$0: Extra arguments ignored\n"; } } if (!$password) { #if only hostname was on command line - get pw from file data $password = $SERVERS{$Keys[0]} || die "$0: Password for $Keys[0] not in file\n"; } } } sub load_servers { # file format is hostname:password with one per line local($server,$password); if (-r $SERVER_FILE) { $server_count=0; #load servers & passwords from file open(INFILE,$SERVER_FILE); while(<INFILE>) { if ($_ =~ /\;/) { #comment line - skipt it next; } ($server,$password) = split(":",$_); $SERVERS{$server}=$password; $server_count++; } } else { warn "$0: No servers file.\n"; usage() if $#ARGV == 0; } } sub login { local($password) = @_; sendit("\n",0); waitfor($LOGIN_PROMPT,0,20); sendit("$ROOT\n",0); waitfor($PASSWORD_PROMPT,0,20); sendit("$password\n",0); } sub connectto { local($host,$port,$iaddr,$paddr,$proto,$line); ($host,$port) = @_; local($FAIL)=1; if ($port =~ /\D/) { $port = getservbyname($port,'tcp') } die "No Port!" unless $port; $iaddr = inet_aton($host) or die "$0: $host Invalid Host\n"; $paddr = sockaddr_in($port,$iaddr); $proto = getprotobyname('tcp'); socket(SOCK,PF_INET,SOCK_STREAM,$proto) or die "$0: socket: $!"; eval { # we dont want to hang forever local $SIG{ALRM} = sub { warn "$0: Timeout connecting to $host\n";$FAIL=0;}; alarm 10; #set the clock ticking! connect(SOCK, $paddr) or die "$0: Can't connect :$!"; }; alarm 0; #stop the clock! return($FAIL) if !$FAIL; login($SERVERS{$server}); waitfor($PROMPT,0,10); return($FAIL); } sub disconnect { sendit("\n",0); waitfor($PROMPT,0,10); sendit("exit\n",0); close(SOCK); print "\n"; } sub sendit { #### options #### # sendit(STRING,OPTION); # STRING - any string # OPTION - 0 = dont echo local # 1 = echo local local($target,$print) = @_; $len = length($target); if ($print == 1) { print $target."\n"; } else { #print "\n"; } syswrite(SOCK ,$target, $len); } sub waitfor { #### options ###### # waitfor(PATTERN,OPTION,TIMEOUT); # pattern - any pattern not a regx # option - 0=wait for pattern and display nothing # 1=wait for pattern, display all text received including line pattern is on # 2=wait for pattern, display all text received excluding line pattern is on # timeout - will wait ~TIMEOUT seconds before giving up. # local(@BUFFER,$line,$a,$len,$target,$print,$pid,$line_count,$i); local ($target,$print,$timeout) = @_; $timeout=10 if !$timeout; $a=""; $len=0; $line=""; $line_count = 0; eval { # we dont want to hang forever local $SIG{ALRM} = sub { print STDERR "$0: Timeout wating for $target\n";exit 1;}; alarm $timeout; #set the clock ticking! while (read SOCK,$a,1 ) { $len++; $line = $line.$a; if ($line =~ /$target/) { # found target print and get out! push @BUFFER,$line if $print == 1; $line_count++ if $print==1; last; } if ($line =~ /More --/) { #handle NS paging syswrite(SOCK,"\n",1); read SOCK,$a,1; #clears some random extra character. $line=""; $a=""; $len=0; next; } if ($line =~ /Invalid Login/) { #bad password! alarm 0; #reset the clock warn "$0: $server Invalid Login!\n"; exit 1; } if ($a eq "\n") { @temp = split(" ",$line); if ($temp[1] eq '-') { #nothing skip these lines } else { push @BUFFER,$line if $print >= 1; $line_count++ if $print >= 1; } $line = ""; $len = 0; } } alarm 0; #reset the clock! local($printed)=0; #dump the results. for ($i=0; $i < $line_count; $i++) { #page though file 23 lines at a time.. print "$BUFFER[$i]"; $printed++; if ($printed == $SCREEN_LEN && $PAGING) { $printed=0; print "-- Press Return for More -- "; $crap = <STDIN>; last if $crap =~ /^q/; } } print_it($print); };# end eval block } --- end perl ---

Subject: Re: (usr-tc) slow connects
From: Russ Panula <rpanula@dacmail.net>
Date: 1997-10-09 17:40:00

On Thu, 9 Oct 1997 16:22:14 -0500 (CDT), Brian <signal@shreve.net> wrote: >But these are with PRI's/spans that have always worked fine in the >past.......... Have you tried installing a new cable between the smartjack and your rack? Are you getting tons of framing errors on the spans? (jump into the T1/PRI console, select status, then span line alarm/event status)

Subject: Re: (usr-tc) slow connects
From: Brian <signal@shreve.net>
Date: 1997-10-09 18:26:27

On Thu, 9 Oct 1997, Russ Panula wrote: > On Thu, 9 Oct 1997 16:22:14 -0500 (CDT), Brian <signal@shreve.net> > wrote: > > >But these are with PRI's/spans that have always worked fine in the > >past.......... > > Have you tried installing a new cable between the smartjack and your > rack? > > Are you getting tons of framing errors on the spans? (jump into the > T1/PRI console, select status, then span line alarm/event status) > > > I seem to have a large amount of errors on my first hubs pri lines.........these are whats been causing my problems. Telco has been contacted, and I have verified and REFLASHED the pri code and am still having the problems, configuration has been verified! HUB #1 Span Line 1 Alarm/Event Status Time since clear (days::hh:mm:ss): 0::23:11:24 Receiver Gain: 0.0 dB Errored Seconds: 270 Severely Errored Seconds: 269 Failed Seconds: 279 Bipolar Violations: 1626 Framing Bit Errors: 61617 Change In Frame Alignment: 1 Frame Slips: 1 Bursty Errored Seconds (ESF Only): 1 CRC Errors (ESF Only): 65535 Excessive CRC Error (ESF Only): 0 Out of Frame: N Out of Frame: (Red Alarm): N Loss of Signal: N Loss of Signal: (Red Alarm): N Remote Frame Alarm: N Remote Frame Alarm: (Yellow Alarm): N Alarm Indication Signal: N Alarm Indication Signal: (Blue Alarm): N Loop Back: None D-Channel Status: Up Span Line 2 Alarm/Event Status Time since clear (days::hh:mm:ss): 0::23:12:12 Receiver Gain: 0.0 dB Errored Seconds: 275 Severely Errored Seconds: 274 Failed Seconds: 284 Bipolar Violations: 4134 Framing Bit Errors: 1070 Change In Frame Alignment: 1 Frame Slips: 2 Bursty Errored Seconds (ESF Only): 1 CRC Errors (ESF Only): 65535 Excessive CRC Error (ESF Only): 0 Out of Frame: N Out of Frame: (Red Alarm): N Loss of Signal: N Loss of Signal: (Red Alarm): N Remote Frame Alarm: N Remote Frame Alarm: (Yellow Alarm): N Alarm Indication Signal: N Alarm Indication Signal: (Blue Alarm): N Loop Back: None D-Channel Status: Up HUB #2 Span Line 1 Alarm/Event Status Time since clear (days::hh:mm:ss): 0::23:35:12 Receiver Gain: 7.5 dB Errored Seconds: 2 Severely Errored Seconds: 1 Failed Seconds: 0 Bipolar Violations: 474 Framing Bit Errors: 0 Change In Frame Alignment: 1 Frame Slips: 1 Bursty Errored Seconds (ESF Only): 0 CRC Errors (ESF Only): 25 Excessive CRC Error (ESF Only): 0 Out of Frame: N Out of Frame: (Red Alarm): N Loss of Signal: N Loss of Signal: (Red Alarm): N Remote Frame Alarm: N Remote Frame Alarm: (Yellow Alarm): N Alarm Indication Signal: N Alarm Indication Signal: (Blue Alarm): N Loop Back: None D-Channel Status: Up Span Line 2 Alarm/Event Status Time since clear (days::hh:mm:ss): 0::23:35:23 Receiver Gain: 0.0 dB Errored Seconds: 3 Severely Errored Seconds: 1 Failed Seconds: 0 Bipolar Violations: 1 Framing Bit Errors: 0 Change In Frame Alignment: 1 Frame Slips: 2 Bursty Errored Seconds (ESF Only): 0 CRC Errors (ESF Only): 7 Excessive CRC Error (ESF Only): 0 Out of Frame: N Out of Frame: (Red Alarm): N Loss of Signal: N Loss of Signal: (Red Alarm): N Remote Frame Alarm: N Remote Frame Alarm: (Yellow Alarm): N Alarm Indication Signal: N Alarm Indication Signal: (Blue Alarm): N Loop Back: None D-Channel Status: Up HUB #3 Span Line 1 Alarm/Event Status Time since clear (days::hh:mm:ss): 1::0:3:27 Receiver Gain: 0.0 dB Errored Seconds: 3 Severely Errored Seconds: 1 Failed Seconds: 0 Bipolar Violations: 1 Framing Bit Errors: 0 Change In Frame Alignment: 1 Frame Slips: 2 Bursty Errored Seconds (ESF Only): 0 CRC Errors (ESF Only): 8 Excessive CRC Error (ESF Only): 0 Out of Frame: N Out of Frame: (Red Alarm): N Loss of Signal: N Loss of Signal: (Red Alarm): N Remote Frame Alarm: N Remote Frame Alarm: (Yellow Alarm): N Alarm Indication Signal: N Alarm Indication Signal: (Blue Alarm): N Loop Back: None D-Channel Status: Up Span Line 2 Alarm/Event Status Time since clear (days::hh:mm:ss): 1::0:3:48 Receiver Gain: 0.0 dB Errored Seconds: 1 Severely Errored Seconds: 1 Failed Seconds: 0 Bipolar Violations: 8 Framing Bit Errors: 0 Change In Frame Alignment: 1 Frame Slips: 0 Bursty Errored Seconds (ESF Only): 0 CRC Errors (ESF Only): 7 Excessive CRC Error (ESF Only): 0 Out of Frame: N Out of Frame: (Red Alarm): N Loss of Signal: N Loss of Signal: (Red Alarm): N Remote Frame Alarm: N Remote Frame Alarm: (Yellow Alarm): N Alarm Indication Signal: N Alarm Indication Signal: (Blue Alarm): N Loop Back: None D-Channel Status: Up /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: (usr-tc) Detecting Overheating (script to do so)
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1997-10-09 19:34:08

Here's a little Unix script I use on my TC racks to update the NMC LED display with a number and the current temperature. For example, if TC unit 3 is at 89 degrees, it sets the display to `3 89'. If it's over 100 degrees, then it doesn't print the rack number. This naming scheme may not work well if you have more than 9 racks; in such a case, the temperature will be truncated on the display. My NMCs are named N.usr.mgmt within my domain, so they can be addressed as 1.usr.mgmt, 2.usr.mgmt, 3.usr.mgmt, and 4.usr.mgmt. I call it, thus, as set_usr_display 1 2 3 4 to update all of my units. If the temperature is >=39C, it calls a program called `beep', that, on my system, pages me. You can comment that out, or adapt it to your local paging system. This Bourne shell script requires the CMU SNMP utilities with the USR mibs in /etc/mib.txt, bc, cut, and logger for recording the data in syslog. The local2 facility on my system is devoted to environmental factors such as this. Let me know if you find this useful; I'd be interested to hear if it or the idea is in use somewhere else. --- Mark R. Lindsey, mark@datasys.net Network Engineer, DSS Online Voice: +1 912 241 0607; Fax: +1 912 241 0190 #!/bin/sh - # Set the hub display number on a USR with its number and temperature # Mark Lindsey, Wed Aug 20 14:16:38 EDT 1997 # <mark@datasys.net> # Maximum operating temperature, in Celsius max_operating_temperature_c=39 # Note: it's actually 40, but we'd want to be alarmed before we hit the # max temperature. # This is the suffix that's appended to the number given on the cmd line suffix=usr.mgmt # Private (rw) community community=private # Syslog facility for logging environmental factors facility=local2 export PREFIX=.iso.org.dod.internet.private.enterprises.usr for hub_number in $@ do hub_name=$hub_number.$suffix # Get the temperature in Celsius hub_temperature_c_temp=`snmpget $hub_name $community nas.nmc.nmcStat.nmcStatTemperature 2>/dev/null` || continue hub_temperature_c=`echo $hub_temperature_c_temp | cut -d' ' -f3` # Convert temperature to Fahrenheit; I use gnu bc hub_temperature_f=`echo "($hub_temperature_c * 9/5) + 32" | bc` # Determine whether to beep us with an alarm if [ $hub_temperature_c -ge $max_operating_temperature_c ]; then ## This uses a custom program `beep' to page me. beep "Temperature on USR hub $hub_number is too high! ($hub_temperature_f degrees F)" root logger -t "$hub_number.usr" -p $facility.warning "Temperature: $hub_temperature_f degrees F TEMPERATURE TOO HIGH!" else # Log the temperature logger -t "$hub_number.usr" -p $facility.info "Temperature: $hub_temperature_f degrees F" fi # If the temperature is three digits long, then don't dislay # the hub number if [ $hub_temperature_f -ge 100 ]; then display_string=" $hub_temperature_f" else display_string="$hub_number $hub_temperature_f" fi # Set the number snmpset $hub_name $community nas.chs.uchasConfig.uchasDisplayName s "$display_string" 2>&1 >/dev/null done

Subject: Re: (usr-tc) slow connects
From: eric@dol.net
Date: 1997-10-09 20:22:17

At 05:40 PM 10/9/97 -0600, you wrote: >On Thu, 9 Oct 1997 16:22:14 -0500 (CDT), Brian <signal@shreve.net> >wrote: > >>But these are with PRI's/spans that have always worked fine in the >>past.......... > >Have you tried installing a new cable between the smartjack and your >rack? > >Are you getting tons of framing errors on the spans? (jump into the >T1/PRI console, select status, then span line alarm/event status) > Is usr ever going to improve this function? I think it is archaic (sp) that i have to have a modem at a remote site to get into the pri card. This needs to be done via the net from say the. nmc or setserver card. Delaware Online!.........The SMART Choice! With 56K X2 Modems Phone : 302-762-0375 Fax: 302-762-3462 WWW: www.dol.net Eight out of five people have a problem understanding statistics! ****************Customer support is our bottom line!*********************

Subject: Re: (usr-tc) slow connects
From: Russ Panula <rpanula@dacmail.net>
Date: 1997-10-09 20:58:26

On Thu, 9 Oct 1997 18:26:27 -0500 (CDT), Brian <signal@shreve.net> wrote: >HUB #1 >---------------------------------- > Span Line 1 Alarm/Event Status > > Time since clear (days::hh:mm:ss): 0::23:11:24 > Receiver Gain: 0.0 dB > Errored Seconds: 270 > Severely Errored Seconds: 269 > Failed Seconds: 279 > Bipolar Violations: 1626 > Framing Bit Errors: 61617 > Change In Frame Alignment: 1 > Frame Slips: 1 > Bursty Errored Seconds (ESF Only): 1 > CRC Errors (ESF Only): 65535 > Excessive CRC Error (ESF Only): 0 > Out of Frame: N Out of Frame: (Red Alarm): N > Loss of Signal: N Loss of Signal: (Red Alarm): N > Remote Frame Alarm: N Remote Frame Alarm: (Yellow Alarm): N > Alarm Indication Signal: N Alarm Indication Signal: (Blue Alarm): N > Loop Back: None > D-Channel Status: Up > > Span Line 2 Alarm/Event Status > > Time since clear (days::hh:mm:ss): 0::23:12:12 > Receiver Gain: 0.0 dB > Errored Seconds: 275 > Severely Errored Seconds: 274 > Failed Seconds: 284 > Bipolar Violations: 4134 > Framing Bit Errors: 1070 > Change In Frame Alignment: 1 > Frame Slips: 2 > Bursty Errored Seconds (ESF Only): 1 > CRC Errors (ESF Only): 65535 > Excessive CRC Error (ESF Only): 0 > Out of Frame: N Out of Frame: (Red Alarm): N > Loss of Signal: N Loss of Signal: (Red Alarm): N > Remote Frame Alarm: N Remote Frame Alarm: (Yellow Alarm): N > Alarm Indication Signal: N Alarm Indication Signal: (Blue Alarm): N > Loop Back: None > D-Channel Status: Up It's odd that both PRI's look bad...that might point to a bad PRI card. Plug those bad boys into another PRI card. If that doesn't work, try using new cables. If that still doesn't work, it's probably a telco problem. Open a ticket with them and have them loop to the smartjack and run some patterns through it. If the telco still can't see a problem and you've tried different cables and PRI cards, have them come on site with a T-Berd to check whatever wiring they are responsible for. If they *still* cannot find anything, talk them into simulating your circuit with the T-Berd and plug it directly into your hub using whatever wiring the telco is not responsible for to see if your in-house wiring has been hexed. >HUB #2 >------------------------------------------------ > Span Line 1 Alarm/Event Status > > Time since clear (days::hh:mm:ss): 0::23:35:12 > Receiver Gain: 7.5 dB Receiver Gain at 7.5dB? Is there a reason for this? Regards, Russ (wishing he had a T-Berd so he could tell USWest when to shove it)

Subject: Re: (usr-tc) Detecting Overheating (script to do so)
From: Russ Panula <rpanula@dacmail.net>
Date: 1997-10-09 21:16:31

Ok, who's going to set up a USR-TC specific script web/ftp site...?

Subject: Re: (usr-tc) slow connects
From: Brian <signal@shreve.net>
Date: 1997-10-09 22:24:59

> > >HUB #2 > >------------------------------------------------ > > Span Line 1 Alarm/Event Status > > > > Time since clear (days::hh:mm:ss): 0::23:35:12 > > Receiver Gain: 7.5 dB > > Receiver Gain at 7.5dB? Is there a reason for this? > > Regards, > Russ > (wishing he had a T-Berd so he could tell USWest when to shove it) > is there a way to change it? where? I thought the hub automatically sets this. Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: Re: (usr-tc) slow connects
From: David Bolen <db3l@ans.net>
Date: 1997-10-09 22:45:46

eric@dol.net writes: > Is usr ever going to improve this function? I think it is archaic (sp) that > i have to have a modem at a remote site to get into the pri card. > This needs to be done via the net from say the. nmc or setserver card. It can be - you can get at this information from the NMC over SNMP. The stats are not necessarily computed exactly the same way (the TTY is a continuous counter, while via the NMC is a DS1 interval MIB with 15-minute intervals), but between that and the USR-specific DS1 configuration/status MIB objects, the information is available. Check out the DS0, DS1, and UDS1 MIBs. Of course, I still keep all of my TTY ports on all cards wired up for remote access (via a local terminal server so I need a single OOB line for the rack). Every so often the TTY debugging output can come in handy, or if I manage to brick the NMC or management connection to the card I can perform a TTY software download of new code. Always good to have a fallback :-) I think that as of the TCS 2.5.1 PRI code there are only two status screens available on the TTY that aren't accessible via the NMC (the chassis slow device configuration and the ISDN-gateway device status by slot). Even that is too many, as I think _everything_ should be doable through the NMC, but it's not too bad as far as coverage goes. -- 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) net medic
From: David Carter <david@corp.netcom.net.uk>
Date: 1997-10-10 02:46:13

Dear Pris, > considering changing that next year because of it. Are others seeing > support issues cropping up from net medic use? Yes. It's terrible with noisy lines and it's stupid reports about the egress router. I field many "complaints" from users which turn out to be their modem or telco issues, because of it's reports. Often people install it to diagnose a problem they see, then approach us with the attitude "your equipment is wonky" - this needles me. Someone from VitalSigns called me and informed me that they we aware of the bugs which I'd illustrated to them. However, given their methods of extracting data, I would steer clear of this software, even if they do "iron them out". Even if their methods were sound there are no two identical ISPs, and therefore results will always vary with automated report tools. Regards, -- David Carter, 2nd Level Support, NETCOM Internet. david@corp.netcom.net.uk As for the future, your task is not to forsee it, but to enable it. Antoine de Saint-Exupery

Subject: (usr-tc) RE: (USR-TC) UNUSUAL PROB
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1997-10-10 08:32:00

DB>> Removing the static IP address fixes DB>> everything. If I wasn't able to get to a certain range of devices, DB>> I'd think I had a routing problem but everything works except the DB>> NMC card. Thoughts ? DB>It would probably help to have some actual addresses and routing DB>information for your environment as well as any information you may DB>have in terms of traceroutes or other pointers that might indicate DB>exactly at what point the packets stop flowing in the right DB>direction. Tests from different points might help indicate if the DB>problem is in the forward or reverse (response) direction. DB>One thought (but its a reach) would be that if somehow your static DB>address was from the same block as your NMC is in, and if you have DB>routing announcements on by default from the NETServer and it is DB>still using RIP1 then the activation of that user might announce the DB>entire classful prefix containing the static route and then other DB>boxes on the wire (like perhaps your site router) would incorrect DB>send the NMCs traffic to the NETServer instead. DB>But it's hard to say without seeing the relationship between your DB>ethernet addressing, static address and routing setup. David, Thanks for attempting to help me troubleshoot this but I was really wanting to know if there were any inherent problems that folks knew about with routing between the Netserver and the NMC when RADIUS assigns static IP addresses. I believe I have a handle on it now. Thanks, Jeff Binkley ASA Network Computing CMPQwk 1.42 9999

Subject: Re: (usr-tc) Problems
From: Craig Nelson <craig@jetcity.com>
Date: 1997-10-10 10:43:23

We also saw similar problems last Friday and Saturday - went in a upgraded 2 of our racks, everything went fine, then that very night the third rack, the one I specifically left completely alone, started freaking with these same errors - dropping people during authentication. Reseting the modems seemed to fix things, but it degraded again quickly. I finally was able to clear it up by hard-resetting the netserver. At 07:25 PM 10/6/97 -0500, you wrote: >On Mon, 6 Oct 1997 eric@dol.net wrote: > >> I think it must be a solar flare. We had some of the same problems this >> weekend reported by customers. We seem to be fine right now. A friend with >> one tc system had to reflash his entire chassis on Sunday and then >> everything was fine but he experienced custoemrs not connecting and failing >> with the famous dun error. >> eric >> > > > > > >Anyone else see these problems, or just us? > >Brian > > > > > > > >> >> At 06:39 PM 10/6/97 -0500, you wrote: >> >All of the sudden, since Friday, we have had alot of users call and say >> >they are having problems connecting. It drops them after a few minutes. >> > >> >Some users said there dialup networking says "Cannot negotiate compatible >> >protocols", Others get wierd numeric errors. >> > >> >Are any of you seeing any of this? I am thinking MSIE 4.0 hosed there >> >systems, but havent ruled out my end of the link just yet. >> > >> >Brian >> > >> > >> >/-------------------------- signal@shreve.net >> >| Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | >> >| Systems Administrator | Perl, Linux | Web hosting, online stores, | >> >| ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | >> >| 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | >> >| headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | >> >\-------------------------- 318-222-2638 x109 >> > >> > >> > >> > >> Delaware Online!.........The SMART Choice! With 56K X2 Modems >> Phone : 302-762-0375 Fax: 302-762-3462 WWW: www.dol.net >> Eight out of five people have a problem understanding statistics! >> ****************Customer support is our bottom line!********************* >> >> >> > >/-------------------------- signal@shreve.net -----------------------------\ >| Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | >| Systems Administrator | Perl, Linux | Web hosting, online stores, | >| ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | >| 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | >| headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | >\-------------------------- 318-222-2638 x109 -----------------------------/ > > > > > <.>-----------------------------------------------<.> The thing about Crayons is, They can take take you more places than Starships -Guinan <.>-----------------------------------------------<.>

Subject: Re: (usr-tc) net medic
From: pris sears <sears@vt.edu>
Date: 1997-10-10 12:38:49

At 2:46 AM 10/10/97, David Carter wrote: >Dear Pris, > >> considering changing that next year because of it. Are others seeing >> support issues cropping up from net medic use? > >Yes. It's terrible with noisy lines and it's stupid reports about the >egress router. I field many "complaints" from users which turn out to be >their modem or telco issues, because of it's reports. Often people >install it to diagnose a problem they see, then approach us with the >attitude "your equipment is wonky" - this needles me. > >Someone from VitalSigns called me and informed me that they we aware of >the bugs which I'd illustrated to them. However, given their methods of >extracting data, I would steer clear of this software, even if they do >"iron them out". Even if their methods were sound there are no two >identical ISPs, and therefore results will always vary with automated >report tools. Thanks for the info, David. I am suggesting to our powers that be that we offically refuse to support it, and post such prominently on our web pages, especially the "recommended modems" pages. I like David Lesher's response to a request for net medic info I saw on comp.dcom modems:

Subject: Re: (usr-tc) slow connects
From: David Bolen <db3l@ans.net>
Date: 1997-10-10 14:32:25

Brian <signal@shreve.net> writes: > > > Time since clear (days::hh:mm:ss): 0::23:35:12 > > > Receiver Gain: 7.5 dB > > > > Receiver Gain at 7.5dB? Is there a reason for this? (...) > is there a way to change it? where? I thought the hub automatically sets > this. It does and in and of itself it shouldn't represent a problem. You can control your own transmission (or often termed the line build out (LBO)) gain but the card will automatically perform its own equalization on the input side based on the signal strength it is receiving from the telco. The reason you may have a non-zero receiver gain is if the connection between your gear is lengthy. I may be off on the length ranges slightly, but I think a gain of 0 is for handling 0-150ft lengths whereas 7.5dB is the next range (150-300). You can also see 15dB (300-450) or 22dB (450+) although I don't know that I've actually ever seen a circuit run with 22dB - normally instead that is an indication that something is physically wrong with the span and the card is simply trying to boost the signal as much as it can to no effect. We have however operated in situations with 15dB gain (it was a building in Houston where the telco demarc was in the basement and the connection to our equipment on an upper floor was a single copper span). Of course, if you used to have a gain of 0, and suddenly it changed to 7.5dB it might be an indication that your telco has "re-engineered" (which they love to do without any notice, although that's typically in the central office and not necessarily at your premises) your circuit. So as such it might be another piece in the puzzle if this is a hub exhibiting poorer quality connections. But that's a question of change and not the absolute value. -- 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) x2 capible
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-10 17:13:03

Brian said once upon a time: >Is there a way via TCM, to tell users if there line is x2 capible, like >usr's line test does? > >I mean can I check the signal-to-noise ratio, or some MIB or something >that will tell me if x2 will work, at least a good chance of it working? There is, and we talked with Paul from USR about what specs on the SNMP MIBs will give us the necessary information to determine this. We're trying to work something up that will enable people to check this via a web page. The hardest thing is tying a modem to a RADIUS login. The best idea we've had is to ask for their phone number and then find their modem via CID. Paul sent us a paper detailing what to look for. I'm not sure if we're permitted to redistribute it or not, but if it is OK, I'll put it in the archives.

Subject: Re: (usr-tc) slow connects
From: Brian <signal@shreve.net>
Date: 1997-10-10 17:18:56

On Fri, 10 Oct 1997, David Bolen wrote: > Brian <signal@shreve.net> writes: > > > > > Time since clear (days::hh:mm:ss): 0::23:35:12 > > > > Receiver Gain: 7.5 dB > > > > > > Receiver Gain at 7.5dB? Is there a reason for this? > (...) > > is there a way to change it? where? I thought the hub automatically sets > > this. > > It does and in and of itself it shouldn't represent a problem. You > can control your own transmission (or often termed the line build out > (LBO)) gain but the card will automatically perform its own > equalization on the input side based on the signal strength it is > receiving from the telco. > > The reason you may have a non-zero receiver gain is if the connection > between your gear is lengthy. I may be off on the length ranges > slightly, but I think a gain of 0 is for handling 0-150ft lengths > whereas 7.5dB is the next range (150-300). You can also see 15dB > (300-450) or 22dB (450+) although I don't know that I've actually ever > seen a circuit run with 22dB - normally instead that is an indication > that something is physically wrong with the span and the card is > simply trying to boost the signal as much as it can to no effect. We > have however operated in situations with 15dB gain (it was a building > in Houston where the telco demarc was in the basement and the > connection to our equipment on an upper floor was a single copper span). Our demarks are in the same room as our hubs (pairgain card), the cable between the pairgain and usr hub is about a 15ft cable..........does it sound like something may be the matter? Brian > > Of course, if you used to have a gain of 0, and suddenly it changed to > 7.5dB it might be an indication that your telco has "re-engineered" > (which they love to do without any notice, although that's typically > in the central office and not necessarily at your premises) your > circuit. So as such it might be another piece in the puzzle if this > is a hub exhibiting poorer quality connections. But that's a question > of change and not the absolute value. > > -- David > > /-----------------------------------------------------------------------\ > \ David Bolen \ Internet: db3l@ans.net / > | ANS Communications, Inc. \ Phone: (914) 701-5327 | > / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ > \-----------------------------------------------------------------------/ > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: Re: (usr-tc) net medic
From: Phillip Kippen <kippen1@ecom.net>
Date: 1997-10-10 17:35:49

Just a quick note on Net Medic: I tested the program on a completely empty network running 5 TC's, a full T and a Cisco 2514 using IGRP. I added one static route that I used for the test and low and behold..... Net Medic Reported Signs of Router Egress on a router which had absolutely no saturation. Hmmm sounds a ridiculous to me. Deffinately stay clear of this product and if you can, dedicate some free space on your home page to publish a few remarks about why their software if such a pile of &$#% ! Take care, Phil Kippen David Carter wrote: > Dear Pris, > > > considering changing that next year because of it. Are others seeing > > support issues cropping up from net medic use? > > Yes. It's terrible with noisy lines and it's stupid reports about the > egress router. I field many "complaints" from users which turn out to be > their modem or telco issues, because of it's reports. Often people > install it to diagnose a problem they see, then approach us with the > attitude "your equipment is wonky" - this needles me. > > Someone from VitalSigns called me and informed me that they we aware of > the bugs which I'd illustrated to them. However, given their methods of > extracting data, I would steer clear of this software, even if they do > "iron them out". Even if their methods were sound there are no two > identical ISPs, and therefore results will always vary with automated > report tools. > > Regards, > -- > David Carter, 2nd Level Support, NETCOM Internet. > david@corp.netcom.net.uk > As for the future, your task is not to forsee it, but to enable it. Antoine de Saint-Exupery

Subject: (usr-tc) x2 capible
From: Brian <signal@shreve.net>
Date: 1997-10-10 18:02:36

Subject: Re: (usr-tc) x2 capible
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-10 18:14:50

Brian said once upon a time: >Would be good, also the best and easiest thing to do, is to grab there ip >using the standard HTTP enviroment variable REMOTE_ADDR, take that, grep a >pmwho from whichever netserver is assigned that IP, and then you get the >port number.............. Yes, but if you are using round-robin, the port number does not always correlate to a modem slot.

Subject: Re: (usr-tc) x2 capible
From: Brian <signal@shreve.net>
Date: 1997-10-10 19:04:55

On Fri, 10 Oct 1997, Pete Ashdown wrote: > Brian said once upon a time: > > >Is there a way via TCM, to tell users if there line is x2 capible, like > >usr's line test does? > > > >I mean can I check the signal-to-noise ratio, or some MIB or something > >that will tell me if x2 will work, at least a good chance of it working? > > There is, and we talked with Paul from USR about what specs on the SNMP > MIBs will give us the necessary information to determine this. We're > trying to work something up that will enable people to check this via a web > page. The hardest thing is tying a modem to a RADIUS login. The best idea > we've had is to ask for their phone number and then find their modem via > CID. > > Paul sent us a paper detailing what to look for. I'm not sure if we're > permitted to redistribute it or not, but if it is OK, I'll put it in the > archives. > > Would be good, also the best and easiest thing to do, is to grab there ip using the standard HTTP enviroment variable REMOTE_ADDR, take that, grep a pmwho from whichever netserver is assigned that IP, and then you get the port number.............. Anyone else know about this info? I am sure its not that difficult, which MIBS? Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: Re: (usr-tc) x2 capible
From: Brian <signal@shreve.net>
Date: 1997-10-10 19:27:53

On Fri, 10 Oct 1997, Pete Ashdown wrote: > Brian said once upon a time: > > >Would be good, also the best and easiest thing to do, is to grab there ip > >using the standard HTTP enviroment variable REMOTE_ADDR, take that, grep a > >pmwho from whichever netserver is assigned that IP, and then you get the > >port number.............. > > Yes, but if you are using round-robin, the port number does not always > correlate to a modem slot. > it doesnt matter if your using round robin or not. Here is what we do: We get the users IP address : 208.214.44.15 Ok, so 208.214.44.15 is in the block of IP's assigned to USR hub #1. pmwho usrhub1 |grep "hostnameforthatip" |awk '{ print $1 }' now you have the slot they are dialed into, round robin or fixed it doesnt matter. now you simply query the MIBS for that slot.........we do this to show users there connect speeds etc. Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: Re: (usr-tc) x2 capible
From: David Bolen <db3l@ans.net>
Date: 1997-10-10 19:39:39

Brian <signal@shreve.net> writes: > I mean can I check the signal-to-noise ratio, or some MIB or something > that will tell me if x2 will work, at least a good chance of it working? If the user has a V.34 modulation connection (check mdmCsModulation; this actually won't work if they're using an X2 modem unless they've only gotten a V.34 connection in which case it's kind of moot :-)), and you are running the 2.5.1 code, you can use objects in the mdmCs table to get the same information from the modem as you would on an ATI11 or ATY11 screen. (The mdmCs tree grew quite a bit in TCS 2.5.x). Of course, it's not a precise science, both because there really isn't any single parameter that guarantees x2 can work (although some values are a sure bet it won't, but there's a large grey area), and the other thing is that any stats you can get from the chassis is based on the signal it is _receiving_, while x2 really cares about how the client modem perceives the signal you are _transmitting_. The good news is that circuit paths are typically symmetric, but I've definitely seen cases where that isn't true. As for whether or not x2 has a good chance of working, the single best thing to query is going to be the frequency response of your session (e.g., the same as an ATY11). To do that you'll want to query the mdmCsFreqProbeData and mdmCsLevelProbeData. They are both opaque octet strings - the frequency data is a series of 2-byte words (in Intel-LSB format) representing each frequency level, and the level probe data is a series of 1-byte dB attenuation values. It's literally the output of an ATY11 screen with the left (frequency) column placed into one object and the level value placed into the other. If you're being "proper" you should query both and use the frequency data to index into the level data, but once you know what your code orders them like you can of course skip past and just grab the level data, looking for the offsets you care about. The most important thing for x2 is the level drop between 3300 and 3750Hz. The exact threshold is debatable, but I would suggest not expecting an x2 connection if it drops more than 24-25dB over that interval. Much beyond that is definitely a hard "gate" for x2 - too much high frequency loss (which is generally, but not exclusively, because of multiple-A/D conversions) and the client modem won't even attempt x2, as opposed to at least trying x2 and maybe falling back. (You'll find the dB for 3300 at offset 24 in the level object value, and 3750 at offset 21 - counting from 0) It is also important (although less so) that there not be an enormous dynamic range between the lowest (150Hz) and highest (3750Hz) frequencies or else the modem won't be able to equalize the curve and even with a flat high frequency response might not be able to achieve x2. Unfortunately I've just "eyeballed" this in the past so I don't have a good threshold to look for, and different client modems may have higher quality equalization hardware (Courier's used to be much better I think but that isn't true as much with more current Sportsters). You might also want to take a look at the symbol table rate that the modem was able to achieve with V.34, as it gives another indication of the overall bandwidth the modem was able to make use of on the line. Check out the mdmCsQSymRateTx object for the transmit symbol rate. If the user is getting at least 3429 you're in good shape (and you'll typically find the user getting 28.8-33.6K connections with V.34). 3200 isn't quite as good (and the user will tend to have 21.6K-26.4K V.34 rates) but still usable for x2. Odds aren't really that great much lower than that. The SNR is also very important on the line, but again you have the problem of the chassis having a receive SNR but it can't tell what the client is seeing. For a client modem, SNR tops out between 60-70 so the closer you are to that the better. You can check the mdmCsQSNR object for the chassis side SNR. I'm not entirely positive that it's accurate though (there were problems with it during the beta stages). It's supposed to be the SNR x 10, but at the moment querying mine it almost seems to be SNR/10, since I'm getting values in the 3-7 range. The frequency drop is probably your best indicator, but in any of these cases it's not going to be guarantee one way or the other, since even if you see a big frequency drop it may not be symmetric. -- 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) SNMP x2 capable
From: Laszlo Vecsey <master@internexus.net>
Date: 1997-10-10 20:03:51

On Fri, 10 Oct 1997, Pete Ashdown wrote: > Brian said once upon a time: > > >Is there a way via TCM, to tell users if there line is x2 capible, like > >usr's line test does? > > > >I mean can I check the signal-to-noise ratio, or some MIB or something > >that will tell me if x2 will work, at least a good chance of it working? > > There is, and we talked with Paul from USR about what specs on the SNMP > MIBs will give us the necessary information to determine this. We're > trying to work something up that will enable people to check this via a web > page. The hardest thing is tying a modem to a RADIUS login. The best idea > we've had is to ask for their phone number and then find their modem via > CID. You can SNMP query through the list of IP addresses that are online, and match up one of them to the REMOTE_ADDR value passed to your cgi-bin program. Because of the way things are set up, part of the OID number will correspond to the port value, and I would imagine once you had this port number you could easily find what you need from there in the same way. > Paul sent us a paper detailing what to look for. I'm not sure if we're > permitted to redistribute it or not, but if it is OK, I'll put it in the > archives. > > - lv

Subject: Re: (usr-tc) net medic
From: David Carter <david@corp.netcom.net.uk>
Date: 1997-10-10 20:11:39

Dear Pris, > Thanks for the info, David. I am suggesting to our powers that be that we > offically refuse to support it, and post such prominently on our web pages, I am the power that is when it comes to support and I have no question over not supporting this product, officially or unofficially. However, this doesn't stop users installing it. I hope they tidy it up 100 degrees. Regards, -- David Carter, 2nd Level Support, NETCOM Internet. david@corp.netcom.net.uk Be content with your lot; one cannot be first in everything. Aesop

Subject: Re: (usr-tc) x2 capible
From: David Bolen <db3l@ans.net>
Date: 1997-10-10 20:27:19

Pete Ashdown <pashdown@xmission.com> writes: > Yes, but if you are using round-robin, the port number does not always > correlate to a modem slot. If "port" is the NETServer port number then it should. The input DS0 channel to modem mapping may vary, but that's on the TDM bus side. The packet bus links between a particular NETServer port and the corresponding modem is fixed. Even in later code when you can define the initial mapping, that mapping never changes so as long as you know how your NETServer is configured you can backtrack from port to modem entity. -- 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) x2 capible
From: Mike Andrews <mandrews@termfrost.org>
Date: 1997-10-10 23:51:02

The way I do it is to get the IP address the user's using and then query ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.aaa.bbb.ccc.ddd. This gives me the interface number that's attached to that IP address... which on our racks seems to be S-Port number + 3. Once you have the S-Port you can figure out which modem card they're on pretty quickly. I've got a CGI that I wrote about a month ago that pulls all the line stats off the modem and graphs the EQ curve (on v.34 connects) in HTML format. I've been hesitant to release it because the code is pretty disgusting and has tons of site-specific crud in it. (It was written in one caffeine-drenched weekend right after we installed our first rack and were having problems.) It also requires ucd-snmp at the moment because I haven't rewritten the snmpget stuff in Perl. The graphs require the GIFs from Analog (an httpd logfile analyzer). However it looks like a few people could find this useful, so if you want it, drop me a line... -- Mike Andrews (MA12) "Oh my god, they killed Kenny!" mandrews@dcr.net -- mandrews@termfrost.org -- http://www.termfrost.org/ Senior Systems & Network Administrator, Digital Crescent, Frankfort, KY Providing x2 Internet Access in Franklin, Anderson, and Shelby Counties On Fri, 10 Oct 1997, David Bolen wrote: > Pete Ashdown <pashdown@xmission.com> writes: > > > Yes, but if you are using round-robin, the port number does not always > > correlate to a modem slot. > > If "port" is the NETServer port number then it should. > > The input DS0 channel to modem mapping may vary, but that's on the TDM > bus side. The packet bus links between a particular NETServer port > and the corresponding modem is fixed. Even in later code when you can > define the initial mapping, that mapping never changes so as long as > you know how your NETServer is configured you can backtrack from port > to modem entity. > > -- David

Subject: (usr-tc) IP assigned to 0.0.0.0 problem
From: Walt <wgnann@islc.net>
Date: 1997-10-11 02:30:35

I'm new to this list and still figuring out how to use this box. I have a strange problem with a couple of IPs on one of my TC boxes trying to assign themselves twice. When it tries to assign itself twice it gives a IP in use error and assigns the user 0.0.0.0 which causes the connection to drop immediately. It's strangely similar to an old ComOS bug in the Livingston Portmasters. I know these boxes work off ComOS as well and was wondering if 1) has anyone else encountered this and 2) how do you fix it. Thanks, Walt Walter N. Gnann ISLC, Manager Phone: 803.770.1000 Fax: 803.770.1002 http://www.islc.net wgnann@islc.net

Subject: Re: (usr-tc) IP assigned to 0.0.0.0 problem
From: Stephen Fisher <lithium@cia-g.com>
Date: 1997-10-11 04:53:50

On Sat, 11 Oct 1997, Walt wrote: > I'm new to this list and still figuring out how to use this box. I have > a strange problem with a couple of IPs on one of my TC boxes trying to > assign themselves twice. When it tries to assign itself twice it gives > a IP in use error and assigns the user 0.0.0.0 which causes the > connection to drop immediately. It's strangely similar to an old ComOS > bug in the Livingston Portmasters. I know these boxes work off ComOS as Which was fixed a year or two ago. > well and was wondering if 1) has anyone else encountered this and 2) how > do you fix it. Use Livingston equipment..=).. it was fixed a long time ago. - Steve - Systems Manager - Community Internet Access, Inc. - Gallup and Grants, New Mexico

Subject: Re: (usr-tc) IP assigned to 0.0.0.0 problem
From: Stephen Fisher <lithium@cia-g.com>
Date: 1997-10-11 04:53:50

Subject: (usr-tc) ISDN->I-modem or Daughtercard?
From: Brian <signal@shreve.net>
Date: 1997-10-11 11:04:44

I was wondering how most of you are handling your ISDN calls: Daughtercard or I-Modem? We currently use the Munich Daughtercard because that is what we have used for so long. Is there any advantages of using the I-modems instead? Does it help anything, by offloading everything from the Daughtercard? I think you just set your ISDN gw in the PRI card to slot 0 to get this functionality, and then go into the ISDN options of TCM and set the modems up accordingly. We run PPP in the modems rather than the netserver, we feel we have seen better results with this, and it makes sense. We are just wondering if we should do the same with ISDN.......just put everything on S ports ............... Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: (usr-tc) SNMP
From: William M Sheeler Sr <tcra@talon.net>
Date: 1997-10-11 14:27:40

What is being used by the masses for an SNMP management program, that will not only do the TC's but Cisco, switches etc ? We are looking for something that is ,hate to say, Windows compatible. Thanks in advance TTFN Bill William M Sheeler, Sr www.talon.net ceo TCRA Computers and voice 610.670.6491 TALON Network Services, Inc voice 610.670.4923 Fax for both fax 610.670.6495 ( Total Area Linked Online Nationwide Network Services, Inc) " Live with Passion " " It's in your moments of decision that your destiny is shaped " ANTHONY ROBBINS

Subject: Re: (usr-tc) SNMP
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1997-10-11 17:01:59

: What is being used by the masses for an SNMP management program, that will : not only do the TC's but Cisco, switches etc ? We are looking for : something that is ,hate to say, Windows compatible. There's HP Openview.

Subject: Re: (usr-tc) error
From: Jaye Mathisen <mrcpu@cdsnet.net>
Date: 1997-10-11 17:53:45

One of the link_fail's you get when you just call in and hang up, like a wrong number, but I thought is was link_fail=21. I would be interested in seeing this as well. On Sat, 11 Oct 1997, Brian wrote: > > Does anyone know how to diagnose an error message like this? > > Oct 11 18:59:49 usr1ts1 S13 didn't get online! status=-1, > connect_fail=32, link_fail=31 > > Where do I cross reference these numbers? > > Brian > > > /-------------------------- signal@shreve.net -----------------------------\ > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > | Systems Administrator | Perl, Linux | Web hosting, online stores, | > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | > | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | > \-------------------------- 318-222-2638 x109 -----------------------------/ > > >

Subject: Re: (usr-tc) error
From: Jaye Mathisen <mrcpu@cdsnet.net>
Date: 1997-10-11 17:53:45

Subject: (usr-tc) error
From: Brian <signal@shreve.net>
Date: 1997-10-11 19:02:20

Subject: Re: (usr-tc) IP assigned to 0.0.0.0 problem
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-10-11 19:06:51

This problem was only seen on Livingston and NETServer 8/16 boxes about a year and a half back. What version on NETServer code are you using? Is it a chassis or NETServer 8/16 krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Sat, 11 Oct 1997, Walt wrote: > I'm new to this list and still figuring out how to use this box. I have a > strange problem with a couple of IPs on one of my TC boxes trying to assign > themselves twice. When it tries to assign itself twice it gives a IP in use > error and assigns the user 0.0.0.0 which causes the connection to drop > immediately. It's strangely similar to an old ComOS bug in the Livingston > Portmasters. I know these boxes work off ComOS as well and was wondering if > 1) has anyone else encountered this and 2) how do you fix it. > > Thanks, > > Walt > ---------------------------------------------------- > Walter N. Gnann > ISLC, Manager > Phone: 803.770.1000 > Fax: 803.770.1002 > http://www.islc.net > wgnann@islc.net > ---------------------------------------------------- > >

Subject: Re: (usr-tc) ISDN->I-modem or Daughtercard?
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-10-11 19:09:47

On Sat, 11 Oct 1997, Brian wrote: > > I was wondering how most of you are handling your ISDN calls: Daughtercard > or I-Modem? We currently use the Munich Daughtercard because that is what > we have used for so long. > > Is there any advantages of using the I-modems instead? Does it help > anything, by offloading everything from the Daughtercard? > > I think you just set your ISDN gw in the PRI card to slot 0 to get this > functionality, and then go into the ISDN options of TCM and set the modems > up accordingly. > > We run PPP in the modems rather than the netserver, we feel we have seen > better results with this, and it makes sense. We are just wondering if we > should do the same with ISDN.......just put everything on S ports > ............... > > Brian At first we just has regular code on the Quad modems, it could take only anlog calls, so we had a daughter card to accept Digital calls, Now you can accept both analog and digital calls on the modems. You can now accept ISDN calls on the S ports and ppp on the modems will certainly help. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec > > > /-------------------------- signal@shreve.net -----------------------------\ > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > | Systems Administrator | Perl, Linux | Web hosting, online stores, | > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | > | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | > \-------------------------- 318-222-2638 x109 -----------------------------/ > > >

Subject: Re: (usr-tc) SNMP
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-10-11 19:11:24

Use Cmu snmp or Ucd snmp, krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Sat, 11 Oct 1997, William M Sheeler Sr wrote: > What is being used by the masses for an SNMP management program, that will > not only do the TC's but Cisco, switches etc ? We are looking for > something that is ,hate to say, Windows compatible. > > Thanks in advance > > TTFN > > Bill > > > William M Sheeler, Sr www.talon.net > ceo > TCRA Computers and voice 610.670.6491 > TALON Network Services, Inc voice 610.670.4923 > Fax for both fax 610.670.6495 > > ( Total Area Linked Online Nationwide Network Services, Inc) > > > " Live with Passion " > > " It's in your moments of decision that your destiny is shaped " > ANTHONY ROBBINS >

Subject: Re: (usr-tc) error
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-10-11 19:13:03

It basically means that the connection did not take place due to some line error. 32 and 31 have some explanations which I shall provide you on Monday. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Sat, 11 Oct 1997, Brian wrote: > > Does anyone know how to diagnose an error message like this? > > Oct 11 18:59:49 usr1ts1 S13 didn't get online! status=-1, > connect_fail=32, link_fail=31 > > Where do I cross reference these numbers? > > Brian > > > /-------------------------- signal@shreve.net -----------------------------\ > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > | Systems Administrator | Perl, Linux | Web hosting, online stores, | > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | > | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | > \-------------------------- 318-222-2638 x109 -----------------------------/ > > >

Subject: (usr-tc) error
From: Brian <signal@shreve.net>
Date: 1997-10-11 22:53:39

Subject: Re: (usr-tc) IP assigned to 0.0.0.0 problem
From: MegaZone <megazone@livingston.com>
Date: 1997-10-12 03:52:20

Once upon a time Stephen Fisher shaped the electrons to say... >Which was fixed a year or two ago. Late 1995. -MZ, coordinated that bug hunt... -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588

Subject: Re: (usr-tc) 24 Port Card
From: MegaZone <megazone@livingston.com>
Date: 1997-10-12 03:57:08

Once upon a time John Campbell shaped the electrons to say... > Rumor from USR says that they are supposed to ship Friday, but he says >that they were also supposed to ship last Friday. Yeah, someone over at the 3Com/USR booth at InterOp was saying that. I had a number of people tell me a 3Com rep claimed the Hi-Per cards would be shipping next week. But I also had others tell me that a 3Com rep told them it was a month off. I had one suit writer from some industry rag (I don't recall which, too many people in 3 days...) come up to me in the Livingston booth with something akin to "3Com says the Hi-Per Access will ship next week. What is Livingston's competitive stance?" Or something like that. But he wasn't the only one. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588

Subject: Re: (usr-tc) get user on port?
From: MegaZone <megazone@livingston.com>
Date: 1997-10-12 04:09:26

Once upon a time Laszlo Vecsey shaped the electrons to say... >So I'm not sure which one would win overall, SNMP or telnet. Can SNMP even >provide all the information that is produced from a 'show sessions' >listing? Maybe David Bolen can comment on all this .. (do your tools use a There are other uses for SNMP user info. Our next generation RADIUS supports simultaneous login restriction by using an SNMP query to check when an ACCT STOP packet has not been received. There is another RADIUS out there from a user that does this now I understand. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588

Subject: Re: (usr-tc) IP assigned to 0.0.0.0 problem
From: Walt <wgnann@islc.net>
Date: 1997-10-12 19:21:55

I'm using Netserver version 3.5.34 on a Total Control Chassis. It seems to have cropped up when I was changing the address pool size and starting IP information. After I rebooted the chassis the problem seems to have gone away. While the problem was occurring it kept trying to duplicate about 5 different IPs over and over. I don't know if changing the address pool caused the problem, but I don't test the theory when you have to cut off 48 customers in the process. Walt -----Original Message----- >This problem was only seen on Livingston and NETServer 8/16 boxes about >a year and a half back. What version on NETServer code are you using? >Is it a chassis or NETServer 8/16 > >krish > > >----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ >tkrishna@bubba.ae.usr.com >----------------------------/ http://interproc.ae.usr.com ----/ >-------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec >-------------------------------------------------------------------------/ > >On Sat, 11 Oct 1997, Walt wrote: > >> I'm new to this list and still figuring out how to use this box. I have a >> strange problem with a couple of IPs on one of my TC boxes trying to assign >> themselves twice. When it tries to assign itself twice it gives a IP in use >> error and assigns the user 0.0.0.0 which causes the connection to drop >> immediately. It's strangely similar to an old ComOS bug in the Livingston >> Portmasters. I know these boxes work off ComOS as well and was wondering if >> 1) has anyone else encountered this and 2) how do you fix it. >> >> Thanks, >> >> Walt >> ---------------------------------------------------- >> Walter N. Gnann >> ISLC, Manager >> Phone: 803.770.1000 >> Fax: 803.770.1002 >> http://www.islc.net >> wgnann@islc.net >> ---------------------------------------------------- >> >> > >

Subject: Re: (usr-tc) IP assigned to 0.0.0.0 problem
From: Stephen Fisher <lithium@cia-g.com>
Date: 1997-10-12 21:04:03

With ComOS you must always reboot after changing the address pool size/starting point. - Steve - Systems Manager - Community Internet Access, Inc. - Gallup and Grants, New Mexico On Sun, 12 Oct 1997, Walt wrote: > I'm using Netserver version 3.5.34 on a Total Control Chassis. It seems to > have cropped up when I was changing the address pool size and starting IP > information. After I rebooted the chassis the problem seems to have gone > away. While the problem was occurring it kept trying to duplicate about 5 > different IPs over and over. I don't know if changing the address pool > caused the problem, but I don't test the theory when you have to cut off 48 > customers in the process. > > Walt > -----Original Message----- > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > To: usr-tc@mail.xmission.com <usr-tc@mail.xmission.com> > Date: Sunday, October 12, 1997 8:12 AM > Subject: Re: (usr-tc) IP assigned to 0.0.0.0 problem > > > >This problem was only seen on Livingston and NETServer 8/16 boxes about > >a year and a half back. What version on NETServer code are you using? > >Is it a chassis or NETServer 8/16 > > > >krish > > > > > >----------------------------------------- > > \ T.S.V. Krishnan \ > > \ Network System Engineer \ ( : - : ) > > \ 3Com ............ \ > > ----------------------------------------------/ > >tkrishna@bubba.ae.usr.com > >----------------------------/ http://interproc.ae.usr.com ----/ > >-------------------------------------------------------------------------\ > > Any Sufficiently advanced bug is indistinguishable for a feature. > > - Rick Kulawiec > >-------------------------------------------------------------------------/ > > > >On Sat, 11 Oct 1997, Walt wrote: > > > >> I'm new to this list and still figuring out how to use this box. I have > a > >> strange problem with a couple of IPs on one of my TC boxes trying to > assign > >> themselves twice. When it tries to assign itself twice it gives a IP in > use > >> error and assigns the user 0.0.0.0 which causes the connection to drop > >> immediately. It's strangely similar to an old ComOS bug in the > Livingston > >> Portmasters. I know these boxes work off ComOS as well and was wondering > if > >> 1) has anyone else encountered this and 2) how do you fix it. > >> > >> Thanks, > >> > >> Walt > >> ---------------------------------------------------- > >> Walter N. Gnann > >> ISLC, Manager > >> Phone: 803.770.1000 > >> Fax: 803.770.1002 > >> http://www.islc.net > >> wgnann@islc.net > >> ---------------------------------------------------- > >> > >> > > > > > >

Subject: (usr-tc) line problems
From: Brian <signal@shreve.net>
Date: 1997-10-12 23:53:45

I am still having a rash of problems from the last 2 weeks. Can someone tell me if this is normal on this span: Span Line 1 Alarm/Event Status Time since clear (days::hh:mm:ss): 0::11:47:44 Receiver Gain: 7.5 dB Errored Seconds: 2 Severely Errored Seconds: 1 Failed Seconds: 0 Bipolar Violations: 0 Framing Bit Errors: 809 Change In Frame Alignment: 0 Frame Slips: 0 Bursty Errored Seconds (ESF Only): 1 CRC Errors (ESF Only): 271 Excessive CRC Error (ESF Only): 0 Out of Frame: N Out of Frame: (Red Alarm): N Loss of Signal: N Loss of Signal: (Red Alarm): N Remote Frame Alarm: N Remote Frame Alarm: (Yellow Alarm): N Alarm Indication Signal: N Alarm Indication Signal: (Blue Alarm): N Loop Back: None D-Channel Status: Up its only been up 11 hours and has quite a few errors, and also its the ONLY pri we have that has 7.5db gain......others have 0............. how bad is 809 framing bit errors in 11 hours? massive? Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: Re: (usr-tc) IP assigned to 0.0.0.0 problem (fwd)
From: MegaZone <megazone@livingston.com>
Date: 1997-10-13 00:57:28

Once upon a time Walt shaped the electrons to say... >have cropped up when I was changing the address pool size and starting IP >information. After I rebooted the chassis the problem seems to have gone Sounds like they haven't changed the core ComOS pool code. If you change the starting IP or change the size of a pool you must reboot. ComOS allocates the pool at boot time. Shifting the pool after boot has undefined effects on address allocation. Unless USR changed this - but it sure sounds like it is the same. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588

Subject: Re: (usr-tc) IP assigned to 0.0.0.0 problem (fwd)
From: Walt <wgnann@islc.net>
Date: 1997-10-13 07:13:39

Thanks. I guess the side effect is the Netserver assigning multiple IPs. Won't try that again anytime soon. Walt -----Original Message----- >Once upon a time Walt shaped the electrons to say... >>have cropped up when I was changing the address pool size and starting IP >>information. After I rebooted the chassis the problem seems to have gone > >Sounds like they haven't changed the core ComOS pool code. > >If you change the starting IP or change the size of a pool you must reboot. >ComOS allocates the pool at boot time. > >Shifting the pool after boot has undefined effects on address allocation. > >Unless USR changed this - but it sure sounds like it is the same. > >-MZ >-- >Livingston Enterprises - Chair, Department of Interstitial Affairs >Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com >For support requests: support@livingston.com <http://www.livingston.com/> >Snail mail: 4464 Willow Road, Pleasanton, CA 94588 > > >

Subject: (usr-tc) Call Tracking
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1997-10-13 08:29:00

I am running the MS Access version of the Merit RADIUS software which came with our USRobotics Total Control nodes. Whenever we enable the call tracking option to monitor concurrent logins etc.., we end up with a problem every few days where it appears RADIUS isn't detecting a hangup. This causes users to get maximum session limit failures trying to login. Is anyone else seeing this thype of a problem ? I am running the 2.5.1 software with the latest version of the Security & Accounting software on the website. Jeff Binkley ASA Network Computing CMPQwk 1.42 9999

Subject: (usr-tc) V34 back channel
From: Brian <signal@shreve.net>
Date: 1997-10-13 08:39:30

Subject: Re: (usr-tc) Call Tracking
From: NetSol, dns Admin <dns-admin@netsol.net>
Date: 1997-10-13 08:54:55

We have the same problem. Although in the modem "trap setting" enable all on the first six options and "dialup in call dration" does help minimized the problem. -- but it's still there. Liping Jeff Binkley wrote: > I am running the MS Access version of the Merit RADIUS software which > came with our USRobotics Total Control nodes. Whenever we enable the > call tracking option to monitor concurrent logins etc.., we end up with > a problem every few days where it appears RADIUS isn't detecting a > hangup. This causes users to get maximum session limit failures trying > to login. Is anyone else seeing this thype of a problem ? I am running > the 2.5.1 software with the latest version of the Security & Accounting > software on the website. > > Jeff Binkley > ASA Network Computing > > CMPQwk 1.42 9999 -- Netsol Technologies 805 S. Lemon Ave. Walnut, CA 91789 (909) 869-6455 (909) 869-6459 fax Liping@netsol.net

Subject: Re: (usr-tc) IP assigned to 0.0.0.0 problem (fwd)
From: Michael Wronski <mwronski@coredump.ae.usr.com>
Date: 1997-10-13 09:09:18

This is the case.. After change of pool starting address, the NS must be rebooted.. -M At 12:57 AM 10/13/97 -0700, you wrote: >Once upon a time Walt shaped the electrons to say... >>have cropped up when I was changing the address pool size and starting IP >>information. After I rebooted the chassis the problem seems to have gone > >Sounds like they haven't changed the core ComOS pool code. > >If you change the starting IP or change the size of a pool you must reboot. >ComOS allocates the pool at boot time. > >Shifting the pool after boot has undefined effects on address allocation. > >Unless USR changed this - but it sure sounds like it is the same. > >-MZ >-- >Livingston Enterprises - Chair, Department of Interstitial Affairs >Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com >For support requests: support@livingston.com <http://www.livingston.com/> >Snail mail: 4464 Willow Road, Pleasanton, CA 94588 > > `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' Mike Wronski(mwronski@coredump.ae.usr.com) 3Com/U.S.Robotics Network Systems Engineer (Level 3) PGP: http://coredump.ae.usr.com/pgp

Subject: (usr-tc) Using serial port on Analog/Digital modem
From: Brian Elfert <brian@citilink.com>
Date: 1997-10-13 10:16:22

I have a US Robotics 2059 chassis with quad analog/digital modems. I'm trying to compare the performance of the Netserver versus plugging a serial cable into a Portmaster. My problem is that the T1 card always shows those modems as 'Corresponding modem in busy out'. I set the line interface settings to NIC and a DTE rate of 115K. The modems have been deactivated in the Netserver, and reset. I went into the actions/commands section, and made sure they were in an on hook state. Any ideas to get them working? Brian

Subject: Re: (usr-tc) line problems
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-13 12:20:04

You might want to query your phone company and find out if they've put you on different equipment, overflow equipment, or if they're throttling access to your number. We've seen and heard of all this behavior with ISPs and phone co's. USWest will do all sorts of dirty tricks.

Subject: Re: (usr-tc) IP assigned to 0.0.0.0 problem
From: Jordyn A. Buchanan <jordyn@bestweb.net>
Date: 1997-10-13 13:20:37

At 7:06 PM -0500 10/11/97, Tatai SV Krishnan wrote: >This problem was only seen on Livingston and NETServer 8/16 boxes about >a year and a half back. What version on NETServer code are you using? >Is it a chassis or NETServer 8/16 Actually, I haven't noticed this particular problem on any recent revisions of the code, but we have seen a few times in the last month or so a condition in which a NetServer 16 will go crazy and assign the *same* IP address to a bunch of users--they don't get 0.0.0.0 but it's no better when six or seven users have the identical address... This is on boxes running 3.2.5.3. Jordyn |----------------------------------------------------------------| |Jordyn A. Buchanan mailto:jordyn@bestweb.net | |Bestweb Corporation http://www.bestweb.net | |Senior System Administrator +1.914.271.4500 | |----------------------------------------------------------------|

Subject: (usr-tc) 16 meg Netserver Upgrade
From: Greg Coffey <greg@coffey.com>
Date: 1997-10-13 14:58:10

We're in the process of upgrading the memory of the netserver card. I have a nonparity, nonedo 16 meg 72 pin simm to add. Is there anything else that I need to do to the system to make this work? Thanks, Greg Coffey, CoffeyNet Voice 307-234-5443 307-234-5446 Fax ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ 142 S. Center St. US Robotics x2 56k $20 in Casper Casper, WY 82601 Local Internet for Casper, Rawlins, Douglas, www.coffey.com Wheatland, Pinedale, Lander & Lusk, WY ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~

Subject: Re: (usr-tc) 16 meg Netserver Upgrade
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-13 15:44:06

Greg Coffey said once upon a time: > >We're in the process of upgrading the memory of the netserver card. I have >a nonparity, nonedo 16 meg 72 pin simm to add. Is there anything else that >I need to do to the system to make this work? You need parity.

Subject: Re: (usr-tc) 16 meg Netserver Upgrade
From: Curt Shambeau <curt@execpc.com>
Date: 1997-10-13 17:07:21

> >We're in the process of upgrading the memory of the netserver card. I have > >a nonparity, nonedo 16 meg 72 pin simm to add. Is there anything else that > >I need to do to the system to make this work? > > You need parity. No, you don't. The genuine USR netserver upgrades are NOT parity, and I have upgraded several others, and have never used parity SIMMs. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Exec-PC Vice President, Information Services |

Subject: Re: (usr-tc) 16 meg Netserver Upgrade
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-13 18:04:29

Curt Shambeau said once upon a time: > >> >We're in the process of upgrading the memory of the netserver card. I have >> >a nonparity, nonedo 16 meg 72 pin simm to add. Is there anything else that >> >I need to do to the system to make this work? >> >> You need parity. > >No, you don't. The genuine USR netserver upgrades are NOT parity, and I >have upgraded several others, and have never used parity SIMMs. I stand corrected.

Subject: Re: (usr-tc) 16 meg Netserver Upgrade
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1997-10-13 18:21:03

: We're in the process of upgrading the memory of the netserver card. I have : a nonparity, nonedo 16 meg 72 pin simm to add. Is there anything else that : I need to do to the system to make this work? Maybe a smaller SIMM: We plugged a 16 meg SIMM into an older netserver, and it fouled it up pretty bad. USR tech support told us to install no more than 4M more, I believe. --- Mark R. Lindsey, mark@datasys.net Network Engineer, DSS Online Voice: +1 912 241 0607; Fax: +1 912 241 0190

Subject: Re: (usr-tc) 16 meg Netserver Upgrade
From: Greg Coffey <greg@coffey.com>
Date: 1997-10-13 18:29:40

We tried the 16 meg and could not ping anything from the TC box after the installation. Took it back out and it started working again. We only have 24 lines active in it right now, will we benefit much by adding the 16 meg? I think we have to have 16 on it to do the next upgrade for the software that USR just released. At 06:48 PM 10/13/97 -0400, you wrote: >On Mon, 13 Oct 1997, Mark R. Lindsey wrote: > >> : We're in the process of upgrading the memory of the netserver card. I have >> : a nonparity, nonedo 16 meg 72 pin simm to add. Is there anything else that >> : I need to do to the system to make this work? >> >> Maybe a smaller SIMM: We plugged a 16 meg SIMM into an older netserver, and >> it fouled it up pretty bad. USR tech support told us to install no more than >> 4M more, I believe. > >We've gotten some 16 meg upgrades from USR after our Netservers started >losing their minds (46 callers AND frame relay was just too much for 4 >megs :> ) and they are indeed non-parity 72-pin simms.. The trick to >making them work AT ALL is flashing to at least version 3.5.34 .. > >:> > >ek. > > > Thanks, Greg Coffey, CoffeyNet Voice 307-234-5443 307-234-5446 Fax ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ 142 S. Center St. US Robotics x2 56k $20 in Casper Casper, WY 82601 Local Internet for Casper, Rawlins, Douglas, www.coffey.com Wheatland, Pinedale, Lander & Lusk, WY ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~

Subject: Re: (usr-tc) 16 meg Netserver Upgrade
From: Edward Kern <dag@soulfood.org>
Date: 1997-10-13 18:48:21

On Mon, 13 Oct 1997, Mark R. Lindsey wrote: > : We're in the process of upgrading the memory of the netserver card. I have > : a nonparity, nonedo 16 meg 72 pin simm to add. Is there anything else that > : I need to do to the system to make this work? > > Maybe a smaller SIMM: We plugged a 16 meg SIMM into an older netserver, and > it fouled it up pretty bad. USR tech support told us to install no more than > 4M more, I believe. We've gotten some 16 meg upgrades from USR after our Netservers started losing their minds (46 callers AND frame relay was just too much for 4 megs :> ) and they are indeed non-parity 72-pin simms.. The trick to making them work AT ALL is flashing to at least version 3.5.34 .. :> ek.

Subject: (usr-tc) #!%* HiPer delayed yet again
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-13 18:57:34

The word is "November" now. We're adding nearly 200 lines this month alone, and we're making up for the delays with eval units. I sure hope USR is planning on releasing a bugless product.

Subject: Re: (usr-tc) isdn modems
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-10-13 20:38:40

On Mon, 13 Oct 1997, Brian wrote: > I was trying to get ISDN to goto the modems today and had no luck. > > I set the ISDN-GW slot to 0, and had the ISDN settings set in the modems, > but no go............is there something else I need to do here? > > Brian Make sure you have modem code 5.6.x or above, which support ISDN, and also make sure taht you save the setting of ISDN GW on the PRI. The calls now will be directed towards modems. krish > > > > /-------------------------- signal@shreve.net -----------------------------\ > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > | Systems Administrator | Perl, Linux | Web hosting, online stores, | > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | > | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | > \-------------------------- 318-222-2638 x109 -----------------------------/ > > >

Subject: (usr-tc) isdn modems
From: Brian <signal@shreve.net>
Date: 1997-10-13 22:15:39

Subject: Re: (usr-tc) Using serial port on Analog/Digital modem
From: Wayne Barber <barberw@tidewater.net>
Date: 1997-10-14 09:07:09

> I set the line interface settings to NIC and a DTE rate of 115K. The > modems have been deactivated in the Netserver, and reset. Did you set line interface to NIC or DTE Interface to NIC? Line interface needs to stay at t1TDM. > Brian > > Wayne Barber - barberw@tidewater.net Internet System Administrator Coastal Telco Services

Subject: Re: (usr-tc) isdn modems
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-14 13:50:05

Tatai SV Krishnan said once upon a time: >On Mon, 13 Oct 1997, Brian wrote: > >> I was trying to get ISDN to goto the modems today and had no luck. >> >> I set the ISDN-GW slot to 0, and had the ISDN settings set in the modems, >> but no go............is there something else I need to do here? >> >> Brian > >Make sure you have modem code 5.6.x or above, which support ISDN, and >also make sure taht you save the setting of ISDN GW on the PRI. The >calls now will be directed towards modems. Is this possible to use with the DSS-T1 card for 56K ISDN? If not, what is the benefit in having my modem cards handle ISDN calls?

Subject: Re: (usr-tc) quad-modem idletime out
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-10-14 21:42:45

On Wed, 15 Oct 1997, James Cox wrote: > I must be overlooking something obvious: I have set my quad-modem idletime > outs to 20 minutes, reset the ports, even rebooted the TC hub. But I still > have users with lots of idle time not being disconnected automatically. I'm > not using radius, yet. I thought the modem would take care of this. > > Any suggestions? > > Jim > The idle time out should be set on the NETServer or via Radius and not on the Quad modems. The quad modems should be loaded from Default settings - Since the modems are on the packet bus, the default setting will set the modems properlly. Set your modems to default settings, setup the hardware templete and save it to NVRAM. On the NETServer do the following in order to set the idle time set all idle 20 This will set the idle time for 20 min on all the ports. You can also issues the attribute idle-timeout for all the users, via radius. This will solve your problem. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec > > ******************************** > James Cox cox@wmesa.com > www.wmesa.com > West Mesa Communications > Fastest Dialup Access in El Paso > >

Subject: Re: (usr-tc) isdn modems
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-10-14 21:46:25

> Is this possible to use with the DSS-T1 card for 56K ISDN? If not, what is > the benefit in having my modem cards handle ISDN calls? > > The munich daughter board card on the NETServer is a device which can handle ISDN calls directly. But this card emulates virtual ports. The quad modem with ISDN support is an actual ISDN device. This is the main difference. You will be using a hardware device to handle ISDN calls instead of virtual devices. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec

Subject: Re: (usr-tc) quad-modem idletime out
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-10-15 05:50:15

On Wed, 15 Oct 1997, Jeff Binkley wrote: > -> > I must be overlooking something obvious: I have set my quad-modem idletime > -> > outs to 20 minutes, reset the ports, even rebooted the TC hub. But I still > -> > have users with lots of idle time not being disconnected automatically. > -> I'm > not using radius, yet. I thought the modem would take care of this. > > -> > Any suggestions? > -> > > -> > Jim > -> > > -> The idle time out should be set on the NETServer or via Radius and not on > -> the Quad modems. The quad modems should be loaded from Default settings - > -> Since the modems are on the packet bus, the default setting will set the > -> modems properlly. Set your modems to default settings, setup the hardware > -> templete and save it to NVRAM. On the NETServer do the following in order > -> to set the idle time > -> > -> set all idle 20 > -> > -> This will set the idle time for 20 min on all the ports. > -> > -> You can also issues the attribute idle-timeout for all the users, via > -> radius. > -> This will solve your problem. > > The outstanding question from a week ago on this subject is whether the RADIUS > setting will override the Netserver setting ? In other words if I used the > NETSERVER to set the "default" for all ports at say 15 minutes but I had one > custoemr, who paid extra, and I wanted them to have a longer timeout, would the > RADIUS option override it if I set it to say 60 minutes ? Or would the lower > value take precedence ? > > Jeff Binkley > ASA Network Computing > The Radius setting should override the port setting. When the idle time is issued by the Radius all the port setting is over written by the radius profile. In your case the user will stay as long as Radius has set the idle time. krish

Subject: Re: (usr-tc) isdn modems
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-10-15 05:55:07

On Wed, 15 Oct 1997, Pete Ashdown wrote: > Tatai SV Krishnan said once upon a time: > > > >> Is this possible to use with the DSS-T1 card for 56K ISDN? If not, what is > >> the benefit in having my modem cards handle ISDN calls? > >> > >> > >The munich daughter board card on the NETServer is a device which can > >handle ISDN calls directly. But this card emulates virtual ports. The > >quad modem with ISDN support is an actual ISDN device. This is the main > >difference. You will be using a hardware device to handle ISDN calls > >instead of virtual devices. > > So back to my original question. Can I handle ISDN calls over DSS with > this? Secondly, by moving ISDN to the quad-modems, am I gaining speed or > freeing up processing power on the Netserver? > > Does USR have any documentation *anywhere* about this feature? I'm happy > to RTFM in this case, but there appears to be no M. > You are freeing up the processing on the NETServer if you set ppp on the modems. I cannot say that you will gain speed, ( atleast I have not tested this ) but you should have more through put, since the ISDN modem is a hardware device, you will have better performance. I am not aware of the manual or any doc in this case. I will try to get more information on this for you. krish

Subject: Re: (usr-tc) Net Manager Card
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-10-15 05:57:49

try totalcontrol krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Wed, 15 Oct 1997, David Bolen wrote: > Peter Barton <peter@flash.net> writes: > > > I just received a NMC from USR/3Com and it already has a password set > > up on it. Can anyone tell me how to clear the community strig/password? > > I believe DIP switch 5 on an NMC will erase flash upon boot (similar > to the NETServer). Set the switch, boot up, then reset the switch and > boot again to begin running normally. > > -- 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) quad-modem idletime out
From: James Cox <cox@ruby.wmesa.com>
Date: 1997-10-15 07:46:50

I must be overlooking something obvious: I have set my quad-modem idletime outs to 20 minutes, reset the ports, even rebooted the TC hub. But I still have users with lots of idle time not being disconnected automatically. I'm not using radius, yet. I thought the modem would take care of this. Any suggestions? Jim ******************************** James Cox cox@wmesa.com www.wmesa.com West Mesa Communications Fastest Dialup Access in El Paso

Subject: Re: (usr-tc) Second T-1 woes
From: eric@dol.net
Date: 1997-10-15 08:51:44

At 09:42 AM 10/15/97 -0500, you wrote: > >I've had a TC chassis running for some time now and installed a second PRI >about 2 weeks ago. Both PRIs have D channels on them. In order to test that >the second one worked, I knocked down the first one early one morning and >calls continued to come in on the second PRI. Now last night we had our first >occasion where the first PRI filled up and instead of calls going to the second >PRI, we got a busy signal. My first inclination would be to call Ameritech >but I am not 100% sure it is their problem. I went into the PRI settings and >attempted to change the call routing parameter to see if I could get calls onto >the modems in slots 8-13 (the second PRI) by changing the analog modem >selection from first available to roundrobin. This had the calls being >sequenced over cards 2-7, the first PRI's cards. I next tried fixed assignment >and seemed to resemeble more of a least idle selection sequence. At this point PRI's are not assined any particular group of modems. I you use round robin then you may have modem 1 free and the call comes in via the second pri and gets on modem 1. make sure the modems are active in the netserver. you may need to make them active and then reset the cards. > Delaware Online!.........The SMART Choice! With 56K X2 Modems Phone : 302-762-0375 Fax: 302-762-3462 WWW: www.dol.net Eight out of five people have a problem understanding statistics! ****************Customer support is our bottom line!*********************

Subject: (usr-tc) Second T-1 woes
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1997-10-15 09:42:00

I've had a TC chassis running for some time now and installed a second PRI about 2 weeks ago. Both PRIs have D channels on them. In order to test that the second one worked, I knocked down the first one early one morning and calls continued to come in on the second PRI. Now last night we had our first occasion where the first PRI filled up and instead of calls going to the second PRI, we got a busy signal. My first inclination would be to call Ameritech but I am not 100% sure it is their problem. I went into the PRI settings and attempted to change the call routing parameter to see if I could get calls onto the modems in slots 8-13 (the second PRI) by changing the analog modem selection from first available to roundrobin. This had the calls being sequenced over cards 2-7, the first PRI's cards. I next tried fixed assignment and seemed to resemeble more of a least idle selection sequence. At this point I am not sure how to get calls over to the other cards. Is it normal for round robin to only hunt within a single PRI on the TC ? I'm suspecting the real problem is a D channel parameter problem since they appear to work independently. Thoughts ? This is going into a DMS-100 switch. Jeff Binkley ASA Network Computing

Subject: Re: (usr-tc) TC Errors
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-15 10:29:23

Adam Wills said once upon a time: > >Our Network Management card has suddenly popped a sold RED light on the >"hub-status" light (second down). I am not at the location, but I assume >this problem would involve some problem in ethernet wire running TO the >network management card right? Wrong. It can be anything from a stuck modem, to a broken fan, to a bad power supply. Pull up TCM and look for the yellow card.

Subject: Re: (usr-tc) isdn modems
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-15 10:37:16

Tatai SV Krishnan said once upon a time: > >> Is this possible to use with the DSS-T1 card for 56K ISDN? If not, what is >> the benefit in having my modem cards handle ISDN calls? >> >> >The munich daughter board card on the NETServer is a device which can >handle ISDN calls directly. But this card emulates virtual ports. The >quad modem with ISDN support is an actual ISDN device. This is the main >difference. You will be using a hardware device to handle ISDN calls >instead of virtual devices. So back to my original question. Can I handle ISDN calls over DSS with this? Secondly, by moving ISDN to the quad-modems, am I gaining speed or freeing up processing power on the Netserver? Does USR have any documentation *anywhere* about this feature? I'm happy to RTFM in this case, but there appears to be no M.

Subject: Re: (usr-tc) quad-modem idletime out
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1997-10-15 10:51:00

-> > I must be overlooking something obvious: I have set my quad-modem idletime -> > outs to 20 minutes, reset the ports, even rebooted the TC hub. But I still -> > have users with lots of idle time not being disconnected automatically. -> I'm > not using radius, yet. I thought the modem would take care of this. > -> > Any suggestions? -> > -> > Jim -> > -> The idle time out should be set on the NETServer or via Radius and not on -> the Quad modems. The quad modems should be loaded from Default settings - -> Since the modems are on the packet bus, the default setting will set the -> modems properlly. Set your modems to default settings, setup the hardware -> templete and save it to NVRAM. On the NETServer do the following in order -> to set the idle time -> -> set all idle 20 -> -> This will set the idle time for 20 min on all the ports. -> -> You can also issues the attribute idle-timeout for all the users, via -> radius. -> This will solve your problem. The outstanding question from a week ago on this subject is whether the RADIUS setting will override the Netserver setting ? In other words if I used the NETSERVER to set the "default" for all ports at say 15 minutes but I had one custoemr, who paid extra, and I wanted them to have a longer timeout, would the RADIUS option override it if I set it to say 60 minutes ? Or would the lower value take precedence ? Jeff Binkley ASA Network Computing

Subject: Re: (usr-tc) quad-modem idletime out
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-15 11:05:53

Jeff Lynch said once upon a time: >Just getting started with my Enterprise Hubs and don't have my T1's >installed yet, but for what it's worth. A few years back, we had >to disable idle timeout per port on Livingston Portmasters to allow Radius >to idle parameters. Since the Netservers use an older version of COMOS >I would try disabling idle timeout (set to 0) on each port and put the >"Idle-Timeout = xxxx" in your users file. This isn't necessary on the TC's. It believes the RADIUS Idle-Timeout over anything else, specified or not. However, this doesn't stop people from spoofing. As stated previously, it would be great if we could make whatever detects "activity" tied to a filter. However, most TCP based traffic would still need to be let through. There are times when I need to spoof my own system, so I just setup a loop of "telnet host 13" to hit the clock port every five minutes. Maybe if USR built in some sort of intelligent monitor that looked for repeated traffic over set periods of time. That is, if someone is hitting the POP server every N minutes for X time, disconnect them. I'll bet a brick against London that most spoofers don't use random waits in their loop scripts.

Subject: (usr-tc) interesting problem
From: Brett Hawn <blh@texas.net>
Date: 1997-10-15 11:32:14

Our Radius logs pretty much everything these days for our own use and one thing we've noticed. When we manually kick users off the tc rack (instead of them disconnecting, etc) the Account-Session-Time is being set to 0 ie. This is an obvious bug Wed Oct 15 04:06:10 1997 Acct-Session-Id = 00002C3B User-Name = <USERNAME> NAS-IP-Address = 206.127.27.65 NAS-Port = 31 Acct-Status-Type = Start Acct-Authentic = RADIUS Called-Station-Id = 4850133 Vendor-Specific = Vendor-Specific = Vendor-Specific = Vendor-Specific = Vendor-Specific = Vendor-Specific = Vendor-Specific = Vendor-Specific = NAS-Identifier = tc01.austin NAS-Port-Type = Async Service-Type = Framed Framed-Protocol = PPP Framed-IP-Address = 209.99.40.37 Acct-Delay-Time = 0 Wed Oct 15 09:09:21 1997 Acct-Session-Id = 00002C3B User-Name = <USERNAME> NAS-IP-Address = 206.127.27.65 NAS-Port = 31 Acct-Status-Type = Stop Acct-Session-Time = 0 Acct-Terminate-Cause = Admin-Reset Acct-Authentic = RADIUS Called-Station-Id = 4850133 Vendor-Specific = Vendor-Specific = Vendor-Specific = Vendor-Specific = Vendor-Specific = Vendor-Specific = Vendor-Specific = Vendor-Specific = NAS-Identifier = tc01.austin Acct-Input-Octets = 386287 Acct-Output-Octets = 15300756 Acct-Input-Packets = 16702 Acct-Output-Packets = 21899 NAS-Port-Type = Async Service-Type = Framed Framed-Protocol = PPP Framed-IP-Address = 209.99.40.37 Acct-Delay-Time = 0 -- A lack of forethought and planning on your part tends to constitute a lack of cash on my part.

Subject: Re: (usr-tc) quad-modem idletime out
From: Jeff Lynch <jeff@mercury.jorsm.com>
Date: 1997-10-15 11:43:24

On Wed, 15 Oct 1997, Jeff Binkley wrote: [snip] > The outstanding question from a week ago on this subject is whether the RADIUS > setting will override the Netserver setting ? In other words if I used the > NETSERVER to set the "default" for all ports at say 15 minutes but I had one > custoemr, who paid extra, and I wanted them to have a longer timeout, would the > RADIUS option override it if I set it to say 60 minutes ? Or would the lower > value take precedence ? > > Jeff Binkley > ASA Network Computing > Just getting started with my Enterprise Hubs and don't have my T1's installed yet, but for what it's worth. A few years back, we had to disable idle timeout per port on Livingston Portmasters to allow Radius to idle parameters. Since the Netservers use an older version of COMOS I would try disabling idle timeout (set to 0) on each port and put the "Idle-Timeout = xxxx" in your users file. ========================================================================= Jeffrey A. Lynch, President 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) idletime question
From: pris sears <sears@vt.edu>
Date: 1997-10-15 11:51:06

Hi, has anyone come up with something clever to keep users from circumventing the idle-timeout? Many users set their email s/w to check often enough to get around the idle timeout - even if they don't get/send any mail it still resets the timer. We figured out how to keep ppp keepalives and pings from resetting the timer, but these empty mail checks are a stumper, (the ports are seemingly random that the checks and answers from the mail server go on) and some little users keep clinging on all day, resulting in busy signals for others at certain times. Thanks for any info - Pris

Subject: (usr-tc) TC Errors
From: Adam Wills (Global 2000) <sysadmin@global2000.net>
Date: 1997-10-15 12:07:49

Our Network Management card has suddenly popped a sold RED light on the "hub-status" light (second down). I am not at the location, but I assume this problem would involve some problem in ethernet wire running TO the network management card right? I had a tech run a clean wire to it, and its solid red (even though the unit is still fully accessible via TCM and can be ping'd to the network management card). the NMC and the NETSERVER card are on 2 phsical ethernet segements, and both are fully accessible and have been for months. Before I spend the time to head over to examine this RED alarm, any suggestions? I'm sifting through about 500 pages of manual pre-dated before RAP came out, so i'm not holding my breath to find the answers in there. Adam Wills Global 2000 Communications Director of Networking Systems 1840 Western Ave. sysadmin@global2000.net Albany, NY, 12203 http://www.global2000.net (518) 452-1465

Subject: Re: (usr-tc) idletime question
From: Adam Wills (Global 2000) <sysadmin@global2000.net>
Date: 1997-10-15 12:09:20

We set a 'session-limit' of 6 hours for users who are a problem like that. If you wanted, set a session-limit of 6 hours for everyone and just watch for say 2 weeks which users keep get radius-log-off messages in your rad accounting for "session-limit reached". Then you know who are at fault and you can start targeting just them (say with session-limits of 60 minutes until they disabled this). Adam Wills Global 2000 Communications Director of Networking Systems 1840 Western Ave. sysadmin@global2000.net Albany, NY, 12203 http://www.global2000.net (518) 452-1465 On Wed, 15 Oct 1997, pris sears wrote: > Hi, has anyone come up with something clever to keep users from > circumventing the idle-timeout? Many users set their email s/w to check > often enough to get around the idle timeout - even if they don't get/send > any mail it still resets the timer. We figured out how to keep ppp > keepalives and pings from resetting the timer, but these empty mail checks > are a stumper, (the ports are seemingly random that the checks and answers > from the mail server go on) and some little users keep clinging on all day, > resulting in busy signals for others at certain times. > > Thanks for any info - Pris > > >

Subject: Re: (usr-tc) TC Errors
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1997-10-15 12:21:25

Thus spake Adam Wills >Our Network Management card has suddenly popped a sold RED light on the >"hub-status" light (second down). I am not at the location, but I assume >this problem would involve some problem in ethernet wire running TO the >network management card right? I had a tech run a clean wire to it, and >its solid red (even though the unit is still fully accessible via TCM and >can be ping'd to the network management card). the NMC and the NETSERVER >card are on 2 phsical ethernet segements, and both are fully accessible >and have been for months. Before I spend the time to head over to examine >this RED alarm, any suggestions? I'm sifting through about 500 pages of >manual pre-dated before RAP came out, so i'm not holding my breath to find >the answers in there. If there is any card in the chassis in any sort of wigged out state (I'll leave the definition of wigged out up to the reader as its rather vague...intentionally so cause I'm not sure exactly what the definition is myself), the NMC card will show a red light. If you see any other cards in the chassis that are a yellow color, I'd say you have a candidate for the wigged out card. Do a hardware reset on that card and I suspect the NMC card will return to a nice pleasant green. If you don't have any yellow cards, then I'm not really sure, unless you've got a wigged out card, but not wigged out enough to make it yellow. *shrug* -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) quad-modem idletime out
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-15 12:26:28

Jeff Lynch said once upon a time: >I hate to say it, but the only definate way to completely solve this >problem is per unit charging. In our market, this is not possible, >because of the competition, so we just have to keep enough lines >installed to make idle spoofing unnecessary. What about people running their own server services? If they buy a static IP from us (which has its legitimate use under non-dedicated connections), then some people will abuse it. The way we approach this is to give them a friendly phone call that states, "Hmmm, you've been connected 95% of the time over a period of a week. Looks like you'd be interested in upgrading to dedicated services." We either get an apology, or the customer will usually upgrade.

Subject: (usr-tc) Perl counting routines
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-15 12:49:51

I had a need to write a script that would tabulate usage on our TC's during different times of the day, and on demand. The following Perl subroutines utilize "tcmperf" to return the number of people connected on a particular chassis. No warrantee express or implied. Feel free to distribute and modify. Blah blah blah. #!/usr/local/bin/perl $ENV{'TCMHOME'} = "/usr/local/lib/tcm"; $readsnmp = "public"; $tcmperf = "$ENV{'TCMHOME'}/bin/tcmperf -s 1 -c $readsnmp "; # count_channels_pri(NMC name, # of spans) # assumes NMC is "city-snmp" # returns the number of currently connected channels sub count_channels_pri { ($rack,$spans) = @_; $connected = 0; $idle = 0; while ($spans > 0 ) { open ( TCMPERF, "$tcmperf -G \"timeslot status group\" \"timeslot status\" ${rack}-snmp:s1c${spans}t1-23 2>&1 |"); while (<TCMPERF>) { if (/Timeslot Status/) { $connected = $connected + scalar(@junk = m/\bconnected\b/g); } } --$spans; } return ($connected); } # count_channels_ds1(NMC name, # of spans) # assumes NMC is "city-snmp" # returns the number of currently connected channels sub count_channels_ds1 { ($rack,$spans) = @_; $connected = 0; $idle = 0; while ($spans > 0 ) { open ( TCMPERF, "$tcmperf -G \"ds0 stats\" \"ds0 timeslot status\" ${rack}-snmp:s1c${spans}t1-24 2>&1 |"); while (<TCMPERF>) { if (/Timeslot Status/) { $connected = $connected + scalar(@junk = m/\bconnected\b/g); } } --$spans; } return ($connected); } # count_analog_modems(NMC IP/name, # of cards) # assumes modems in multiples of 4 and they start at slot 2 # assumes NMC is "city-snmp" # returns the number of currently connected modems sub count_analog_modems { ($rack,$slot) = @_; $connected = 0; $idle = 0; $slot = $slot + 1; while< ($slot > 1 ) { open ( TCMPERF, "$tcmperf -G \"call statistics\" \"operational status of a modem\" ${rack}-snmp:s${slot}c1-4 2>&1 |"); while (<TCMPERF>) { if (/Operational Status/) { $connected = $connected + scalar(@junk = m/\bonlineAnswer\b/g); } } --$slot; } return ($connected); }

Subject: Re: (usr-tc) idletime question
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1997-10-15 12:53:00

-> We set a 'session-limit' of 6 hours for users who are a problem like that. -> If you wanted, set a session-limit of 6 hours for everyone and just watch -> for say 2 weeks which users keep get radius-log-off messages in your rad -> accounting for "session-limit reached". Then you know who are at fault and -> you can start targeting just them (say with session-limits of 60 minutes -> until they disabled this). -> -> Adam Wills Global 2000 Communications -> Director of Networking Systems 1840 Western Ave. -> sysadmin@global2000.net Albany, NY, 12203 -> http://www.global2000.net (518) 452-1465 Where is this set at ? Jeff Binkley ASA Network Computing

Subject: Re: (usr-tc) quad-modem idletime out
From: Jeff Lynch <jeff@mercury.jorsm.com>
Date: 1997-10-15 12:58:01

On Wed, 15 Oct 1997, Pete Ashdown wrote: > Jeff Lynch said once upon a time: > > >Just getting started with my Enterprise Hubs and don't have my T1's > >installed yet, but for what it's worth. A few years back, we had > >to disable idle timeout per port on Livingston Portmasters to allow Radius > >to idle parameters. Since the Netservers use an older version of COMOS > >I would try disabling idle timeout (set to 0) on each port and put the > >"Idle-Timeout = xxxx" in your users file. > > This isn't necessary on the TC's. It believes the RADIUS Idle-Timeout over > anything else, specified or not. However, this doesn't stop people from > spoofing. As stated previously, it would be great if we could make > whatever detects "activity" tied to a filter. However, most TCP based > traffic would still need to be let through. There are times when I need to > spoof my own system, so I just setup a loop of "telnet host 13" to hit the > clock port every five minutes. > > Maybe if USR built in some sort of intelligent monitor that looked for > repeated traffic over set periods of time. That is, if someone is hitting > the POP server every N minutes for X time, disconnect them. I'll bet a > brick against London that most spoofers don't use random waits in their > loop scripts. Great idea, but I doubt USR or any access server vendor would do it because it's a moving target. Then someone will write randomness into idle spoofer shareware. Spoofers will find new ways to spoof. Alternatively, the data can be easily syslogged and parsed more powerfully and flexibly on a Unix host, but then he could spoof by popping a server beyond your control. That leaves forcing everything through a proxy and spending lots of time being big brother. The random spoofers will also get t Then you get into problems of policy, ie, you may not set your mail check at a lower level than our idle timeout, for example. I hate to say it, but the only definate way to completely solve this problem is per unit charging. In our market, this is not possible, because of the competition, so we just have to keep enough lines installed to make idle spoofing unnecessary. ========================================================================= Jeffrey A. Lynch, President 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) FYI: Lucent to buy Livingston.
From: Michael Wronski <mwronski@coredump.ae.usr.com>
Date: 1997-10-15 13:37:10

I just heard this.. Very interesting.. Lucent Technologies To Purchase Livingston Enterprises, Inc., A Leader In Remote Access Networking For The Internet Business/Technology Editors Business Wire - October 15, 1997 11:31 LUCENT-TECH LIVINGSTON LU %NEW-JERSEY %COMPUTERS %ELECTRONICS %COMED %TELECOMMUNICATIONS %INTERACTIVE %MULTIMEDIA %INTERNET %MERGERS %ACQ V%BW P%BW Purchase of Livingston Adds to Enhanced Data Networking Portfolio In another step to address high-growth opportunities in the Internet and data networking business, Lucent Technologies today said it will acquire Livingston Enterprises, Inc., a leading provider of remote access networking solutions, in a merger involving approximately $650 million worth of Lucent stock. Livingston is a leading global provider of equipment that remotely connects computers to providers of Internet service. The transaction is expected to be completed by the end of December. "While the data networking industry is growing rapidly, the remote access business is particularly attractive, with overall growth at more than 20 percent and with the demand for equipment to service providers growing by nearly 50 percent annually," said Bill O'Shea, president of Lucent's Business Communications group, who has overall responsibility for the corporation's data networking strategy. "By purchasing Livingston, we have the opportunity to add significant new data networking revenue." "Just last month Lucent introduced a strategy to address the data networking business and a series of new products that were positively received by the industry," said Harry Bosco, president of Lucent's Broadband Networking Systems group. "Today we are taking the next step in implementing that strategy by adding Livingston's people and their next-generation products to our portfolio -- making our offer to service providers and enterprises even more powerful." Livingston, as a division of Lucent, will remain headquartered in Pleasanton, Calif. The division will be headed by Steven Willens, its current president and CEO. The division will report to O'Shea. "We are tremendously excited about becoming a part of Lucent," Willens said. "On our own, we built a leadership position providing remote access servers to more than 2,200 Internet Service Providers (ISPs) around the world," he said. "Just think what we can do with the relationships and resources of Lucent behind us." "With our existing remote access server family and with new capabilities under development, working as a part of Lucent we have the opportunity to more effectively meet the needs of the diverse set of ISPs and traditional service providers offering Internet service," he said. "This deal with Lucent is a natural fit -- our advanced technology and products and Lucent's unmatched experience as a high-quality supplier to large service providers." O'Shea noted that the Internet industry will continue to see larger service providers entering the market or going for larger market share. "These large network operators specialize in providing high-quality, highly-reliable communications networks," he said. "They are demanding that their equipment suppliers deliver systems that integrate into existing operations systems, that deliver cost-effective administration and maintenance support and that experience minimal downtime. The Lucent-Livingston combination will deliver on all of these critical customer requirements." The purchase is expected to result in a one-time, non-cash charge against earnings. The charge involves an accounting writeoff assigned to in-process research and development and will be taken in the first fiscal quarter of 1998 assuming the transaction is closed by Dec. 31, 1997. Excluding this one time charge, the purchase is expected to be slightly dilutive to earnings in the first year of operation and neutral by year two. Livingston, a privately held corporation founded in 1986, markets products to more than 2,200 Internet Service Providers worldwide. The company's RADIUS(TM) software has become an industry standard for providing Internet access security, accounting and billing information, and network management. Last year Livingston introduced the highly-reliable PortMaster 3 remote access concentrator, which integrates digital modem, router and communications server functionality with support for analog modems, ISDN, frame relay and leased line connections. The PortMaster 3 is based on Lucent's leading K56flex(TM) modem technology. In addition to remote access concentrators, Livingston provides office routers and firewall routers that are resold by ISPs to corporate customers for Internet connectivity and other remote access networking applications. In September, Lucent introduced an enhanced portfolio of intelligent switching, access and network management products as a part of its plan to dramatically improve data network performance. As a part of its data networking portfolio, Lucent also offers industry-leading professional support services capability through NetCare(R)Services, a broad set of consulting, integration, management and maintenance services for multivendor data and video networks, voice systems and networks and call centers. For more information on Livingston Enterprises, Inc., browse the company's home page at http://www.livingston.com. Lucent Technologies designs, builds and delivers a wide range of public and private networks, communications systems and software, business telephone systems and microelectronics components. Bell Labs is the research and development arm for the company. More information about Lucent Technologies, headquartered in Murray Hill, N.J., is available on its Web site at http://www.lucent.com. NOTE: There will be a media conference call at 1:30 p.m. Eastern time with Harry Bosco -- president of Lucent's Broadband Network Group. The call-in number is 1-800-288-8961. CONTACT: Lucent Technologies, Murray Hill John Callahan 908/953-5350 (office) 703/758-1449 (home) johncallahan@lucent.com or Lynda Beighley 908/582-3060 (office) 201/635-7959 (home) lbeighley@lucent.com

Subject: (usr-tc) Net Manager Card
From: Peter Barton <peter@flash.net>
Date: 1997-10-15 13:57:36

I just received a NMC from USR/3Com and it already has a password set up on it. Can anyone tell me how to clear the community strig/password? Thanks in advance, Peter Barton FlashNet Communications Project Leader for Network Administration (817)332-8883 ext. 290

Subject: Re: (usr-tc) quad-modem idletime out
From: MegaZone <megazone@livingston.com>
Date: 1997-10-15 14:41:59

Once upon a time Jeff Binkley shaped the electrons to say... >The outstanding question from a week ago on this subject is whether the RADIUS >setting will override the Netserver setting ? In other words if I used the RADIUS should override the local idle timer. UNLESS RADIUS sends a 0. 0 is supposed to mean 'use the local timer'. If you really want to have NO timer for someone, then set it to 0 locally and use RADIUS to set it for everyone who has them. I think that's easier myself anyway - centralized management. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588

Subject: Re: (usr-tc) Net Manager Card
From: David Bolen <db3l@ans.net>
Date: 1997-10-15 16:22:44

Peter Barton <peter@flash.net> writes: > I just received a NMC from USR/3Com and it already has a password set > up on it. Can anyone tell me how to clear the community strig/password? I believe DIP switch 5 on an NMC will erase flash upon boot (similar to the NETServer). Set the switch, boot up, then reset the switch and boot again to begin running normally. -- 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) quad-modem idletime out
From: Pris Sears <sears@vt.edu>
Date: 1997-10-15 16:22:57

>On Wed, 15 Oct 1997, Pete Ashdown wrote: > >> Jeff Lynch said once upon a time: >> >> Maybe if USR built in some sort of intelligent monitor that looked for >> repeated traffic over set periods of time. That is, if someone is hitting >> the POP server every N minutes for X time, disconnect them. I'll bet a >> brick against London that most spoofers don't use random waits in their >> loop scripts. > >Great idea, but I doubt USR or any access server vendor would do it >because it's a moving target. Then someone will write randomness >into idle spoofer shareware. Spoofers will find new ways to spoof. >Alternatively, the data can be easily syslogged and parsed more powerfully >and flexibly on a Unix host, but then he could spoof by popping a server >beyond your control. That leaves forcing everything through a proxy >and spending lots of time being big brother. The random spoofers >will also get t I think our users that are willing and able to go this far are a big minority - as Jeff says, most don't use any random waits - most are just using the built-in feature of many email programs to check at x minutes which requires almost no thought on the users' part to set, but is really hard to filter out as an undesirable keepalive on our end. the folks that run our mailserver hate that feature anyway, as some folks set it to really low times and beat up the mailserver. maybe there would be an answer on the mailserver end? set it to ignore requests more often than x minutes? that would be really popular with our mail folks. >Then you get into problems of policy, ie, you may not set >your mail check at a lower level than our idle timeout, for example. we thought of something similar, but rejected the idea as impractical, hard to enforce, etc. >I hate to say it, but the only definate way to completely solve this >problem is per unit charging. In our market, this is not possible, >because of the competition, so we just have to keep enough lines >installed to make idle spoofing unnecessary. I'm at a .edu, per unit charging ain't gonna happen....our aup has some vague talk about net access being a "shared resource" and we are very stingy with static ip addresses, but there are not any specifics about how many hours a day a user can be connected, etc. we don't have levels of service, just a flat fee. and I think we just have too many users, all with easy to set up email clients that do autochecks, to set up a list of offenders to kick off at a time limit. it just wouldn't be practical... we've fought with this for a while now and not come up with any good solutions. maybe it will have to come from the mail server/client s/w folks. - Pris

Subject: Re: (usr-tc) ISDN->I-modem or Daughtercard?
From: David Bolen <db3l@ans.net>
Date: 1997-10-15 16:28:26

Brian <signal@shreve.net> writes: > Is there any advantages of using the I-modems instead? Does it help > anything, by offloading everything from the Daughtercard? Technically the daughtercard implements the low level framing and HDLC control and what not, and it can handle the full set of channels so there's no particular need to offload load from it. However, the NETServer CPU does have to take care of the other aspects of the PPP session, so switching to servicing ISDN calls via the modems does offload some CPU in that regard (assuming that you have SLIP/PPP framing in the modems enabled on the NETServer). > I think you just set your ISDN gw in the PRI card to slot 0 to get this > functionality, and then go into the ISDN options of TCM and set the modems > up accordingly. Pretty much. The PRI defaults to "falling over" to trying any modems in the chassis that are ISDN capable if either (a) there is no default gateway configured or (b) the default gateway is not accepting the call, such as if you use up the B channels you have configured the NETServer to accept. > We run PPP in the modems rather than the netserver, we feel we have seen > better results with this, and it makes sense. We are just wondering if we > should do the same with ISDN.......just put everything on S ports We've done both - often choosing the modem path as simpler for some of our back-end tools in the short term because it looks just like analog calls (from the perspective of port usage). My guess is that you'll achieve slightly better latency via the direct NETServer approach because there is no packet bus involved in the path. I haven't quantified this for sure though. One negative with the current code base with the modem approach is that they do not currently implement CCP compression, which you can have with the NETServer directly. So you'll lose 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) line problems
From: David Bolen <db3l@ans.net>
Date: 1997-10-15 16:32:20

Brian <signal@shreve.net> writes: > its only been up 11 hours and has quite a few errors, and also its the > ONLY pri we have that has 7.5db gain......others have 0............. > > how bad is 809 framing bit errors in 11 hours? massive? No, it's not massive (think of how many bits-per-second are flying across a 1.5Mbps circuit), but it might still be indicative of a bigger problem. The time scale would also be useful, since you managed to accumulate enough problems at one point to have a full 2 errored seconds. If you use TCM (or direct SNMP) you can query DS1 interval stats in 15 minute intervals - this would let you "bucket" your errors over a time scale as opposed to just having a single totals value. You might find that you are taking the errors gradually, or that they all occurred during a single spike or event. But if this is one of many similar circuits at your site (similarly homed, routed, physically cabled and terminated, etc..) then the deviation in the receiver gain and error count is a good indication that you've got a circuit problem. I'd suggest having the telco test to their demarc and if they claim it's clean see if they're willing to run to your equipment (the card will respond to their remote loopback as long as you've enabled the configuration option). If the problem seems to point at you, try switching the cabling and/or the line card. -- 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) V34 back channel
From: David Bolen <db3l@ans.net>
Date: 1997-10-15 16:33:41

Brian <signal@shreve.net> writes: > What do you all recommend running the v34 back channel at on the Quad > Modems? Perhaps I'm mis-reading the question, but you don't really specify a back channel - it's something that the modems automatically negotiate. You shouldn't have to worry about any configuration in that regard. Are you asking if you should be trying to limit it or something? -- 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) Net Manager Card
From: Casey Cook <caseyc@gate.net>
Date: 1997-10-15 16:52:00

The password on the newer NMC cards is the default read/write string, 'public' for read and 'private' for write. When prompted for that initial password at the console, enter 'private' and once in you can configure it to whatever you want. On Wed, 15 Oct 1997, Peter Barton wrote: > I just received a NMC from USR/3Com and it already has a password set > up on it. Can anyone tell me how to clear the community strig/password? > > Thanks in advance, > > > Peter Barton > FlashNet Communications > Project Leader for Network Administration > (817)332-8883 ext. 290 > > > =============================== Casey Cook CyberGate Network Administrator caseyc@gate.net ===============================

Subject: Re: (usr-tc) Second T-1 woes
From: Brian <signal@shreve.net>
Date: 1997-10-15 17:26:46

On Wed, 15 Oct 1997, Jeff Binkley wrote: > > I've had a TC chassis running for some time now and installed a second PRI > about 2 weeks ago. Both PRIs have D channels on them. In order to test that > the second one worked, I knocked down the first one early one morning and > calls continued to come in on the second PRI. Now last night we had our first > occasion where the first PRI filled up and instead of calls going to the second > PRI, we got a busy signal. My first inclination would be to call Ameritech > but I am not 100% sure it is their problem. I went into the PRI settings and > attempted to change the call routing parameter to see if I could get calls onto > the modems in slots 8-13 (the second PRI) by changing the analog modem > selection from first available to roundrobin. This had the calls being > sequenced over cards 2-7, the first PRI's cards. I next tried fixed assignment > and seemed to resemeble more of a least idle selection sequence. At this point > I am not sure how to get calls over to the other cards. Is it normal for > round robin to only hunt within a single PRI on the TC ? I'm suspecting the > real problem is a D channel parameter problem since they appear to work > independently. Thoughts ? This is going into a DMS-100 switch. > The next time this happens, check the DS0 status on the span having problem. If they are LOOS or OOS instead of IDLE, then go into "command" section and "Change DS0 status for entire span" and put them back in service. With DMS 100 switches for example, if the telco puts them oos for a while, you HAVE to manually put them back in service, the command sent from the dms 100 to the tc hub, usually will not work, this is some problem with dms 100's that USR is aware of from what I understand. Brian > > Jeff Binkley > ASA Network Computing > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: Re: (usr-tc) idletime question
From: Charles Hill <chill@ionet.net>
Date: 1997-10-15 18:04:38

> Hi, has anyone come up with something clever to keep users from > circumventing the idle-timeout? Charge users by the minute if they use more than X hours a month. Cellular service works like that, why not internet service? -CH

Subject: Re: (usr-tc) Perl counting routines
From: Brian <signal@shreve.net>
Date: 1997-10-15 18:08:16

On Wed, 15 Oct 1997, Pete Ashdown wrote: > I had a need to write a script that would tabulate usage on our TC's during > different times of the day, and on demand. The following Perl subroutines > utilize "tcmperf" to return the number of people connected on a particular > chassis. No warrantee express or implied. Feel free to distribute and > modify. Blah blah blah. Where can one get tcmperf? Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: Re: (usr-tc) 16 meg Netserver Upgrade
From: Greg Coffey <greg@coffey.com>
Date: 1997-10-15 19:31:27

We did get it working with the same nonparity one that I tried earlier. Seemed that the cure was to upgrade the software on the netserver card first and that took care of it. Thanks for the suggestions. At 06:21 PM 10/13/97 -0400, you wrote: >: We're in the process of upgrading the memory of the netserver card. I have >: a nonparity, nonedo 16 meg 72 pin simm to add. Is there anything else that >: I need to do to the system to make this work? > >Maybe a smaller SIMM: We plugged a 16 meg SIMM into an older netserver, and >it fouled it up pretty bad. USR tech support told us to install no more than >4M more, I believe. > >--- >Mark R. Lindsey, mark@datasys.net >Network Engineer, DSS Online >Voice: +1 912 241 0607; Fax: +1 912 241 0190 > > Thanks, Greg Coffey, CoffeyNet Voice 307-234-5443 307-234-5446 Fax ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ 142 S. Center St. US Robotics x2 56k $20 in Casper Casper, WY 82601 Local Internet for Casper, Rawlins, Douglas, www.coffey.com Wheatland, Pinedale, Lander & Lusk, WY ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~

Subject: (usr-tc) Looking for Netserver and dual T1 Cards
From: Greg Coffey <greg@coffey.com>
Date: 1997-10-15 19:34:22

I'm still looking for a netserver card and dual T1 card to update an older chassis here. Surely one of you has an extra one of them around that you'd like to convert to some cash. Older T1 cards are fine, here in UselessWestland, PRI's are EXPENSIVE. Thanks, Greg Coffey, CoffeyNet Voice 307-234-5443 307-234-5446 Fax ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ 142 S. Center St. US Robotics x2 56k $20 in Casper Casper, WY 82601 Local Internet for Casper, Rawlins, Douglas, www.coffey.com Wheatland, Pinedale, Lander & Lusk, WY ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~

Subject: Re: (usr-tc) quad-modem idletime out
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1997-10-15 21:42:00

-> > -> > The outstanding question from a week ago on this subject is whether the -> RADIUS -> > setting will override the Netserver setting ? In other words if I used -> the > NETSERVER to set the "default" for all ports at say 15 minutes but I -> had one > custoemr, who paid extra, and I wanted them to have a longer -> timeout, would the -> > RADIUS option override it if I set it to say 60 minutes ? Or would the -> lower -> > value take precedence ? -> > -> > Jeff Binkley -> > ASA Network Computing -> > -> The Radius setting should override the port setting. When the idle time is -> issued by the Radius all the port setting is over written by the radius -> profile. In your case the user will stay as long as Radius has set the idle -> time. Krish, Thanks for the reply. I had hoped it worked this way. We'll do some testing. Jeff Binkley ASA Network Computing

Subject: Re: (usr-tc) idletime question
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1997-10-15 22:34:04

: > Hi, has anyone come up with something clever to keep users from : > circumventing the idle-timeout? : : Charge users by the minute if they use more than X hours a month. : Cellular service works like that, why not internet service? Brutal markets where that makes you the oddball and the target of advertising render that unfeasible. I'm a fan of the `Virtually-unlimited' account, where a rather high number (250 hours, e.g.) is set per month. When a user averages over that limit for, say, 3 months, then they get a note in the email and a bill for dedicated services. You'll want to build that into the original contract they sign, though. Mark

Subject: Re: (usr-tc) EdgeServer questions
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-10-16 02:55:43

On Thu, 16 Oct 1997, Randy Doran wrote: > Were thinking of trying out an EdgeServer card at one of our remote pops > and I'm looking for some information on them. Does anybody know if they > have a hard drive on them or do they have lots of flash rom? Do they come > with OS and software installed or can you load your own? How would a > radius file be loaded on them? Has anybody had any experience with them > and can tell me if there is any advantage to using one of them as opposed > to a stand alone Unix box for radius? Any information would be helpful. > Thanks, > Randy Doran > CyberGate Network Operations The Edge server card has 3 flavors - NT, Solaris and BSDI. It comes with a harddrive. This is a NT server running RAS and uses the packet bus to communicate with the modems, Users are configured on the RAS and they log on to the NT server. You can run Radius on these Edgeserver NT. I am not sure about Solaris and BSDI - I do know we have it. krish > >

Subject: Re: (usr-tc) 16 meg Netserver Upgrade
From: Wayne Barber <barberw@tidewater.net>
Date: 1997-10-16 08:49:15

> We did get it working with the same nonparity one that I tried earlier. > Seemed that the cure was to upgrade the software on the netserver card > first and that took care of it. Thanks for the suggestions. > > Thanks, > Greg Coffey, CoffeyNet Voice 307-234-5443 307-234-5446 Fax I tried doing this, too. I upgraded the software to 3.5.34 and then installed the 16meg SIMM. However, when I did this the netserver card reset itself every 10 - 30 minutes - dropping all users when it did that. Anyone know what needs to be changed? The netserver has an FC3 chip if that matters. Here's the version: U.S. Robotics Total Control (tm) NETServer Card V.34 V3.3.3 Build date: Nov 27 1996 Build time: 17:06:59 Network Interface Card: Ethernet (24) Packet Bus Circuit : Standard Licensed for 60 ports. Thanks, Wayne Barber - barberw@tidewater.net Internet System Administrator Coastal Telco Services

Subject: Re: (usr-tc) (SNMX) Perl counting routines
From: Wayne Barber <barberw@tidewater.net>
Date: 1997-10-16 09:18:18

I also was interested in seeing how many modems were in use automatically, but went a different route. Here is an SNMX script that connects to the nmc and then checks the status of each modem. This script could easily be modified (and improved, I'm sure) to check for problems. You also need SNMX, which is freely available from www.cpro.com and the USR MIB which came with TCM. Just invoke SNMX on your system: snmx mdmtest > output.file (to overwrite output.file) or snmx mdmtest >> output.file (if you want to append to the output.file) or snmx mdmtest (to output to screen) Here's the whole script: set -clear set $busy = 0 connect <nmc> <public> <private> 10 mib -load usr.mdb cd /private/enterprises/usr/nas/mdm/mdmCs/mdmCsTable/mdmCsEntry repeat foreach $status in mdmCsStatus if $status eq 8 set $busy = [$busy + 1] endif endrepeat set -exec $date = "date '+%a %b %e %T %Y'" echo $date.1 $busy exit On the connect line, don't use the <>s and substitute the name of your nmc card along with the public and private strings and the timeout value of 10 or lower. The public, private and timeout can be omitted if the public and private strings are still at the default of public and private. Wayne Barber - barberw@tidewater.net Internet System Administrator Coastal Telco Services

Subject: Re: (usr-tc) Perl counting routines
From: Michael Wronski <mwronski@coredump.ae.usr.com>
Date: 1997-10-16 09:51:36

At 06:08 PM 10/15/97 -0500, you wrote: >On Wed, 15 Oct 1997, Pete Ashdown wrote: > >> I had a need to write a script that would tabulate usage on our TC's during >> different times of the day, and on demand. The following Perl subroutines >> utilize "tcmperf" to return the number of people connected on a particular >> chassis. No warrantee express or implied. Feel free to distribute and >> modify. Blah blah blah. > >Where can one get tcmperf? > Its part of TCM UNIX.. -M `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' Mike Wronski(mwronski@coredump.ae.usr.com) 3Com/U.S.Robotics Network Systems Engineer (Level 3) PGP: http://coredump.ae.usr.com/pgp

Subject: Re: (usr-tc) (SNMX) Perl counting routines
From: Michael Wronski <mwronski@coredump.ae.usr.com>
Date: 1997-10-16 10:00:08

Another way to find out how many modems are in use is to query the LED's in the chassis.. Using the following two OID's: $LEDstates = '.1.3.6.1.4.1.429.1.1.3.5.0'; #Is LED on/off/blinking $LEDcolor = '.1.3.6.1.4.1.429.1.1.3.6.0'; #Is LED red/yellow/green You can get the data for a chassis in one get and then parse it for the number of modems. I suggest using LEDcolor and look for the green ones. The description of this OID is in the OLD mib document supplied with NMC cards. Its a bit string and its values tell you the location and color of the LEDS. The program is not as simple but the return time is fairly quick.. -M At 09:18 AM 10/16/97 +0000, you wrote: >I also was interested in seeing how many modems were in use >automatically, but went a different route. Here is an SNMX script >that connects to the nmc and then checks the status of each modem. >This script could easily be modified (and improved, I'm sure) to >check for problems. You also need SNMX, which is freely available >from www.cpro.com and the USR MIB which came with TCM. Just invoke >SNMX on your system: > >snmx mdmtest > output.file (to overwrite output.file) >or >snmx mdmtest >> output.file (if you want to append to the >output.file) >or >snmx mdmtest (to output to screen) > >Here's the whole script: > >set -clear >set $busy = 0 >connect <nmc> <public> <private> 10 >mib -load usr.mdb >cd /private/enterprises/usr/nas/mdm/mdmCs/mdmCsTable/mdmCsEntry >repeat >foreach $status in mdmCsStatus > if $status eq 8 > set $busy = [$busy + 1] >endif >endrepeat >set -exec $date = "date '+%a %b %e %T %Y'" >echo $date.1 $busy >exit > >On the connect line, don't use the <>s and substitute the name of >your nmc card along with the public and private strings and the >timeout value of 10 or lower. The public, private and timeout can be >omitted if the public and private strings are still at the default of >public and private. > > > > >Wayne Barber - barberw@tidewater.net >Internet System Administrator >Coastal Telco Services > `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' Mike Wronski(mwronski@coredump.ae.usr.com) 3Com/U.S.Robotics Network Systems Engineer (Level 3) PGP: http://coredump.ae.usr.com/pgp

Subject: Re: (usr-tc) Looking for Netserver and dual T1 Cards
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-16 11:30:03

Greg Coffey said once upon a time: > >I'm still looking for a netserver card and dual T1 card to update an older >chassis here. Surely one of you has an extra one of them around that you'd >like to convert to some cash. Older T1 cards are fine, here in >UselessWestland, PRI's are EXPENSIVE. I have a pair.. I think. Let me check and I'll get back to you with a price.

Subject: Re: (usr-tc) Perl counting routines
From: Garry Shtern <shterng@akula.com>
Date: 1997-10-16 13:54:21

At 09:51 AM 10/16/97 -0500, Michael Wronski wrote: >> >Its part of TCM UNIX.. > But if you don't have HPUX or Solaris you won't be able to use it. Is there anyway to get a source code to this program? Garry Shtern shterng@akula.com Chief Network Administrator http://www.akula.com Akula Communications Corp. tel. (212) 292-8892

Subject: (usr-tc) ISDN port weirdness
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-16 14:22:35

I'm starting to see entries like this on my Netserver ISDN ports: I19 daynacom - Netwrk In WAITING RESP - 6days Resetting the port doesn't do anything to fix it. Yet, the port doesn't get reused by a regular ISDN session (note the 6 days). -- Pete XMission

Subject: (usr-tc) EdgeServer questions
From: Randy Doran <rtdoran@gate.net>
Date: 1997-10-16 14:28:35

Were thinking of trying out an EdgeServer card at one of our remote pops and I'm looking for some information on them. Does anybody know if they have a hard drive on them or do they have lots of flash rom? Do they come with OS and software installed or can you load your own? How would a radius file be loaded on them? Has anybody had any experience with them and can tell me if there is any advantage to using one of them as opposed to a stand alone Unix box for radius? Any information would be helpful. Thanks, Randy Doran CyberGate Network Operations

Subject: Re: (usr-tc) Perl counting routines
From: Michael Wronski <mwronski@coredump.ae.usr.com>
Date: 1997-10-16 15:24:26

At 01:54 PM 10/16/97 -0400, you wrote: >At 09:51 AM 10/16/97 -0500, Michael Wronski wrote: >>> >>Its part of TCM UNIX.. >> > >But if you don't have HPUX or Solaris you won't be able to use it. Is >there anyway to get a source code to this program? No, sorry. This is not shareware or freeware. I would suggest ucdsnmp and perl if you dont plan to invest in the TCM package.. -M `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' Mike Wronski(mwronski@coredump.ae.usr.com) 3Com/U.S.Robotics Network Systems Engineer (Level 3) PGP: http://coredump.ae.usr.com/pgp

Subject: Re: (usr-tc) ISDN port weirdness
From: Michael Wronski <mwronski@coredump.ae.usr.com>
Date: 1997-10-16 16:32:55

At 05:06 PM 10/16/97 -0400, you wrote: >If you are running an MPIP server and you have any NetServer clients with >different versions of code then you will see this. If you upgrade all of >the MPIP NetServer clients to the same version (all 3.4.x or all 3.5.x) >then this problem should go away. I don't think the different versions of >code know how to talk to each other through the MPIP server and >eventually all 59 "I" ports will get stuck like this. To clear those >stuck ports you will have to reboot the NetServer. > >Randy Doran Randy is correct. For MPIP applications all netservers involved should be running the same code. -M `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' Mike Wronski(mwronski@coredump.ae.usr.com) 3Com/U.S.Robotics Network Systems Engineer (Level 3) PGP: http://coredump.ae.usr.com/pgp

Subject: Re: (usr-tc) EdgeServer questions
From: David Bolen <db3l@ans.net>
Date: 1997-10-16 16:59:40

Randy Doran <rtdoran@gate.net> writes: > Were thinking of trying out an EdgeServer card at one of our remote pops > and I'm looking for some information on them. Does anybody know if they > have a hard drive on them or do they have lots of flash rom? The current EdgeServer configuration is a 64MB 486DX4-100 with a 1GB hard drive. It does have a flash SIMM on it as well - I don't know the exact size, but I'm betting it's only a 2MB or so. Technically, the base card of the EdgeServer is the same as the "enhanced" NETServer card, with the exception that a different DRAM bank is surface mounted with 32MB of memory (as opposed to 16MB on the NETServer). The RAM SIMM slot contains a 32MB SIMM. The daughter card (the EdgeServer occupies two slots) contains the hard and floppy drive (both are basically notebook-type hardware, the hard drive is the 12mm form factor IDE). There are two NICs - the one behind the primary slot is the same high performance ethernet NIC used for other cards such as the NETServer (although the NMC still uses the older ethernet NIC). The one behind the secondary slot exports a SCSI-2 interface. There's no SCSI hardware on the actual EdgeServer itself but you can use the external connector for anything you want (such as a CD-ROM for installations and stuff). In addition to the NICs, there are jacks on the _front_ of the EdgeServer where you can plug in a standard keyboard, VGA monitor and mouse. > Do they come > with OS and software installed or can you load your own? How would a 3Com's primary environment is WinNT, modified to have a packet bus driver and NMC communications. This allows you to terminate modem calls internally within the chassis on the WinNT system as well as have some basic remote management via the NMC. Of course, you can also run anything else you want on it under WinNT. I believe that 3Com does sell it all pre-installed and ready to go. 3Com also announced a while back that they were working with BSDI to support BSD/OS on the unit - don't know if they actively sell that yet or not. As for loading your own, technically the EdgeServer is just a normal 486PC, and yes, you can just boot a DOS diskette and/or just about any other systems that can work on a PC. There are some wrinkles however in terms of the NICs - there are some specific (and to my knowledge, undocumented) I/O instructions that must be executed to control the IRQ/DMA lines used by the various ports on the NICs. Without that although you'll be able to use the system locally (keyboard/monitor/mouse) it won't have network or serial console access. I think the SCSI may work normally though. So you'd probably want to stick with an OS supported by 3Com. > How would a > radius file be loaded on them? That would depend on the OS you were running. In general, you'd just be installing/running an appropriate RADIUS server for the environment you were using on the EdgeServer, and then that RADIUS server would control how it kept the database of users and/or how you updated it. > Has anybody had any experience with them > and can tell me if there is any advantage to using one of them as opposed > to a stand alone Unix box for radius? Any information would be helpful. We've got perhaps 500 of them in operation in our network at this time, having standardized on them as our remote management platform when they became available at the end of '96. By and large we've been very happy with them. We operate them running a customized build of BSD/OS, and they are all managed remotely (none have local keyboard/display/mouse configurations). I don't have any experience with the WinNT configuration, but the hardware works well for us. Of those we had installed as of 6 months ago (about 120), the average uptime for the boxes is around 4 months. About 30% of those boxes have been up the whole time (average uptime of that set is 230 days). Of course, stability is as much a function of the OS as the hardware, but all in all we've been happy, and the EdgeServers have held up quite well when compared to other Unix management platforms we have deployed. (I guess this is kind of a statistically insignificant metric since all sorts of issue such as scheduled maintenance, site outages, etc.. can contribute to downtime without being the fault of the EdgeServer, but it sounds kind of good anyway :-)) As for advantages over a stand alone Unix box, the single biggest one for us is form factor. By fitting into a chassis it saves us rack space, shares the redundant power supplies of the chassis (and thus also works in a DC environment), and permits some remote control such as hardware resets if it is hung - providing you have an NMC in the chassis with the EdgeServer. Of course, such resets run the risk of file corruption just like cycling any PC, but it's still nice to have that option remotely if you want. Of course, there's also a benefit to sharing the same vendor for your management machine as you do for the dialup gear in terms of servicing, maintenance, etc... If you need multiple boxes in a location to provide other services, you can outfit a chassis just with EdgeServers and get perhaps 7-8 machines in the space of one chassis (8.75" rack space). The primary downside compared to a standalone PC is that you pay for the above form factor and remote convenience - perhaps significantly more if you don't already have a chassis with spare slots and have to get a chassis to hold the EdgeServer. It's kind of like buying a notebook computer, which costs more than the equivalent desktop machine. The current hardware is also only a DX4-100, so you can certainly get a much more powerful PC cheaply. -- 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) ISDN port weirdness
From: Randy Doran <rtdoran@gate.net>
Date: 1997-10-16 17:06:27

If you are running an MPIP server and you have any NetServer clients with different versions of code then you will see this. If you upgrade all of the MPIP NetServer clients to the same version (all 3.4.x or all 3.5.x) then this problem should go away. I don't think the different versions of code know how to talk to each other through the MPIP server and eventually all 59 "I" ports will get stuck like this. To clear those stuck ports you will have to reboot the NetServer. Randy Doran CyberGate Network Operations On Thu, 16 Oct 1997, Pete Ashdown wrote: > I'm starting to see entries like this on my Netserver ISDN ports: > > I19 daynacom - Netwrk In WAITING RESP - 6days > > Resetting the port doesn't do anything to fix it. Yet, the port doesn't > get reused by a regular ISDN session (note the 6 days). > > -- > Pete > XMission > > >

Subject: Re: (usr-tc) USR TC reboots?
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-16 17:10:41

Bob Purdon said once upon a time: >A few weeks ago I remember seeing someone comment that all of their TC >racks on the one network segment rebooted within a short time of each >other.. > >Ours have just done the same thing - over the course of an hour BOTH of >our racks at one POP rebooted after 90 days of uptime. > >Any ideas anyone? I still don't know what caused it, but I blocked off my Netservers and NMC cards at our borders with Cisco filters. There have been 488 matches since, no idea if they're malicious or not. I wonder how the Netservers would react to a "smurf" attack?

Subject: Re: (usr-tc) Perl counting routines
From: David Bolen <db3l@ans.net>
Date: 1997-10-16 17:21:49

Michael Wronski <mwronski@coredump.ae.usr.com> writes: > No, sorry. This is not shareware or freeware. I would suggest ucdsnmp and > perl if you dont plan to invest in the TCM package.. Or if you're a TCL user, we use the Scotty/TNM snmp stuff for most of our scripts. (We've tweaked it to read our own MIB format files, but the standard package directly reads .mib files). -- 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) EdgeServer questions
From: Richard Mazurowski <sysop@surfnetcorp.com>
Date: 1997-10-16 17:40:25

Randy Doran wrote: > > Were thinking of trying out an EdgeServer card at one of our remote pops > and I'm looking for some information on them. Does anybody know if they > have a hard drive on them or do they have lots of flash rom? Do they come > with OS and software installed or can you load your own? How would a > radius file be loaded on them? Has anybody had any experience with them > and can tell me if there is any advantage to using one of them as opposed > to a stand alone Unix box for radius? Any information would be helpful. > Thanks, > Randy Doran > CyberGate Network Operations I do not actually use one right now but I just got back from and ISP meeting that 3Com held in Illinois and I was looking at the card at their facility......The card has a PCMCIA hard drive built in and comes pre-loaded with NT......you could also use BSDI Unix as well with the card...Pretty nice...3Com says the list is like 10 grand but I am not sure.....Nice unit.....ANS also leases space in the 3Com building where the built the pop equiptment for AOL....8foot ANS rack....4 Total control enterpise hubs fully populated....plus another total hub with various cards in it ans a cisco 2501 router....the other total hub has the edgeserver card in it running unix and the clients are actually authenticated by the edgeserver right there at the pop....Even thought AOL is involved and I dont like to hear about them it was pretty interesting....If you need more info please let me know......

Subject: Re: (usr-tc) USR TC reboots?
From: eric@dol.net
Date: 1997-10-16 17:41:29

At 05:10 PM 10/16/97 -0600, you wrote: >Bob Purdon said once upon a time: > >>A few weeks ago I remember seeing someone comment that all of their TC >>racks on the one network segment rebooted within a short time of each >>other.. >> >>Ours have just done the same thing - over the course of an hour BOTH of >>our racks at one POP rebooted after 90 days of uptime. >> >>Any ideas anyone? > >I still don't know what caused it, but I blocked off my Netservers and NMC >cards at our borders with Cisco filters. There have been 488 matches >since, no idea if they're malicious or not. I wonder how the Netservers >would react to a "smurf" attack? what command would that be that would block off the cards at the ciscos. thanks Eric Delaware Online!.........The SMART Choice! With 56K X2 Modems Phone : 302-762-0375 Fax: 302-762-3462 WWW: www.dol.net Eight out of five people have a problem understanding statistics! ****************Customer support is our bottom line!*********************

Subject: Re: FW: (usr-tc) overheating usr-tc's
From: Andy <beezer@xmission.com>
Date: 1997-10-16 17:55:00

On Thu, 9 Oct 1997, Curt Shambeau wrote: > You can buy a US Robotics fan try alone. > USR Part# 000668-0 List Price: $ 516.00 - > Could probably get it for around $425 or so from a reseller of some sort. Cheaper option.. Mount a high volume squirl cage fan to a "lid" and set it on top of the rack cabinet. Not pretty, but highly functional.

Subject: Re: (usr-tc) net medic
From: Andy <beezer@xmission.com>
Date: 1997-10-16 18:07:37

On Thu, 9 Oct 1997, pris sears wrote: > There is a fair amount of grumbling from support about this and no one is > looking forward to more. We've been supporting USR user modems, but are > considering changing that next year because of it. Are others seeing > support issues cropping up from net medic use? We have not seen much of it yet, but did see alot of unwarrented messages generated from the 1.0 version (they later called a "beta"). I've been using it from home for the trial period, and it blames most problems on us - even though things are fine both locally and over the backbone. As tech support, I don't give a rats a$$ that you can supposedly change the program's sensativity. This back seat driving from USR and Net Medic wastes our time and loses customers. As far as I'm concerned, it's to be "unsupported" by ISPs and only discussed when Net Medic staff call back on their dime to explain these magic formulas on a conference call. :)

Subject: Re: (usr-tc) x2 capible
From: Andy <beezer@xmission.com>
Date: 1997-10-16 18:29:04

On Fri, 10 Oct 1997, Brian wrote: > Would be good, also the best and easiest thing to do, is to grab there ip > using the standard HTTP enviroment variable REMOTE_ADDR, take that, grep a > pmwho from whichever netserver is assigned that IP, and then you get the > port number.............. This would be a good approach, although potential customers may want the answer before they pay for net access or support. In this case, a shell script allows anonymous users to login as something like "x2test" to get a report.

Subject: Re: (usr-tc) TC Errors (fwd)
From: Bob Purdon <bobp@southcom.com.au>
Date: 1997-10-16 18:43:15

> Our Network Management card has suddenly popped a sold RED light on the > "hub-status" light (second down). I am not at the location, but I assume > this problem would involve some problem in ethernet wire running TO the > network management card right? I had a tech run a clean wire to it, and > its solid red (even though the unit is still fully accessible via TCM and > can be ping'd to the network management card). the NMC and the NETSERVER > card are on 2 phsical ethernet segements, and both are fully accessible > and have been for months. Check the fan in the back of the power supply. One of ours runs solid red and it's because the fan speed sensor is defective. It could be that your fan, or speed sensor, has failed. Regards, Bob Purdon, Southern Internet.

Subject: Re: (usr-tc) quad-modem idletime out
From: Andy <beezer@xmission.com>
Date: 1997-10-16 18:44:32

On Wed, 15 Oct 1997, Pete Ashdown wrote: > Maybe if USR built in some sort of intelligent monitor that looked for > repeated traffic over set periods of time. That is, if someone is hitting > the POP server every N minutes for X time, disconnect them. I'll bet a > brick against London that most spoofers don't use random waits in their > loop scripts. Stealth Ping @ http://www.mcs.net/~orvonton/ Works by randomizing pings between 15 and 100 seconds.

Subject: Re: (usr-tc) EdgeServer questions
From: David Bolen <db3l@ans.net>
Date: 1997-10-16 19:04:57

Richard Mazurowski <sysop@surfnetcorp.com> writes: > ANS also leases space in the 3Com building where Hey, you're not supposed to be able to peek at our installation bay :-) But for what it's worth, I don't think we "lease space" - just pay USR for rack construction according to our specifications. -- 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) USR TC reboots?
From: David Bolen <db3l@ans.net>
Date: 1997-10-16 19:09:13

Bob Purdon <bobp@southcom.com.au> writes: > Ours have just done the same thing - over the course of an hour BOTH of > our racks at one POP rebooted after 90 days of uptime. > > Any ideas anyone? Site power fluctuations? There used to be some types of network traffic - such as multicast in the earliest NMC code - that could cause components to reboot, although typically different behavior would affect the NMC versus the NETServer since they are based on different stacks. I haven't noticed anything like that recently, but I suppose it's a possibility. If you are using both NETServers and NMCs did they both reboot (and/or any other gear you may have info from at the site), or just one or the other. If both, something like power is more likely whereas if just one, perhaps something else. If it was just the NETServers you also get to bring issues into the picture like potentially a code bug triggered by an asychronous event like a routing update or something. If you have syslogging it might be interesting to see what was going on just prior to the event. -- 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) Investing in TCM
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-10-17 02:40:14

Problem solving and problem resoulution is not the topic which Mike is talking about. When you need some features like TCM for unix systems ( linux and other OS based ) if you can also follow up with request to your sales team, that would help us as a company to understand what the customer is looking for. Feedback from sales is very important for the company. I suggest that when you need features apart from letting us know here, do follow up with your sales people. Some times support may be slow but we shall surely take your input and make sure that our customers are happy. We like to know your problems with our support so that we work towards solving these issues. regards krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Fri, 17 Oct 1997, Pete Ashdown wrote: > Michael Wronski said once upon a time: > > >Please don't post your requests to me or this list. Send them to your sales > >rep or > >to customer service. > > I'd be glad to if it wasn't such a painful experience. For example, after > I caught the CSLIP bug in 3.5.93, someone on the list suggested that I call > support so it can be worked on. I did that, and I also mailed Krish about > it. This is a comparison: > > Support: Called in. Waited for 45 minutes for a technician. When I finally > got one, I told him there was a problem with SLIP in 3.5.93. They wanted > an account so they could dial into my server to verify this. > > I told them that I had already tried three different platforms, and that I > didn't have the problem prior to 3.5.93. They still wanted the account, I > obliged. > > Krish: I email him the problem. He emails me back stating that he was able > to replicate it and it is defininitely there in CSLIP. Shutting of VJ > compression is a workaround. > > Support: Calls me back two days later. "Are you having a problem with > Quake lag?" No, I only went to 3.5.93 to resolve that problem as I stated > in my original call. My problem is with SLIP. "We'll call you back." > > Support: Two weeks later, leaves a message on our voice mail. "Your > problem is being escalated." > > Support: One month later, they reach me in a phone call. "Sorry, we can't > replicate this problem in 3.5.34." IT ISN'T 3.5.34!! It was 3.5.93, as > stated in the original call. > > Support: Today. I receive a call from 3Com asking how my last support > issue was resolved. It still hasn't been resolved. So I proceed to pan > the support. > > > After this experience, I have a hard time imagining that Krish is working > for the same company. > > A suggestion to 3Com/USR: Setup an email box that people can submit > problems to. Go one step further and put a ticketing system on the box. >

Subject: (usr-tc) Investing in TCM
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1997-10-17 07:03:14

: >>Its part of TCM UNIX.. : >> : > : >But if you don't have HPUX or Solaris you won't be able to use it. Is : >there anyway to get a source code to this program? Mike from USR said: : No, sorry. This is not shareware or freeware. I would suggest ucdsnmp and : perl if you dont plan to invest in the TCM package.. I think you missed the point of his question; for my part, my firm has dumped piles of cash into service agreements, too, but we don't happen to use an OS to which the TCM has been ported. Is USR/3Com averse to porting it to other Unix variants? (at least one of the x86 Unices, please!) There are programming firms that'd handle the task, and it make many of us quite happy to be able to use this tool that you considered so fundamental to operation. --- Mark R. Lindsey, mark@datasys.net Network Engineer, DSS Online voice: +1 912 241 0607; Fax: +1 912 241 0190

Subject: Re: (usr-tc) EdgeServer questions
From: Tim Buchalka <tim@newave.net.au>
Date: 1997-10-17 07:49:04

They have a 2.5" 1GB HDD. Come by default with NT 4.0 and 64Mb Ram

Subject: Re: (usr-tc) Investing in TCM
From: Michael Wronski <mwronski@coredump.ae.usr.com>
Date: 1997-10-17 09:01:52

At 07:03 AM 10/17/97 -0400, you wrote: >: >>Its part of TCM UNIX.. >: >> >: > >: >But if you don't have HPUX or Solaris you won't be able to use it. Is >: >there anyway to get a source code to this program? > >Mike from USR said: >: No, sorry. This is not shareware or freeware. I would suggest ucdsnmp and >: perl if you dont plan to invest in the TCM package.. > >I think you missed the point of his question; for my part, my firm has >dumped piles of cash into service agreements, too, but we don't happen >to use an OS to which the TCM has been ported. Is USR/3Com averse to >porting it to other Unix variants? (at least one of the x86 Unices, >please!) There are programming firms that'd handle the task, and it make >many of us quite happy to be able to use this tool that you considered >so fundamental to operation. > This is not my area. Nor do I have a strong influence on what platforms are supported. Most of us in Network engineering have voiced our requests for other UNIX platform support and I believe that we are making headway in the Solaris x86 and linux arenas. It is also beneficial if the customers make requests to sales,marketing or even call our support number. The first tier support personnel are able to make formal feature requests on behalf of the customers.. A request doesn't mean implementation, but all feature requests are reviewed each release cycle. If there is enough customer request, things can get done.. Please don't post your requests to me or this list. Send them to your sales rep or to customer service. -Mike `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' Mike Wronski(mwronski@coredump.ae.usr.com) 3Com/U.S.Robotics Network Systems Engineer (Level 3) PGP: http://coredump.ae.usr.com/pgp

Subject: (usr-tc) USR TC reboots?
From: Bob Purdon <bobp@southcom.com.au>
Date: 1997-10-17 10:33:57

A few weeks ago I remember seeing someone comment that all of their TC racks on the one network segment rebooted within a short time of each other.. Ours have just done the same thing - over the course of an hour BOTH of our racks at one POP rebooted after 90 days of uptime. Any ideas anyone? Regards, Bob Purdon, Southern Internet.

Subject: Re: (usr-tc) Investing in TCM
From: pstern@polarnet.com
Date: 1997-10-17 12:16:30

At ISPCon I went to a USR sales session on the Edgeserver because I was interested in the BSDI support. I was amazed to find out USR doesn't even sell it but will make sales arrangements to put a package together of their hardware and BSDI's OS through a third party vendor. Okay well that was strange....I asked some questions about how the BSDI port worked on the Edgeserver. I was told they didn't know. I asked if you could manage the NMC from the BSDI OS and was told no but it was possibly being worked on. USR doesn't seem to understand there are alot of people who don't want to run Windows just to run TCM. I got alot of puzzled looks about that request. I have asked numerous USR sales people about the TCM for Solaris(Unix) no one has been able to answer what flavor it was for and or knew about sparc versus x86 issues. On the exhibition floor I tried to find someone who knew anything about the BSDI Edgeserver and was told to go visit BSDI. I did and they said talk to USR, "we don't know anything about it because all we did was port over the ethernet connection stuff." Sure makes a customer feel good about spending money on a product. Like other people in this list I have been sorely disappointed in the contract tech support quality. USR knows how to get your money but they don't know how to deliver decent tech support. They could learn something from Cisco on this point. I very much appreciate that you participate in this mailing list and are probably doing it on your own initiative. I wish some decision level people would do the same. Incidentally BSDI reported back to me that the Portmux problem is in USR's code, not handling telnet sessions properly. Based on my experience with Livingston and Cisco equipment working perfectly I am inclined to agree with their assessment. peter peter stern pstern@polarnet.com System Administration

Subject: Re: (usr-tc) Investing in TCM
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-17 12:40:21

Michael Wronski said once upon a time: >Please don't post your requests to me or this list. Send them to your sales >rep or >to customer service. I'd be glad to if it wasn't such a painful experience. For example, after I caught the CSLIP bug in 3.5.93, someone on the list suggested that I call support so it can be worked on. I did that, and I also mailed Krish about it. This is a comparison: Support: Called in. Waited for 45 minutes for a technician. When I finally got one, I told him there was a problem with SLIP in 3.5.93. They wanted an account so they could dial into my server to verify this. I told them that I had already tried three different platforms, and that I didn't have the problem prior to 3.5.93. They still wanted the account, I obliged. Krish: I email him the problem. He emails me back stating that he was able to replicate it and it is defininitely there in CSLIP. Shutting of VJ compression is a workaround. Support: Calls me back two days later. "Are you having a problem with Quake lag?" No, I only went to 3.5.93 to resolve that problem as I stated in my original call. My problem is with SLIP. "We'll call you back." Support: Two weeks later, leaves a message on our voice mail. "Your problem is being escalated." Support: One month later, they reach me in a phone call. "Sorry, we can't replicate this problem in 3.5.34." IT ISN'T 3.5.34!! It was 3.5.93, as stated in the original call. Support: Today. I receive a call from 3Com asking how my last support issue was resolved. It still hasn't been resolved. So I proceed to pan the support. After this experience, I have a hard time imagining that Krish is working for the same company. A suggestion to 3Com/USR: Setup an email box that people can submit problems to. Go one step further and put a ticketing system on the box.

Subject: Re: (usr-tc) Investing in TCM
From: MegaZone <megazone@livingston.com>
Date: 1997-10-17 14:47:31

Once upon a time David Bolen shaped the electrons to say... >so if a customer wants to do so they can install it. In such a case, >however, you're effectively buying a USR 486 PC, and then installing >BSDI on it, so USR might not address BSD/OS specific OS questions. So, the question that begs to be asked - Anyone running Linux on an Edgeserver? -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588

Subject: Re: (usr-tc) Investing in TCM
From: Brian <signal@shreve.net>
Date: 1997-10-17 16:16:41

On Fri, 17 Oct 1997, Pete Ashdown wrote: > Michael Wronski said once upon a time: > > >Please don't post your requests to me or this list. Send them to your sales > >rep or > >to customer service. > > I'd be glad to if it wasn't such a painful experience. For example, after > I caught the CSLIP bug in 3.5.93, someone on the list suggested that I call > support so it can be worked on. I did that, and I also mailed Krish about > it. This is a comparison: > > Support: Called in. Waited for 45 minutes for a technician. When I finally > got one, I told him there was a problem with SLIP in 3.5.93. They wanted > an account so they could dial into my server to verify this. > > I told them that I had already tried three different platforms, and that I > didn't have the problem prior to 3.5.93. They still wanted the account, I > obliged. > > Krish: I email him the problem. He emails me back stating that he was able > to replicate it and it is defininitely there in CSLIP. Shutting of VJ > compression is a workaround. > > Support: Calls me back two days later. "Are you having a problem with > Quake lag?" No, I only went to 3.5.93 to resolve that problem as I stated > in my original call. My problem is with SLIP. "We'll call you back." <much deleted> When I call support, they will ask to look at our hubs via TCM. Then via TCM if all looks normal they seem to be at a dead end. They don't use debug level output, logfiles, tap's or anything else to try and diagnose the problem. Some are reluctant to escalate when they should, I wish there was a test we could take, so that we could "skip" level one. On the other hand I find level 2 quite on the ball, as they should be. Most experienced USR hub admins know more than USR level 1. Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: Re: (usr-tc) USR TC FAQ
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-17 16:52:51

Brian said once upon a time: > > >I think there needs to be a USR TC faq, there are so many common mistakes >and posts about things to this list. Good idea Brian. A lot of information could be culminated from past archives as well. Are you volunteering? ;-)

Subject: Re: (usr-tc) Investing in TCM
From: Brian <signal@shreve.net>
Date: 1997-10-17 16:55:58

On Fri, 17 Oct 1997, David Bolen wrote: > Brian <signal@shreve.net> writes: > > > On the other hand I find level 2 quite on the ball, as they should be. > > Most experienced USR hub admins know more than USR level 1. > > Does USR still offer that deal that if you go pass a test or take a > course or something you can certify yourself to automatically pass > level 1 to level 2? If so, might be useful for the more experienced > admin folks here. > > -- David Does anyone know about this, from USR or otherwise? I am interested, and I am sure others are interested. Please send info to the list on this. Brian > > /-----------------------------------------------------------------------\ > \ David Bolen \ Internet: db3l@ans.net / > | ANS Communications, Inc. \ Phone: (914) 701-5327 | > / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ > \-----------------------------------------------------------------------/ > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: (usr-tc) USR TC FAQ
From: Brian <signal@shreve.net>
Date: 1997-10-17 17:12:49

I think there needs to be a USR TC faq, there are so many common mistakes and posts about things to this list. For example, we could summarize some common problems that were in each netserver revision. Another cool thing, would be to list all the undocumented commands, info about the "secret menu" in the PRI card, info on how to get out of RTSCOPE when you accidently hit the wrong key and get thrown into it, etc etc etc Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: Re: (usr-tc) Investing in TCM
From: David Bolen <db3l@ans.net>
Date: 1997-10-17 17:40:41

<pstern@polarnet.com> (Note that any info in this note is my own and shouldn't be construed to be anything other than that - I don't know any official positions of 3Com or BSDI on this stuff..) > At ISPCon I went to a USR sales session on the Edgeserver because I was > interested in the BSDI support. I was amazed to find out USR doesn't even > sell it but will make sales arrangements to put a package together of > their hardware and BSDI's OS through a third party vendor. Okay well that > was strange....I asked some questions about how the BSDI port worked on > the Edgeserver. I was told they didn't know. For the most part it's a standard BSD/OS installation. There's very little that requires changing to work on an EdgeServer, although it does involve some kernel tweaks. Those changes involve activation of the ethernet and serial console ports on the NIC, and twiggling of the on-card LEDs for the appropriate types of operations. That's about it. In my case I also tweaked some of the console stuff to make BSDI a little more tolerant of booting without a keyboard and always treating the serial port as the console (since all our boxes are remote). We're still running BSD/OS 2.1, but I presume BSDI moved the changes forward into the 3.0 base. > I asked if you could manage the NMC from the BSDI OS and was told no but > it was possibly being worked on. USR doesn't seem to understand there are > alot of people who don't want to run Windows just to run TCM. I got alot > of puzzled looks about that request. I have asked numerous USR sales > people about the TCM for Solaris(Unix) no one has been able to answer what > flavor it was for and or knew about sparc versus x86 issues. If you're talking about using the BSDI EdgeServer to perform SNMP management operations to an NMC, the answer should be yes in general, since you just generate SNMP stuff over the ethernet to the NMC. It wouldn't happen internal to the chassis or anything. However, that would be direct SNMP support - as has come up recently on the list I don't think TCM is supported on that varied a set of Unix platforms yet. > On the exhibition floor I tried to find someone who knew anything about > the BSDI Edgeserver and was told to go visit BSDI. I did and they said > talk to USR, "we don't know anything about it because all we did was port > over the ethernet connection stuff." Sure makes a customer feel good about > spending money on a product. Yeah, I don't quite know how that all works. I know that BSDI and USR basically came to an agreement to interoperate together on the EdgeServer, but I guess it turns out to be more of a "I know my [platform|os] will work [with|on] your [os|platform]". Think of it this way... From BSDI's viewpoint, it's just like asking will BSD/OS run on my Dell PC, or will it support this ethernet card. If BSD/OS has the right driver, or they've tested it on the platform, the answer will be yes, but actually installing and running it is going to be up to you. From USR's viewpoint, they've essentially built a 486-PC in a form factor for a chassis. They have a preferred, locally sold/maintained platform (WinNT), but have validated that BSD/OS will operate on it, so if a customer wants to do so they can install it. In such a case, however, you're effectively buying a USR 486 PC, and then installing BSDI on it, so USR might not address BSD/OS specific OS questions. -- 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) Investing in TCM
From: David Bolen <db3l@ans.net>
Date: 1997-10-17 17:46:15

Brian <signal@shreve.net> writes: > On the other hand I find level 2 quite on the ball, as they should be. > Most experienced USR hub admins know more than USR level 1. Does USR still offer that deal that if you go pass a test or take a course or something you can certify yourself to automatically pass level 1 to level 2? If so, might be useful for the more experienced admin folks here. -- 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) Investing in TCM
From: David Bolen <db3l@ans.net>
Date: 1997-10-17 17:59:33

MegaZone <megazone@livingston.com> writes: > So, the question that begs to be asked - > > Anyone running Linux on an Edgeserver? I expect someone just has to get 3Com to externally publish the few instructions necessary to activate the IRQ/DMA stuff on the ethernet NIC. Without that while I expect Linux should install just fine, you won't have access to the ethernet or interrupt driven serial I/O to the serial console port. I'm not sure if this would be a problem or not - I can't see why especially, but then I'm a source code release kind of guy... -- 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) USR TC FAQ
From: Brian <signal@shreve.net>
Date: 1997-10-17 18:17:39

On Fri, 17 Oct 1997, Pete Ashdown wrote: > Brian said once upon a time: > > > > > >I think there needs to be a USR TC faq, there are so many common mistakes > >and posts about things to this list. > > Good idea Brian. A lot of information could be culminated from past > archives as well. Are you volunteering? ;-) > Well, I don't really have very good technical writing skills ;-).......but I volunteer all the information I know. I understand that TOO much information in the wrong hands could mean trouble for alot of peoples setups. But I also beleive that all information should be available for those willing to risk the use of the information. I have used the undocumented screen in the PRI card many times, I've gotten thrown into Rtscope too many times to count (on accident!), used commands like "sh mem -v" on the netserver to see problems I may have been having etc............ so who's up to compiling the information, heh, the USR TC "unauthorized" :)))))) Also, it would be cool to have an ftp site with all the cool perl/snmp scripts people have been hacking up lately. Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: Re: (usr-tc) USR TC reboots?
From: Bob Purdon <bobp@southcom.com.au>
Date: 1997-10-17 22:02:06

> > Ours have just done the same thing - over the course of an hour BOTH of > > our racks at one POP rebooted after 90 days of uptime. > > Site power fluctuations? That was my initial thought also. Further investigation shows both racks keeling over at the same time, although other non-UPS protected equipment was fine (but I'm sure routers will ride-out fluctuations much better than a fully loaded TC rack). Then, nearly an hour later, *one* of the racks was knocked out again. A day ago we experienced the ethernet lockup problem on one rack - a problem we've not experienced previously. > If you are using both NETServers and NMCs did they both reboot (and/or Yes, both the NETServer and NMC rebooted. > other. If both, something like power is more likely whereas if just > one, perhaps something else. It's looking more and more like power. > If you have syslogging it might be interesting to see what was going > on just prior to the event. We are syslogging, and there was nothing of any significance prior to the event. I've got router filters logging all packets to the NETservers, just in case anything untoward is going on, which was my initial suspicion... Regards, Bob Purdon, Southern Internet.

Subject: (usr-tc) mpip w/I-Modems
From: Brian <signal@shreve.net>
Date: 1997-10-17 23:33:51

Is there any known problems with MPIP and the new Imodem code for USR TC hubs? I set hub 2 and 3 for ISDN via modem (ISDN-GW slot = 0) I left hub 1 to the Munich card. hub 1 is the MPIP server btw. call comes in, hub 1 grabs a channel, hub 2 or 3 will grab the next, and all is well. I set hub 1 to be isdn gw =0 as well then when I dial in I get: Jul 18 23:28:36 ns pppd[290]: Serial connection established. Jul 18 23:28:36 ns chat[292]: CO -- got it Jul 18 23:28:37 ns pppd[290]: Using interface ppp0 Jul 18 23:28:37 ns pppd[290]: Connect: ppp0 <--> /dev/cup56 Jul 18 23:28:47 ns pppd[290]: Remote message: Login Succeeded Jul 18 23:28:50 ns pppd[290]: local IP address 208.214.45.1 Jul 18 23:28:50 ns pppd[290]: remote IP address 208.214.44.53 Jul 18 23:28:56 ns pppd[290]: local IP address 208.214.45.1 Jul 18 23:28:56 ns pppd[290]: remote IP address 208.214.44.53 Jul 18 23:29:03 ns pppd[290]: local IP address 208.214.45.1 Jul 18 23:29:03 ns pppd[290]: remote IP address 208.214.44.53 Jul 18 23:29:09 ns pppd[290]: local IP address 208.214.45.1 Jul 18 23:29:09 ns pppd[290]: remote IP address 208.214.44.53 Jul 18 23:29:15 ns pppd[290]: local IP address 208.214.45.1 Jul 18 23:29:15 ns pppd[290]: remote IP address 208.214.44.53 . . . it keeps sending me the IP info. finally i just logged in and changed it back to 16 for the isdn gw Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: Re: (usr-tc) Modems go inactive
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-10-18 01:07:10

On Mon, 18 Aug 1997, Tim Brown wrote: > I have a TC Hub with 12 digital quad modems and a dual T1 card. > Periodically (recently more frequently) all of the modems go into an > inactive status. To fix the problem I telnet to the Netserver and > set modem s5-s52 active > save all > reset all The first thing you need to do is to set the modem to default. This can be done by using TCM, select all the modems and go to action commands and set them all to default. Save to NVRAM and then reset the modems. Now again select the modems and set modem with hardware templete and save it NVRAM. Now go to the NETServer and reset all the modems. By doing this you are setting the modems to default setup which is necessary for the modems to stay on the packet bus. This setting once saved will remain and your modems will never drop off the NETSever. > The box doesn't lock up as the T1's are still up (calls come in, just no > answer from the modems) and I can still ping and telnet to the box. It's a > pain because when it happens, users get disconnected, but no "stop" is sent > to the Radius Accounting server. > Anyone have a solution for this? > Thanks, Tim. > Check the NETServer to see what is the accouting server set to, see if the NETServer is sending you accoutning packets. If you are receiving start and not stop them there is a problem with your radius or the NETServer which can be identified by looking at your global setting on the NETServer and the show netconns screen. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec

Subject: Re: (usr-tc) Modems go inactive
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-10-18 10:39:09

This is in the TCM Select all the modems and go to actions commands, one of the option is hardware templete That is what I am talking about. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Mon, 18 Aug 1997, Tim Brown wrote: > > The first thing you need to do is to set the modem to default. This can > > be done by using TCM, select all the modems and go to action commands and > > > set them all to default. Save to NVRAM and then reset the modems. Now > > again select the modems and set modem with hardware templete and save it > > NVRAM. Now go to the NETServer and reset all the modems. > > Thanks for your response. I understood everything you said except "set > modem with hardware templete". What is a "hardware templete"? > Tim > >

Subject: Re: (usr-tc) USR TC FAQ
From: Bob Purdon <bobp@southcom.com.au>
Date: 1997-10-18 10:59:10

> so who's up to compiling the information, heh, the USR TC "unauthorized" > :)))))) I'll volunteer. I don't profess to be a Dave Bolen when it comes to the USR TC gear, but I'm sure I can manage to look after a FAQ. > Also, it would be cool to have an ftp site with all the cool perl/snmp > scripts people have been hacking up lately. I can volunteer space for that also if required. Regards, Bob Purdon, Southern Internet.

Subject: Re: (usr-tc) USR TC FAQ
From: Allen Marsalis <am@shreve.net>
Date: 1997-10-18 12:32:43

Brian just wrote: >On Fri, 17 Oct 1997, Pete Ashdown wrote: > >> Brian said once upon a time: >> > >> > >> >I think there needs to be a USR TC faq, there are so many common mistakes >> >and posts about things to this list. >> >> Good idea Brian. A lot of information could be culminated from past >> archives as well. Are you volunteering? ;-) >> > >Well, I don't really have very good technical writing skills ;-).......but >I volunteer all the information I know. > Well.. Uh.. I made an "A" in "technical writing" brian.. Since we work in the same office, it should be easy to coordinate.. If you'll volunteer the info, I'll organize it so novices (like me) can understand it. And that's usually the target audience faqs are directed toward.. We could probably spare alittle bandwidth also if you want to set up an ftp site.. Since USR will probably port TCM to the PalmPilot before linux ;) I really want to help support TC users anyway I can.. Especially linux folks.. Allen _________________________________________________________________ Allen Marsalis President, Shrevenet, Inc. Thoughtful Provider of Internet Services 333 Texas St. Suite 619 Shreveport, LA 71101 Ph. 318.222.2NET (2638) FAX: 318.221.6612 mailto:am@shreve.net http://www.shreve.net

Subject: (usr-tc) tcenema script
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-18 15:09:34

I've been using the TCM shell commands more and more, simply because I can script them. The following script is useful for rebooting your Netservers because it cleans out your channels at the same time. I've had experience where power fluctuations, phases of the moon, and staring at racks in the wrong way, can cause channels to "stick" or go into tone mode. The following script fixes these. You could axe the reset of the Netserver if you wanted to just flush the channels. #!/bin/csh # TCenema - Will reset a netserver and clean out any "stuck" channels # Usage: tcenema rackname snmp-read snmp-write setenv TCMDIR "/usr/local/lib/tcm" set rack=$1 set read=$2 set write=$3 # Busy out the spans $TCMDIR/bin/tcmcmd -E "local out of service" -G "commands" -C $write -c $read ${rack}-snmp:s1c1 $TCMDIR/bin/tcmcmd -E "local out of service" -G "commands" -C $write -c $read ${rack}-snmp:s1c2 # Reset the Netserver $TCMDIR/bin/tcmcmd -E "hardware reset" -G "commands" -c $read -C $write ${rack}-snmp:s16 # Clean the channels by disconnecting all of them $TCMDIR/bin/tcmcmd -E "disconnect" -G "commands" -C $write -c $read ${rack}-snmp:s1c1t1-23 $TCMDIR/bin/tcmcmd -E "disconnect" -G "commands" -C $write -c $read ${rack}-snmp:s1c2t1-23 # Wait for the Netserver to come alive sleep 60 # Unbusy all the channels and each span $TCMDIR/bin/tcmcmd -E "in service" -G "commands" -C $write -c $read ${rack}-snmp:s1c1t1-23 $TCMDIR/bin/tcmcmd -E "in service" -G "commands" -C $write -c $read ${rack}-snmp:s1c2t1-23 $TCMDIR/bin/tcmcmd -E "in service" -G "commands" -C $write -c $read ${rack}-snmp:s1c1 $TCMDIR/bin/tcmcmd -E "in service" -G "commands" -C $write -c $read ${rack}-snmp:s1c2

Subject: Re: (usr-tc) Modems go inactive
From: Brian <signal@shreve.net>
Date: 1997-10-18 17:24:12

Subject: Re: (usr-tc) Modems go inactive
From: Brian <signal@shreve.net>
Date: 1997-10-18 17:26:00

On Sat, 18 Oct 1997, Tatai SV Krishnan wrote: > On Mon, 18 Aug 1997, Tim Brown wrote: > > > I have a TC Hub with 12 digital quad modems and a dual T1 card. > > Periodically (recently more frequently) all of the modems go into an > > inactive status. To fix the problem I telnet to the Netserver and > > set modem s5-s52 active > > save all > > reset all > The first thing you need to do is to set the modem to default. This can > be done by using TCM, select all the modems and go to action commands and > set them all to default. Save to NVRAM and then reset the modems. Now > again select the modems and set modem with hardware templete and save it > NVRAM. Now go to the NETServer and reset all the modems. > > By doing this you are setting the modems to default setup which is > necessary for the modems to stay on the packet bus. This setting once > saved will remain and your modems will never drop off the NETSever. > What are the differences between "set to default" and "set to hardware default"? I normally just set to default, make sure they are on packet bus, packet bus answer only, priTdm, and then save. > > krish > > ----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ > tkrishna@bubba.ae.usr.com > ----------------------------/ http://interproc.ae.usr.com ----/ > -------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec > -------------------------------------------------------------------------/ > > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: (usr-tc) Problem, anyone have this experience?
From: Scott Portmaster List <scottport@mail.rpa.net>
Date: 1997-10-18 22:09:17

Hi all; i was wondering if anyone else has experience this problem that are currently having, which started fri, and has not stopped. The NETserver card seems to every so often to stop sending and receiving any kind of traffic, (ping,tcp,etc). The only fix is to reset the nic card, and reset the modems (well, it could be done from tcm, but i am at home :)). Anyway this afternoon i was in the card and noticed that the reported address to the modems was at 0.0.0.0 . I did not set the card up, and the person who did didn't take notes, so what i did was reset it back to what i thought it was supposed to be (note, this machine worked fine for several months) this was 5 hours ago, so far no problems..... has this happened to anyone else, and if so, how did you fix it? I am displeased with the level of tech support. I did not mind being on hold for over an hour (90 mins) until i got a human, but he was not really helpfull (I had to point things out to him -- i knew more than him, and i have not worked with the hardware much). Sigh you pay good money for a product that is SO FUN to work with.... Thanks for the time... Scott

Subject: Re: (usr-tc) Problem, anyone have this experience?
From: Brian <signal@shreve.net>
Date: 1997-10-18 22:56:29

On Sat, 18 Oct 1997, Scott Portmaster List wrote: > > Hi all; > i was wondering if anyone else has experience this problem that > are currently having, which started fri, and has not stopped. The > NETserver card seems to every so often to stop sending and receiving any > kind of traffic, (ping,tcp,etc). The only fix is to reset the nic card, > and reset the modems (well, it could be done from tcm, but i am at home > :)). Anyway this afternoon i was in the card and noticed that the reported > address to the modems was at 0.0.0.0 . I did not set the card up, and the > person who did didn't take notes, so what i did was reset it back to what > i thought it was supposed to be (note, this machine worked fine for > several months) this was 5 hours ago, so far no problems..... > > has this happened to anyone else, and if so, how did you fix it? > > I am displeased with the level of tech support. I did not mind being on > hold for over an hour (90 mins) until i got a human, but he was not > really helpfull (I had to point things out to him -- i knew more than > him, and i have not worked with the hardware much). Sigh you pay good > money for a product that is SO FUN to work with.... The NIC lockup problem on some netserver cards is a known problem. This, as far as I am concerned, is a hardware problem and not software. There is a possibility from what I have seen, that this problem revolves around the netservers that have the FC3 chip on them. We had this problem, with one of our hubs, we sent the card into USR and it was fixed. USR does actually have excellent tech support, actually some of the best I have seen. It is the "front line" that gives you the impression you get. They can probably answer alot of the calls, simple things, and it gives them a chance to learn. Brian > > > Thanks for the time... > > Scott > > > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: [blh@texas.net: (usr-tc) interesting problem]
From: Brett Hawn <blh@texas.net>
Date: 1997-10-19 09:01:19

Since this was pretty much ignored last time I'm resending it, has anyone else seen anything like this? Does anyone have a workaround until USR fixes it? Our Radius logs pretty much everything these days for our own use and one thing we've noticed. When we manually kick users off the tc rack (instead of them disconnecting, etc) the Account-Session-Time is being set to 0 ie. This is an obvious bug Wed Oct 15 04:06:10 1997 Acct-Session-Id = 00002C3B User-Name = <USERNAME> NAS-IP-Address = 206.127.27.65 NAS-Port = 31 Acct-Status-Type = Start Acct-Authentic = RADIUS Called-Station-Id = 4850133 Vendor-Specific = Vendor-Specific = Vendor-Specific = Vendor-Specific = Vendor-Specific = Vendor-Specific = Vendor-Specific = Vendor-Specific = NAS-Identifier = tc01.austin NAS-Port-Type = Async Service-Type = Framed Framed-Protocol = PPP Framed-IP-Address = 209.99.40.37 Acct-Delay-Time = 0 Wed Oct 15 09:09:21 1997 Acct-Session-Id = 00002C3B User-Name = <USERNAME> NAS-IP-Address = 206.127.27.65 NAS-Port = 31 Acct-Status-Type = Stop Acct-Session-Time = 0 Acct-Terminate-Cause = Admin-Reset Acct-Authentic = RADIUS Called-Station-Id = 4850133 Vendor-Specific = Vendor-Specific = Vendor-Specific = Vendor-Specific = Vendor-Specific = Vendor-Specific = Vendor-Specific = Vendor-Specific = NAS-Identifier = tc01.austin Acct-Input-Octets = 386287 Acct-Output-Octets = 15300756 Acct-Input-Packets = 16702 Acct-Output-Packets = 21899 NAS-Port-Type = Async Service-Type = Framed Framed-Protocol = PPP Framed-IP-Address = 209.99.40.37 Acct-Delay-Time = 0 -- A lack of forethought and planning on your part tends to constitute a lack of cash on my part. -----End of forwarded message----- --

Subject: (usr-tc) (usr-tc] FS : TC 48 Port PRI system
From: HIA <hiatmp@hia.net>
Date: 1997-10-19 12:12:49

Hello. We want to sell a new and never installed TC syetem for $13,500. TC 48 Port PRI system (SKU # 001706-0) NMC software TC sercurity software X2 upgrade and Special custom security software for ISP. For more information, please visit www.3com.com/solutions/svprovider/tradein.html Please email to hiatmp@hia.net for more information. Thanks. Kang Houston Internet Access.

Subject: Re: [blh@texas.net: (usr-tc) interesting problem]
From: Michael Wronski <mwronski@coredump.ae.usr.com>
Date: 1997-10-20 08:54:51

Are you reseting S-ports or sending SNMP to put modems on-hook to "Manually" kick users? -M At 09:01 AM 10/19/97 -0500, you wrote: >Since this was pretty much ignored last time I'm resending it, has anyone >else seen anything like this? Does anyone have a workaround until USR fixes >it? > > >Our Radius logs pretty much everything these days for our own use and one >thing we've noticed. When we manually kick users off the tc rack (instead of >them disconnecting, etc) the Account-Session-Time is being set to 0 >ie. > >This is an obvious bug > > >Wed Oct 15 04:06:10 1997 > Acct-Session-Id = 00002C3B > User-Name = <USERNAME> > NAS-IP-Address = 206.127.27.65 > NAS-Port = 31 > Acct-Status-Type = Start > Acct-Authentic = RADIUS > Called-Station-Id = 4850133 > Vendor-Specific = > Vendor-Specific = > Vendor-Specific = > Vendor-Specific = > Vendor-Specific = > Vendor-Specific = > Vendor-Specific = > Vendor-Specific = > NAS-Identifier = tc01.austin > NAS-Port-Type = Async > Service-Type = Framed > Framed-Protocol = PPP > Framed-IP-Address = 209.99.40.37 > Acct-Delay-Time = 0 > > >Wed Oct 15 09:09:21 1997 > Acct-Session-Id = 00002C3B > User-Name = <USERNAME> > NAS-IP-Address = 206.127.27.65 > NAS-Port = 31 > Acct-Status-Type = Stop > Acct-Session-Time = 0 > Acct-Terminate-Cause = Admin-Reset > Acct-Authentic = RADIUS > Called-Station-Id = 4850133 > Vendor-Specific = > Vendor-Specific = > Vendor-Specific = > Vendor-Specific = > Vendor-Specific = > Vendor-Specific = > Vendor-Specific = > Vendor-Specific = > NAS-Identifier = tc01.austin > Acct-Input-Octets = 386287 > Acct-Output-Octets = 15300756 > Acct-Input-Packets = 16702 > Acct-Output-Packets = 21899 > NAS-Port-Type = Async > Service-Type = Framed > Framed-Protocol = PPP > Framed-IP-Address = 209.99.40.37 > Acct-Delay-Time = 0 > >-- >A lack of forethought and planning on your part tends to constitute a lack >of cash on my part. > >-----End of forwarded message----- > >-- >

Subject: Re: (usr-tc) Investing in TCM
From: Michael Wronski <mwronski@coredump.ae.usr.com>
Date: 1997-10-20 08:57:07

At 01:32 PM 10/17/97 -0500, you wrote: >how do we go about shoving the damn bug we've bitched about 15 *&^%$ing >times up someone's ass so they finally fix it? This has what to do with port of TCM or snmp? -M >On Fri, Oct 17, 1997 at 09:01:52AM -0500, Michael Wronski made some electrons appear in the following form: >> At 07:03 AM 10/17/97 -0400, you wrote: >> >: >>Its part of TCM UNIX.. >> >: >> >> >: > >> >: >But if you don't have HPUX or Solaris you won't be able to use it. Is >> >: >there anyway to get a source code to this program? >> > >> >Mike from USR said: >> >: No, sorry. This is not shareware or freeware. I would suggest ucdsnmp and >> >: perl if you dont plan to invest in the TCM package.. >> > >> >I think you missed the point of his question; for my part, my firm has >> >dumped piles of cash into service agreements, too, but we don't happen >> >to use an OS to which the TCM has been ported. Is USR/3Com averse to >> >porting it to other Unix variants? (at least one of the x86 Unices, >> >please!) There are programming firms that'd handle the task, and it make >> >many of us quite happy to be able to use this tool that you considered >> >so fundamental to operation. >> > >> >> This is not my area. Nor do I have a strong influence on what platforms are >> supported. >> Most of us in Network engineering have voiced our requests for other UNIX >> platform >> support and I believe that we are making headway in the Solaris x86 and >> linux arenas. >> It is also beneficial if the customers make requests to sales,marketing or >> even call our support number. The first tier support personnel are able to >> make formal feature requests on behalf of the customers.. A request doesn't >> mean implementation, but all feature requests >> are reviewed each release cycle. If there is enough customer request, >> things can get >> done.. >> >> Please don't post your requests to me or this list. Send them to your sales >> rep or >> to customer service. >> >> -Mike >> >> >> >> >> >> `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' >> Mike Wronski(mwronski@coredump.ae.usr.com) 3Com/U.S.Robotics >> Network Systems Engineer (Level 3) >> PGP: http://coredump.ae.usr.com/pgp >> >> >> >> > >-- >and the Number 1 Sign You've Hired the Wrong Clown for Your Child's Party... > > All the balloon animals are ribbed and lubricated. > `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' Mike Wronski(mwronski@coredump.ae.usr.com) 3Com/U.S.Robotics Network Systems Engineer (Level 3) PGP: http://coredump.ae.usr.com/pgp

Subject: Re: (usr-tc) tcenema script
From: Michael Wronski <mwronski@coredump.ae.usr.com>
Date: 1997-10-20 10:25:52

At 11:05 AM 10/20/97 -0400, you wrote: >Pete, >Looks like a very useful script. How do you get those commands? Do you >have to run Unix TCM to use them? And do you or anybody else know if Unix >TCM runs on a Solaris x86 or does it have to be on a Sparc? >thanx, You must have TCM unix and it is only for sparc at this time.. See previous thread about UNIX ports of TCM and sec & accting.. But all of this is possible with a little more coding and UCD SNMP which is compilable on most UNIX platforms. -M `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' Mike Wronski(mwronski@coredump.ae.usr.com) 3Com/U.S.Robotics Network Systems Engineer (Level 3) PGP: http://coredump.ae.usr.com/pgp

Subject: Re: (usr-tc) tcenema script
From: Randy Doran <rtdoran@gate.net>
Date: 1997-10-20 11:05:55

Pete, Looks like a very useful script. How do you get those commands? Do you have to run Unix TCM to use them? And do you or anybody else know if Unix TCM runs on a Solaris x86 or does it have to be on a Sparc? thanx, Randy Doran CyberGate Network Operations On Sat, 18 Oct 1997, Pete Ashdown wrote: > I've been using the TCM shell commands more and more, simply because I can > script them. The following script is useful for rebooting your Netservers > because it cleans out your channels at the same time. I've had experience > where power fluctuations, phases of the moon, and staring at racks in the > wrong way, can cause channels to "stick" or go into tone mode. The > following script fixes these. You could axe the reset of the Netserver if > you wanted to just flush the channels.

Subject: Re: [blh@texas.net: (usr-tc) interesting problem]
From: Brett Hawn <blh@texas.net>
Date: 1997-10-20 11:48:04

Michael and I have discussed this in private email but for contitnuity I'll mention it on the list as well. I've a script that telnets to the TC rack and resets the S-port #. I've yet to screw with the mib and find the 'hangup' oid On Mon, Oct 20, 1997 at 08:54:51AM -0500, Michael Wronski made some electrons appear in the following form: > Are you reseting S-ports or sending SNMP to put modems on-hook to > "Manually" kick > users? > > -M > > At 09:01 AM 10/19/97 -0500, you wrote: > >Since this was pretty much ignored last time I'm resending it, has anyone > >else seen anything like this? Does anyone have a workaround until USR fixes > >it? > > > > > >Our Radius logs pretty much everything these days for our own use and one > >thing we've noticed. When we manually kick users off the tc rack (instead of > >them disconnecting, etc) the Account-Session-Time is being set to 0 > >ie. > > > >This is an obvious bug > > > > > >Wed Oct 15 04:06:10 1997 > > Acct-Session-Id = 00002C3B > > User-Name = <USERNAME> > > NAS-IP-Address = 206.127.27.65 > > NAS-Port = 31 > > Acct-Status-Type = Start > > Acct-Authentic = RADIUS > > Called-Station-Id = 4850133 > > Vendor-Specific = > > Vendor-Specific = > > Vendor-Specific = > > Vendor-Specific = > > Vendor-Specific = > > Vendor-Specific = > > Vendor-Specific = > > Vendor-Specific = > > NAS-Identifier = tc01.austin > > NAS-Port-Type = Async > > Service-Type = Framed > > Framed-Protocol = PPP > > Framed-IP-Address = 209.99.40.37 > > Acct-Delay-Time = 0 > > > > > >Wed Oct 15 09:09:21 1997 > > Acct-Session-Id = 00002C3B > > User-Name = <USERNAME> > > NAS-IP-Address = 206.127.27.65 > > NAS-Port = 31 > > Acct-Status-Type = Stop > > Acct-Session-Time = 0 > > Acct-Terminate-Cause = Admin-Reset > > Acct-Authentic = RADIUS > > Called-Station-Id = 4850133 > > Vendor-Specific = > > Vendor-Specific = > > Vendor-Specific = > > Vendor-Specific = > > Vendor-Specific = > > Vendor-Specific = > > Vendor-Specific = > > Vendor-Specific = > > NAS-Identifier = tc01.austin > > Acct-Input-Octets = 386287 > > Acct-Output-Octets = 15300756 > > Acct-Input-Packets = 16702 > > Acct-Output-Packets = 21899 > > NAS-Port-Type = Async > > Service-Type = Framed > > Framed-Protocol = PPP > > Framed-IP-Address = 209.99.40.37 > > Acct-Delay-Time = 0 > > > >-- > >A lack of forethought and planning on your part tends to constitute a lack > >of cash on my part. > > > >-----End of forwarded message----- > > > >-- > > -- My personal mission statement is "I live up to the wild and vague promises made by salesmen."

Subject: Re: [blh@texas.net: (usr-tc) interesting problem]
From: Michael Wronski <mwronski@coredump.ae.usr.com>
Date: 1997-10-20 12:24:57

At 11:48 AM 10/20/97 -0500, you wrote: >Michael and I have discussed this in private email but for contitnuity I'll >mention it on the list as well. I've a script that telnets to the TC rack >and resets the S-port #. I've yet to screw with the mib and find the >'hangup' oid > This doesn't solve your acccounting problem, but it is the snmp method of sending modem commands. (Use on hook to hankg up a call) OID's

Subject: (usr-tc) PRI Problems
From: Greg Gibson <gg@pressroom.com>
Date: 1997-10-20 13:48:12

We have recently begun to have a problem in which our PRIs will sporadiacally ring busy even though there is plenty of modem capacity available. They will also, on occassion, ring with no answer even though the equipment appears to be working fine. PRIs shouldn't even ring at all. We are using a combination of USR Total Control Hubs and Livingston PM3s. We have different phone numbers pointing to the USRs and the PM3s. We see this problem on both sets of equipment, although the problem is a bit more prevelent on the USRs than on the PM3s. However, since we see this problem on both sets of equipment and throughout all of our spans we are inclined to believe this is a telco problem rather than a hardware problem. We've had a telco tech out to test our circuits and he found nothing. The phone company is also testing the switch at the CO but so far nothing has been found. One suspicious issue is that we started having this problem after our last two PRIs were installed about a month ago and have never seen this on any of the spans until recently. Has anyone out there experienced this kind of problem before or can anyone offer suggestions? One person has suggested it could be a timing problem which needs to be checked with an oscilliscope from the CO, but I doubt the phone company has tried that. Any help would be appreciated. We are losing hair over this. Thanks, Greg Gibson The PressRoom Online Services

Subject: Re: (usr-tc) PRI Problems
From: David Bolen <db3l@ans.net>
Date: 1997-10-20 14:11:46

Greg Gibson <gg@pressroom.com> writes: > Has anyone out there experienced this kind of problem before or can anyone > offer suggestions? One person has suggested it could be a timing problem > which needs to be checked with an oscilliscope from the CO, but I doubt the > phone company has tried that. I can't speak to the PM3s, but on the USR side, my suggestion to start off would be to enable the PRI-card level traps for all call events (in the dt1TrapEnaTable table), and then log those traps (either via TCM or any other trap receiver). (Oh, you need to be running TCS 2.5.x for these events) This will give you a trail of all calls at the earliest entry point into the USR hub. Any call that the telco hands to your equipment will generate at a minimum a "callArriveEvent" trap. If that call is successfully delivered to a component in the hub, you'll have a "callConnectEvent" trap later followed by a "callTermNormalEvent". If, however, the PRI card is unable to deliver the call to a component (modem or gateway), you'll see a "callTermFailedEvent" trap which will include a cause code to help identify what failed (e.g., out of modems, failure communicating with a modem etc..). In such a failure case, the PRI card is going to generate a release code to the telco which will most likely result in a busy to the end user. What will this identify is whether or not there is any problem within your chassis' in terms of delivering calls, and whether the equipment is directly responsible for busies or not. Since you mention the problem seems to be across various type of equipment I would agree this is not the most likely cause, but watching these traps will let you eliminate it as a possibility. If this shows that you are delivering calls successfully then you kind of need to work backwards towards the phone network, and in conjunction with your telco. The above traps don't completely exonerate your gear (just everything but the PRI card itself). So you might want to ask the telco to generate their own call delivery report, which should indicate counts of how many calls they delivered to each of your spans, and how many your equipment acknowledged successfully. In theory, their count and any count you derive from the above event traps should match perfectly. If they don't, then it probably indicates a communication failure between the telco switch and the PRI cards, such that the telco thinks it is indicating a call arrival but the PRI card is not noticing, and/or considers the telco message on the D channel to be malformed. Presuming that the telco and you are in agreement about this "last leg" of their circuit, the next step is to start working with the telco to push back within their own network. While the actual circuits between their last switch and your equipment may be fine, you might be encountering congestion deeper within their network. This is sometimes more of a problem with CAPs or alternative access providers, since they have their own trunking with the LEC which may saturate if they overcommit it. In such a case you may be perceiving this as a problem with your new circuits only because they increased your capacity to the point where you stressed the internal telco capacity at some other trunk location. Also, while PRI connections normally don't ring, I don't think that's a hard and fast rule, as I believe I've seen PRI connections "ring" back to the end user when activity within the phone network caused rerouting of the call around congestion or otherwise delayed delivery. I can't really speak authoritatively (maybe someone else on the list has a better telco background), but I believe ringing is often controlled by completely separate equipment independent of the call path and receiving it might just indicate that the caller was rerouted or held temporarily to try to work around something like congestion. Depending on how sporadic your problem is, you might be able to get someone from the telco on the line during a period of such problems. Have them monitor your hunt group while you (or ideally they) make a call that results in a busy. If they are calling, they should be able to trap and trace their own (or your) source number to isolate the call path. If it doesn't even show up on their trace, then it's another piece of data that indicates the call is being dropped or busied earlier in the phone network (call path). While the symptoms would certainly seem to suggest something external to your equipment, the odds are good that unless you gather specific data to indicate that you are properly terminating all offered calls, the telco may not push back within their own cloud to look for alternate causes. Trapping and summarizing the above events on the USR gear should permit you to present them appropriate information to help drive the process. Or, you might just find that there really is a failed component on your side which you can fix :-) -- 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) Netserver and UDP packets (quake)
From: Laszlo Vecsey <master@internexus.net>
Date: 1997-10-20 18:54:56

There has been a lot of talk about how 3.5.34 doesn't handle UDP packets as well as it could (affecting Quake/Quakeworld between dialed up users and a server on the local lan) but what about UDP latency to remote Quakeworld servers, out on the internet; can we expect an improvement there as well? - lv

Subject: Re: (usr-tc) PRI Problems
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-21 10:09:51

Greg Gibson said once upon a time: > >We have recently begun to have a problem in which our PRIs will >sporadiacally ring busy even though there is plenty of modem capacity >available. They will also, on occassion, ring with no answer even though >the equipment appears to be working fine. PRIs shouldn't even ring at all. I've seen this happen when either a modem is jammed, or Netserver slots are set to "I"nactive. I don't know why it just doesn't rotate around that, but on occasion it will have behavior like you described. Do this: 1. With TCM set all your PRI channels to "disconnect". 2. Then put them "In Service" 3. Put your spans "In Service" 4. Telnet to the Netserver and do a "show all". Look for any slots that have "I" instead of "R". Reset them.

Subject: Re: (usr-tc) tcenema script & Investing in TCM
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-21 10:54:11

Unfortunately, there's a lot of "preaching to the choir" on this list. I'm not sure how much of USR's management is really listening, and I believe most of the techs who are listening would agree with most of our points. I know for a fact that TCM was contracted. USR probably can't put out other versions because they didn't contract for the other versions. I'm not sure if USR even owns the source-code. The issue with Quake lag is another story. I think most of the engineering emphasis in the past year has been to get off of ComOS and onto their own code. In other words, they don't want to spend much time fixing bugs with the ComOS based code if they're going to replace it in entirety anyway.

Subject: (usr-tc) tcenema script & Investing in TCM
From: Allen Marsalis <am@shreve.net>
Date: 1997-10-21 11:02:20

Hi Michael. I am new to the tc-user list and have only been reading it for a few days now. We are about to purchase our 4th tc hub and have been battling a couple of problems for months now that make me relunctant to keep giving USR more business. I was wondering what your opinion might be on the subject. First off, we have hosted a quake server for months now. We introduce our users to quake then they quit us, only to signup with a competitor and play quake on our server.. This is because quake is nearly unplayable through a TC hub.. I can't really blame them.. USR was informed of the problem months ago and even called our unix admin (brian feeny) for some details. It seems like a simple enough fix but nothing appears to have been done about it.. Does USR plan to address the problem anytime soon? The second problem is that TCM is not available under linux.. Reading the following post has me wondering: At 10:25 AM 10/20/97 -0500, you wrote: >You must have TCM unix and it is only for sparc at this time.. See previous >thread >about UNIX ports of TCM and sec & accting.. > >But all of this is possible with a little more coding and UCD SNMP which is >compilable >on most UNIX platforms. > > >-M What I am hearing is that compiling TCM under different flavors of unix is possible with a little work. But that USR (at this time) can't put forth a few hours coding to make it happen.. I have seen several internet packages (such as DNEWS) available on over a dozen platforms. I know those guys must be compiler crazy but still, I doubt there is too much recoding between the various unix versions.. These two issues remain a major pain for us and we couldn't have made a worst choice of servers to host quake users, that's for sure.. We have played quake from several other competitors and our own analog equipment with much better performance.. Any ideas and or opinions are greatly appreciated as we have been waiting patiently for months hoping that USR will address our concerns.. I know you must be busy as a level 3 engineer so please feel free to forward this message if you think it appropriate.. Thanks for your time... Sincerely, Allen Marsalis _________________________________________________________________ Allen Marsalis President, Shrevenet, Inc. Thoughtful Provider of Internet Services 333 Texas St. Suite 619 Shreveport, LA 71101 Ph. 318.222.2NET (2638) FAX: 318.221.6612 mailto:am@shreve.net http://www.shreve.net

Subject: Re: (usr-tc) mpip w/I-Modems
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-21 11:04:47

Brian said once upon a time: >Is there any known problems with MPIP and the new Imodem code for USR TC >hubs? >I set hub 1 to be isdn gw =0 as well I would imagine that since MPIP is based on the Netserver, using ISDN-Modem would eliminate MPIP support.

Subject: Re: (usr-tc) Netserver and UDP packets (quake)
From: Russ Panula <rpanula@dacmail.net>
Date: 1997-10-21 11:17:23

On Mon, 20 Oct 1997 18:54:56 -0400 (EDT), Laszlo Vecsey <master@internexus.net> wrote: >There has been a lot of talk about how 3.5.34 doesn't handle UDP packets >as well as it could (affecting Quake/Quakeworld between dialed up users >and a server on the local lan) but what about UDP latency to remote >Quakeworld servers, out on the internet; can we expect an improvement >there as well? I would think that since the UDP latency is introduced within the Enterprise Hub, remote and local UDP applications would see a benefit if USR were to actually fix the problem. Regards, Russ

Subject: Re: (usr-tc) mpip w/I-Modems
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-21 11:21:32

Jeff Mcadams said once upon a time: >>I would imagine that since MPIP is based on the Netserver, using ISDN-Modem >>would eliminate MPIP support. > >Why? I have users showing up in a show bun that are on S ports, not I >ports, so its handling MLPPP on a modems...don't know why it couldn't >then deal with MPIP on modems just as well. No idea. I just remember Krish mentioning that there is a loss of functionality by using ISDN-Modem instead of direct to the Netserver.

Subject: Re: (usr-tc) tcenema script & Investing in TCM
From: Russ Panula <rpanula@dacmail.net>
Date: 1997-10-21 11:35:42

On Tue, 21 Oct 1997 11:02:20 -0500, Allen Marsalis <am@shreve.net> wrote: >First off, we have hosted a quake server for months now. We introduce our >users to quake then they quit us, only to signup with a competitor and play >quake on our server.. This is because quake is nearly unplayable through >a TC hub.. I can't really blame them.. USR was informed of the problem >months ago and even called our unix admin (brian feeny) for some details. >It seems like a simple enough fix but nothing appears to have been done >about it.. Does USR plan to address the problem anytime soon? Hear, hear. 6 months should be more than long enough to fix this bug. >The second problem is that TCM is not available under linux.. Reading the >following post has me wondering: > >At 10:25 AM 10/20/97 -0500, you wrote: >>You must have TCM unix and it is only for sparc at this time.. See previous >>thread >>about UNIX ports of TCM and sec & accting.. >> >>But all of this is possible with a little more coding and UCD SNMP which is >>compilable >>on most UNIX platforms. >> >> >>-M > >What I am hearing is that compiling TCM under different flavors of unix is >possible with a little work. But that USR (at this time) can't put forth a >few hours coding to make it happen.. I have seen several internet packages >(such as DNEWS) available on over a dozen platforms. I know those guys must >be compiler crazy but still, I doubt there is too much recoding between the >various unix versions.. Heck, they can't fix a simple UDP bug in 6 months and you expect them to port TCM to another platform? ROFLMAO >These two issues remain a major pain for us and we couldn't have made a >worst choice of servers to host quake users, that's for sure.. We have >played quake from several other competitors and our own analog equipment >with much better performance.. Here's another issue to consider: NO EMAIL SUPPORT. Sure, you've got this _public_ list, but just try sending a question to support@usr.com ... This gets my goose all the time. How can a company with a presence on the Internet that provides goods and services to other individuals on the Internet *not* provide email support for their flagship product? Seems logical enough to me. If it's not obvious yet, I've had a very trying day with my hubs. My apologies to those offended. Regards, Russ

Subject: RE: (usr-tc) tcenema script & Investing in TCM
From: Marshall Morgan <marshall@netdoor.com>
Date: 1997-10-21 12:13:39

On Tuesday, October 21, 1997 12:36 PM, Russ Panula [SMTP:rpanula@dacmail.net] wrote: > > Here's another issue to consider: NO EMAIL SUPPORT. > > Sure, you've got this _public_ list, but just try sending a question > to support@usr.com ... This gets my goose all the time. How can a > company with a presence on the Internet that provides goods and > services to other individuals on the Internet *not* provide email > support for their flagship product? Seems logical enough to me. > > If it's not obvious yet, I've had a very trying day with my hubs. My > apologies to those offended. I would think many people have the very same opinions on the 3COM/USR lack of modern customer support. Once I called the "24 hour" support lines at 11:30 PM on a week night under the "Premium" support plan and had someone call me on a cell phone from his house and then tell me to call back the next day because his battery was running low! Marshall Morgan http://www.netdoor.com 601.969.1434 | Fax 601.969.3838 | 800.952.1570

Subject: Re: (usr-tc) tcenema script & Investing in TCM
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1997-10-21 12:47:38

Thus spake Russ Panula >On Tue, 21 Oct 1997 11:02:20 -0500, Allen Marsalis <am@shreve.net> >wrote: >>First off, we have hosted a quake server for months now. We introduce our >>users to quake then they quit us, only to signup with a competitor and play >>quake on our server.. This is because quake is nearly unplayable through >>a TC hub.. I can't really blame them.. USR was informed of the problem >>months ago and even called our unix admin (brian feeny) for some details. >>It seems like a simple enough fix but nothing appears to have been done >>about it.. Does USR plan to address the problem anytime soon? >Hear, hear. 6 months should be more than long enough to fix this bug. So, please tell Tatai what exactly the problem is with the code and how to reproduce it on demand. I certainly haven't been able to give him a reliable way to reproduce it, but then again, I've only had two customers talk to me about Quake Lag. My beef here is that you folks are familiar with how difficult things can be to troubleshoot (at least I assume you are, I believe most of you are since most of the list is composed of folks that work for ISP's). So far, I haven't seen *anyone* give any solid feedback on Tatai's request for how to *reliably* reproduce the problem. I'm sorry, but 1) if you can't help them pinpoint the problem then I don't see where you have a big right to complain about how long they're taking to fix it...if you want them to fix it faster, give them some substantial help 2) if you don't know specifically what the problem is (apparently, since you haven't been able to tell them how to reliably reproduce it), then how do you know that 6 months is enough time to fix the bug? I would think that if the problem were a known problem then fixing it wouldn't take long, yes, but 99% of debugging something is finding out exactly what is causing the problem. Once you find out what's causing the problem the fix is usually quite easy...you all should know that (the 99% is picked out of air, but you get the idea). >Heck, they can't fix a simple UDP bug in 6 months and you expect them >to port TCM to another platform? ROFLMAO And these two things are related, how? >Here's another issue to consider: NO EMAIL SUPPORT. >Sure, you've got this _public_ list, but just try sending a question >to support@usr.com ... This gets my goose all the time. How can a >company with a presence on the Internet that provides goods and >services to other individuals on the Internet *not* provide email >support for their flagship product? Seems logical enough to me. Indeed, this is a reasonable request, IMHO, but I'm not sure its quite fair to beat up USR on it since I've never seen a request for it...personally I wouldn't make much use of it, but I can see where some certainly would. >If it's not obvious yet, I've had a very trying day with my hubs. My >apologies to those offended. I'm not offended, and I can certainly understand how you could have a trying day with your hubs...I've had a few of my own, but I don't think your post was in any way productive, so I guess I just don't see the point of it. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) tcenema script & Investing in TCM
From: David Bolen <db3l@ans.net>
Date: 1997-10-21 12:58:50

Allen Marsalis <am@shreve.net> writes: > What I am hearing is that compiling TCM under different flavors of unix is > possible with a little work. Not quite. Although how much effort is it to port TCM to other environments is a separate question, what I believe was being said was that anything you can do under TCM can be done with straight SNMP, and thus some programming (script or otherwise) under Unix with any capable SNMP library (such as UCD or CMU). For myself, the thing I particularly like about the TC system is that it is built to be SNMP manageable, and yet not require me to use the vendor software. We've developed an elaborate set of management tools which depend solely on the SNMP support and not on any other provided software, and prefer to manage the system that way. Of course, I realize that my requirements (and willingness to handle a good amount of development) are propably not typical, and would love to see TCM supported on more environments. I suppose it's a question for 3Com in terms of demand and probable payback for porting the code, so I'm sure the more their sales staff hear about requirements for particular platforms, the more likely it might show up there. After all, originally even having a Unix version at all seemed like a pipe dream. -- 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) mpip w/I-Modems
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1997-10-21 13:10:32

Thus spake Pete Ashdown >Brian said once upon a time: >>Is there any known problems with MPIP and the new Imodem code for USR TC >>hubs? >>I set hub 1 to be isdn gw =0 as well >I would imagine that since MPIP is based on the Netserver, using ISDN-Modem >would eliminate MPIP support. Why? I have users showing up in a show bun that are on S ports, not I ports, so its handling MLPPP on a modems...don't know why it couldn't then deal with MPIP on modems just as well. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) X2 Connect Rates Lower with 2.5.1?
From: Greg Gibson <gg@pressroom.com>
Date: 1997-10-21 13:58:37

I'm new to this list so forgive me if this has been discussed before, but has anyone out there had X2 users complain that they are no longer able to connect above 28.8 after you upgraded your hub to 2.5.1? We have had about a half dozen who say they regularly connected at 45k plus but are suddenly now only able to connect at 28.8 or even 26.4. The only thing we have changed recently is the OS upgrade. It's possible that this problem is related to the PRI problem I asked about yesterday (thank you to those who responded...we believe the problem has been traced to translation errors at the CO), but I'm curious if anyone else has received complaints like this from users. Thanks, Greg Gibson The PressRoom Online Services

Subject: Re: (usr-tc) X2 Connect Rates Lower with 2.5.1?
From: David Bolen <db3l@ans.net>
Date: 1997-10-21 15:25:04

Greg Gibson <gg@pressroom.com> writes: > I'm new to this list so forgive me if this has been discussed before, but > has anyone out there had X2 users complain that they are no longer able to > connect above 28.8 after you upgraded your hub to 2.5.1? We have had about > a half dozen who say they regularly connected at 45k plus but are suddenly > now only able to connect at 28.8 or even 26.4. The only thing we have > changed recently is the OS upgrade. Sort of simple initial question, but are you sure you still have the x2 feature enabled in your modems? It shouldn't change across just a code upgrade (unless you were previously running beta code or something), but you might want to verify the feature setting on your NMC and/or modems or try sending the feature code again. It's also a good idea across code changes to instruct all of your modems to restore to a factory default model (such as the hardware flow default) and then re-issue any special settings you have. Sometimes registers and such change and they aren't always cleared properly during the update (yeah, it should work fine, but it's something to try). > It's possible that this problem is related to the PRI problem I asked about > yesterday (thank you to those who responded...we believe the problem has > been traced to translation errors at the CO), but I'm curious if anyone > else has received complaints like this from users. You might also check the mdmCsX2Status (it's in the modem call statistics table) which gives an indication of the x2 status of a call, such as (from the 4.3.8 MIB): x2notOperational(1), x2Operational(2), v8DisabledLocal(3), x2DisabledLocal(4), baud3200DisabledLocal(5), speedLimitedLocal(6), v8notDetectedFromRemote(7), x2notDetectedFromRemote(8), incompatibleVersions(9), incompatibleModes(10), baud3200DisabledRemote(11), excessiveHFAttenuation(12), channelNot3200Baud(13), exitBeforeX2Connect(14) (As with other parameters checking a modem that isn't online gives stats for the previous call). It might give a hint as to why x2 isn't being achieved. -- 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) mpip w/I-Modems
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-21 15:50:26

Brian said once upon a time: >> >I would imagine that since MPIP is based on the Netserver, using ISDN-Modem >> >would eliminate MPIP support. >> >> Why? I have users showing up in a show bun that are on S ports, not I >> ports, so its handling MLPPP on a modems...don't know why it couldn't >> then deal with MPIP on modems just as well. > >is your MPIP server running the isdn on modems also? Nope. I haven't seen good reason to switch to isdn-modem yet.

Subject: Re: (usr-tc) mpip w/I-Modems
From: Brian <signal@shreve.net>
Date: 1997-10-21 16:42:07

On Tue, 21 Oct 1997, Jeff Mcadams wrote: > Thus spake Pete Ashdown > >Brian said once upon a time: > >>Is there any known problems with MPIP and the new Imodem code for USR TC > >>hubs? > > >>I set hub 1 to be isdn gw =0 as well > > >I would imagine that since MPIP is based on the Netserver, using ISDN-Modem > >would eliminate MPIP support. > > Why? I have users showing up in a show bun that are on S ports, not I > ports, so its handling MLPPP on a modems...don't know why it couldn't > then deal with MPIP on modems just as well. is your MPIP server running the isdn on modems also? Brian > -- > Jeff McAdams Email: jeffm@iglou.com > Chief Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: (usr-tc) bundles
From: Brian <signal@shreve.net>
Date: 1997-10-21 17:02:12

What is the difference between these bundles? Bundle: sob is comprised of these 2 links: ----> comport I5 -- EDO type 5 PSN DIRECTORY NUMBER: 545654565654530000000000000----> comport I4 -- EDO type 5 PSN DIRECTORY NUMBER: 545654565654530000000000000 Bundle: signal is comprised of these 2 links: ----> comport -- EDO type 5 PSN DIRECTORY NUMBER: 514956545554565657510000000000 ----> comport I3 -- EDO type 5 PSN DIRECTORY NUMBER: 514956545554565657510000000000 Bundle: am is comprised of these 2 links: ----> comport I1 -- EDO type 3 IEEE 802.1 MAC: 0c07b6f4e500000000000000 ----> comport I0 -- EDO type 3 IEEE 802.1 MAC: 0c07b6f4e500000000000000 I notice 2 use PSN numbers and the other uses a MAC address. Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: Re: (usr-tc) mpip w/I-Modems
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1997-10-21 17:50:56

Thus spake Brian >On Tue, 21 Oct 1997, Jeff Mcadams wrote: >> Thus spake Pete Ashdown >> >Brian said once upon a time: >> >>Is there any known problems with MPIP and the new Imodem code for USR TC >> >>hubs? >> >> >>I set hub 1 to be isdn gw =0 as well >> >> >I would imagine that since MPIP is based on the Netserver, using ISDN-Modem >> >would eliminate MPIP support. >> >> Why? I have users showing up in a show bun that are on S ports, not I >> ports, so its handling MLPPP on a modems...don't know why it couldn't >> then deal with MPIP on modems just as well. >is your MPIP server running the isdn on modems also? No, I don't have anything running ISDN on modems yet, so these are actual modem calls that are showing up in the 'show bun', which (I would think) would indicate that these actual modem calls are using MLPPP and so I don't know of any reason that they should not be able to be bonded via an MPIP connection. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) tcenema script & Investing in TCM
From: Russ Panula <rpanula@dacmail.net>
Date: 1997-10-21 18:51:46

On Tue, 21 Oct 1997 12:47:38 -0400 (EDT), Jeff Mcadams <jeffm@iglou.com> wrote: >So, please tell Tatai what exactly the problem is with the code and how >to reproduce it on demand. I certainly haven't been able to give him a >reliable way to reproduce it, but then again, I've only had two >customers talk to me about Quake Lag. > >My beef here is that you folks are familiar with how difficult things >can be to troubleshoot (at least I assume you are, I believe most of you >are since most of the list is composed of folks that work for ISP's). >So far, I haven't seen *anyone* give any solid feedback on Tatai's >request for how to *reliably* reproduce the problem. 1. Simple network setup: 1 Enterprise Hub, 1 Portmaster PM 2E-30, 1 NetQuake server, 1 remote client, 1 ethernet segment, 1 can or bottle of favorite beverage. 2. Dial remote client into PM 2E-30. Connect to Quake server. Record average in-game ping times using the Quake console command 'ping' over a period of 10 minutes. 3. Dial remote client into Enterprise Hub. Connect to Quake server. Record average in-game ping times using the Quake console command 'ping' over a period of 10 minutes. 4. Compare results. Drink beverage. Rinse. Repeat. Is this not simple stuff? Surely 3Com must have thought of this. For those of you looking for a field trip, you could try using netperf to get quantifiable numbers. http://www.cup.hp.com/netperf/NetperfPage.html >I'm sorry, but >1) if you can't help them pinpoint the problem then I don't see where >you have a big right to complain about how long they're taking to fix >it...if you want them to fix it faster, give them some substantial help > >2) if you don't know specifically what the problem is (apparently, >since you haven't been able to tell them how to reliably reproduce it), >then how do you know that 6 months is enough time to fix the bug? I >would think that if the problem were a known problem then fixing it >wouldn't take long, yes, but 99% of debugging something is finding out >exactly what is causing the problem. Once you find out what's causing >the problem the fix is usually quite easy...you all should know that >(the 99% is picked out of air, but you get the idea). Is the reproducibility of this problem really in question here? When you play Quake through your NETserver's, are you not lagged? Yes? No? Maybe so? >I'm not offended, and I can certainly understand how you could have a >trying day with your hubs...I've had a few of my own, but I don't think >your post was in any way productive, so I guess I just don't see the >point of it. Just agreeing with Allen on the Quake issue. Yes, it _still_ is an issue. Warm regards, Russ

Subject: Re: (usr-tc) List Archive
From: Russ Panula <rpanula@dacmail.net>
Date: 1997-10-21 18:57:11

On Tue, 21 Oct 1997 19:52:54 -0401 (EDT), Vince J Bono <vjb@www.netlabs.net> wrote: > >Being new to this list where can I find an archive ?? http://usr-tc.datasys.net

Subject: Re: (usr-tc) PRI Problems
From: matthew <matthew@the-spa.com>
Date: 1997-10-21 19:06:38

stupid question, what does A R ? instead of A R P mean?? reseting modems from default fixes it, but what exactly does it mean? matthew At 10:09 AM 10/21/97 -0600, you wrote: >Greg Gibson said once upon a time: >> >>We have recently begun to have a problem in which our PRIs will >>sporadiacally ring busy even though there is plenty of modem capacity >>available. They will also, on occassion, ring with no answer even though >>the equipment appears to be working fine. PRIs shouldn't even ring at all. > >I've seen this happen when either a modem is jammed, or Netserver slots are >set to "I"nactive. I don't know why it just doesn't rotate around that, >but on occasion it will have behavior like you described. > >Do this: > > 1. With TCM set all your PRI channels to "disconnect". > 2. Then put them "In Service" > 3. Put your spans "In Service" > 4. Telnet to the Netserver and do a "show all". Look for any slots > that have "I" instead of "R". Reset them. > >

Subject: (usr-tc) List Archive
From: Vince J Bono <vjb@www.netlabs.net>
Date: 1997-10-21 19:52:54

Being new to this list where can I find an archive ?? Thx. Vince

Subject: Re: (usr-tc) tcenema script & Investing in TCM
From: Allen Marsalis <am@shreve.net>
Date: 1997-10-21 20:14:39

At 11:35 AM 10/21/97 -0600, Russ Panula wrote: >Hear, hear. 6 months should be more than long enough to fix this bug. > I think so too. We have patiently waited while watching our old customers, the ones we got up on quake, continue to play quake under a new ISP.. If that's not bad enough, they bitch (on quake) to current customers about how our access sucks.. We reported the problem around 5 or 6 months ago and the last rumor I heard is that they have not been able to replicate the problem. It's hard to imagine that they are trying very hard.. Since we are fully digital except for two analog lines (back door for when the hubs flake out..) we have no fallback option.. And besides, we haven't run a bunch of expensive x2 ads for nothin'.. >Heck, they can't fix a simple UDP bug in 6 months and you expect them >to port TCM to another platform? ROFLMAO Understood. But your humor is _very_ scarry indeed. It implies almost total incompetence on the part of USR's abilities and management. That it is a joke to expect something so common as a bug fix or OS port.. Certainly the management of such a large corporation must be held accountable for such negligence.. Certainly they know what they are doing some very fine (and growing) customers who _DO_ care about such things as support and customer satisfaction.. > >Here's another issue to consider: NO EMAIL SUPPORT. I have had my fair share of torture in the USR hold queue.. But the hostility has left me months ago after pulling out nearly all of my hair (I'm too young to be bald). So I have decided to remain calm and be patient. I have seen this sort of thing before and it is all about contracts, management, and money.. not about engineers for whom I have a great respect.. >Sure, you've got this _public_ list, but just try sending a question >to support@usr.com ... This gets my goose all the time. How can a >company with a presence on the Internet that provides goods and >services to other individuals on the Internet *not* provide email >support for their flagship product? Seems logical enough to me. It is truly amazing that at $13K a pop, and we are buying one of these every 12 weeks, we receive little support directly from USR. The sales staff never checks up on us.. If I was buying a new car every 12 weeks, i'd probably get free lunch and maybe taken to a strip club or something.. Most marketers try to earn you business.. >If it's not obvious yet, I've had a very trying day with my hubs. My >apologies to those offended. > I've had "those days" also and I know what you mean.. I don't see how folks that manage hundreds of these hubs do it.. But the solution is not to put the heat on the engineers or support staff who are probably as dismayed by these problems as the customer.. And at least trying to help.. These problems seem due to a higher power.. Thanks for your thoughts, Allen Marsalis _________________________________________________________________ Allen Marsalis President, Shrevenet, Inc. Thoughtful Provider of Internet Services 333 Texas St. Suite 619 Shreveport, LA 71101 Ph. 318.222.2NET (2638) FAX: 318.221.6612 mailto:am@shreve.net http://www.shreve.net

Subject: (usr-tc) Stupid problem with rlogins
From: Brian Elfert <brian@citilink.com>
Date: 1997-10-21 20:25:27

I've got a user that is gonna drive me batty with his stupid madeup problem. Here's the problem: When he rlogins from a Portmaster to our shell machine, stty reports a baud rate of 115200. When he rlogins from a Total Control chassis to our shell server stty reports a baud rate of 57600. (I tested, and indeed this is the case.) Now I know, and probably everybody on this list knows, that the baud rates set by stty don't mean anything in a rlogin or telnet session. I don't know if some setting is different between the two or what. Here are the settings on my Total Control chassis: Port Type: Login/Netwrk Login/Netwrk (Dial In) (Security) Login Service: PortMux PortMux Device Service: Telnet@6006 Telnet@6006 Modem Stat: READY ACTIVE Databits: 8 8 Stopbits: 1 1 Parity: none none Flow Control: None None* Modem Control: on on HDLC Framing: PPP in modem PPP in modem SLIP Framing: SLIP in NETServer SLIP in NETServer -- Press Return for More -- Modem Presence: Modem is present Init Script: (None) Init When?: Never Hosts: default Terminal Type: vt100 Login Prompt: ^Welcome to Citilink^^tc1 6 username: Idle Timeout: 15 min 0 sec Dial Group: 0 TAP type: OFF OFF Here are the settings from my Portmaster: Active Configuration Default Configuration (* = Host -------------------- --------------------- Can Override) Port Type: Login/Netwrk Login/Netwrk (Dial In) (Security) Login Service: PortMaster PortMaster Baud Rates: 115200 115200,115200,115200 Databits: 8 8 Stopbits: 1 1 Parity: none none Flow Control: RTS/CTS RTS/CTS Modem Control: on on Hosts: default Terminal Type: vt100 Login Prompt: ^Welcome to Citilink^^pm1 26 username: Idle Timeout: 15 minutes Dial Group: 0 Any ideas why the differences in the stty settings? Would setting the default DTE rate on all of the modems to 115200 help? (Yes, I know that this shouldn't affect anything with packetbus) Brian

Subject: Re: (usr-tc) tcenema script & Investing in TCM
From: Allen Marsalis <am@shreve.net>
Date: 1997-10-21 21:01:53

At 10:54 AM 10/21/97 -0600, Pete Ashdown wrote: >Unfortunately, there's a lot of "preaching to the choir" on this list. I'm >not sure how much of USR's management is really listening, and I believe >most of the techs who are listening would agree with most of our points. Exactly.. I just received a kind note from Michael Wronski and find it kind of ironic.. I feel smart engineers should work on new cool stuff, solve real problems, and address customer's technical concerns. Management should be concerned with support issues and overall customer satisfaction. It's a matter of applying the best people where they are most needed.. I feel that griping to an engineer about no email support or poor phone support is really misdirected.. And I sure do want them around (and happy) when I have a technical question.. >I know for a fact that TCM was contracted. USR probably can't put out >other versions because they didn't contract for the other versions. I'm >not sure if USR even owns the source-code. This sure seems to explain things.. >The issue with Quake lag is another story. I think most of the engineering >emphasis in the past year has been to get off of ComOS and onto their own >code. In other words, they don't want to spend much time fixing bugs with >the ComOS based code if they're going to replace it in entirety anyway. > That makes since unless the bug is so big, so hairy, so menacing, as to really piss off your customer base.. I'm not in business to educate customers and present them to the competition on a silver platter.. With the quake bug present, that's exactly what we are doing.. Month after month... Thanks for the explanation.. Allen _________________________________________________________________ Allen Marsalis President, Shrevenet, Inc. Thoughtful Provider of Internet Services 333 Texas St. Suite 619 Shreveport, LA 71101 Ph. 318.222.2NET (2638) FAX: 318.221.6612 mailto:am@shreve.net http://www.shreve.net

Subject: Re: (usr-tc) tcenema script & Investing in TCM
From: Allen Marsalis <am@shreve.net>
Date: 1997-10-21 21:15:57

At 12:58 PM 10/21/97 EDT, you wrote: >Allen Marsalis <am@shreve.net> writes: > >> What I am hearing is that compiling TCM under different flavors of unix is >> possible with a little work. > >Not quite. Although how much effort is it to port TCM to other >environments is a separate question, what I believe was being said was >that anything you can do under TCM can be done with straight SNMP, and >thus some programming (script or otherwise) under Unix with any >capable SNMP library (such as UCD or CMU). Now I understand what was being said. Thanks.. However, rewriting much of the functionality of TCM into your own code seems like alot of redundant work.. There is no one else to share the cost and time of development with.. >For myself, the thing I particularly like about the TC system is that >it is built to be SNMP manageable, and yet not require me to use the >vendor software. We've developed an elaborate set of management tools >which depend solely on the SNMP support and not on any other provided >software, and prefer to manage the system that way. This _is_ a real plus.. (if you have the time for such development). Is there anyone out there that shares or sells "third-party" TC SNMP tools? Sure would be great not to have to start from scratch with only a new SNMP library (and questionable documentation) to start with.. >Of course, I realize that my requirements (and willingness to handle a >good amount of development) are propably not typical, and would love >to see TCM supported on more environments. I suppose it's a question >for 3Com in terms of demand and probable payback for porting the code, >so I'm sure the more their sales staff hear about requirements for >particular platforms, the more likely it might show up there. After >all, originally even having a Unix version at all seemed like a pipe >dream. > >-- David Sounds like you been at it for a while.. Veteran ISP's probably have had time to develop their own tricks and styles.. But newer ISP's without the time to solve _all_ their problems, really could use a solution from someone else who has "been there, done that".. Allen _________________________________________________________________ Allen Marsalis President, Shrevenet, Inc. Thoughtful Provider of Internet Services 333 Texas St. Suite 619 Shreveport, LA 71101 Ph. 318.222.2NET (2638) FAX: 318.221.6612 mailto:am@shreve.net http://www.shreve.net

Subject: Re: (usr-tc) Stupid problem with rlogins
From: Brian Elfert <brian@citilink.com>
Date: 1997-10-21 21:29:36

On Tue, 21 Oct 1997, David Bolen wrote: > Brian Elfert <brian@citilink.com> writes: > > > Any ideas why the differences in the stty settings? Would setting the > > default DTE rate on all of the modems to 115200 help? (Yes, I know that > > this shouldn't affect anything with packetbus) > > If I had to guess what is happening is that both the NETServer and > Portmaster transmit the configured baud rate (or the autodetected > rate) for the serial port of the user as part of the initial rlogin > negotiation. I wasn't sure if the Portmaster could somehow tell the Solaris box the speed it's running at or not. > The problem is that for the NETServer, it is smart enough to know that > a baud rate for a packet bus link is non-sensical, and thus neither > shows it to you on a "show s#" nor allows you to change it. But when > it comes to the rlogin client built into the NETServer, I bet it still > uses that port speed definition as part of the initial session setup. > And I'd bet that although never displayed, that the default values > internally are 57600. This is probably the case. Why wouldn't they use 115200 for packet bus communications? > You could probably try this by getting onto the console at various > baud rates and doing the rlogin and seeing if it transfers correctly. If I really get desperate, I could try this. > My guess is changing the default DTE rate on the modem side isn't > going to change anything, since I expect it's internal to the > NETServer how it considers the "speed" of the packet bus S ports. I didn't think so, but it was stab in the dark. > Maybe showing the user performance timings taken from both dialup > cases in order to show that it doesn't affect performance? :-) I've already demonstrated that the display is no faster or slower depending on the stty baud rate, but he still insists that it changes the display speed. Personally, I'd like to tell this idiot to take a flying leap and find another ISP, but I'm afraid he'd tell anyone he knows not to use us if I did that. To think that he used to work at a local ISP. Maybe they fired him for incompetence. Brian

Subject: Re: (usr-tc) Stupid problem with rlogins
From: David Bolen <db3l@ans.net>
Date: 1997-10-21 21:34:48

Brian Elfert <brian@citilink.com> writes: > Any ideas why the differences in the stty settings? Would setting the > default DTE rate on all of the modems to 115200 help? (Yes, I know that > this shouldn't affect anything with packetbus) If I had to guess what is happening is that both the NETServer and Portmaster transmit the configured baud rate (or the autodetected rate) for the serial port of the user as part of the initial rlogin negotiation. The problem is that for the NETServer, it is smart enough to know that a baud rate for a packet bus link is non-sensical, and thus neither shows it to you on a "show s#" nor allows you to change it. But when it comes to the rlogin client built into the NETServer, I bet it still uses that port speed definition as part of the initial session setup. And I'd bet that although never displayed, that the default values internally are 57600. You could probably try this by getting onto the console at various baud rates and doing the rlogin and seeing if it transfers correctly. I'm not sure that you can get around this. I thought that perhaps you could just reset the speed on the normal S ports (regardless of whether it made a difference or was displayed or not), but apparently 3Com figured you'd never want to do that, so the "set speed" command won't work for packet bus connected ports. My guess is changing the default DTE rate on the modem side isn't going to change anything, since I expect it's internal to the NETServer how it considers the "speed" of the packet bus S ports. Maybe showing the user performance timings taken from both dialup cases in order to show that it doesn't affect performance? :-) -- 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) tcenema script & Investing in TCM
From: Allen Marsalis <am@shreve.net>
Date: 1997-10-21 21:48:36

At 12:47 PM 10/21/97 -0400, Jeff Mcadams wrote: >So, please tell Tatai what exactly the problem is with the code and how >to reproduce it on demand. I certainly haven't been able to give him a >reliable way to reproduce it, but then again, I've only had two >customers talk to me about Quake Lag. Only two? It's good to know that their is another person out there stupid enough to host a quake server under TC access... If the problem was solved, I bet that more TC hubs could be sold to ISP's serving Quake.. Hundreds more.. The lag is not mysterious or a problem to replicate.. I'll be happy risking prosecusion to provide an engineer with a bootleg copy of quake and a free account on our system.. Or call for some passwords and an engineer can "see" it in realtime. We are replicating the problem daily 24/7... week after week, month after month.... What do you want to know? >My beef here is that you folks are familiar with how difficult things >can be to troubleshoot (at least I assume you are, I believe most of you >are since most of the list is composed of folks that work for ISP's). >So far, I haven't seen *anyone* give any solid feedback on Tatai's >request for how to *reliably* reproduce the problem. Play Quake... It's not intermittent.. At least not with the lastest two or three code versions.. >I'm sorry, but >1) if you can't help them pinpoint the problem then I don't see where >you have a big right to complain about how long they're taking to fix >it... B.S... >if you want them to fix it faster, give them some substantial help more B.S... I'm sorry, but I am "nothing but available".. Perhaps we could get a call back on a ticket that is months old... If USR needs more info, then ask.. We can't read minds... We'll be happy to help anyway we can.. But no requests have been made. >2) if you don't know specifically what the problem is (apparently, >since you haven't been able to tell them how to reliably reproduce it), >then how do you know that 6 months is enough time to fix the bug? I >would think that if the problem were a known problem then fixing it >wouldn't take long, yes, but 99% of debugging something is finding out >exactly what is causing the problem. Once you find out what's causing >the problem the fix is usually quite easy...you all should know that >(the 99% is picked out of air, but you get the idea). I get the idea. How do we know that they have spent (needed) months trying to fix it.. Heck they can't even replicate it.. I've spent $100K with USR this year alone. They can afford to fly an engineer out if they just can't "replicate" it or look at it over the pipe at our end.. >I'm not offended, and I can certainly understand how you could have a >trying day with your hubs...I've had a few of my own, but I don't think >your post was in any way productive, so I guess I just don't see the >point of it. >-- >Jeff McAdams Email: jeffm@iglou.com Sorry for venting but it's more productive than exploding.. We can't fix the problem for them.. They must put forth effort also.. And after months of waiting, I appreciate everyones posts which I find informative if not productive.. Thanks. Allen _________________________________________________________________ Allen Marsalis President, Shrevenet, Inc. Thoughtful Provider of Internet Services 333 Texas St. Suite 619 Shreveport, LA 71101 Ph. 318.222.2NET (2638) FAX: 318.221.6612 mailto:am@shreve.net http://www.shreve.net

Subject: Re: (usr-tc) tcenema script & Investing in TCM
From: Russ Panula <rpanula@dacmail.net>
Date: 1997-10-21 21:52:49

On Tue, 21 Oct 1997 20:14:39 -0500, Allen Marsalis <am@shreve.net> wrote: >At 11:35 AM 10/21/97 -0600, Russ Panula wrote: >>Hear, hear. 6 months should be more than long enough to fix this bug. >> > >I think so too. We have patiently waited while watching our old >customers, the ones we got up on quake, continue to play quake under >a new ISP.. If that's not bad enough, they bitch (on quake) to current >customers about how our access sucks.. We reported the problem around >5 or 6 months ago and the last rumor I heard is that they have not been >able to replicate the problem. It's hard to imagine that they are >trying very hard.. Since we are fully digital except for two analog >lines (back door for when the hubs flake out..) we have no fallback >option.. And besides, we haven't run a bunch of expensive x2 ads >for nothin'.. Gotta love the grapevine. ;-) >>Heck, they can't fix a simple UDP bug in 6 months and you expect them >>to port TCM to another platform? ROFLMAO > >Understood. But your humor is _very_ scarry indeed. It implies almost >total incompetence on the part of USR's abilities and management. That >it is a joke to expect something so common as a bug fix or OS port.. >Certainly the management of such a large corporation must be held >accountable for such negligence.. Certainly they know what they are >doing some very fine (and growing) customers who _DO_ care about such >things as support and customer satisfaction.. My humor was perhaps a bit harsh. I do have confidence in USR to "do their job". It's just that at the moment, they haven't fixed a problem that's been facing them for quite some time now. I truly fear they will never fix it. >>Here's another issue to consider: NO EMAIL SUPPORT. > >I have had my fair share of torture in the USR hold queue.. But >the hostility has left me months ago after pulling out nearly all >of my hair (I'm too young to be bald). So I have decided to remain >calm and be patient. I have seen this sort of thing before and it >is all about contracts, management, and money.. not about engineers >for whom I have a great respect.. Call me crazy, but I have no respect for engineers who can't seem to get the job done. It's been 6 months. Where's the fix? I have a hard time believing management swung down and said "Do not, under any circumstances, fix this problem." >>If it's not obvious yet, I've had a very trying day with my hubs. My >>apologies to those offended. >> > >I've had "those days" also and I know what you mean.. I don't see how >folks that manage hundreds of these hubs do it.. But the solution is >not to put the heat on the engineers or support staff who are probably >as dismayed by these problems as the customer.. And at least trying to >help.. These problems seem due to a higher power.. How much help do I need to provide? What more can I tell USR other than my customers who play Quake are leaving in droves? Do I truly need to setup and publish some netperf benchmarks to _show_ them the problem? Do I need to give them packet dumps of Quake sessions? Couldn't their support department do this instead of me? Warm regards, Russ

Subject: Re: (usr-tc) X2 Connect Rates Lower with 2.5.1?
From: Wayne Jordan <wjordan@pcl.net>
Date: 1997-10-21 21:54:04

We originally had this problem and it was because on X2 option had not been activated. At 01:58 PM 10/21/97 -0400, you wrote: >I'm new to this list so forgive me if this has been discussed before, but >has anyone out there had X2 users complain that they are no longer able to >connect above 28.8 after you upgraded your hub to 2.5.1? We have had about >a half dozen who say they regularly connected at 45k plus but are suddenly >now only able to connect at 28.8 or even 26.4. The only thing we have >changed recently is the OS upgrade. > >It's possible that this problem is related to the PRI problem I asked about >yesterday (thank you to those who responded...we believe the problem has >been traced to translation errors at the CO), but I'm curious if anyone >else has received complaints like this from users. > >Thanks, > >Greg Gibson >The PressRoom Online Services > > > Sincerely, Wayne Jordan President PC Land, Inc. <italic><color><param>ffff,0000,0000</param> </color></italic>

Subject: Re: (usr-tc) Stupid problem with rlogins
From: David Bolen <db3l@ans.net>
Date: 1997-10-21 22:45:35

Brian Elfert <brian@citilink.com> writes: > I wasn't sure if the Portmaster could somehow tell the Solaris box the > speed it's running at or not. It's part of the rlogin protocol - right in the front of the session, the client transmits both the terminal type and speed (or can if it wants). See RFC1282 if you're interested in the nitty gritty stuff. > This is probably the case. Why wouldn't they use 115200 for packet bus > communications? There is no "baud rate" for packet bus communications, so they're not using anything. The packet bus is a shared packet datagram bus (I forget the actual bus speed) which has no concept of serialization of bits. Conceptually, you can kind of think about it as an internal ethernet over which the modems and NETServer communicate using UDP to transfer chunks of user data. While you might rate the entire bus bandwidth (ethernet capacity), there's really no per-stream limitation, except perhaps if the hardware or software can't drive a single stream at bus rates. So it doesn't matter what the internal value is. > I've already demonstrated that the display is no faster or slower > depending on the stty baud rate, but he still insists that it changes the > display speed. Is this a user shell that you have any control over default profiles or manually included setup files? Could you could just manually tweak the stty setting if they were coming from the NETServer? > Personally, I'd like to tell this idiot to take a flying leap and find > another ISP, but I'm afraid he'd tell anyone he knows not to use us if I > did that. To think that he used to work at a local ISP. Maybe they fired > him for incompetence. Sheesh, some folks :-) Ok - here's a crufty approach (well, I might call it a neat kludge, but...): Aside from asking USR to implement a way to control this, if you're up for a bit of programming, you can probably hijack the rlogin stream with a forwarder and/or build a custom rlogind (depending on your shell machine platform you may have source, or I think you can get a PD or BSD code for rlogin around). If you can rebuild rlogind, change the source to always set it to 115200 and to listen on a custom port. Run that on your machine. Then define this user to point to the new port rather than the stock rlogind port. He won't know the difference :-) Barring that, you can construct a small piece of code that listens on one port and just forwards connections to another. You can run this right on the same machine and reroute connections to the standard rlogin port. The rlogin startup code is really easy - just 4 NUL terminated strings (one of which is terminal/speed). So upon receiving a connection, grab the 4 strings, rewrite the speed, send it on, and then step back and transparently forward bytes. I've got some basic forwarding code lying around somewhere that should be easy to adapt, at least for test purposes - used to use it as an NNTP forwarder through a firewall. If you're interested just let me know. -- 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) tcenema script & Investing in TCM
From: Charles Hill <chill@ionet.net>
Date: 1997-10-21 23:42:34

I don't understand all the complaints about Quake lag. We still have a few customers complaining about Quake lag, but we have taken some corrective measures and noted differences in customer configurations between customers who have consistent Quake lag, those who have intermittent lag, and those who have no Quake lag. Running Quakeworld instead of Quake helped. The 3Com Netservers are still noticeably slower, but the latency can be minimized. One of our tech support guys put up a web page to inform users: http://www.ionet.net/~sgoth/ Either the tips fix the problem or fix the customers' perception of the problem. A few leave after trying everything, but the smart ones upgrade to ISDN. ISDN is the answer. Hosting a Quake server (quake.ionet.net) has definitely had a positive effect here. More users sign up to have quick access to our quake server and more users upgrade to ISDN than leave because of a latency disadvantage in Quake. We are still more of in Internet provider than a Quake provider, so I don't stress over it. The Netserver is still the preferred NAS here. Regards, Charles Hill ioNET Network Specialist work: 405.270.7020 cell: 405.833.5477 pager: 405.559.6697 or 4055596697@mobile.att.net email: chill@ionet.net http://www.ionet.net/~chill

Subject: Re: (usr-tc) tcenema script & Investing in TCM
From: Garry Shtern <shterng@akula.com>
Date: 1997-10-22 00:53:12

On Tue, 21 Oct 1997, Allen Marsalis wrote: > the hostility has left me months ago after pulling out nearly all > of my hair (I'm too young to be bald). So I have decided to remain > calm and be patient. I have seen this sort of thing before and it > is all about contracts, management, and money.. not about engineers > for whom I have a great respect.. > > I've had "those days" also and I know what you mean.. I don't see how > folks that manage hundreds of these hubs do it.. But the solution is > not to put the heat on the engineers or support staff who are probably > as dismayed by these problems as the customer.. And at least trying to > help.. These problems seem due to a higher power.. Wow.. you honestly believe that those engineers that are on the (800) 321-8770 queue really know what they are doing? Well let me tell you a little story I just had with USR. Ever since we got Total Controls, about 6 months ago, we had a problem with users complaining about random low connection rates, random unstable connections, and at times lousy connect rates. I have always tried blaming it on the phone company(NYNEX) and explain to the customers that it is not our fault. Well one fine day, I decided to look at some statistical data on the T1 card and saw that we have a "Receiver gain applied" fluctuate from db0 to Not applicable. Naturally, I decided to give USR a call. Waited on hold for about 1 hour listening to that annoying music on hold for the 50th time and got one of the "engineers". Explained what I had and was told that yes it is a problem, we should get telco to do a line check. Lope and behold, telco runs a line check and tells us that the gain on the line is 0db all the way up to smart jack. I call USR back, and try to explain to them the info I got from the telco. Get another "wise" person there to advise the telco to do lbo(Line build out) on the line. Again, I call telco, and get the response: "Your vendor does not know what they are talking about because line build out is performed on the circuit prior to bringing it online and cannot be performed on it after because that would disturb the service of other customers. In addition to the fact that if you had problem with lbo, you wouldn't be able to even get calls coming in." I think to myself, this is stupid, let me call USR again. So again, I call them back and explain to them what I heard from telco. Again, I end up talking to the complete moron. So I decide to get telco on the line with USR so they can work this problem out. Guess what, the USR person could not explain to the telco person anything he wanted them to do, less seemed like he knew what the heck was he talking about himself. Of course, telco guys got incredibly frustrated and don't seem to be really anxious to help us out since our vendor does not know its arm from its elbow. I am not saying this just because I have nothing better to do than to complain about USR's tech support. But I figured that if I am paying $2,700 a year for the support of my equipment, I would be paying for something better than being on hold for an hour and getting completely incompetent people to deal with my problems. On a different note, if any of you have experienced the similar problems, and would suggest what to check for and how to check for it, or what to tell telco to check, I would be more than greatful. -Garry P.s. I did go through all the settings of the T1 card and they do match to the ones of our telco.

Subject: Re: (usr-tc) tcenema script & Investing in TCM
From: David Bolen <db3l@ans.net>
Date: 1997-10-22 01:11:09

Garry Shtern <shterng@akula.com> writes: > Wow.. you honestly believe that those engineers that are on the (800) > 321-8770 queue really know what they are doing? Well let me tell you a > little story I just had with USR. Um, for what it's worth, it's a pretty safe bet that the folks answering the 800 queue aren't "engineers". That's the front line, akin to a NOC or other support center. You have to make it through them (kind of like entering a decathalon) to have a chance at hitting real engineers :-) > Well one fine day, I decided to look at some statistical data on the T1 > card and saw that we have a "Receiver gain applied" fluctuate from db0 to > Not applicable. Hmm, not sure if I've ever seen that one one of our spans... If the span is actually dead, typically I see db22 instead, so I'm not sure what creates that result on the T1 card. > I call USR back, and try to explain to them the info I got from the telco. > Get another "wise" person there to advise the telco to do lbo(Line > build out) on the line. Again, I call telco, and get the response: "Your > vendor does not know what they are talking about because line build out is > performed on the circuit prior to bringing it online and cannot be > performed on it after because that would disturb the service of other > customers. In addition to the fact that if you had problem with lbo, you > wouldn't be able to even get calls coming in." I should point out that your telco is not doing much better here (like that's a big surprise with NYNEX). First off, unless they've got really strange equipment, they should be able to change the LBO on the fly for any individual span without affecting any other span of any other customer. In older gear they might have to flip actual switches, but most modern stuff can handle this remotely (after all you can do it too with the T1 card (the uds1CfgXmitLineBuildOut) in software whenever you want). I suppose somehow you might be sharing a card with a common LBO, but since LBO is primarily for the final leg of the circuit, I'd actually expect it to be set between your demarc (unless it's a dumb demarc) and your equipment. Secondly, while changing the LBO might cause a blip in the circuit, it's not like you were having stellar performance to begin with so who would mind. And there's generally some give, such as if I'm supposed to be running db0 but I boost to db7, you might not even notice it depending on the gear involved. I'm also not sure I agree that the wrong LBO would completely prevent calls. In fact, a marginal LBO could very well accept calls but have the kind of poor connection rates that you were experiencing (so USR wasn't completely off the wall to think of this). > I am not saying this just because I have nothing better to do than to > complain about USR's tech support. But I figured that if I am paying > $2,700 a year for the support of my equipment, I would be paying for > something better than being on hold for an hour and getting completely > incompetent people to deal with my problems. Can't really disagree here. It sounds like at that point (as in any support organization of this type) that the front-line person you were on the line with should have escalated to a supervisor or other similar person to see if progress could be made. Or, on the other side, did you request to speak with a supervisor? That's always something you can try. > On a different note, if any of you have experienced the similar problems, > and would suggest what to check for and how to check for it, or what to > tell telco to check, I would be more than greatful. Just out of curiousity but you said that NYNEX had tested to their smart jack. Did you have them test all the way through to the T1 card? (As long as you've enabled the remote loopback option they should be able to pull it up remotely and run end-to-end tests). You might be looking at a fault in the cable between the demarc and the T1 card, perhaps it's partially grounded or floating and that's confusing one end or the other. At the very least though, I think a reasonable question to 3Com at this point is "under what conditions might I see a value of 'notApplicable' for a receiver gain on a DS1 span of a T1 card?" Someone there ought to be able to come up with that answer (even if they go back into development to get it) and that might also give a hint as to a direction to look at for a cause. -- 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) tcenema script & Investing in TCM
From: Garry Shtern <shterng@akula.com>
Date: 1997-10-22 01:29:37

On Wed, 22 Oct 1997, David Bolen wrote: > I should point out that your telco is not doing much better here (like > that's a big surprise with NYNEX). First off, unless they've got > really strange equipment, they should be able to change the LBO on the > fly for any individual span without affecting any other span of any > other customer. In older gear they might have to flip actual > switches, but most modern stuff can handle this remotely (after all > you can do it too with the T1 card (the uds1CfgXmitLineBuildOut) in > software whenever you want). I suppose somehow you might be sharing a > card with a common LBO, but since LBO is primarily for the final leg > of the circuit, I'd actually expect it to be set between your demarc > (unless it's a dumb demarc) and your equipment. Well here is the issue.. Our telco is not NYNEX, it is MCI. And according to the person who came onsite, they would have to flip the switch to do the lbd test. He also said that our lbd is set to 0 and does not change randomly. > Just out of curiousity but you said that NYNEX had tested to their > smart jack. Did you have them test all the way through to the T1 > card? (As long as you've enabled the remote loopback option they > should be able to pull it up remotely and run end-to-end tests). > > You might be looking at a fault in the cable between the demarc and > the T1 card, perhaps it's partially grounded or floating and that's > confusing one end or the other. That thought also crossed my mind. However, we have 4 T1s and ALL of them are having this problem. We can't have all 4 Cables bad. I also thought about having bad connectivity on the smart jack mux in our suite. However, we have ptp circuit on the same mux which are working flawlessly. > > At the very least though, I think a reasonable question to 3Com at > this point is "under what conditions might I see a value of > 'notApplicable' for a receiver gain on a DS1 span of a T1 card?" > > Someone there ought to be able to come up with that answer (even if > they go back into development to get it) and that might also give a > hint as to a direction to look at for a cause. > I asked them exactly this question. None of the people there were able to answer it for me. Sounds pathetic, doesn't it? -Garry

Subject: Re: (usr-tc) tcenema script & Investing in TCM
From: David Bolen <db3l@ans.net>
Date: 1997-10-22 01:45:57

Garry Shtern <shterng@akula.com> writes: > Well here is the issue.. Our telco is not NYNEX, it is MCI. And according Whoops - sorry - I read NYNEX as your phone company in another paragraph and assumed that was the telco under discussion. > to the person who came onsite, they would have to flip the switch to do > the lbd test. He also said that our lbd is set to 0 and does not change > randomly. That I'll buy (just not the other stuff about affecting other customers and all that :-)) > That thought also crossed my mind. However, we have 4 T1s and ALL of them > are having this problem. We can't have all 4 Cables bad. Actually you'd be surprised - particularly if they were all constructed by the same person/company and/or at the same time. It's a small thing to try changing when out of other ideas :-) But having this happen on all spans (I'm presuming you don't have any "good" ones?) is also a good indication of some sort of configuration problem or mismatch, however subtle. Some sort of general misconfig between the two ends or along the call path. > We can't have all 4 Cables bad. I also thought > about having bad connectivity on the smart jack mux in our suite. However, > we have ptp circuit on the same mux which are working flawlessly. Any other indicators that look bad on the spans (incrementing errors, any violations, slips, etc..)? Maybe the notApplicable value shows up while the card is trying to deal with errors. You mentioned you verified configuration with MCI, but even if you aren't seeing specific framing errors, if you're picking up stuff like BPVs when actual user traffic is ongoing, you might try verifying the framing/encoding configuration of your spans _all the way through_ to the switch delivering service (or the local telco if you go through MCI to them to get dialtone). We've had cases where we had, for example, an ESF/B8ZS circuit, but some intermediate segment of the path was actually going through an M13 using AMI (or vice versa). Because the final segment was driven by the local smart jack (which was configured properly) all the basic framing counters looked great. The only time we had problems was during sessions where the data flowing through the intermediate segment got messed up because of the differing one's density requirements of the two encodings. That and the idea of having MCI do an end-to-end test from the closest point of the switch delivering dialtone (presuming they are doing that) out to your gear (which they can remote loop) and stressing it (QRSS, test patterns, etc..) to see if they can discover any pattern sensitivity within the span. > I asked them exactly this question. None of the people there were able to > answer it for me. Sounds pathetic, doesn't it? Don't know what to say to this... only option I can see is request escalation within the support organization. -- 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) tcenema script & Investing in TCM
From: Garry Shtern <shterng@akula.com>
Date: 1997-10-22 02:00:06

On Wed, 22 Oct 1997, David Bolen wrote: > Any other indicators that look bad on the spans (incrementing errors, > any violations, slips, etc..)? Maybe the notApplicable value shows up > while the card is trying to deal with errors. > > You mentioned you verified configuration with MCI, but even if you > aren't seeing specific framing errors, if you're picking up stuff like > BPVs when actual user traffic is ongoing, you might try verifying the > framing/encoding configuration of your spans _all the way through_ to > the switch delivering service (or the local telco if you go through > MCI to them to get dialtone). We've had cases where we had, for > example, an ESF/B8ZS circuit, but some intermediate segment of the > path was actually going through an M13 using AMI (or vice versa). > Because the final segment was driven by the local smart jack (which > was configured properly) all the basic framing counters looked great. > The only time we had problems was during sessions where the data > flowing through the intermediate segment got messed up because of the > differing one's density requirements of the two encodings. Interesting idea.. However, I did perfomance analysis of the spans and all the possible tests there are show 0 for the error count of any sort. I guess that would also indicate tha our cabling is good. Also, 3 out of 4 cables are from the same company. However, the 4th one was made inhouse. And all 4 are having the same errors.. > > That and the idea of having MCI do an end-to-end test from the closest > point of the switch delivering dialtone (presuming they are doing > that) out to your gear (which they can remote loop) and stressing it > (QRSS, test patterns, etc..) to see if they can discover any pattern > sensitivity within the span. Good idea.. I will give MCI a call tomorrow and ask them to do the tests while we enable the loopback on the T1 card. Also, maybe you know, what they did is send 1006 Hz tone on one of the channels and asked me if I can measure it on my end. I did not know what to do. Maybe you know how exactly would I be able to measure something like that.. Thanks a lot. -Garry

Subject: Re: (usr-tc) tcenema script & Investing in TCM
From: David Bolen <db3l@ans.net>
Date: 1997-10-22 02:11:42

Garry Shtern <shterng@akula.com> writes: > Good idea.. I will give MCI a call tomorrow and ask them to do the tests > while we enable the loopback on the T1 card. Also, maybe you know, what > they did is send 1006 Hz tone on one of the channels and asked me if I can > measure it on my end. I did not know what to do. Maybe you know how > exactly would I be able to measure something like that.. Thanks a lot. The quad modems support both receiving and transmitting the 404, 1004 and 2804Hz standard analog test tones (are you sure it was 1006, not 1004?). I'm not going to be able to give you exact specifics in regards to how to do this in TCM (perhaps someone else on the list knows - my ancient recollection seems to recall a Test menu somewhere), but the general procedure at the SNMP level is: * Place the DS0 in question into transparent mode (this is a DS0 level command). * On the modem that maps to that DS0, issue the command "receiveTone". This is a modem level command. * Repeatedly query the objects mdmTfRxFreq and mdmTfRxAmpl objects for the same modem. (These objects are part of the tone table within the modem test function group). * When done, restore the DS0 to the normal operational state by issuing the "restore" DS0 level command for that channel. Those objects will yield the current frequency and amplitude of the signal you are receiving. Obviously it should match what MCI is transmitting and/or any deviation can let you know what is going on along the circuit. You can also generate test tones by: * Place the DS0 in question into transparent mode (this is a DS0 level command). * Set the mdmTfTxFreq and mdmTfTxAmpl objects (they are in the same table as above) for the modem attached to that DS0 to the values you want. The TxFreq object must be one of the above frequences, and the TxAmpl object can from from -40 to 0. * On the same modem issue the modem level "generateTone" command. The modem will continue to generate the tone as long as you let it. * When done, issue the "terminateTest" command to the modem. * Then, restore the DS0 to the normal operational state by issuing the "restore" DS0 level command for that channel. I'm pretty sure TCM had a screen where you could just fill in the parameters, select the span and then perform the function (either monitoring received tones or generating selected tones). -- David

Subject: Re: (usr-tc) tcenema script & Investing in TCM
From: Allen Marsalis <am@shreve.net>
Date: 1997-10-22 04:30:36

At 12:53 AM 10/22/97 -0400, Garry Shtern wrote: >Wow.. you honestly believe that those engineers that are on the (800) >321-8770 queue really know what they are doing? Well let me tell you a >little story I just had with USR. I didn't exactly say that. I've just come to accept the reality of all this. That the engineers seem to see the problem and care about it more than management who is ultimately responsible.. And bitching to engineers, just because they have an open ear, and management doesn't, just isn't right. (but I will give an answering service hell..) I have incredible tech support stories. (as many USR customers do) There was the time I called in at around 11pm and was told that an engineer would call me back.. I waited till about 2am and never received the call, so called them back. The TC "answering service" told me that no techs were on call (didn't answer the page).. After explaining that we purchased a 24/7 support contract and that we must speak with someone (in not such nice terms) she hung up on me!.. In my face! Can't even reach first base.. Stunned (and pissed) I called my sales rep the next day.. to return my equipment.. A level 3 engineer was on the phone and solved my problem in less than 5 minutes.. I hate 3com worse. I called them with a few questions about a brand new superstack switch and was told that I had to pay for a contract.. I explained that we only had the unit for a day and I was told that no phone support is offered with the product. I told the support "screener" that I would simply return the unit to the place of purchase if they couldn't answer a couple of questions. She said go ahead.. So I did.. And purchased a Cisco catalyst.. I'm happy, the reseller is happy, and 3com loses out.. Over a few minutes of time. Such fools.. And don't get me started about queue times and music that makes you want to die. But the Level 3 engineers are good if you can get one in a reasonable length of time.. But usually takes days to bring level 1 up to speed and escallate the problem to level 3.. That's the whole problem.. It's not the customers job to train level 1 guys.. And wait days to get competent help.. We wouldn't have called if it was something simple.. I think a certification program (ala CCE, CNE,..) would be cool to tier support services. Let the dummys talk to dummys and the competent users talk to competent engineers.. I know right off the bat, if brian calls up USR, it's a level 3 problem.. Sure would save alot on USR's phone bill.. >I am not saying this just because I have nothing better to do than to >complain about USR's tech support. But I figured that if I am paying >$2,700 a year for the support of my equipment, I would be paying for >something better than being on hold for an hour and getting completely >incompetent people to deal with my problems. Yeah I kinda would like my money back on that one.. (to put toward another hub ;) Allen

Subject: Re: (usr-tc) tcenema script & Investing in TCM
From: Greg Coffey <greg@coffey.com>
Date: 1997-10-22 07:16:11

>I hate 3com worse. I called them with a few questions about a brand new >superstack switch and was told that I had to pay for a contract.. I explained >that we only had the unit for a day and I was told that no phone support is >offered with the product. I told the support "screener" that I would simply >return the unit to the place of purchase if they couldn't answer a couple >of questions. She said go ahead.. So I did.. And purchased a Cisco >catalyst.. >I'm happy, the reseller is happy, and 3com loses out.. Over a few minutes >of time. Such fools.. I went through the same drill with a switch 1000 with them. It sits unpowered on the bottom shelf here holding up a cheap 24 port hub that merrily does better than the $3000 boat anchor that has no tech support available. The 3com hub seems to give us a lot of latency at times on the network. Anymore, we get our tech support here, I can get an answer here faster than I can get a rep on the line at 3com. Less frustration, and better information. We wanted to offer upgrades for sportster modems to our customers back when we first set up the x2 for their convenience. We went through the USR merry-go-round of people that sent us on to the next department but nobody had any answers. One lady told me that you had to buy from USR and that they weren't available from retailers like moi. I then pointed out their web page which indicated they were available from Best Buy, Compusa and other retailers. She sent me back to my sales rep who indicated they had not a clue on how to handle my request. I don't buy a new chassis every 12 days or every other month for that matter, there are only two of us here in the boonies to figure this out. I don't like paying for tech support under any circumstances but especially for what I'm getting from USR. Our box currently works pretty well, I do have analog lines too for troubled quake subscribers, but I've had to kick open the tech support door too after hours once or twice. I've read postings here for months and watched the quake lag problem go unresolved for all of that time. I think its a serious problem and am amazed at the lack of action/concern at 3com/USR. I know that 3com people at least monitor this forum and we've had tirades similar to this in the past with little noticeable improvement. We, for the most part, seem to be loyal to this technology but I pity anyone that is installing a rack that has no knowedge of this group. Perhaps we can form an association and wield a little more clout that way with our mother organization. I'm OK, you're OK and damn it, we deserve better. >>I am not saying this just because I have nothing better to do than to >>complain about USR's tech support. But I figured that if I am paying >>$2,700 a year for the support of my equipment, I would be paying for >>something better than being on hold for an hour and getting completely >>incompetent people to deal with my problems. > >Yeah I kinda would like my money back on that one.. (to put toward >another hub ;) > >Allen Amen. Thanks, Greg Coffey, CoffeyNet 142 S. Center St. ** $20 local Casper USR x2 56k access ** Casper, WY 82601 Wheatland, Pinedale, Lander, Lusk http://www.coffey.com Douglas & Rawlins (307) 234-5443

Subject: Re: (usr-tc) tcenema script & Investing in TCM
From: Brian <signal@shreve.net>
Date: 1997-10-22 08:19:42

> I am not saying this just because I have nothing better to do than to > complain about USR's tech support. But I figured that if I am paying > $2,700 a year for the support of my equipment, I would be paying for > something better than being on hold for an hour and getting completely > incompetent people to deal with my problems. > > On a different note, if any of you have experienced the similar problems, > and would suggest what to check for and how to check for it, or what to > tell telco to check, I would be more than greatful. > > -Garry > Once again, if anyone has the information about the test you can pass to skip level one usr tc tech support, please forward to the list so we all can be vindicated. Brian > P.s. I did go through all the settings of the T1 card and they do match to > the ones of our telco. > > > > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: Re: (usr-tc) tcenema script & Investing in TCM
From: Laszlo Vecsey <master@internexus.net>
Date: 1997-10-22 10:04:11

On Wed, 22 Oct 1997, David Bolen wrote: > The quad modems support both receiving and transmitting the 404, 1004 > and 2804Hz standard analog test tones (are you sure it was 1006, not 1004?). Hmm, it would be kind of interesting if a custom tone could be transmitted, or wav audio could be sent out :) What would be involved with creating your own custom quad code, netserver code, etc, to run on the usr-tc? Is there any information available on this? I imagine a day when the complete source to running and maintaining usr-tc hardware is available under GNU.. from the lack of USRobotic support we've all seen, a project like this might actually be successful! ;) - lv

Subject: Re: (usr-tc) tcenema script & Investing in TCM
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1997-10-22 10:33:18

Thus spake Russ Panula >1. Simple network setup: 1 Enterprise Hub, 1 Portmaster PM 2E-30, 1 >NetQuake server, 1 remote client, 1 ethernet segment, 1 can or bottle >of favorite beverage. >2. Dial remote client into PM 2E-30. Connect to Quake server. Record >average in-game ping times using the Quake console command 'ping' over >a period of 10 minutes. >3. Dial remote client into Enterprise Hub. Connect to Quake server. >Record average in-game ping times using the Quake console command >'ping' over a period of 10 minutes. >4. Compare results. Drink beverage. Rinse. Repeat. >Is this not simple stuff? Surely 3Com must have thought of this. Doesn't work here. We only get Quake Lag occasionally...but certainly not all the time (at least from what I've been told by our Quake players) >Is the reproducibility of this problem really in question here? Apparently, yes. >When >you play Quake through your NETserver's, are you not lagged? Yes? >No? Maybe so? Not always here apparently (not a Quake player myself, but the two that I've talked to about it say it doesn't always happen) >Just agreeing with Allen on the Quake issue. Yes, it _still_ is an >issue. I agree...and apparently, so does Tatai (at the very least...I would guess Michael Wronski (sp?) does as well) However, I guess I just don't see it as the earth shattering problem that you all do...that's would be more reflecting the very limited number of customers we've had complain about it I guess though. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) USRobotics support, Quakelag, and Investing in TCM
From: Laszlo Vecsey <master@internexus.net>
Date: 1997-10-22 10:42:01

On Wed, 22 Oct 1997, Jeff Mcadams wrote: > >4. Compare results. Drink beverage. Rinse. Repeat. > > >Is this not simple stuff? Surely 3Com must have thought of this. > > Doesn't work here. We only get Quake Lag occasionally...but certainly > not all the time (at least from what I've been told by our Quake > players) AFAIK the quake lag only shows up when the usr-tc reaches a certain amount of users/activity. Maybe USRobotics is checking for quakelag on an empty usr-tc (dialing up with just one or two modems) instead of a realisticly loaded system? - lv

Subject: Re: (usr-tc) tcenema script & Investing in TCM
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1997-10-22 10:45:20

Thus spake Allen Marsalis >The lag is not mysterious or a problem to replicate.. I'll be happy >risking prosecusion to provide an engineer with a bootleg copy of >quake and a free account on our system.. Or call for some passwords >and an engineer can "see" it in realtime. We are replicating the problem >daily 24/7... week after week, month after month.... What do you want >to know? I'm not sure what they're working on with it. I know I got an email from Tatai asking me to see what I could do to make the problem reproducible on demand...to that point, I haven't been successful with it...perhaps you have some ideas on what configuration is needed to make it reproducible for them then...I don't. >Play Quake... It's not intermittent.. At least not with the lastest >two or three code versions.. According to my two Quake players it is...maybe different code versions are part of the puzzle then. *shrug* >more B.S... I'm sorry, but I am "nothing but available".. Perhaps >we could get a call back on a ticket that is months old... If USR >needs more info, then ask.. We can't read minds... We'll be happy >to help anyway we can.. But no requests have been made. From a previous message to usr-tc in reply to Brian Feeny dated Sep. 29th...I don't recall seeing any significant responses: Brian, We have been working hard to find a solution to this quake problem. We have seen this problem in our lab. We cannot succesfully reproduce this problem as and when needed. Please let me know how we can reproduce the problem, time and time again. Any help from you is greatly appriciated. krish >I get the idea. How do we know that they have spent (needed) months trying >to fix it.. Heck they can't even replicate it.. Neither can I. >I've spent $100K with USR this year alone. Don't want to start this into a pissing match, but we just put in a single order for about that much equipment...that figure doesn't particularly impress me. >Sorry for venting but it's more productive than exploding.. I can understand that... :) I sometimes feel sorry for my fiance' who I tend to vent to...however I get the reciprocal from her too, so I guess that's fair. :) >We can't fix >the problem for them.. They must put forth effort also.. And after months >of waiting, I appreciate everyones posts which I find informative if not >productive.. Thanks. I agree that they need to put forth the effort, but from what I've seen, they are, but are being held up by not being able to reproduce the problem when they need to. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) USRobotics support, Quakelag, and Investing in TCM
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1997-10-22 10:49:00

Thus spake Laszlo Vecsey >On Wed, 22 Oct 1997, Jeff Mcadams wrote: >> >4. Compare results. Drink beverage. Rinse. Repeat. >> >> >Is this not simple stuff? Surely 3Com must have thought of this. >> >> Doesn't work here. We only get Quake Lag occasionally...but certainly >> not all the time (at least from what I've been told by our Quake >> players) >AFAIK the quake lag only shows up when the usr-tc reaches a certain amount >of users/activity. That has been my understanding all along, and I believe at the very least Tatai was aware of that. Incidentally, we don't get it consistently, and our hubs are in a first available hunt group, so the first 4 hubs are almost always completely full...yet we don't consistently see it...must be some other piece of the puzzle. >Maybe USRobotics is checking for quakelag on an empty >usr-tc (dialing up with just one or two modems) instead of a realisticly >loaded system? I got the impression that they loaded them down rather heavily, but I don't know that it was ever explicitely stated that they were. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) Quake lag
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-22 11:47:25

Has anyone who is experiencing the Quake lag problem tried the workarounds that I posted to the list a month or so ago? Reducing retrains and berrs to zero really helps. We have a FAQ up at: http://www.xmission.com:80/help/faqs/quake_modems.html

Subject: Re: (usr-tc) tcenema script & Investing in TCM
From: Garry Shtern <shterng@akula.com>
Date: 1997-10-22 12:54:40

At 04:30 AM 10/22/97 -0500, Allen Marsalis wrote: >At 12:53 AM 10/22/97 -0400, Garry Shtern wrote: > >>Wow.. you honestly believe that those engineers that are on the (800) >>321-8770 queue really know what they are doing? Well let me tell you a >>little story I just had with USR. > >I didn't exactly say that. I've just come to accept the reality of all >this. That the engineers seem to see the problem and care about it more >than management who is ultimately responsible.. And bitching to engineers, >just because they have an open ear, and management doesn't, just isn't >right. (but I will give an answering service hell..) > Yeah well.. I wish I could say the same. However, the biggest problem I had, was the fact that the 1st level tech. support guys don't know anything and you can not get them to transfer you to anyone higher. Garry Shtern shterng@akula.com Chief Network Administrator http://www.akula.com Akula Communications Corp. tel. (212) 292-8892

Subject: Re: (usr-tc) tcenema script & Investing in TCM
From: David Bolen <db3l@ans.net>
Date: 1997-10-22 13:19:25

Laszlo Vecsey <master@internexus.net> writes: > Hmm, it would be kind of interesting if a custom tone could be > transmitted, or wav audio could be sent out :) I'm not absolutely sure what happens if you try to set frequencies other than the three primary test frequencies - it might work. Wav's are probably out though :-) > What would be involved with creating your own custom quad code, netserver > code, etc, to run on the usr-tc? Is there any information available on > this? I doubt stuff like that would ever be generally available. It's kind of like asking 3Com to produce a development environment so you can rebuild your code for your external Courier (it's flashable, so why not?) :-) Originally, there was an "API card" product offered (same card as the original NETServer) along with some libraries (VRTx (sp?) OS, packet bus interface) and you could write your own code for the card. Of course, if you wanted it to do something like the NETServer, you'd have to implement or purchase an IP stack and build everything from the ground up. I haven't heard anything along these lines for a long time, so I have a feeling that this card was dropped as far as a generally available product. -- 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) Quake lag
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1997-10-22 13:56:28

Thus spake Pete Ashdown >Has anyone who is experiencing the Quake lag problem tried the workarounds >that I posted to the list a month or so ago? Reducing retrains and berrs >to zero really helps. We have a FAQ up at: > http://www.xmission.com:80/help/faqs/quake_modems.html I've given the suggestions that were posted on the list to my two Quake'ers that have mentioned lag to check out...haven't heard much of anything from either of them about it...not sure what that means. Neither of them were really complaining about it, but mentioned the slowdown so I took the opportunity to have them do some testing for me. I'll see what I can get from them. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) tcenema script & Investing in TCM
From: Allen Marsalis <am@shreve.net>
Date: 1997-10-22 15:01:07

At 10:45 AM 10/22/97 -0400, Jeff wrote: >I'm not sure what they're working on with it. I know I got an email >from Tatai asking me to see what I could do to make the problem >reproducible on demand...to that point, I haven't been successful with >it...perhaps you have some ideas on what configuration is needed to make >it reproducible for them then...I don't. The problem might be best reproduced under an environment typical of an ISP.. That is, at least a moderate load on the hub and at least 5 or 6 players on the quake server.. We rarely have less than that many simultaneous players cause it is not much fun to play by yourself or "one on one".. It would be a mistake to try and replicate this problem with an empty hub and only 1 or 2 players IMO.. This does not represent the typical environment out in the field.. We have also noticed that the lag might also relate to outgoing (upload) connect speeds from the client as quake is more bandwidth intensive in one direction. But even with a good connection, the problem usually occurs within ten minutes of play.. It drifts in and out.. One minute it's playable, and the next, it's not.. The best way to quantify the problem is with the quake "ping".. If you play long enough, it will happen.. It's not intermittant between users, everyone experiences it, but I guess it is sort of intermittent within a play session.. We have tried all sorts of things to remedy the situation such as disabling x2, compression, EC, etc. on the client side. These do affect play but seem totally independant of "big lag" problem where it just fades away with pings upward of 1000-2000... This always seems to happen sooner or later under any modem configuration.. >>Play Quake... It's not intermittent.. At least not with the lastest >>two or three code versions.. > >According to my two Quake players it is...maybe different code versions >are part of the puzzle then. *shrug* We have kept current with code revisions and have always had the problem so I really can't say much.. >>From a previous message to usr-tc in reply to Brian Feeny dated Sep. >29th...I don't recall seeing any significant responses: > > Brian, > > We have been working hard to find a solution to this quake problem. We > have seen this problem in our lab. We cannot succesfully reproduce this > problem as and when needed. Please let me know how we can reproduce the > problem, time and time again. Any help from you is greatly appriciated. > > krish (blush) I was not aware of this email correspondence. I do know that USR called us by phone and asked brian some questions.. And we haven't heard anything since.. It's much easier to contact us than it is to wait in the queue at USR.. I really do want to help in anyway I can. It seems that they could just telnet or console into our hub and see exactly what's happening.. Am I wrong? >>I get the idea. How do we know that they have spent (needed) months trying >>to fix it.. Heck they can't even replicate it.. > >Neither can I. I really can't see how there is a problem observing this "bug".. If you can't replicate it under typical circumstances, I am at a loss.. I can only offer to show you our setup.. I'll even pay for the phone call.. Spending months "chasing ghosts" happens every now and then. I don't see this problem as a "ghost". It's more like a brick that hits everyone sooner or later.. >>I've spent $100K with USR this year alone. > >Don't want to start this into a pissing match, but we just put in a >single order for about that much equipment...that figure doesn't >particularly impress me. I'm was not trying to impress anyone (and I can't piss far like I used to). I was just stating that they won't loose there ass trying to fix this problem (like I will) and the profits from one customer might pay for the whole thing.. They can afford to fix this.. >>Sorry for venting but it's more productive than exploding.. > >I can understand that... :) I sometimes feel sorry for my fiance' who >I tend to vent to...however I get the reciprocal from her too, so I >guess that's fair. :) I wonder about those couples who never argue.. Need some friction to keep things lively.. >>We can't fix >>the problem for them.. They must put forth effort also.. And after months >>of waiting, I appreciate everyones posts which I find informative if not >>productive.. Thanks. > >I agree that they need to put forth the effort, but from what I've seen, >they are, but are being held up by not being able to reproduce the >problem when they need to. If there is anything we can do to help, or provide a known site exhibiting the problem, please let brian or I know. We are available, easily reached, and will give considerable attention to anyone willing to fix this problem.. But please hurry before I'm tempted to go purchase a portmaster as our next hub.. BTW, Micheal Wronski sent me an email saying that the new super-dupper Netserver does not exhibit the problem.. But it's not out yet. This seems like an expensive solution for a problem that should have never existed but it is good to know that there is more than one hope at solving this problem.. Allen

Subject: Re: (usr-tc) USRobotics support, Quakelag, and Investing in TCM
From: Rick Payne <rickp@corp.netcom.net.uk>
Date: 1997-10-22 15:59:35

>>>>> "Jeff" == Jeff Mcadams <jeffm@iglou.com> writes: Jeff> available hunt group, so the first 4 hubs are almost always Jeff> completely full...yet we don't consistently see it...must be Jeff> some other piece of the puzzle. I believe the Quake frame rate has quite a bit to do with it as well. Rick -- Rick Payne, Senior Network Admin | Meddle not in the affairs of NETCOM Internet Ltd. | dragons - for you are crunchy & rickp@corp.netcom.net.uk | taste great dipped in chocolate.

Subject: Re: (usr-tc) tcenema script & Investing in TCM
From: Laszlo Vecsey <master@internexus.net>
Date: 1997-10-22 17:24:22

On Wed, 22 Oct 1997, Allen Marsalis wrote: > BTW, Micheal Wronski sent me an email saying that the new super-dupper > Netserver does not exhibit the problem.. But it's not out yet. This seems > like an expensive solution for a problem that should have never existed but > it is good to know that there is more than one hope at solving this > problem.. Hmm... might this suggest that they _can't_ fix the quakelag problem with the current netservers, because of hardware issues? I sure hope not.. - lv

Subject: Re: (usr-tc) tcenema script & Investing in TCM
From: eric@dol.net
Date: 1997-10-22 20:11:56

We run a quake server that has anywhere from 10 to 20+ every night. My customer who manages it said that after i ugraded the modem to the latest code 5.6.7 that it improved the lag and it works fine. They dial in via total control systems as well as pm3s with flex. Eric > >The problem might be best reproduced under an environment typical of >an ISP.. That is, at least a moderate load on the hub and at least >5 or 6 players on the quake server.. We rarely have less than that >many simultaneous players cause it is not much fun to play by yourself >or "one on one".. It would be a mistake to try and replicate this >problem with an empty hub and only 1 or 2 players IMO.. This does not >represent the typical environment out in the field.. > Delaware Online!.........The SMART Choice! With 56K X2 Modems Phone : 302-762-0375 Fax: 302-762-3462 WWW: www.dol.net Eight out of five people have a problem understanding statistics! ****************Customer support is our bottom line!*********************

Subject: Re: (usr-tc) USRobotics support, Quakelag, and Investing in TCM
From: Allen Marsalis <am@shreve.net>
Date: 1997-10-22 21:31:20

At 05:00 AM 10/23/97 +1100, yall wrote: > >> AFAIK the quake lag only shows up when the usr-tc reaches a certain >> amount of users/activity. Maybe USRobotics is checking for quakelag on >> an empty usr-tc (dialing up with just one or two modems) instead of a >> realisticly loaded system? > >As per previous post - problems are rare here. Two chassis - one analogue >with 56 modems, one PRI with some analogue (44 modems). Most quake is >played during peak times (most ports active). > >Regards, > >Bob Purdon, >Southern Internet. > I wonder if the problem occurs with analog modems _and_ digital modems, (we have no analog lines). All other analog equipment i've seen works fine with quake. It seems that if the problem is in the Netserver, it really wouldn't matter if you were trunking analog or digital.. But then again if it's netserver related, why doesn't ISDN lag?... Allen

Subject: Re: (usr-tc) tcenema script & Investing in TCM
From: Allen Marsalis <am@shreve.net>
Date: 1997-10-22 21:43:45

At 05:24 PM 10/22/97 -0400, you wrote: >On Wed, 22 Oct 1997, Allen Marsalis wrote: > >> BTW, Micheal Wronski sent me an email saying that the new super-dupper >> Netserver does not exhibit the problem.. But it's not out yet. This seems >> like an expensive solution for a problem that should have never existed but >> it is good to know that there is more than one hope at solving this >> problem.. > >Hmm... might this suggest that they _can't_ fix the quakelag problem with >the current netservers, because of hardware issues? I sure hope not.. > >- lv > > Uh.. Now that I think about it.. if they cant replicate the problem with the old netserver card, how do they know for certain that there is no problem with the new card.. Think about it.. Allen

Subject: Re: (usr-tc) Quake lag
From: Allen Marsalis <am@shreve.net>
Date: 1997-10-23 01:07:24

At 11:47 AM 10/22/97 -0600, Pete Ashdown wrote: >Has anyone who is experiencing the Quake lag problem tried the workarounds >that I posted to the list a month or so ago? Reducing retrains and berrs >to zero really helps. We have a FAQ up at: > > http://www.xmission.com:80/help/faqs/quake_modems.html > One technician wrote me: > >... I tried it all, it helps a little, >its mostly just turning off error correction and stuff, but above all he >recommends Quake World, this is all fine and dandy but: > >Quake does not lag on Portmasters, it does not lag on terminal servers >with individual modems. you can compensate for the udp latency of the >netserver a little using no ec and no compression etc, but that doesnt >stop the true problem. its also a major pain to explain to users how to >turn off these settings in there modems, many modems use different >settings, and then save to non volitile memory. > >I am just banking on the newest software fixing it........i hope it >does.......lag hasnt been to bad lately but its definitly not gone. > Another wrote: > >I went to that page and tried what they suggested. at&n18&u28 which forces >the modem to connect no lower then 28.8 but no higher then 33.3 which is >what I connected at. Same problem. Ping was into 1200 or so. But when I >was dead, which was often :), the ping was around 160 or so...... > I'm wonder what the differences are in our configuration verses the folks who seem to be able to fix the problem.. Allen _________________________________________________________________ Allen Marsalis President, Shrevenet, Inc. Thoughtful Provider of Internet Services 333 Texas St. Suite 619 Shreveport, LA 71101 Ph. 318.222.2NET (2638) FAX: 318.221.6612 mailto:am@shreve.net http://www.shreve.net

Subject: Re: (usr-tc) Quake lag
From: David Carter <david@corp.netcom.net.uk>
Date: 1997-10-23 02:12:05

Dear Pete, > Has anyone who is experiencing the Quake lag problem tried the workarounds > that I posted to the list a month or so ago? I picked up a new tip there - fixed rate connections &N which has helped some of our Quakers. AFAIAC there is no "quake lag" problem - it is now fixable at the client end. Many of our users are enjoying lag-free play. I rarely see anything above 200 (mostly 160) running squake on Redhat 4.1, dialling in @ X2 (important to run irqtune). My line is about 8dB higher in attentuation than the ideal and I see BLERs are retrains, so I'm not seeing the best results. One chap is still complaining about PODs, but he does run OpenGL. Cheers, -- David Carter, 2nd Level Support, NETCOM Internet. david@corp.netcom.net.uk God promises a safe landing, but not a calm passage. Bulgarian Proverb

Subject: Re: (usr-tc) tcenema script & Investing in TCM
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-10-23 03:47:06

Send me a detailed email on your problem, with your phone number so that I can conatact you. I am currently out of station. I will check my email and get back to you latest by the end of this week. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Tue, 21 Oct 1997, Jeff Mcadams wrote: > Thus spake Russ Panula > >On Tue, 21 Oct 1997 11:02:20 -0500, Allen Marsalis <am@shreve.net> > >wrote: > >>First off, we have hosted a quake server for months now. We introduce our > >>users to quake then they quit us, only to signup with a competitor and play > >>quake on our server.. This is because quake is nearly unplayable through > >>a TC hub.. I can't really blame them.. USR was informed of the problem > >>months ago and even called our unix admin (brian feeny) for some details. > >>It seems like a simple enough fix but nothing appears to have been done > >>about it.. Does USR plan to address the problem anytime soon? > > >Hear, hear. 6 months should be more than long enough to fix this bug. > > So, please tell Tatai what exactly the problem is with the code and how > to reproduce it on demand. I certainly haven't been able to give him a > reliable way to reproduce it, but then again, I've only had two > customers talk to me about Quake Lag. > > My beef here is that you folks are familiar with how difficult things > can be to troubleshoot (at least I assume you are, I believe most of you > are since most of the list is composed of folks that work for ISP's). > So far, I haven't seen *anyone* give any solid feedback on Tatai's > request for how to *reliably* reproduce the problem. > > I'm sorry, but > 1) if you can't help them pinpoint the problem then I don't see where > you have a big right to complain about how long they're taking to fix > it...if you want them to fix it faster, give them some substantial help > 2) if you don't know specifically what the problem is (apparently, > since you haven't been able to tell them how to reliably reproduce it), > then how do you know that 6 months is enough time to fix the bug? I > would think that if the problem were a known problem then fixing it > wouldn't take long, yes, but 99% of debugging something is finding out > exactly what is causing the problem. Once you find out what's causing > the problem the fix is usually quite easy...you all should know that > (the 99% is picked out of air, but you get the idea). > > >Heck, they can't fix a simple UDP bug in 6 months and you expect them > >to port TCM to another platform? ROFLMAO > > And these two things are related, how? > > >Here's another issue to consider: NO EMAIL SUPPORT. > > >Sure, you've got this _public_ list, but just try sending a question > >to support@usr.com ... This gets my goose all the time. How can a > >company with a presence on the Internet that provides goods and > >services to other individuals on the Internet *not* provide email > >support for their flagship product? Seems logical enough to me. > > Indeed, this is a reasonable request, IMHO, but I'm not sure its quite > fair to beat up USR on it since I've never seen a request for > it...personally I wouldn't make much use of it, but I can see where some > certainly would. > > >If it's not obvious yet, I've had a very trying day with my hubs. My > >apologies to those offended. > > I'm not offended, and I can certainly understand how you could have a > trying day with your hubs...I've had a few of my own, but I don't think > your post was in any way productive, so I guess I just don't see the > point of it. > -- > Jeff McAdams Email: jeffm@iglou.com > Chief Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 >

Subject: Re: (usr-tc) tcenema script & Investing in TCM
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-10-23 03:56:34

I am not sure of any such test, I do know that USR has a certification program., I will get information from our training department about this and post it. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Wed, 22 Oct 1997, Brian wrote: > > I am not saying this just because I have nothing better to do than to > > complain about USR's tech support. But I figured that if I am paying > > $2,700 a year for the support of my equipment, I would be paying for > > something better than being on hold for an hour and getting completely > > incompetent people to deal with my problems. > > > > On a different note, if any of you have experienced the similar problems, > > and would suggest what to check for and how to check for it, or what to > > tell telco to check, I would be more than greatful. > > > > -Garry > > > > > Once again, if anyone has the information about the test you can pass to > skip level one usr tc tech support, please forward to the list so we all > can be vindicated. > > Brian > > > > > P.s. I did go through all the settings of the T1 card and they do match to > > the ones of our telco. > > > > > > > > > > /-------------------------- signal@shreve.net -----------------------------\ > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > | Systems Administrator | Perl, Linux | Web hosting, online stores, | > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | > | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | > \-------------------------- 318-222-2638 x109 -----------------------------/ > > >

Subject: Re: (usr-tc) tcenema script & Investing in TCM
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-10-23 04:03:26

Quake is still a problem, We have some specific changes to our drivers in the next release of code 3.6.x which does address this problem. Agreed when you dial to a pm3 you do not see tany latency but you do see latency if you dial to a NETServer or a accend . At this point we are not ignoring the problem, we did some changes and we have certain customers who are working with us on this issue. If you can help us test this new code, please send me a email, I will reply back to you only on Monday ( latest). krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Wed, 22 Oct 1997, Jeff Mcadams wrote: > Thus spake Russ Panula > >1. Simple network setup: 1 Enterprise Hub, 1 Portmaster PM 2E-30, 1 > >NetQuake server, 1 remote client, 1 ethernet segment, 1 can or bottle > >of favorite beverage. > > >2. Dial remote client into PM 2E-30. Connect to Quake server. Record > >average in-game ping times using the Quake console command 'ping' over > >a period of 10 minutes. > > >3. Dial remote client into Enterprise Hub. Connect to Quake server. > >Record average in-game ping times using the Quake console command > >'ping' over a period of 10 minutes. > > >4. Compare results. Drink beverage. Rinse. Repeat. > > >Is this not simple stuff? Surely 3Com must have thought of this. > > Doesn't work here. We only get Quake Lag occasionally...but certainly > not all the time (at least from what I've been told by our Quake > players) > > >Is the reproducibility of this problem really in question here? > > Apparently, yes. > > >When > >you play Quake through your NETserver's, are you not lagged? Yes? > >No? Maybe so? > > Not always here apparently (not a Quake player myself, but the two that > I've talked to about it say it doesn't always happen) > > >Just agreeing with Allen on the Quake issue. Yes, it _still_ is an > >issue. > > I agree...and apparently, so does Tatai (at the very least...I would > guess Michael Wronski (sp?) does as well) However, I guess I just don't > see it as the earth shattering problem that you all do...that's would be > more reflecting the very limited number of customers we've had complain > about it I guess though. > -- > Jeff McAdams Email: jeffm@iglou.com > Chief Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 >

Subject: Re: (usr-tc) USRobotics support, Quakelag, and Investing in TCM
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-10-23 04:04:14

No we are testing the quake lag with lot of calls on the chassis, we do generate a number of calls and test the same/ krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Wed, 22 Oct 1997, Laszlo Vecsey wrote: > On Wed, 22 Oct 1997, Jeff Mcadams wrote: > > > >4. Compare results. Drink beverage. Rinse. Repeat. > > > > >Is this not simple stuff? Surely 3Com must have thought of this. > > > > Doesn't work here. We only get Quake Lag occasionally...but certainly > > not all the time (at least from what I've been told by our Quake > > players) > > AFAIK the quake lag only shows up when the usr-tc reaches a certain amount > of users/activity. Maybe USRobotics is checking for quakelag on an empty > usr-tc (dialing up with just one or two modems) instead of a realisticly > loaded system? > > - lv > >

Subject: Re: (usr-tc) tcenema script & Investing in TCM
From: Bob Purdon <bobp@southcom.com.au>
Date: 1997-10-23 04:58:47

> Not always here apparently (not a Quake player myself, but the two that > I've talked to about it say it doesn't always happen) Ditto here. We run Quakeworld, and our players rarely complain of any lag. When they do, we reboot the server Quake sits on and it goes along merrily for another week or so. Many of our players are X2 users. Quake may be a different beast entirely of course... Regards, Bob Purdon, Southern Internet.

Subject: Re: (usr-tc) USRobotics support, Quakelag, and Investing in TCM
From: Bob Purdon <bobp@southcom.com.au>
Date: 1997-10-23 05:00:17

> AFAIK the quake lag only shows up when the usr-tc reaches a certain > amount of users/activity. Maybe USRobotics is checking for quakelag on > an empty usr-tc (dialing up with just one or two modems) instead of a > realisticly loaded system? As per previous post - problems are rare here. Two chassis - one analogue with 56 modems, one PRI with some analogue (44 modems). Most quake is played during peak times (most ports active). Regards, Bob Purdon, Southern Internet.

Subject: (usr-tc) Radius
From: Terry Kennedy <terry@olypen.com>
Date: 1997-10-23 08:28:42

Anyone know of a good version of RADIUS besides Merrit product that will compile on SCO ?

Subject: Re: (usr-tc) tcenema script & Investing in TCM
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1997-10-23 08:39:50

Thus spake Allen Marsalis >At 05:24 PM 10/22/97 -0400, you wrote: >>On Wed, 22 Oct 1997, Allen Marsalis wrote: >>> BTW, Micheal Wronski sent me an email saying that the new super-dupper >>> Netserver does not exhibit the problem.. But it's not out yet. This seems >>> like an expensive solution for a problem that should have never existed but >>> it is good to know that there is more than one hope at solving this >>> problem.. >>Hmm... might this suggest that they _can't_ fix the quakelag problem with >>the current netservers, because of hardware issues? I sure hope not.. >Uh.. Now that I think about it.. if they cant replicate the problem with >the old netserver card, how do they know for certain that there is no >problem with the new card.. Think about it.. They can't *reliably* replicate it, they can't replicate it on demand, they have and do see it in their setup, just can't get it to do it always when they need it. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Quake lag
From: Brian Elfert <brian@citilink.com>
Date: 1997-10-23 09:48:48

On Wed, 22 Oct 1997, Allen Marsalis wrote: > >Hmm... might this suggest that they _can't_ fix the quakelag problem with > >the current netservers, because of hardware issues? I sure hope not.. > > Uh.. Now that I think about it.. if they cant replicate the problem with > the old netserver card, how do they know for certain that there is no > problem with the new card.. Think about it.. I thought one of the messages said that they have seen the problem, but they can't recreate it on demand, so it's fairly hard to fix. It could be that they've never seen the problem even once with the new router card. Brian

Subject: Re: (usr-tc) Investing in TCM
From: Kamil Kukura <kamil@nw3.unicom.cz>
Date: 1997-10-23 10:59:37

By David Bolen: > From BSDI's viewpoint, it's just like asking will BSD/OS run on my > Dell PC, or will it support this ethernet card. If BSD/OS has the > right driver, or they've tested it on the platform, the answer will be > yes, but actually installing and running it is going to be up to you. > > From USR's viewpoint, they've essentially built a 486-PC in a form > factor for a chassis. They have a preferred, locally sold/maintained > platform (WinNT), but have validated that BSD/OS will operate on it, > so if a customer wants to do so they can install it. In such a case, > however, you're effectively buying a USR 486 PC, and then installing > BSDI on it, so USR might not address BSD/OS specific OS questions. I thought USR has managed to built packet bus drivers for BSDI. I expect I can have somemore 60 /dev/tty devices mapped to the modem ports. Otherwise, my booksize 486 still fits well in rack's shelf right under the chassis. Kamil Kukura U N I C O M (authorized distributor of U.S.Robotics) Usti nad Labem, Czech Republic

Subject: Re: (usr-tc) USRobotics support, Quakelag, and Investing in TCM
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-23 11:08:20

Bob Purdon said once upon a time: >Interestingly, I remember seeing someone mention a while back that the >only platform they've used that *doesn't* suffer "Quake Lag" was the >Xylogics Annex boxes - their PM's, TC's, Cisco's, etc all exhibited the >problem. I can't find a reference to it now though :-( I mentioned that our Xylogics boxes don't have the problem. We only have Xylogics and TC's.

Subject: Re: (usr-tc) Investing in TCM
From: Kamil Kukura <kamil@nw3.unicom.cz>
Date: 1997-10-23 11:12:29

By Pete Ashdown [stuff about crapy 3com support] > > > After this experience, I have a hard time imagining that Krish is working > for the same company. > > A suggestion to 3Com/USR: Setup an email box that people can submit > problems to. Go one step further and put a ticketing system on the box. > We do have email support and ticketing here in europe: euronetsys@usr.com However, the other side is still human being and sometimes human thinking. Our customer was up to sending us to hell as Netserver was sending radius accounting packets with missing Authenticator field (i.e. no authentication). I was given answers from euro-support like "are you using USR accnt server?", "when did you buy chassis?", etc. Finally, the problem has been solved in 3.5.34 code, even though I learned that months later as it's left up to "acct_authchk" switch, which is off by default. (no matter radius's RFC says the packet MUST have authenticator). Kamil Kukura U N I C O M (authorized distributor of U.S.Robotics) Usti nad Labem, Czech Republic

Subject: Re: (usr-tc) Disconnect causes
From: Curt Shambeau <curt@execpc.com>
Date: 1997-10-23 12:14:15

> > We are seeing a bunch of dropped calls recently. They are trapped as > "ReTransmitLimit", a few unknowns, and "DS0Teardowns". It seems that the > higher the call is on the TDM channel the larger chance it will be dropped. > I can find the list of events but no descrition or truth tables of thier > causes. The only one I find obvious are the ModemDiscCmd type's > > Our chassis was purchased as a PRI ready but came with the T1 code that we > flash upgraded. I have heard that the PRI card is shipped with more memory. > Could this be part of the problem? And what type and size of memories--both > flash and RAM--SHOULD be on a a unit with 2-Pri Spans 46 modems. (Though > only 1/23 are in use now) It is most likely a bad T1 - I'd have the phone company monitor it when there is a load in it. I've had some T1's that work fine with 5-10 people on it, but as soon as it starts hitting the end, it falls apart. Most of the time it was a bad repeater along the way. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Exec-PC Vice President, Information Services |

Subject: Re: (usr-tc) USRobotics support, Quakelag, and Investing in TCM
From: Brian <signal@shreve.net>
Date: 1997-10-23 13:03:38

On Thu, 23 Oct 1997, Bob Purdon wrote: > > > I wonder if the problem occurs with analog modems _and_ digital modems, > > (we have no analog lines). All other analog equipment i've seen works > > fine with quake. It seems that if the problem is in the Netserver, it > > really wouldn't matter if you were trunking analog or digital.. > > All of our lines (in this context) are served by NETServers, running > 3.5.33. > > > But then again if it's netserver related, why doesn't ISDN lag?... > > Is that the case, or is it just that too few people use ISDN to have > noticed? it does lag isdn.......................... > > Interestingly, I remember seeing someone mention a while back that the > only platform they've used that *doesn't* suffer "Quake Lag" was the > Xylogics Annex boxes - their PM's, TC's, Cisco's, etc all exhibited the > problem. I can't find a reference to it now though :-( Most people with portmasters I know havent seen the problem. Also I didn't see the problem with a Cyclades YeP-16 and a bunch of sportster 28.8k's hanging off it. Brian > > Regards, > > Bob Purdon, > Southern Internet. > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: Re: (usr-tc) Disconnect causes
From: TSpaulding <tsplding@talweb.com>
Date: 1997-10-23 13:10:52

This is what I was given by a USR/3COM tech ***************** Here are some of the common disconnect reasons, starting with the one you described: ds0Teardown(37) _ 'Call Teardown' The T1 or PRI Card initiated the disconnect. This usually occurs because the remote modem has hung up: the central office signals to the T1 or PRI card when there is a disconnect at the other end of a call. This reason only applies to T1 or PRI calls, not to POTS calls. This reason is a catch-all on T1 and PRI calls. It can mean the remote modem went on hook abruptly without sending a V.42 Disc, MNP LD, or GSTN Cleardown. Even if the remote modem sends these before going on-hook, there is a race condition over whether it will be received locally before the ds0Teardown is received. As a failure to connect reason, this could mean that a non-modem call was received. v42DisconnectCmd(26) _ 'DISC Received' The remote modem sent a V.42 error control Disconnect request. This is a normal disconnect procedure under V.42 error control when the remote modem is the initiator of the disconnect. This would occur if the user or application sent +++, ATH, or dropped DTR on the remote modem. escapeSequence(2) _ 'Escape code' The user or application software sent the modem the +++ escape code (or other character as set in S2) and the modem was configured to disconnect the call on reception of the escape code (see Dipswitch9 operation). This is affected by S2, the escape code character; S12, the escape code guard time; and by Dipswitch9 (S14.0), escape to online command mode or disconnect. TCM has a third option of disabling +++ detection, which is equivalent to setting S2 greater than 127. athCommand(3) _ 'ATH0 Command' The user or application software sent the modem the ATH (or ATH0) command while the modem was in online command mode. carrierLoss(4) _ 'Loss of Carrier' The modem detected loss of the remote modem's carrier and waited the duration specified in Register S10 (default is 0.7 seconds). Note to tech support: For higher speed modulations, carrier loss detection is disabled when other recovery mechanisms are being used such as retraining. It should be rare to see this as a disconnect or fail to connect reason since other reasons will usually be used or will be detected sooner. inactivityTimout(5) _ 'Inactivity Timeout' The modem detected no activity (characters being sent or received) for the duration specified in Register S19 (default is 0, timer disabled). noDialTone(16) _ 'No Dialtone' The modem was set for X2,4,6, or 7 and the modem was not able to detect Dial Tone from the central office before dialling, or after the 'W', wait for 2nd dial tone, dial modifier. keyAbort(17) _ 'Keypress Abort' The modem detected a keypress while training. lineBusy(18) _ 'Busy' The modem detected busy tone because the number dialled was busy. noAnswer(19) _ 'No Answer' The modem was dialling with the '@' dial modifier, and did not detect an answer. An answer is defined as 1 or more RINGs followed by 5 or more seconds of silence. voice(20) _ 'Voice' This value is not used. noAnswerTone(21) This value is not used. noCarrier(22) _ 'No Carrier' The modem was not able to connect with the remote modem within S7 seconds. undetermined(23) This value is not reported in the I6 screen. This is the value reported to the NMC on a query during modem training. none(32) _ 'No Connection' or 'Online' This is the value reported to the NMC on a query of disconnect reason during modem training or while connected, or a query of the call fail reason when the call did not fail. In the I6 screen, the modem will report No Connection after being reset or on powerup. From online command mode, it will display 'Online' instead of a disconnect reason rcvdGatewayDiscCmd(62) _ 'Gateway Disconnect Command Received' The Gateway card sent the modem a disconnect command. This is a normal method of terminating a call locally. This only applies to calls on the packetbus and is analogous to dtrDrop on the RS-232 NIC interface. So yes, the disconnect occurred at the users end, but the CO relayed a DS0Teardown message before the hangup could get to the chassis. ______________________________ Reply Separator Thank you. Thomas Spaulding http://www.talweb.com/tsplding Staff@TalWeb.com http://www.talweb.com -----Original Message----- >Help!!! Just point me in the right direction (Documentation) > >We are seeing a bunch of dropped calls recently. They are trapped as >"ReTransmitLimit", a few unknowns, and "DS0Teardowns". It seems that the >higher the call is on the TDM channel the larger chance it will be dropped. >I can find the list of events but no descrition or truth tables of thier >causes. The only one I find obvious are the ModemDiscCmd type's > >Our chassis was purchased as a PRI ready but came with the T1 code that we >flash upgraded. I have heard that the PRI card is shipped with more memory. >Could this be part of the problem? And what type and size of memories--both >flash and RAM--SHOULD be on a a unit with 2-Pri Spans 46 modems. (Though >only 1/23 are in use now) > >---------- >> From: David Bolen <db3l@ans.net> >> To: usr-tc@mail.xmission.com >> Subject: RE: (usr-tc) Disconnect causes >> Date: Wednesday, August 27, 1997 7:33 PM >> >> Tom Bilan <tom@tdi.net> writes: >> >> > Would you rather program VLAs or just have the correct terminate >> > code where the terminate code is supposed to be? >> >> As has been noted in previous notes, I believe as regards to a >> termination cause, the correct code is where it's supposed to be. >> >> Personally, I'm not really in favor of USR avoiding VSAs just because >> particular servers don't yet support it - that seems to me to akin to >> the cart driving the horse. >> >> But to answer your question, it's not really any difference to me >> whether its a VSA or a non-VSA attribute (both of which are formally a >> standard part of RADIUS). I've had VSA support in my own custom >> server for a long time, so there's no extra overhead or programming >> involved. If I hadn't done the programming yet for them and I was at >> this stage, then yes, I'd probably opt to do the programming. After >> all, that's more or less why the programming got there in the first >> place :-) >> >> Unfortunately, it's not at all based on any existing publically >> available base, nor would it probably be releasable anyway (not due to >> my choice - I'd release my entire server if it were up to me). >> >> -- David >> >> /-----------------------------------------------------------------------\ >> \ David Bolen \ Internet: db3l@ans.net / >> | ANS Communications, Inc. \ Phone: (914) 789-5327 | >> / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ >> \-----------------------------------------------------------------------/ >> >> > >

Subject: Re: (usr-tc) USRobotics support, Quakelag, and Investing in TCM
From: Brian <signal@shreve.net>
Date: 1997-10-23 13:18:10

On Thu, 23 Oct 1997, Laszlo Vecsey wrote: > On Thu, 23 Oct 1997, Bob Purdon wrote: > > > > But then again if it's netserver related, why doesn't ISDN lag?... > > > > Is that the case, or is it just that too few people use ISDN to have > > noticed? > > As previously mentioned, I think &N settings for x2 modems, adjusting the > fifo in Win95, and ISDN are just masking the real problem. I just wrote up > a test program to send UDP test packets of varying sizes (from a 28.8 > linux box, through the usr-tc, to a linux server on the local lan) and > noticed some interesting things as the packet size rose. Beginning at > ~2500bytes or so and up, I noticed that every 5 or 10 packets took about > two to three times longer to transmit than normal. > > I'm not sure if Quake even generates packets this large or not (perhaps > occasionaly), or if MTU settings affect this.. Laszlo, I thought of doing this. Can you send me the client/server? I was going to do something simple using sockets in perl but would be interested in looking at what you have.....to do some testing with. Brian > > - lv > > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: Re: (usr-tc) PRI Problems
From: Brian <signal@shreve.net>
Date: 1997-10-23 13:27:12

On Mon, 20 Oct 1997, David Bolen wrote: > Greg Gibson <gg@pressroom.com> writes: > > > Has anyone out there experienced this kind of problem before or can anyone > > offer suggestions? One person has suggested it could be a timing problem > > which needs to be checked with an oscilliscope from the CO, but I doubt the > > phone company has tried that. > > I can't speak to the PM3s, but on the USR side, my suggestion to start > off would be to enable the PRI-card level traps for all call events > (in the dt1TrapEnaTable table), and then log those traps (either via > TCM or any other trap receiver). (Oh, you need to be running TCS > 2.5.x for these events) > Just curious, what are you all using to receive traps on under UNIX? Currently I don't monitor traps, but I know its good to do so. I have TCM running under NT, but would prefer to set logserver and log traps in Linux. Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: (usr-tc) Radius Error Message
From: pat@coffey.com
Date: 1997-10-23 13:41:26

We have our tc hub running radius off of a linux box and I keep getting the following message. radius[19129]: could not cache client datum for host 204.248.xxx.xx Has anyone seen this? If so what does it mean? Thanks, Pat

Subject: Re: (usr-tc) USRobotics support, Quakelag, and Investing in TCM
From: Laszlo Vecsey <master@internexus.net>
Date: 1997-10-23 13:58:29

On Thu, 23 Oct 1997, Bob Purdon wrote: > > But then again if it's netserver related, why doesn't ISDN lag?... > > Is that the case, or is it just that too few people use ISDN to have > noticed? As previously mentioned, I think &N settings for x2 modems, adjusting the fifo in Win95, and ISDN are just masking the real problem. I just wrote up a test program to send UDP test packets of varying sizes (from a 28.8 linux box, through the usr-tc, to a linux server on the local lan) and noticed some interesting things as the packet size rose. Beginning at ~2500bytes or so and up, I noticed that every 5 or 10 packets took about two to three times longer to transmit than normal. I'm not sure if Quake even generates packets this large or not (perhaps occasionaly), or if MTU settings affect this.. - lv

Subject: Re: (usr-tc) PRI Problems
From: David Bolen <db3l@ans.net>
Date: 1997-10-23 14:39:09

Brian <signal@shreve.net> writes: > Just curious, what are you all using to receive traps on under UNIX? > Currently I don't monitor traps, but I know its good to do so. I have TCM > running under NT, but would prefer to set logserver and log traps in > Linux. For us the trap handling at the moment is built into our primary (kind of does everything including the kitchen sink) statistics daemon, which is built with the ISODE libraries. I wouldn't recommend imposing ISODE on anyone though (our use arises since our daemon is a SMUX sub-agent to the Unix snmpd .. it's a long story) You should be able to use most any library though - I believe the CMU library comes with a sample snmptrapd, although you've got to enhance it to actually do MIB lookups on the trap and bindings if you want to get useful information for an enterprise trap such as from the USR gear. -- 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) AIGH! stupid phone system
From: Brian <signal@shreve.net>
Date: 1997-10-23 14:39:28

On Thu, 23 Oct 1997, Jeff Mcadams wrote: > Ok, we have a really brain-dead phone system that disconnected me on my > call at just about the time that I think the USR first-level tech dude > was about to get a clue. > > Anyway...really simple question...might be faster to get the answer here > than waiting through their hold queue again.... > > I want to put a user in RADIUS (Merit RADIUS in our case) that is a > login user, but I have two shell servers that I want to round-robin the > connections between. > > To do this, I've set up the shell servers as hosts in all the netservers > and set randomhosts on...no problem there. The problem is...what do I > need to put in the RADIUS user file in Login-IP-Host to make the > netserver use the default hosts set up on the netserver? > > (Simple question, right? Took me 15 minutes to get the rock on the > other end of the phone to understand what I was asking). Perfectly valid question. If you think you would have gotten an answer to this out of level 1, your smoking crack. No, I don't know the answer, I didn't even know about roundrobining hosts, thats kinda neat. Brian > -- > Jeff McAdams Email: jeffm@iglou.com > Chief Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: (usr-tc) Glueing Networks
From: Brian <signal@shreve.net>
Date: 1997-10-23 14:45:21

I have a problem I am hoping someone here can help me with: I have 3 /24's 208.206.76.0 For servers and virtual domains 208.214.44.0 For dialup users, tc hubs 208.214.45.0 For dialup users, broken into /28's for routed LANs Now, because USR TC's, DO NOT support OSPF, what I am currently doing, is enabling RIP on our Cisco, enabling Broadcast on our TC hubs, and basically multiplying packets on our Ethernet * 2. This sucks. Now I am wondering, if there is ANYWAY I can do something on the TC hubs to allow them to talk to 208.206.76.0 directly and not have to go thru the Cisco. I read the chapter on Supernetting, but was kinda confused. I am not sure Supernetting is what I want, it probably isn't. But it would sure save ALOT of bandwidth, and a few ms latancy to have my 3 network addresses all directly accessable without having to go thru the router. OSPF would solve all this. Is there anything that can be done to get this to work, or are all of you in RIP hell with me? R.I.P. Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: (usr-tc) AIGH! stupid phone system
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1997-10-23 14:48:00

Ok, we have a really brain-dead phone system that disconnected me on my call at just about the time that I think the USR first-level tech dude was about to get a clue. Anyway...really simple question...might be faster to get the answer here than waiting through their hold queue again.... I want to put a user in RADIUS (Merit RADIUS in our case) that is a login user, but I have two shell servers that I want to round-robin the connections between. To do this, I've set up the shell servers as hosts in all the netservers and set randomhosts on...no problem there. The problem is...what do I need to put in the RADIUS user file in Login-IP-Host to make the netserver use the default hosts set up on the netserver? (Simple question, right? Took me 15 minutes to get the rock on the other end of the phone to understand what I was asking). -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) AIGH! stupid phone system
From: David Bolen <db3l@ans.net>
Date: 1997-10-23 15:25:07

Jeff Mcadams <jeffm@iglou.com> writes: > To do this, I've set up the shell servers as hosts in all the netservers > and set randomhosts on...no problem there. The problem is...what do I > need to put in the RADIUS user file in Login-IP-Host to make the > netserver use the default hosts set up on the netserver? How about just putting the hosts themselves in your RADIUS server? The randomhost feature should randomize target hosts no matter what they source (global list, per-port list or acquired via RADIUS). So just put in separate Login-IP-Host attributes for each of your addresses (up to a maximum of 9). I'm not positive about your specific question, but I believe that either leaving out that attribute entirely, or potentially having only a single such attribute with a value of 0.0.0.0 may do what you want. -- 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) AIGH! stupid phone system
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1997-10-23 15:32:42

Subject: (usr-tc) adding ISDN
From: Jeff Lynch <jeff@mercury.jorsm.com>
Date: 1997-10-23 15:35:06

I assume there is a radius check value or reply value to grant or deny a dial-up user ISDN priviledges. Would you mind describing how you typically control analog and ISDN access on Netserver and Livingston ComOS based equipment through RADIUS user file check and reply values? We use BRI on Netserver 16I for ISDN due to the high cost of PRI here. Our non-ISDN lines are currently coming on standard lines to Livingston PMs but will migrate to USR TC Hubs with Channelized T1 very soon. Thanks. ========================================================================= Jeffrey A. Lynch, President 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) Glueing Networks
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1997-10-23 15:50:11

Thus spake Brian >Now, because USR TC's, DO NOT support OSPF, what I am currently doing, is >enabling RIP on our Cisco, enabling Broadcast on our TC hubs, and >basically multiplying packets on our Ethernet * 2. set ripv2 on :) ripv2 supports classless addressing. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Glueing Networks
From: Brian <signal@shreve.net>
Date: 1997-10-23 15:51:02

On Thu, 23 Oct 1997, Jeff Mcadams wrote: > Thus spake Brian > >Now, because USR TC's, DO NOT support OSPF, what I am currently doing, is > >enabling RIP on our Cisco, enabling Broadcast on our TC hubs, and > >basically multiplying packets on our Ethernet * 2. > > set ripv2 on > > :) > > ripv2 supports classless addressing. Yeah, ripv2 is on, and I am Broadcasting rip, thats what I am saying. But how does that allow me to "glue" the networks? They still have to go thru the Cisco. Brian > -- > Jeff McAdams Email: jeffm@iglou.com > Chief Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: Re: (usr-tc) AIGH! stupid phone system
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1997-10-23 16:09:43

Thus spake David Bolen >Jeff Mcadams <jeffm@iglou.com> writes: >> To do this, I've set up the shell servers as hosts in all the netservers >> and set randomhosts on...no problem there. The problem is...what do I >> need to put in the RADIUS user file in Login-IP-Host to make the >> netserver use the default hosts set up on the netserver? >How about just putting the hosts themselves in your RADIUS server? >The randomhost feature should randomize target hosts no matter what >they source (global list, per-port list or acquired via RADIUS). So >just put in separate Login-IP-Host attributes for each of your >addresses (up to a maximum of 9). >I'm not positive about your specific question, but I believe that >either leaving out that attribute entirely, or potentially having only >a single such attribute with a value of 0.0.0.0 may do what you want. Ok, apparently I'm missing something *really* simple here, but I'm not sure what. Can anyone tell me why none of these user entries are working? I've included most of the variations I've tried...almost all generate a "Host is Currently Unavailable" message when logging in. USR_NETS Password="hello" Service-Type = Login Alternatively with at various times: Login-IP-Host = 192.107.41.3 Login-IP-Host = "192.107.41.3" Login-IP-Host = 0.0.0.0 Login-IP-Host = "0.0.0.0" Login-IP-Host = 255.255.255.255 Login-IP-Host = "255.255.255.255" 192.107.41.3 is one of the shell servers here and is listed in the host entry in the netserver. Figured I'd try to get just connectivity to a single login host working first and can't even seem to do that. :/ Again, this is Merit RADIUS server. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) adding ISDN
From: MegaZone <megazone@livingston.com>
Date: 1997-10-23 16:32:29

Once upon a time Jeff Lynch shaped the electrons to say... >I assume there is a radius check value or reply value to grant or deny >a dial-up user ISDN priviledges. Would you mind describing how >you typically control analog and ISDN access on Netserver and >Livingston ComOS based equipment through RADIUS user file check and reply If the NAS supports sending it in the Auth-Req, you can use NAS-Port-Type as a checkitem. user Auth-Type = System, NAS-Port-Type = ISDN user Auth-Type = System, NAS-Port-Type = Async Like that. PM-3s will send it, I think TCs do too. >here. Our non-ISDN lines are currently coming on standard lines to >Livingston PMs but will migrate to USR TC Hubs with Channelized T1 very >soon. Sorry to hear that. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588

Subject: (usr-tc) MPIP is failing again
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-23 16:39:08

My MPIP is failing again. After resetting all the times on all my Netservers, reconfiguring the MPIP settings twice, I am getting log messages like this on my MPIP server: Oct 23 16:33:52 XXXX.xmission.com mpip_process_request: Oct 23 16:33:52 XXXX.xmission.com MPIP_LINK_DEREG_REQ Oct 23 16:33:52 XXXX.xmission.com ^M Oct 23 16:34:02 XXXX.xmission.com mpip_process_request: Oct 23 16:34:02 XXXX.xmission.com [BIF IS NULL] Oct 23 16:34:02 XXXX.xmission.com [MPIP_LINK_REG_REQ] Oct 23 16:34:02 XXXX.xmission.com ^M What does this mean? I was on the verge of launching our bonding service, now I'll have to hold back again. I'm on 3.5.93, on all the racks. -- Pete XMission

Subject: Re: (usr-tc) AIGH! stupid phone system
From: David Bolen <db3l@ans.net>
Date: 1997-10-23 16:51:37

Brian <signal@shreve.net> writes: > If you think you would have gotten an answer to this out of level 1, your > smoking crack. No, I don't know the answer, I didn't even know about > roundrobining hosts, thats kinda neat. It's not really round-robin, but a pseudo-random selection out of a pool of hosts. You can't achieve true round-robin because of the lack of state from call to call (although for local definitions the NETServer has a global or per-port list, that list is taken anew for each call, and obviously the list is new in each RADIUS response), but it's still useful. For those who may be interested, I ran some simulations back in early '96 for one of my sites (about 8 NETServers at the time I think) feeding into 8 target hosts using randomization as well as other methods like true round-robin. Using real call data (so realistic call arrival rates, duration, etc.. - about 25,000 calls) it showed a distribution (simultaneous user count per each target host): 1 2 3 4 5 6 7 8 Min Max Random (Avg) 33 34 33 31 33 32 32 31 31 34 (Peak) 61 74 66 61 64 64 62 64 61 74 Round-Robin (Avg) 31 33 32 33 32 34 32 31 31 34 (Peak) 57 60 65 66 61 64 64 57 57 66 So true randomization averages about the same as a true round-robin, but the round-robin has an advantage in terms of keeping a tighter range of peak simultaneous usage. The actual performance is obviously affected by the number of NETServers and the number of hosts. And a round-robin approach gets better the more central to the system you perform the round-robin (not surprisingly I suppose). Of course, the simulation also assumed that all calls were accepted by the target hosts - if they ever refuse connections, then your fallover (backup) methodology becomes very important. Of course, to do a true round-robin with the NETServer you kind of need to handle it external to the NETServer, so the randomize feature allows you to come close without having to have off-card support. For our case, we eventually settled on a round-robin distribution handled by the local rack management machine (so it's a round-robin system per 4 NETServers) with a randomized set of backup hosts. We only return 'n' hosts in a response, but the primary round-robin and randomized n-1 backups are selected from an overall much larger set. -- 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) Glueing Networks
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1997-10-23 16:56:22

Thus spake Brian >On Thu, 23 Oct 1997, Jeff Mcadams wrote: >> Thus spake Brian >> >Now, because USR TC's, DO NOT support OSPF, what I am currently doing, is >> >enabling RIP on our Cisco, enabling Broadcast on our TC hubs, and >> >basically multiplying packets on our Ethernet * 2. >> >> set ripv2 on >> >> :) >> >> ripv2 supports classless addressing. >Yeah, ripv2 is on, and I am Broadcasting rip, thats what I am saying. But >how does that allow me to "glue" the networks? They still have to go thru >the Cisco. Well...ripv2 does basically the same thing OSPF does (classless dynamic routing protocol), so however you were going to do it in OSPF, you should be able to do it with ripv2. The main difference being...OSPF scales better, and is a link state type of routing protocol where ripv2 is a hop count type of routing protocol....the end function that they perform are basically the same though. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) AIGH! stupid phone system
From: David Bolen <db3l@ans.net>
Date: 1997-10-23 16:57:00

Jeff Mcadams <jeffm@iglou.com> writes: > Ok, apparently I'm missing something *really* simple here, but I'm not > sure what. Can anyone tell me why none of these user entries are > working? I've included most of the variations I've tried...almost all > generate a "Host is Currently Unavailable" message when logging in. It's hard to say without knowing the actual variations, because my guess is that other than the possibility of 0.0.0.0 selecting the global list (which it doesn't sound like it does, so my guess for that might be to leave it out entirely) you don't want such an entry in a response. > USR_NETS Password="hello" > Service-Type = Login > > Alternatively with at various times: > Login-IP-Host = 192.107.41.3 > Login-IP-Host = "192.107.41.3" > Login-IP-Host = 0.0.0.0 > Login-IP-Host = "0.0.0.0" > Login-IP-Host = 255.255.255.255 > Login-IP-Host = "255.255.255.255" To be on the safe side, you don't show a Login-Service attribute here. Presumably you want to set it either to Telnet, Rlogin or TCP-Clear depending on what your target host is going to expect out of the data stream. (It's possible the NETServer is defaulting to PortMux without any other information) I might also recommend including a Login-TCP-Port to eliminate any further ambiguity, although it should default to the appropriate port for the service type you select (e.g., 23 for telnet), but if you are creating a clear tunnel for some async protocol you may want to pick another port. > 192.107.41.3 is one of the shell servers here and is listed in the host > entry in the netserver. Figured I'd try to get just connectivity to a > single login host working first and can't even seem to do that. :/ Double check the syslog output of your NETServer while you are trying to log in - it should reflect a failure to connect to the target host (well, at least for telnet stuff - not positive about rlogin or portmux). -- 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) Glueing Networks
From: David Bolen <db3l@ans.net>
Date: 1997-10-23 17:14:03

Brian <signal@shreve.net> writes: > Now, because USR TC's, DO NOT support OSPF, what I am currently doing, is > enabling RIP on our Cisco, enabling Broadcast on our TC hubs, and > basically multiplying packets on our Ethernet * 2. In such an environment, if you also allow your NETServers to listen to RIP routing information, they should hear the same announcements (presumably from your other NETServers) that the Cisco hears, and thus use the more direct route when applicable. If your problem is then the fact that the per-NETServer prefix is smaller than a classful (in this case /24) size, with RIPv1 you can solve this with the netmask table as long as you use a consistent prefix size (which it sounds like is /28 in your case), or as another response suggested, shift to using RIPv2 which will allow the NETServers to both broadcast and listen to arbitrary prefix size announcements. -- 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) tcenema script & Investing in TCM
From: Brian <signal@shreve.net>
Date: 1997-10-23 17:28:46

On Thu, 23 Oct 1997, Tatai SV Krishnan wrote: > I am not sure of any such test, I do know that USR has a certification > program., I will get information from our training department about this > and post it. > > krish Krish, Thanks, it would be much appreciated. Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: Re: (usr-tc) AIGH! stupid phone system
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1997-10-23 18:06:12

Thus spake David Bolen >It's hard to say without knowing the actual variations, because my >guess is that other than the possibility of 0.0.0.0 selecting the >global list (which it doesn't sound like it does, so my guess for that >might be to leave it out entirely) you don't want such an entry in a >response. Actually, the 0.0.0.0 did work, but it was other problems which turned out to be causing this... :/ >To be on the safe side, you don't show a Login-Service attribute here. >Presumably you want to set it either to Telnet, Rlogin or TCP-Clear >depending on what your target host is going to expect out of the data >stream. (It's possible the NETServer is defaulting to PortMux without >any other information) Added this. >I might also recommend including a Login-TCP-Port to eliminate any >further ambiguity, although it should default to the appropriate port >for the service type you select (e.g., 23 for telnet), but if you are >creating a clear tunnel for some async protocol you may want to pick >another port. And this....and it seemed to work...so apparently, it was defaulting to something funky other than telnet 23. :/ >Double check the syslog output of your NETServer while you are trying >to log in - it should reflect a failure to connect to the target host >(well, at least for telnet stuff - not positive about rlogin or >portmux). Never made it that far to have to check, but I'll keep that in mind in the future... Thanks for the help. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) adding ISDN
From: MegaZone <megazone@livingston.com>
Date: 1997-10-23 18:11:25

Once upon a time Garry Shtern shaped the electrons to say... >Well actually.. This aside from the topic, but unless you guys can come up >with something like TCM and NMC for PM3, I doubt a lot people will be As for TCM - have you been to any recent tradeshows to see Amber (the new Pmconsole) or Betty (the new RADIUS server - billing package - report generator - user database management ceter)? Both are in limited trials now and should be in wide beta soon. Both are Pure Java so users won't have this "when are they going to port TCM to platform X" issue. As for the NMC - what features in particular? SNMP support has been improved in each recent release. 3.8 will have SNMP modem information and some SNMP TRAP ability. And so on, we're adding it in steps, not all at once. 3.8 also has a new command parser and help subsystem. And for most people it seems things like OSPF, BGP, extremely low latency (Quakers love it), is more imporant. 3.8 will add a number of things like ethernet multihoming, OSPF over demand links, etc. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588

Subject: Re: (usr-tc) MPIP is failing again
From: Brian <signal@shreve.net>
Date: 1997-10-23 18:11:32

On Thu, 23 Oct 1997, Pete Ashdown wrote: > My MPIP is failing again. After resetting all the times on all my > Netservers, reconfiguring the MPIP settings twice, I am getting log > messages like this on my MPIP server: > > Oct 23 16:33:52 XXXX.xmission.com mpip_process_request: > Oct 23 16:33:52 XXXX.xmission.com MPIP_LINK_DEREG_REQ > Oct 23 16:33:52 XXXX.xmission.com ^M > Oct 23 16:34:02 XXXX.xmission.com mpip_process_request: > Oct 23 16:34:02 XXXX.xmission.com [BIF IS NULL] > Oct 23 16:34:02 XXXX.xmission.com [MPIP_LINK_REG_REQ] > Oct 23 16:34:02 XXXX.xmission.com ^M > > What does this mean? I was on the verge of launching our bonding service, > now I'll have to hold back again. > > I'm on 3.5.93, on all the racks. check the time on all the hubs, it should be the same, if not, set timeserver and reset time if any of the hubs changed from a server to a client or vice versa, it has to be rebooted, or so I am told. make sure the ISDN is handled by the netserver. Brian > > -- > Pete > XMission > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: (usr-tc) RipV2, routed, etc
From: Brian <signal@shreve.net>
Date: 1997-10-23 18:29:23

Ok, so trying to "glue" my networks, i did this: Enabled "routed -s -g" on all my UNIX machines on 208.206.76.0/24 Enabled "ripv2" and "set net0 routing on" for all tc hubs, which are on 208.214.44.0/24. Is that all that needs to be done? Or do I have to mess with a gateways/netmasks file? The router, still has a static route on it for the networks, I suppose I really should turn that off, and let RIP take care of it from now on...........any help would be appreciated. Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: Re: (usr-tc) AIGH! stupid phone system
From: David Bolen <db3l@ans.net>
Date: 1997-10-23 18:36:38

Jeff Mcadams <jeffm@iglou.com> writes: > And this....and it seemed to work...so apparently, it was defaulting to > something funky other than telnet 23. :/ Well, did you add both at the same time? If so, you can't really tell :-) If for example, you didn't have the Login-Service in there in the first place, the NETServer might have defaulted to PortMux (and to it's natural port which is like in the 1600-1700 range or something). So you might find that adding the Login-Service of telnet changes the default for port to the normal 23 and you could technically leave off the Login-TCP-Port. Of course, if you know what it is, putting it in can't hurt. -- 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) USRobotics support, Quakelag, and Investing in TCM
From: Bob Purdon <bobp@southcom.com.au>
Date: 1997-10-23 18:37:36

> I wonder if the problem occurs with analog modems _and_ digital modems, > (we have no analog lines). All other analog equipment i've seen works > fine with quake. It seems that if the problem is in the Netserver, it > really wouldn't matter if you were trunking analog or digital.. All of our lines (in this context) are served by NETServers, running 3.5.33. > But then again if it's netserver related, why doesn't ISDN lag?... Is that the case, or is it just that too few people use ISDN to have noticed? Interestingly, I remember seeing someone mention a while back that the only platform they've used that *doesn't* suffer "Quake Lag" was the Xylogics Annex boxes - their PM's, TC's, Cisco's, etc all exhibited the problem. I can't find a reference to it now though :-( Regards, Bob Purdon, Southern Internet.

Subject: Re: (usr-tc) adding ISDN
From: Jeff Lynch <jeff@mercury.jorsm.com>
Date: 1997-10-23 19:18:43

On Thu, 23 Oct 1997, MegaZone wrote: > Once upon a time Jeff Lynch shaped the electrons to say... > >I assume there is a radius check value or reply value to grant or deny > >a dial-up user ISDN priviledges. Would you mind describing how > >you typically control analog and ISDN access on Netserver and > >Livingston ComOS based equipment through RADIUS user file check and reply > > If the NAS supports sending it in the Auth-Req, you can use > NAS-Port-Type as a checkitem. > > user Auth-Type = System, NAS-Port-Type = ISDN > > user Auth-Type = System, NAS-Port-Type = Async > > Like that. PM-3s will send it, I think TCs do too. Thanks. This is what I was looking for. > > >here. Our non-ISDN lines are currently coming on standard lines to > >Livingston PMs but will migrate to USR TC Hubs with Channelized T1 very > >soon. > > Sorry to hear that. > > -MZ Not to worry. We'll have both, it's the PM2s we're phasing out, except for BRI. The ones we're getting rid of are ransom for the TC trade up. I've aways believed in Livingston. ========================================================================= Jeffrey A. Lynch, President 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) adding ISDN
From: MegaZone <megazone@livingston.com>
Date: 1997-10-23 19:50:35

Once upon a time Charles Hill shaped the electrons to say... >officially have to support it. Maybe I have a misconception that DOV is >not very reliable. PRI isn't THAT much more expensive than T1. DOV works rock solid in my experience. It isn't just to get ISDN over chanT1. If the BRI DATA tarriffs in an area are insane, users can use DOSBS and get VOICE tarriffs. Friends of mine in MA run a 24x7 128K ISDN link DOSBS for less than $200 a month. DATA tarriff is over $1000 a month - I think over $1500. The telco misbilled them one month at the data rate. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588

Subject: Re: (usr-tc) AIGH! stupid phone system
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1997-10-23 20:00:13

Thus spake David Bolen >Jeff Mcadams <jeffm@iglou.com> writes: >> And this....and it seemed to work...so apparently, it was defaulting to >> something funky other than telnet 23. :/ >Well, did you add both at the same time? If so, you can't really tell >:-) Yeah, and I'm not exactly urgent to break it again to find out. :) Actually, I *believe* I had Login-Service in there at one point during my original testing, so I think maybe it was defaulting to a different port even with telnet, but that just doesn't seem to make sense. *shrug* >Of course, if you know what it is, putting it in can't hurt. Which is my planned course of action here...better safe then sorry. :) -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) adding ISDN
From: Garry Shtern <shterng@akula.com>
Date: 1997-10-23 20:19:46

At 04:32 PM 10/23/97 -0700, MegaZone wrote: >>here. Our non-ISDN lines are currently coming on standard lines to >>Livingston PMs but will migrate to USR TC Hubs with Channelized T1 very >>soon. > >Sorry to hear that. > Well actually.. This aside from the topic, but unless you guys can come up with something like TCM and NMC for PM3, I doubt a lot people will be reluctant to trade livingston products for USR. We are getting 2 PM3 hubs but only for one thing: DOV support. Once USR starts supporting DOV, those PM3 hubs will go directly to them for a trade in. Sorry to break it to you but Livingston has a long way to go in terms of management software and user interfaces. Btw, does anyone know when exactly 3com intends to support DOV? Garry Shtern shterng@akula.com Chief Network Administrator http://www.akula.com Akula Communications Corp. tel. (212) 292-8892

Subject: Re: (usr-tc) adding ISDN
From: MegaZone <megazone@livingston.com>
Date: 1997-10-23 21:02:16

Once upon a time Charles Hill shaped the electrons to say... >My understanding of "data over voice bearer service" is this: my PRI >interface recognizes a voodoo DOSBS call and spoofs the switch into >delivering a data call that is flagged as a voice call in the call setup. No. It is a voice call - period. It is made, routed, and received as a voice call. Just like a modem. The only different is the data in the stream is HDLC and not analog modem signals. There is no spoofing. The issue is the receiving gear needs to know how to handle the call. Most devices need two phone numbers on PRI - one for modems, one for DOSBS. And cannot do both on ChanT1 - they need to be configured for one or the other up front. The PM-3 has a way to detect the data content and automatically determine how to handle the call on one number, PRI or ChanT1. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588

Subject: Re: (usr-tc) adding ISDN
From: Charles Hill <chill@ionet.net>
Date: 1997-10-23 21:14:58

> Once USR starts supporting DOV, those PM3 hubs will go directly to them > for a trade in. > > Btw, does anyone know when exactly 3com intends to support DOV? Then they'd better hurry up with DOVBS, because that trade-in promo ends Dec 15. :) Personally, I hope they get NFAS support for the HiPer DSP ironed out first. DOV is not important to me, and I don't want to officially have to support it. Maybe I have a misconception that DOV is not very reliable. PRI isn't THAT much more expensive than T1. Especially since the new PRI over UAS tariff just passed in many states in US Wasteland. -CH

Subject: Re: (usr-tc) adding ISDN
From: Charles Hill <chill@ionet.net>
Date: 1997-10-23 22:41:00

> It isn't just to get ISDN over chanT1. If the BRI DATA tarriffs in an > area are insane, users can use DOSBS and get VOICE tarriffs. > > Friends of mine in MA run a 24x7 128K ISDN link DOSBS for less than $200 > a month. DATA tarriff is over $1000 a month - I think over $1500. The > telco misbilled them one month at the data rate. My understanding of "data over voice bearer service" is this: my PRI interface recognizes a voodoo DOSBS call and spoofs the switch into delivering a data call that is flagged as a voice call in the call setup. I don't imagine that is a hard feature to implement, but what are the legalities of spoofing a telco switch by accepting the disguised digital call? Not that we aren't all violating tariffs as a general practice in some way or another, but I'm curious. Is the onus on the customer for placing such a call? I have seen telcos cancel our orders or deny us service over tariff violations before. -CH

Subject: Re: (usr-tc) adding ISDN
From: Charles Hill <chill@ionet.net>
Date: 1997-10-23 22:54:27

> If you make an x2 call over a digital path (e.g., sourced on a BRI), > then it will negotiate symmetric mode, and you'll get a full 56K or > 64K (depending on whether any part of the path is RBS) in both > directions. I will certainly recommend the I-modem solution to customers who have the means. Have you tested the 64k symmetrical x2 connect? I've never tried it, since digital sync connects are usually the goal. How does DOSBS deal with RBS? Does the TA detect it somehow, or is it a trial-and-error thing the caller must tweak? -CH

Subject: Re: (usr-tc) adding ISDN
From: David Bolen <db3l@ans.net>
Date: 1997-10-23 23:08:04

Charles Hill <chill@ionet.net> writes: > Then they'd better hurry up with DOVBS, because that trade-in promo ends > Dec 15. :) Personally, I hope they get NFAS support for the HiPer DSP > ironed out first. DOV is not important to me, and I don't want to > officially have to support it. I'd kind of like to have the option to support DOV for users who wanted it, but one option that does exist today for people who have x2 capable TAs (are there any other than the I-Modem yet?) is symmetric x2. If you make an x2 call over a digital path (e.g., sourced on a BRI), then it will negotiate symmetric mode, and you'll get a full 56K or 64K (depending on whether any part of the path is RBS) in both directions. This might not be directly comparable to DOV (in terms of more limited equipment choices, etc..), but it does provide one avenue of achieving a similar goal - that of a high performance call over analog or voice service if you've got the gear. -- 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) adding ISDN
From: David Bolen <db3l@ans.net>
Date: 1997-10-24 00:03:10

Charles Hill <chill@ionet.net> writes: > I will certainly recommend the I-modem solution to customers who have the > means. Have you tested the 64k symmetrical x2 connect? I've never tried > it, since digital sync connects are usually the goal. It's worked great in the cases where I've used it - just tell your I-Modem to make an analog call (*V2=3) and then make a normal call. If the I-Modem has the x2 feature enabled and you call into a TC hub with TCS 2.5.1 (I forget if symmetric was fully in 2.5 or not, but I think so) they should negotiate the symmetric x2. The one difference over a straight ISDN call (and presumably a DOVBS) is that the default V.42/42bis increases your latency over a purely digital call. Then again, it also compresses your data and can help replace the CCP you may have negotiated over the digital call (or be better if the digital target device wasn't going to allow CCP anyway). You can always turn off the compression part anyway. The other negative is that because (at least on the I-Modem) the TurboPPP stuff (and built in MLPPP) is part of the whole digital async<->sync PPP setup, I don't think you can use both B channels in this mode simultaneously with the I-Modem handling the MLPPP duties, like you can with a digital call. Not positive, but I don't think so. But for a straight analog call, the 64K (or 56K) works just great - and in both directions. > How does DOSBS deal with RBS? Does the TA detect it somehow, or is it a > trial-and-error thing the caller must tweak? Good question - I'm not familiar with it enough to know for sure. I'm not sure exactly how it could be negotiated, so my best guess would be that it is either configured for a specific rate or else just assumes a default. -- 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) adding ISDN
From: Garry Shtern <shterng@akula.com>
Date: 1997-10-24 00:08:08

On Thu, 23 Oct 1997, MegaZone wrote: > As for TCM - have you been to any recent tradeshows to see Amber (the new > Pmconsole) or Betty (the new RADIUS server - billing package - report > generator - user database management ceter)? Both are in limited trials > now and should be in wide beta soon. Both are Pure Java so users won't > have this "when are they going to port TCM to platform X" issue. Maybe. However, I seriously doubt that they come even close to the ability that TCM gives to control every single card of the Total Control chassis. How about detailed statistical information on the performance of a T1/PRI card? How about the ability to easily configure every register on the modem and have the information about each one of them right on your screen? How about constant updates on the LEDs to show you what is currently going on the chassis? None of the Livinston software even come close and I doubt it will any time soon. As I always say, Livingston is great when it comes to the underlying functionality. But when it comes to monitoring, statistics and management, you guys have a long way to go. > > As for the NMC - what features in particular? SNMP support has been > improved in each recent release. 3.8 will have SNMP modem information > and some SNMP TRAP ability. And so on, we're adding it in steps, not > all at once. > > 3.8 also has a new command parser and help subsystem. > > And for most people it seems things like OSPF, BGP, extremely low latency > (Quakers love it), is more imporant. 3.8 will add a number of things > like ethernet multihoming, OSPF over demand links, etc. OSFP is great, BGP is usefull only for a huge ISP and useless for a small one, low latency is wonderful. As I said before, Livingston is great with the command line features not management. And when you have 100+ ports, the management plays a lot bigger role. Take for example auto-response system, do you guys have anything close to this? Is on the list of your future developments? Maybe now, since Lucent bought you out. Again, I am not trying to say anything bad about Livingston. I had your products when we were a smaller ISP and found them great. But now, I will only buy PM3 because they have something that is vital to providing ISDN in NY. -Garry

Subject: Re: (usr-tc) adding ISDN
From: Garry Shtern <shterng@akula.com>
Date: 1997-10-24 00:10:23

On Thu, 23 Oct 1997, Charles Hill wrote: > Then they'd better hurry up with DOVBS, because that trade-in promo ends > Dec 15. :) Personally, I hope they get NFAS support for the HiPer DSP > ironed out first. DOV is not important to me, and I don't want to > officially have to support it. Maybe I have a misconception that DOV is > not very reliable. PRI isn't THAT much more expensive than T1. > Especially since the new PRI over UAS tariff just passed in many states in > US Wasteland. > Maybe not for you but in NYC you have to pay .30$ for every 5 minutes you are online with 2B channels. And I doubt a lot people are willing to pay this kind of money for ISDN anywhere in the USA. -Garry

Subject: Re: (usr-tc) adding ISDN
From: MegaZone <megazone@livingston.com>
Date: 1997-10-24 00:28:26

Once upon a time Garry Shtern shaped the electrons to say... >Maybe. However, I seriously doubt that they come even close to the ability >that TCM gives to control every single card of the Total Control chassis. Amber allows you to control everything in the chassis. >How about detailed statistical information on the performance of a T1/PRI >card? Some of this is there, what we've been asked for. Easy to add more if needed. And Betty has a defined API users can write their own modules for. >How about the ability to easily configure every register on the >modem and have the information about each one of them right on your >screen? We don't have modem registers. There are very few settings for the modems, quite deliberately. >How about constant updates on the LEDs to show you what is >currently going on the chassis? Yep, this is in Amber. Mutliple chassis controlled at once. A backpanel view with an 'LED' for each modem with the color indicating status. An LED for each session. LEDs for ethernet, etc. So you can call up a backpanel view in Amber on any machine that runs Java and get an instant visual indication of status. You haven't seen anything we've been previewing in the past six months I take it. Come to Internet World in NYC in December - a few big announcements are scheduled. >the management plays a lot bigger role. Take for example auto-response >system, do you guys have anything close to this? Is on the list of your >future developments? Maybe now, since Lucent bought you out. I'm not sure what you mean by auto-response system. I've heard the term used for different things. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588

Subject: (usr-tc) Glueing Networks
From: Rick Payne <rickp@corp.netcom.net.uk>
Date: 1997-10-24 09:27:05

>>>>> "Brian" == Brian <signal@shreve.net> writes: Brian> Now, because USR TC's, DO NOT support OSPF, what I am Tell me about it. I've been asking USR for OSPF for well over a year. Last time I was in Chicago, (this time last year), they said "in a year". I'm now told March. I'll believe it when I see it. Rick -- Rick Payne, Senior Network Admin | Meddle not in the affairs of NETCOM Internet Ltd. | dragons - for you are crunchy & rickp@corp.netcom.net.uk | taste great dipped in chocolate.

Subject: Re: (usr-tc) AIGH! stupid phone system
From: matthew <matthew@the-spa.com>
Date: 1997-10-24 12:50:28

it probably wasn't you, we have an excellent phone system and we get dropped pretty often while on hold with usr tech support or while they are transferring us. matthew At 02:48 PM 10/23/97 -0400, you wrote: >Ok, we have a really brain-dead phone system that disconnected me on my >call at just about the time that I think the USR first-level tech dude >was about to get a clue. > >Anyway...really simple question...might be faster to get the answer here >than waiting through their hold queue again.... > >I want to put a user in RADIUS (Merit RADIUS in our case) that is a >login user, but I have two shell servers that I want to round-robin the >connections between. > >To do this, I've set up the shell servers as hosts in all the netservers >and set randomhosts on...no problem there. The problem is...what do I >need to put in the RADIUS user file in Login-IP-Host to make the >netserver use the default hosts set up on the netserver? > >(Simple question, right? Took me 15 minutes to get the rock on the >other end of the phone to understand what I was asking). >-- >Jeff McAdams Email: jeffm@iglou.com >Chief Network Administrator Voice: (502) 966-3848 >IgLou Internet Services (800) 436-4456 > >

Subject: Re: (usr-tc) adding ISDN
From: matthew <matthew@the-spa.com>
Date: 1997-10-24 12:54:38

It seems to me that the telco's & switch manufacturers will figure out a way to make dov obsolete pretty soon. matthew At 10:41 PM 10/23/97 -0500, you wrote: >> It isn't just to get ISDN over chanT1. If the BRI DATA tarriffs in an >> area are insane, users can use DOSBS and get VOICE tarriffs. >> >> Friends of mine in MA run a 24x7 128K ISDN link DOSBS for less than $200 >> a month. DATA tarriff is over $1000 a month - I think over $1500. The >> telco misbilled them one month at the data rate. > >My understanding of "data over voice bearer service" is this: my PRI >interface recognizes a voodoo DOSBS call and spoofs the switch into >delivering a data call that is flagged as a voice call in the call setup. >I don't imagine that is a hard feature to implement, but what are the >legalities of spoofing a telco switch by accepting the disguised digital >call? Not that we aren't all violating tariffs as a general practice in >some way or another, but I'm curious. Is the onus on the customer for >placing such a call? I have seen telcos cancel our orders or deny us >service over tariff violations before. > >-CH > > > > > >

Subject: Re: (usr-tc) adding ISDN
From: Garry Shtern <shterng@akula.com>
Date: 1997-10-24 13:00:14

At 12:28 AM 10/24/97 -0700, MegaZone wrote: >I'm not sure what you mean by auto-response system. I've heard the term >used for different things. > >-MZ You can setup the system to do whatever you want it to based on the error conditions received by the system. Garry Shtern shterng@akula.com Chief Network Administrator http://www.akula.com Akula Communications Corp. tel. (212) 292-8892

Subject: Re: (usr-tc) AIGH! stupid phone system
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1997-10-24 14:27:56

Thus spake matthew >it probably wasn't you, we have an excellent phone system and we get >dropped pretty often while on hold with usr tech support or while they are >transferring us. No, we actually had a T1 drop on us, so I don't think this one can be attributed to USR at all. :) -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Routing Question
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-24 14:36:58

Brian said once upon a time: >Everything works fine. What I am trying to get to work, is if I am a >user, dialed into a USR TC hub, which is on 208.214.44.0, I want to be >able to go from the hub, right to a server on 208.206.76.0, without going >thru the router....... This won't work. By definition, hubs only switch between ethernet addresses. Since you are talking about two different subnets, you have to deal with the router, because only the router can direct packets between subnets. My suggestion with a network the size of yours is to try and get everything in one subnet (the secondary address on Cisco's doesn't work all that well anyway) as far as your router, servers, and TC's go. Get your servers running "gated" with RIPv2 listening. That way, they'll address packets for the TC's based on ethernet MAC address and you'll avoid the router, unless it is going outside your network. This gets less and less manageable as your network grows. I was in your situation once, and now in order to switch as many packets as possible, I'm looking at a Catalyst 5500.

Subject: Re: (usr-tc) tcenema script
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-24 15:11:45

Pete Ashdown said once upon a time: >setenv TCMDIR "/usr/local/lib/tcm" If anyone is going to use the aforementioned script, replace TCMDIR with TCMHOME, globally.

Subject: (usr-tc) Routing Question
From: Brian <signal@shreve.net>
Date: 1997-10-24 15:14:50

Right now, our network looks as follows (left out hubs and etherswitches because they are not needed for what I am explaining): ____________ 208.206.76.0/24-------------------------------| | | | | -Multiple UNIX Servers |Cisco 2501 | 208.214.44.0/24-------------------------------| | ||| | | || -USR TC Hub 208.214.44.2 |208.206.76.1| | --USR TC Hub 208.214.44.53 |208.214.44.1| ---USR TC Hub 208.214.44.104 | | 208.214.45.0/28-------------------------------| | thru | | 208.214.45.240/28-----------------------------|____________| The Cisco is configured as follows: interface Ethernet0 description To Office Ethernet ip address 208.214.44.1 255.255.255.0 secondary ip address 208.206.76.1 255.255.255.0 router rip network 208.206.76.0 network 208.214.44.0 network 208.214.45.0 My Total Control Hubs are on 208.214.44.0 and are like this: Routing: Broadcast, Listen (On), RIP V2 Everything works fine. What I am trying to get to work, is if I am a user, dialed into a USR TC hub, which is on 208.214.44.0, I want to be able to go from the hub, right to a server on 208.206.76.0, without going thru the router....... right now it looks like this: ns:~$ traceroute www.shreve.net traceroute to www.shreve.net (208.206.76.5), 30 hops max, 40 byte packets 1 usr2ts1.shreve.net (208.214.44.53) 67.185 ms 68.966 ms 79.603 ms 2 router.shreve.net (208.206.76.1) 79.535 ms 89.231 ms 109.528 ms 3 www.shreve.net (208.206.76.5) 79.454 ms 79.338 ms 79.442 ms I would like it to look like this: ns:~$ traceroute www.shreve.net traceroute to www.shreve.net (208.206.76.5), 30 hops max, 40 byte packets 1 usr2ts1.shreve.net (208.214.44.53) 67.185 ms 68.966 ms 79.603 ms 2 www.shreve.net (208.206.76.5) 79.454 ms 79.338 ms 79.442 ms I am not even sure this is a possibility with the USR Hubs, and equiptment I am using. All the UNIX servers, which reside on 208.206.76.0, have "routed" running. A few questions: 1. Do I have to leave the Cisco multihomed with an ip on both 208.206.76.0 AND 208.214.44.0? 2. How can I get routes to go between network addresses on the same physical ethernet, without going thru the router? 3. I don't have to multihome my servers and tc hubs do I? I mean I am trying to just assign everything an IP on its own network, and not have to get the networks to talk via multihoming. 4. Perhaps there is something that must be done with "netmasks" or "gateways" file? This has me a little confused, probably some of you are doing this now, and could explain it a little. I have read on interior routing protocols, such as the Crab book by O'Reilly, and RIP works nicely when having our TC Hubs route /28's to customers via Radius, the router listens to the broadcasts from the TC Hubs, and everything works great. If this is possible via rip, to have each network be able to talk to one another without going thru the router, than there is more to it than "enable ripv2" I am just looking for a little direction. I really think that the network we have could be alot more efficient if this were to be possible. Thanks, Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: Re: (usr-tc) Routing Question
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-24 15:22:12

Brian said once upon a time: >As far as the secondary address on the Cisco not working very well, I >havent really noticed any problems, or heard of any regarding this. It has been a while (like 9.X days) since I used it, but I just recall bandwidth collapsing on a 2501 when I thew in a secondary. >Putting everything on one subnet is just not viable, we do not have >continginous address space large enough for our growth rate. Sure, one >day they will give us an aggregated block of space, and then things will >be nice, things wont be so difficult. I'm not sure why this is a problem for you. Make a /28 with your TC's, your Ciscos and your servers. Unless you have a huge amount of servers, I don't understand why you couldn't fit everything into this one space. Keep in mind that your modem addresses are in a different subnet. The servers receive routes for them (or you can do this with a static for your pool) and then route packets directly to the TC's. >We have a Catalyst 3200 fully decked out with 100 and 10 base T cards, a >Cisco FastHub 300 also. Is there a way via the Catalyst to get this to >work? See above.

Subject: Re: (usr-tc) Routing Question
From: Brian <signal@shreve.net>
Date: 1997-10-24 16:00:25

On Fri, 24 Oct 1997, Pete Ashdown wrote: > Brian said once upon a time: > > >Everything works fine. What I am trying to get to work, is if I am a > >user, dialed into a USR TC hub, which is on 208.214.44.0, I want to be > >able to go from the hub, right to a server on 208.206.76.0, without going > >thru the router....... > > This won't work. By definition, hubs only switch between ethernet > addresses. Since you are talking about two different subnets, you have to > deal with the router, because only the router can direct packets between > subnets. > > My suggestion with a network the size of yours is to try and get everything > in one subnet (the secondary address on Cisco's doesn't work all that well > anyway) as far as your router, servers, and TC's go. Get your servers > running "gated" with RIPv2 listening. That way, they'll address packets > for the TC's based on ethernet MAC address and you'll avoid the router, > unless it is going outside your network. If it all was on one subnet, I wouldnt have to run gated anyways, because it would just follow the MAC address to begin with. Well thats what I am trying to accomplish, is listening to MAC addresses. But is there a way on the USR TC to listen to MAC addresses from other networks than its own? I mean I turned on ripv2 there, and it still traceroutes through the router instead of going right to the address I would like. As far as the secondary address on the Cisco not working very well, I havent really noticed any problems, or heard of any regarding this. Putting everything on one subnet is just not viable, we do not have continginous address space large enough for our growth rate. Sure, one day they will give us an aggregated block of space, and then things will be nice, things wont be so difficult. > > This gets less and less manageable as your network grows. I was in your > situation once, and now in order to switch as many packets as possible, I'm > looking at a Catalyst 5500. We have a Catalyst 3200 fully decked out with 100 and 10 base T cards, a Cisco FastHub 300 also. Is there a way via the Catalyst to get this to work? /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/

Subject: RE: (usr-tc) Question
From: Andy Yu-Hun Liao <aliao@aicom.com>
Date: 1997-10-24 18:04:41

------ =_NextPart_000_01BCE0A7.4E985E60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The answer is YES. That's what we do here for a very short period of time until we got some = very serious routing problem. =20 The basic is that Netserver's version we used to run doesn't supprt OSPF = nor RIP2. Therefore, the routing to several TCs we have all screw up. Here is what we had. 4 TCs runing on one network (.208) while its IP = assign pool is on another network (.209). This gives us problem because = RIP doesn't support subnet. Therefore, a lot of packet tends to go to = the wrong place. TC1 assign starts 209.1 TC2 assign starts 209.50 Router will either route ALL 209 packets to TC1 or TC2, depending on the = lastest RIP it received. 2 way to solve this, 1. Use RIP2 on Netservers 2. Setup static route in the router Our only solution at that time was not to use this scheme because we = don't have RIP2 nor we had control of the router (our upstream rent us = and don't give us control of it). Andy Yu-Hun Liao System Administrator/Internet Team AICOM Internet Services, a division of AIC Asia International Services = Corporation http://www.aicom.com Voice: (604) 298-2881 Fax: (604) 298-5813 -----Original Message----- Sent: Friday, October 24, 1997 5:10 PM I just want to confirm something: Is it possible to put the netservers/nmc's on one network, yet have them assign there ip's from a different netblock: i.e. netserver ip 208.206.76.50 then on it do "set assigned 208.214.44.1" Brian /-------------------------- signal@shreve.net = | Brian Feeny | USR TC Hubs | ShreveNet Inc. = (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, = | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & = LANs | | 89 CRX, Akimoto intake, DC |-=3D*:Quake:*=3D-| http://www.shreve.net/ = | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 = | \-------------------------- 318-222-2638 x109 = ------ =_NextPart_000_01BCE0A7.4E985E60 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IiwBAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAeAMAAAIAAAAQAAAAAwAAMAMAAAAL AA8OAAAAAAIB/w8BAAAATwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHVzci10Y0BtYWlsLnht aXNzaW9uLmNvbQBTTVRQAHVzci10Y0BtYWlsLnhtaXNzaW9uLmNvbQAAHgACMAEAAAAFAAAAU01U UAAAAAAeAAMwAQAAABkAAAB1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20AAAAAAwAVDAEAAAADAP4P BgAAAB4AATABAAAAGwAAACd1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20nAAACAQswAQAAAB4AAABT TVRQOlVTUi1UQ0BNQUlMLlhNSVNTSU9OLkNPTQAAAAMAADkAAAAACwBAOgEAAAAeAPZfAQAAABkA AAB1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20AAAAAAgH3XwEAAABPAAAAAAAAAIErH6S+oxAZnW4A 3QEPVAIAAAAAdXNyLXRjQG1haWwueG1pc3Npb24uY29tAFNNVFAAdXNyLXRjQG1haWwueG1pc3Np b24uY29tAAADAP1fAQAAAAMA/18AAAAAAgH2DwEAAAAEAAAAAAAAAxAAAAADAAAwBAAAAAsADw4B AAAAAgH/DwEAAABMAAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAEAVVNSb2JvdGljcyBUQyBNYWls aW5nIExpc3QAU01UUAB1c3ItdGNAeG1pc3Npb24uY29tAB4AAjABAAAABQAAAFNNVFAAAAAAHgAD MAEAAAAUAAAAdXNyLXRjQHhtaXNzaW9uLmNvbQADABUMAQAAAAMA/g8GAAAAHgABMAEAAAAbAAAA VVNSb2JvdGljcyBUQyBNYWlsaW5nIExpc3QAAAIBCzABAAAAGQAAAFNNVFA6VVNSLVRDQFhNSVNT SU9OLkNPTQAAAAADAAA5AAAAAAsAQDoAAAAAHgD2XwEAAAAbAAAAVVNSb2JvdGljcyBUQyBNYWls aW5nIExpc3QAAAIB918BAAAATAAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAABAFVTUm9ib3RpY3Mg VEMgTWFpbGluZyBMaXN0AFNNVFAAdXNyLXRjQHhtaXNzaW9uLmNvbQADAP1fAQAAAAMA/18AAAAA AgH2DwEAAAAEAAAAAAAABPbBAQSAAQAWAAAAUkU6ICh1c3ItdGMpIFF1ZXN0aW9uABgHAQWAAwAO AAAAzQcKABgAEgAEACkABQA6AQEggAMADgAAAM0HCgAYABEANAA6AAUAegEBCYABACEAAABEMjQ5 RkE5MDdENENEMTExODU2NjAwODA0OEVDMzQ1RgATBwEDkAYAvAkAACEAAAALAAIAAQAAAAsAIwAA AAAAAwAmAAAAAAALACkAAAAAAAMALgAAAAAAAwA2AAAAAABAADkA4LB2+eHgvAEeAHAAAQAAABYA AABSRTogKHVzci10YykgUXVlc3Rpb24AAAACAXEAAQAAABYAAAABvODh+USQ+knUTH0R0YVmAIBI 7DRfAAAeAB4MAQAAAAMAAABNUwAAHgAfDAEAAAAWAAAAV2luZG93cy9haWNtYWlsL2FsaWFvAAAA AwAGEDtTO8oDAAcQPQYAAB4ACBABAAAAZQAAAFRIRUFOU1dFUklTWUVTVEhBVFNXSEFUV0VET0hF UkVGT1JBVkVSWVNIT1JUUEVSSU9ET0ZUSU1FVU5USUxXRUdPVFNPTUVWRVJZU0VSSU9VU1JPVVRJ TkdQUk9CTEVNVEhFQkEAAAAAAgEJEAEAAACiBgAAngYAAKsKAABMWkZ1QjkhHgMACgByY3BnMTI1 FjIA+Atgbg4QMDMznQH3IAKkA+MCAGNoCsDgc2V0MCAHEwKDAFDjAvIQ2VRhaANxAoMOUKEQdnBy cTIRdn0KgNkIyCA7CW8OMDUCgAqB7HVjAFALA2MSEgvEEyCoaGUgAHF3BJAgBADgIFlFUy4KogqE CoDRGRBhdCcEIHcbARtQsRkwZG8gGSAJcCACEBEFwGEgdgSQeSBzMxNQACAgcAZxBHAgb8hmIHQH cSB1AjADEekbsWdvBUBzA3AZMBzE7R2CdQQgA2B1HhAPIB1gwwNgAmBlbS4gCuMaeNkZMGJhDdEZ snQbcgfA/nQf0RzBGzEcwQCQAiAbou8gIAmAHgAb8HIeYBvRB5BkbicfEXVwFIAFQE8gU1BGIG4F sVJJPFAyIUEZEQlwHGFlLP8i8RkwIFYlEREwHMEHQBMgvkMbQRkwEQAcwBlAbAMg7wTxB9EmEBor SBwiGcEbZvURAGQhQTQpgyVBIJIkYScCIBkwLlB0dwWwayDkKC4B0DgpG1EDECwRnSNwICcQGUAE EGlnA6D8cG8G8BmyJGEAcB8AHBGZLns5KSdDGcFnaRzA3wQgICEg1SJgBZBhJMEm8vclex0yJgBi LoEnTBygCQDnBUAd4QqwY2sRQB4ACfC+ZCLhG/Ae8CUCKCJ3A2CTIKILYGNlGixDMTA23nMBkAAg BCAygS4X4zri8xSwO08uNQFAGkkIACBw9xmRA/AqYWUv0DGiIFIZMPhBTEw8EjfVOJM7AgWx/zzR KAABAB1wOHAt1SgiC2D/O7AHkAVANNIv0CBABZA/0M8cwC0AGjoUsHdhHPAo4q8G8CohIwAEACwa NDEhQP5VNKQUsCRhI1cQwEWUIUD9BmB0JhA7oh4QIrBARAuAtygXBJAaOk8IcC4BbBzx/wbwIHEx MjgxG3IeE0YABCD/MXElAjSSRtIqgRkgHjE0Vr8bsyXCKgNH8ybCLLQgBaD/AjADYAMgHeJLFy7w CGEq4fs7sAlwYTQwCXACMDOSAHD/HcBQtDNCM5JSaS/QMrAaOEcYMgLREiFzMTcaNEFDOHAc8Fl1 LUglUUw9BzBvGjQGsEPBNDBBZD5tC4AEAFKQGxAFsC9JNwIwBJE4IVRUYVilSUPcT00wAFvGBmF2 DeAHkP83MkLgXgAkQx3hXOERcACQvxygW7RKIQIgKWFd1iAIUF5yNcFgQxo1GFJ1AyBoQQJAcDov L3djUC5/C3AFoCEwY7FX42KwPkVWim9eETou8DYwNC9QgDI5OC0yODg8ZahGYXhlWjVmMDNXOokT 0zE2VzpsaTNlgFcKoANgOFBjBUAtarJPFwUQM0Bggk0HkHNhZ/5larMaNmpEPkMLMWpEAgBgaS0x NDQBQGnQMRw4MAFADNBuU2IgRtUDYToMg2IRYEIHIQOgwFtTTVRQOjBiB0CuQB0QCXAcwC4ugV0a NZ9vgAZgAjBv52+gaWRGEJ0oAE9qgCDwGZEyNCgAgDE5OTcgNToPQEggUE1yV1Rvb+dV/lMIAAbg SjEEICmQBdALcL9p0CChWcA7sHJYNiBqanGFb+coICByLXRjL1D+UQpQO7Bh2GzPbdNp1Au28RpJ SSBqICAbkQBwTrP7UmFuIHI0MB8yRtEPIG/gf33qBCBEYTCwMFEhASUCcA8gcCgTLoFIpS9ubWP3 GzEuHCgAeTghKgMoIVx19zBFMZIsEXAbMQNSXmMBIG8cIVTBLoECYG84AICbaV4uOiCC+IcBPBE4 LxE2/C43i0A+NighLiJEUhvhviIRMTA1JOGK425QLm5gvTxQIho6cHMaOho0L2qzf5EvarIdAHFO aqST/5R1XOuVgBpDfHBlRgnhHPCW3W+WAHbxd5JZgGIEIJYAU5dxsyNRXTFjIUAoM27AjCkymhBm ADYzOJexX5WmWmQEIFrbl3ZQBJBsIygAWcBudXiXwVdl/2+AE1B64Q8gKABMoQuAGTB/O7An0V5B mpqY7Jccl+NQlwMQHwGXwUQHMS1VSeALjiJnkDaE4UlTRE5kICZZsEFOmJGVpjiRQQBDUlgoAEFr B3C/HwAb8AuAAZA4ECgARF9wYHwtPSo6erCmsTp4Kj0tlgBib2Nwcagvf2Qml0iVphkgLPAkISgA RWcIcIHQNcNleBEAfsJ8EkwFsGRTcUMvU06/lgCngx/CHMFlUIrpM6rp/5WAlH+R+JnRZgCaJm8g QPG/sW+0aqoAj88aOhVBALegAAADABAQAAAAAAMAERAAAAAAAwCAEP////9AAAcwABEFVuDgvAFA AAgwABEFVuDgvAELAACACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMAAoAIIAYAAAAAAMAA AAAAAABGAAAAABCFAAAAAAAAAwAFgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUAALcNAAAeACWACCAG AAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA4LjAAAwAmgAggBgAAAAAAwAAAAAAAAEYAAAAA AYUAAAAAAAALAC+ACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAMIAIIAYAAAAAAMAAAAAA AABGAAAAABGFAAAAAAAAAwAygAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAeAEGACCAGAAAA AADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgBCgAggBgAAAAAAwAAAAAAAAEYAAAAAN4UA AAEAAAABAAAAAAAAAB4AQ4AIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAAAAAeAD0A AQAAAAUAAABSRTogAAAAAAMADTT9NwAABJw= ------ =_NextPart_000_01BCE0A7.4E985E60--

Subject: RE: (usr-tc) Question
From: Andy Yu-Hun Liao <aliao@aicom.com>
Date: 1997-10-24 18:04:41

The answer is YES. That's what we do here for a very short period of time until we got some = very serious routing problem. =20 The basic is that Netserver's version we used to run doesn't supprt OSPF = nor RIP2. Therefore, the routing to several TCs we have all screw up. Here is what we had. 4 TCs runing on one network (.208) while its IP = assign pool is on another network (.209). This gives us problem because = RIP doesn't support subnet. Therefore, a lot of packet tends to go to = the wrong place. TC1 assign starts 209.1 TC2 assign starts 209.50 Router will either route ALL 209 packets to TC1 or TC2, depending on the = lastest RIP it received. 2 way to solve this, 1. Use RIP2 on Netservers 2. Setup static route in the router Our only solution at that time was not to use this scheme because we = don't have RIP2 nor we had control of the router (our upstream rent us = and don't give us control of it). Andy Yu-Hun Liao System Administrator/Internet Team AICOM Internet Services, a division of AIC Asia International Services = Corporation http://www.aicom.com Voice: (604) 298-2881 Fax: (604) 298-5813 -----Original Message----- Sent: Friday, October 24, 1997 5:10 PM I just want to confirm something: Is it possible to put the netservers/nmc's on one network, yet have them assign there ip's from a different netblock: i.e. netserver ip 208.206.76.50 then on it do "set assigned 208.214.44.1" Brian /-------------------------- signal@shreve.net = | Brian Feeny | USR TC Hubs | ShreveNet Inc. = (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, = | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & = LANs | | 89 CRX, Akimoto intake, DC |-=3D*:Quake:*=3D-| http://www.shreve.net/ = | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 = | \-------------------------- 318-222-2638 x109 =

Subject: (usr-tc) Question
From: Brian <signal@shreve.net>
Date: 1997-10-24 19:09:50

Subject: (usr-tc) Channelized T1 versus PRI?
From: Brian Elfert <brian@citilink.com>
Date: 1997-10-24 20:01:57

Has anyone tested a channelized B8ZS/ESF T1 versus PRI, both from the same switch? This is for a USR Total Control chassis, of course. I'm particularly interested in x2 performance, but I'd also be interested in V.34 performance too. What I'm doing is transitioning my dedicated line customers off of a MP/8I using BRI lines to a Total Control chassis. I'd like to use channelized T1, but I'm afraid that the speed difference might be too great. PRI is about double the cost of channelized T1. Both the PRI and the channelized T1 would be off of the same switch. Brian

Subject: Re: (usr-tc) Question
From: David Bolen <db3l@ans.net>
Date: 1997-10-24 20:32:58

Brian <signal@shreve.net> writes: > Is it possible to put the netservers/nmc's on one network, yet have them > assign there ip's from a different netblock: Sure - in fact that's probably the most typical method of doing it, since it separates out your network addressing and equipment from the dialup users (for routing purposes, filtering, etc..). I would definitely suggest doing it this way if only because of the possibility for separation of administrative control over the two types of network blocks. You will need to set up routing to know to use which NETServer to reach the appropriate dialup prefix (either dynamically or statically). If you had been using addresses from the same prefix that the NETServer thinks is on its local ethernet, then you can get away without doing this since the NETServer will proxy-arp any requests for its dialup users. At our dialup nodes, the ethernet addressing is from address blocks we use just for our equipment. Dialup addressing is from a different block. Overall blocks for a single site are statically configured into the site routers to announce to the backbone (that prevents flapping just due to dialup user access). We then let the NETServers announce individual dialup users to the local site routers with RIP so that the site router gets the next hop right. Providing you're only dealing with single IP dialup users (no LAN dialup) you can do this fine with RIPv1 - just set the netmask table on the NETServer to force it to announce all dialup prefixes as host routes. In our case the site router is a Cisco. It has a static route to Null0 for the site prefix, which is distributed into BGP/OSPF for backbone announcement. So any traffic for dialup users at that site will always get to that Cisco but will be dropped if that particular address isn't currently assigned. The Cisco is then configured to listen to RIP (no announcement in our case), but not redistribute RIP into any other protocols, and the NETServer to announce RIP with a host level netmask. Oh, and our other NETServers listen to RIP as well. What this does is as a dialup user comes in, the address is assigned and then that local NETServer announces it's availability in a flash RIP update (and then later in the periodic RIP update). The Cisco (and other NETServers) hear about the host route and install it in their table. For other NETServers at the site, they default to the local gateway, or will directly hop to the appropriate NETServer if one customer tries to talk to another at that site, since they have the host route. For backbone traffic to a dialup customer it arrives at the local Cisco due to the general site-level prefix sent to the backbone, and then the Cisco will follow the next hop NETServer in the local routing table as discovered by RIP. In the case of LAN dialup, if you were using classless prefixes for the dialup users, you'd need to enable RIPv2 on the NETServers such that the prefixes were communicated properly among local equipment at the site. -- 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) Question
From: David Bolen <db3l@ans.net>
Date: 1997-10-24 21:18:11

Andy Yu-Hun Liao <aliao@aicom.com> writes: > Here is what we had. 4 TCs runing on one network (.208) while its IP = > assign pool is on another network (.209). This gives us problem because = > RIP doesn't support subnet. Therefore, a lot of packet tends to go to = > the wrong place. Well, RIP doesn't support subnets, but it does support host routes as opposed to network routes. > TC1 assign starts 209.1 > TC2 assign starts 209.50 > > Router will either route ALL 209 packets to TC1 or TC2, depending on the = > lastest RIP it received. As long as you are assigning individual addresses to users, just put an entry in your netmask table for the 209 network or networks using 255.255.255.255. Then, your NETServers will include each dialup user individually in their RIP announcement as host routes and you won't have a problem with the overall route oscillating. This works quite a ways back in terms of NETServer releases (back before they added RIPv2). -- 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) x2 users connect speed
From: John Arden <jarden@server.delrio.com>
Date: 1997-10-25 16:12:24

I have got a small handful (6) of x2 users (courier & sporster) that are having all kind of problems getting an x2 connect. Initially I had wrote it off as the user having a bad line as the other 95% of my x2 customers are doing great. I have one very enthustatic user who has spent quite a bit of time of on the phone with USR trying to resolve this problem Also these users can connect to the USR bbs's at x2 speeds but cannot get anything over 28.8K here. At this point I'm not sure where to go. I would sure entertain any suggestions. TIA for any responses. jarden@mail.delrio.com

Subject: (usr-tc) RE: (USR-TC) TCENEMA SCRIPT & INVESTING IN TCM
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1997-10-26 07:26:00

-> Unfortunately, there's a lot of "preaching to the choir" on this list. I'm -> not sure how much of USR's management is really listening, and I believe -> most of the techs who are listening would agree with most of our points. -> I know for a fact that TCM was contracted. USR probably can't put out other -> versions because they didn't contract for the other versions. I'm not sure -> if USR even owns the source-code. -> -> The issue with Quake lag is another story. I think most of the engineering -> emphasis in the past year has been to get off of ComOS and onto their own -> code. In other words, they don't want to spend much time fixing bugs with -> the ComOS based code if they're going to replace it in entirety anyway. From my experieince working with large companies and numerous vendors, your best recourse is the sales department. They generally have much more acess to the ears of those who can implement change since they can tie problems to revenue streams. I'd suggest going after the ISP reps at 3Com. I've had pretty good sucess with them. Jeff Binkley ASA Network Computing

Subject: (usr-tc) RE: (USR-TC) TCENEMA SCRIPT & INVESTING IN TCM
From: Allen Marsalis <am@shreve.net>
Date: 1997-10-26 12:12:38

At 07:26 AM 10/26/97 -0500, you wrote: >-> Unfortunately, there's a lot of "preaching to the choir" on this list. I'm >-> not sure how much of USR's management is really listening, and I believe >-> most of the techs who are listening would agree with most of our points. >-> I know for a fact that TCM was contracted. USR probably can't put out other >-> versions because they didn't contract for the other versions. I'm not sure >-> if USR even owns the source-code. >-> >-> The issue with Quake lag is another story. I think most of the engineering >-> emphasis in the past year has been to get off of ComOS and onto their own >-> code. In other words, they don't want to spend much time fixing bugs with >-> the ComOS based code if they're going to replace it in entirety anyway. > >>From my experieince working with large companies and numerous vendors, your >best recourse is the sales department. They generally have much more acess to >the ears of those who can implement change since they can tie problems to >revenue streams. I'd suggest going after the ISP reps at 3Com. I've had >pretty good sucess with them. > >Jeff Binkley >ASA Network Computing > Ya know, that a good idea.. I would much rather give a salesperson a hard time about overdue updates and bug fixes, etc. than an "engineer" (good or bad)... My rep used to be Tom Goodman at USR and he _was_ a really good salesman (and knowledgeable too). But of course they moved him up and I have a new salesperson who seems to think we're gone too.. It's almost like when you buy your first box, they know they have you hooked, and don't have to try so hard.. What I would really like to see is the email address <management@usr.com>.. But the sales department is probably the closest you can get with large corporations.. Now that USR and 3COM are one, do they still have separate ISP reps for both or did they consolidate?.. Just wondering if there is "another tree to climb".. Anyway they finally seem to be addressing our main problem (quake lag) so hopfully my wrath will be spared.. Allen Marsalis ShreveNet, Inc.

Subject: RE: (usr-tc) Channelized T1 versus PRI?
From: Marshall Morgan <marshall@netdoor.com>
Date: 1997-10-26 12:32:26

On Friday, October 24, 1997 8:02 PM, Brian Elfert [SMTP:brian@citilink.com] wrote: > Has anyone tested a channelized B8ZS/ESF T1 versus PRI, both from the same > switch? This is for a USR Total Control chassis, of course. > > I'm particularly interested in x2 performance, but I'd also be interested > in V.34 performance too. > > What I'm doing is transitioning my dedicated line customers off of a MP/8I > using BRI lines to a Total Control chassis. I'd like to use channelized > T1, but I'm afraid that the speed difference might be too great. PRI is > about double the cost of channelized T1. Both the PRI and the channelized > T1 would be off of the same switch. > > Brian > We have both B8ZS/ESF CT1 and PRI installed in different citys/same switch type and have not seen a significant average connect rate difference between the two. The sample is over a few hundred lines for more than 90 days worth of calls. BTW: Remember to get Trunk Side connections! Marshall Morgan http://www.netdoor.com 601.969.1434 | Fax 601.969.3838 | 800.952.1570

Subject: RE: (usr-tc) Glueing Networks
From: Marshall Morgan <marshall@netdoor.com>
Date: 1997-10-26 12:56:11

On Thursday, October 23, 1997 3:51 PM, Brian [SMTP:signal@shreve.net] wrote: > On Thu, 23 Oct 1997, Jeff Mcadams wrote: > > > Thus spake Brian > > >Now, because USR TC's, DO NOT support OSPF, what I am currently doing, is > > >enabling RIP on our Cisco, enabling Broadcast on our TC hubs, and > > >basically multiplying packets on our Ethernet * 2. > > > > set ripv2 on > > > > :) > > > > ripv2 supports classless addressing. > > Yeah, ripv2 is on, and I am Broadcasting rip, thats what I am saying. But > how does that allow me to "glue" the networks? They still have to go thru > the Cisco. Brian, On our Cisco routers we do something like the following where locations have more than one TC: ip route 208.137.132.0 255.255.255.192 208.148.192.10 ip route 208.137.132.64 255.255.255.192 208.148.192.12 ip route 208.137.132.128 255.255.255.192 208.148.192.14 ip route 208.137.132.192 255.255.255.192 208.148.192.16 As you can see, we just send 64 IP's to each NETServer ... using .1, .65, .129, and .193 as the beginning of the assigned addresses for each terminal server ... which are on the LAN of 208.148.192.x in this example. Set broadcast on the Ethernet as well. BTW: Most packets are probably not destined for your local network. Marshall Morgan http://www.netdoor.com 601.969.1434 | Fax 601.969.3838 | 800.952.1570

Subject: Re: (usr-tc) x2 users connect speed
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-10-27 09:11:28

Is it possible for you to get me the syslog from your netserver when this problem starts ? krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Mon, 27 Oct 1997, Greg Gibson wrote: > We've reset, even re-seated, every card in the machine and this did not > cure the busy/ring no answer problem. This problem is has been > intermittent, mind you, and we have yet to determine what sets it off. > > What we have seen is that a modem card will start to reject calls. If we > reset that card it will begin taking calls again, but the card next to it > will reject calls when the lines fill up to that point, and we end up > resetting every single modem in unit. Then it will run for a period of time > (sometimes a couple of days, sometimes a few hours) before it begins > rejecting calls again. > > The reason we originally thought it was a telco problem was because we have > also seen this behavior on our PM3s...Livingston told us to upgrade our > ComOS to 3.7.1 and that would fix it...since upgrading we haven't seen this > problem on the PM3s anymore, but we have seen it on the Total Control > unit...just last night as a matter of fact. > > gg > > > At 02:01 PM 10/27/97 -0600, you wrote: > > > > > >On Mon, 27 Oct 1997, David Bolen wrote: > > > >> > Please report back. I've seen similar results with 2.5.1. > >> > >> One question to both of these points - when upgrading to 2.5.1, did > >> you instruct all modems to restore from one of the hardware templates, > >> and then re-issue any special settings, or did you just upgrade and > >> leave all settings alone. I would definitely recommend the former, > >> and I know that there was a variety of "interesting" and ambiguous > >> behavior during some of the x2 releases without doing that. If that > >> happens to match these cases, then restoring to 2.5 may "fix" the > >> problem, but only because it's been restored to a build expecting the > >> appropriate internal registers and such as they are. > > > >David's absolutely right here. When I upgraded to 2.5.1, all of my modems > >either wouldn't answer or did V.34 only until I do a reset on every modem. > > > >Brian > > > > > > > >

Subject: Re: (usr-tc) bug in USR Netserver software
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-10-27 09:35:03

Yes this is a bug with the NETServer, we shall log it and fix it soon. No radius server should crash due to this, atleast I have not seen any fail due to this. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Mon, 27 Oct 1997, David Bolen wrote: > Erik Bos <erik@xs4all.net> writes: > > > The length of the User-Password attribute (at offset 0x1f) should be at > > least 0x12 (that includes two bytes for the identifier and its length) > > instead of 0x02. > > Hey, yep - looks like a bug. It seems to happen even in challenges if > you enter an empty string. > > As for the correct length it must be at least 16 bytes (payload) but > also must be a multiple of 16 given the MD5 encoding algorithm that > requires padding the password to a multiple of 16 characters. > > > Most RADIUS servers I'm aware of assume that this attribute is at least 16 > > bytes long, this might result in (serious) problems caused by memory > > corruption. > > Well, regardless of the NETServer bug, if a server blows up or has a > problem because of this that's a bug in the server, IMO. No matter > what a client generates in a packet, compliant or not, the server > should be able to handle it, refusing it if it wants, but certainly > not crashing or corrupting memory or anything. The 'ol IETF adage of > being conservative in what you send but flexible in what you'll > receive. > > -- 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) Is there a way to get the TC Ripv2 to only broadcast
From: Jaye Mathisen <mrcpu@cdsnet.net>
Date: 1997-10-27 10:24:07

the network route, and not the host routes? A vast majority of my customers are dynamic, and I don't need their /32's filling up the RIP tables, but it would be nice to just assign a subnet to the netserver card, and have it generate the proper network route to advertise, then let individual users that need static IP's broadcast the appropriate /32's.

Subject: (usr-tc) HCU vs NMC
From: Brian Elfert <brian@citilink.com>
Date: 1997-10-27 11:17:38

What is the difference between a Hub Control Unit, and an NMC card? Can the HCU do x2? Brian

Subject: Re: (usr-tc) x2 users connect speed
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-27 12:23:24

Greg Gibson said once upon a time: >At first we thought there was a telco problem, but now we believe it is >something within the Total Control hub. We went back today and reflashed >the unit with the previous version (2.5) to see if this cures our ills. Please report back. I've seen similar results with 2.5.1.

Subject: Re: (usr-tc) Mail.Only Filter
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-27 13:16:43

Wayne Jordan said once upon a time: >I need help on creating a mail.only filter in a usr-tc hub. Any help would >be appreciated other than look in the manual :-). Plug in everything but the comments. X.X.X.X is our DNS server, Y.Y.Y.Y is the mail server and the secondary DNS server. Both X.X.X.X and Y.Y.Y.Y and our web servers are in the same subnet. Add "mail" to your RADIUS Filter-Id profile. del filter mail.in del filter mail.out add filter mail.in # POP passwd set filter mail.in 1 permit 0.0.0.0/0 Y.Y.Y.Y/32 tcp dst eq 106 # POP2 set filter mail.in 2 permit 0.0.0.0/0 Y.Y.Y.Y/32 tcp dst eq 109 # POP3 set filter mail.in 3 permit 0.0.0.0/0 Y.Y.Y.Y/32 tcp dst eq 110 # IMAP set filter mail.in 4 permit 0.0.0.0/0 Y.Y.Y.Y/32 tcp dst eq 143 # SMTP set filter mail.in 5 permit 0.0.0.0/0 Y.Y.Y.Y/32 tcp dst eq 25 # DNS udp responses set filter mail.in 6 permit 0.0.0.0/0 X.X.X.X/32 udp dst eq 53 set filter mail.in 7 permit 0.0.0.0/0 Y.Y.Y.Y/32 udp dst eq 53 set filter mail.in 8 permit 0.0.0.0/0 X.X.X.X/32 tcp dst eq 53 set filter mail.in 9 permit 0.0.0.0/0 Y.Y.Y.Y/32 tcp dst eq 53 # Our web servers only set filter mail.in 10 permit 0.0.0.0/0 Y.Y.Y.0/24 tcp dst eq 80 set filter mail.in 11 permit 0.0.0.0/0 Y.Y.Y.0/24 tcp dst eq 8000 set filter mail.in 12 permit 0.0.0.0/0 Y.Y.Y.0/24 tcp dst eq 443 # Block everything else set filter mail.in 13 deny 0.0.0.0/0 0.0.0.0/0 add filter mail.out # Established TCP connections set filter mail.out 1 permit Y.Y.Y.0/24 0.0.0.0/0 tcp estab # DNS udp responses set filter mail.out 2 permit Y.Y.Y.Y/32 0.0.0.0/0 udp src eq 53 set filter mail.out 3 permit X.X.X.X/32 0.0.0.0/0 udp src eq 53 # Block everything else set filter mail.out 4 deny 0.0.0.0/0 0.0.0.0/0 save all

Subject: Re: (usr-tc) x2 users connect speed
From: David Bolen <db3l@ans.net>
Date: 1997-10-27 13:20:58

John Arden <jarden@server.delrio.com> writes: > Also these users can connect to the USR bbs's at x2 speeds but cannot > get anything over 28.8K here. At this point I'm not sure where to go. > I would sure entertain any suggestions. Are those users making a local phone call into your equipment, but a long distance call into the USR BBS? If so, then the behavior they see could very well be a "problem" with their local phone connection - there are cases where a local phone call is routed through older switching paths within a telco, of which some of those paths may introduce additional A/D conversions. However, the same call made to a long distance number often gets shunted over newer larger trunks to a long distance exchange point and doesn't introduce any problems. (Interestingly enough, this is a general issue with any of the newer PCM protocols - it may be more common to have better long distance connections than local connections - if the two differ at all - than the reverse) I would suggest having your users check an ATY11 output (and perhaps the SNR on an ATI11) after making both a call to the USR BBS and to your number. The key is going to be the high end frequency response, but the general thing to look for is whether or not the values differ significantly. If they do (and probably best to try a few calls to be sure), then the odds are very good the two calls are following different paths, each of which can result in very different x2 behavior. -- 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) Mail.Only Filter
From: Wayne Jordan <wjordan@pcl.net>
Date: 1997-10-27 13:24:55

------ =_NextPart_000_01BCE2DB.B82CF300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I need help on creating a mail.only filter in a usr-tc hub. Any help would be appreciated other than look in the manual :-). Thanks. Wayne Jordan President PC Land, Inc. ------ =_NextPart_000_01BCE2DB.B82CF300 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IjkTAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAyAEAAAEAAAAQAAAAAwAAMAIAAAAL AA8OAAAAAAIB/w8BAAAATwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHVzci10Y0BtYWlsLnht aXNzaW9uLmNvbQBTTVRQAHVzci10Y0BtYWlsLnhtaXNzaW9uLmNvbQAAHgACMAEAAAAFAAAAU01U UAAAAAAeAAMwAQAAABkAAAB1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20AAAAAAwAVDAEAAAADAP4P BgAAAB4AATABAAAAGwAAACd1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20nAAACAQswAQAAAB4AAABT TVRQOlVTUi1UQ0BNQUlMLlhNSVNTSU9OLkNPTQAAAAMAADkAAAAACwBAOgEAAAAeAPZfAQAAABkA AAB1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20AAAAAAgH3XwEAAABPAAAAAAAAAIErH6S+oxAZnW4A 3QEPVAIAAAAAdXNyLXRjQG1haWwueG1pc3Npb24uY29tAFNNVFAAdXNyLXRjQG1haWwueG1pc3Np b24uY29tAAADAP1fAQAAAAMA/18AAAAAAgH2DwEAAAAEAAAAAAAAArFkAQSAAQARAAAATWFpbC5P bmx5IEZpbHRlcgDZBQEFgAMADgAAAM0HCgAbAA0AGAA3AAEAVgEBIIADAA4AAADNBwoAGwANABcA JQABAEMBAQmAAQAhAAAAQjhDQUU2RjlDOTRFRDExMTg1MTIwODAwMDlFRjA1QTAAJgcBA5AGACwE AAAhAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAAAAAAQAA5 AMBm3AEO47wBHgBwAAEAAAARAAAATWFpbC5Pbmx5IEZpbHRlcgAAAAACAXEAAQAAABYAAAABvOMO AbP55sq5TskR0YUSCAAJ7wWgAAAeAB4MAQAAAAUAAABTTVRQAAAAAB4AHwwBAAAAEAAAAHdqb3Jk YW5AcGNsLm5ldAADAAYQiuNyRAMABxCGAAAAHgAIEAEAAABlAAAASU5FRURIRUxQT05DUkVBVElO R0FNQUlMT05MWUZJTFRFUklOQVVTUi1UQ0hVQkFOWUhFTFBXT1VMREJFQVBQUkVDSUFURURPVEhF UlRIQU5MT09LSU5USEVNQU5VQUw6LSlUSAAAAAACAQkQAQAAAB4BAAAaAQAAZAEAAExaRnVFYYpR AwAKAHJjcGcxMjUWMgD4C2BuDhAwMzOdAfcgAqQD4wIAY2gKwGBzZXQwIAcTAoB9swqACMggOwlv DjA1AoDZCoF1YwBQCwNjAEELtRAgSSBuCeBkIGhQZWxwIAIgIAUAZYRhdAuAZyBhIADAhQMQLgIg bHkgZgMQGnQEkCALgBcxdXNyiC10YxYgdWIuEXBWbhfgFjN3CGBsFhBi0mUXMHBwCXBjBzAYMPkW EG90FjAFwBtwA5EJAJxvaxhiG3EXUW51B0DgIDotKS4KogqECoASVBvRa3Mde1dheWkV4CBKBbBk AHAdhFAfCXAAkAEAAjAgNUMgTMkAcGQsFbBuYx1wFQAXAUAdkxHxACMwAAADABAQAAAAAAMAERAB AAAAAwCAEP////9AAAcwwLct0w3jvAFAAAgwwLct0w3jvAELAACACCAGAAAAAADAAAAAAAAARgAA AAADhQAAAAAAAAMAAoAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAFgAggBgAAAAAAwAAA AAAAAEYAAAAAUoUAALcNAAAeACWACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA4LjAA AwAmgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALAC+ACCAGAAAAAADAAAAAAAAARgAAAAAO hQAAAAAAAAMAMIAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAygAggBgAAAAAAwAAAAAAA AEYAAAAAGIUAAAAAAAAeAEGACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgBC gAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4AQ4AIIAYAAAAAAMAAAAAAAABG AAAAADiFAAABAAAAAQAAAAAAAAAeAD0AAQAAAAEAAAAAAAAAAwANNP03AADcug== ------ =_NextPart_000_01BCE2DB.B82CF300--

Subject: Re: (usr-tc) HCU vs NMC
From: David Bolen <db3l@ans.net>
Date: 1997-10-27 13:27:37

> What is the difference between a Hub Control Unit, and an NMC card? The HCU (I had read, never had one myself) was a version of the older RCU for a TC hub. The RCU was the controller for the precurser (TC "rackmount") chassis, before the current chassis (originally called the enterprise network hub) became available. The HCU and NMC are completely different beasts, with the HCU using whatever proprietary management protocol the RCU had implemented, which interoperated with the older management software. The NMC uses a standard IP and SNMP stack to perform the management. > Can the HCU do x2? I presume you mean can it "activate" the x2 feature, since neither the NMC (nor presumably the HCU) actually "do" x2 - that's in the modem. However, if the modem itself is not permanently x2 activated (you can order them that way from USR), then you do need to activate the feature via the NMC. I don't know if the HCU has anything similar - heck, I would have guessed that you couldn't even buy HCUs any more, but I might be wrong. -- 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) x2 users connect speed
From: Greg Gibson <gg@pressroom.com>
Date: 1997-10-27 13:41:19

At 04:12 PM 10/25/97 -0500, you wrote: >I have got a small handful (6) of x2 users (courier & sporster) that are >having all kind of problems getting an x2 connect. Initially I had wrote >it off as the user having a bad line as the other 95% of my x2 customers >are doing great. Since upgrading our our TC chassis to the latest 2.5.1 software we have had a number of similar problems. We have seen busy signals on the unit when plenty of modems were available, rings with no answer, and we have a dozen or so X2 users who say they were getting high connect rates at one time, but since our problems started they cannot connect at X2 at all. We DO have people getting X2 connects, but we have several people who are no longer getting X2s...and some of these people were getting 50k+ connects with us previously. At first we thought there was a telco problem, but now we believe it is something within the Total Control hub. We went back today and reflashed the unit with the previous version (2.5) to see if this cures our ills. We've spent a lot of time on the phone with both USR and the telco. We've gotten far better support from the phone company than we have gotten from USR for support that we are paying for. gg

Subject: Re: (usr-tc) x2 users connect speed
From: Brian Elfert <brian@citilink.com>
Date: 1997-10-27 14:01:49

On Mon, 27 Oct 1997, David Bolen wrote: > > Please report back. I've seen similar results with 2.5.1. > > One question to both of these points - when upgrading to 2.5.1, did > you instruct all modems to restore from one of the hardware templates, > and then re-issue any special settings, or did you just upgrade and > leave all settings alone. I would definitely recommend the former, > and I know that there was a variety of "interesting" and ambiguous > behavior during some of the x2 releases without doing that. If that > happens to match these cases, then restoring to 2.5 may "fix" the > problem, but only because it's been restored to a build expecting the > appropriate internal registers and such as they are. David's absolutely right here. When I upgraded to 2.5.1, all of my modems either wouldn't answer or did V.34 only until I do a reset on every modem. Brian

Subject: Re: (usr-tc) x2 users connect speed
From: matthew <matthew@the-spa.com>
Date: 1997-10-27 14:06:10

usually it turns out to be someone who takes a very bad path between them and you through an outdated telco switch/co that they don't pass through if they call other numbers. matthew At 04:12 PM 10/25/97 -0500, you wrote: >I have got a small handful (6) of x2 users (courier & sporster) that are >having all kind of problems getting an x2 connect. Initially I had wrote >it off as the user having a bad line as the other 95% of my x2 customers >are doing great. I have one very enthustatic user who has spent quite >a bit of time of on the phone with USR trying to resolve this problem >Also these users can connect to the USR bbs's at x2 speeds but cannot >get anything over 28.8K here. At this point I'm not sure where to go. >I would sure entertain any suggestions. > >TIA for any responses. > >jarden@mail.delrio.com > >

Subject: (usr-tc) WTB: PRI or T1 NIC/NAC set
From: Brian Elfert <brian@citilink.com>
Date: 1997-10-27 14:06:42

I'm looking to buy a PRI or T1 NIC/NAC set (latest rev that's flashable between T1 and PRI). Anybody have one for sale? Brian

Subject: Re: (usr-tc) x2 users connect speed
From: David Bolen <db3l@ans.net>
Date: 1997-10-27 14:28:02

Pete Ashdown <pashdown@xmission.com> writes: > Greg Gibson said once upon a time: > > >At first we thought there was a telco problem, but now we believe it is > >something within the Total Control hub. We went back today and reflashed > >the unit with the previous version (2.5) to see if this cures our ills. > > Please report back. I've seen similar results with 2.5.1. One question to both of these points - when upgrading to 2.5.1, did you instruct all modems to restore from one of the hardware templates, and then re-issue any special settings, or did you just upgrade and leave all settings alone. I would definitely recommend the former, and I know that there was a variety of "interesting" and ambiguous behavior during some of the x2 releases without doing that. If that happens to match these cases, then restoring to 2.5 may "fix" the problem, but only because it's been restored to a build expecting the appropriate internal registers and such as they are. -- 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) netMedic
From: Michael Wronski <mwronski@coredump.ae.usr.com>
Date: 1997-10-27 14:37:16

Microsoft has also gotten into the game. ============= VitalSigns' Net.Medic Chosen by Microsoft as Best-of-Breed Internet Utility for Internet Explorer Plus Net.Medic SE included in Internet Explorer Plus for Internet Performance Monitoring SANTA CLARA, Calif., Oct. 27 /PRNewswire/ -- VitalSigns Software, Inc., a leading provider of software solutions that improve the end user's network experience, today announced that Microsoft has included VitalSigns' Net.Medic(TM) SE as an added feature to its Internet Explorer Plus. Net.Medic SE gives end users the ability to monitor, diagnose and correct the performance of their end-to-end Internet connection. Microsoft Internet Explorer Plus, including Net.Medic SE, is available at major retail outlets. ``Offering Net.Medic SE as an added feature to Internet Explorer Plus supports our commitment to providing users with comprehensive and powerful functionality in a browser suite,'' Yusuf Mehdi, director of marketing, applications and Internet client group at Microsoft Corporation. ``As an added utility to Internet Explorer, Net.Medic's performance monitoring and reporting capabilities will provide our users with a unique insight into their Internet experience.'' ============== `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' Mike Wronski(mwronski@coredump.ae.usr.com) 3Com/U.S.Robotics Network Systems Engineer (Level 3) PGP: http://coredump.ae.usr.com/pgp

Subject: Re: (usr-tc) x2 users connect speed
From: Greg Gibson <gg@pressroom.com>
Date: 1997-10-27 14:55:11

At 02:28 PM 10/27/97 EST, you wrote: >One question to both of these points - when upgrading to 2.5.1, did >you instruct all modems to restore from one of the hardware templates, >and then re-issue any special settings, or did you just upgrade and >leave all settings alone. Dave...we were using default settings on the modem...we weren't doing anything fancy...just inbound calls over PRI. When we upgraded, we simply ran the Software Download in TCM and left it alone. gg

Subject: Re: (usr-tc) bug in USR Netserver software
From: David Bolen <db3l@ans.net>
Date: 1997-10-27 15:02:01

Erik Bos <erik@xs4all.net> writes: > The length of the User-Password attribute (at offset 0x1f) should be at > least 0x12 (that includes two bytes for the identifier and its length) > instead of 0x02. Hey, yep - looks like a bug. It seems to happen even in challenges if you enter an empty string. As for the correct length it must be at least 16 bytes (payload) but also must be a multiple of 16 given the MD5 encoding algorithm that requires padding the password to a multiple of 16 characters. > Most RADIUS servers I'm aware of assume that this attribute is at least 16 > bytes long, this might result in (serious) problems caused by memory > corruption. Well, regardless of the NETServer bug, if a server blows up or has a problem because of this that's a bug in the server, IMO. No matter what a client generates in a packet, compliant or not, the server should be able to handle it, refusing it if it wants, but certainly not crashing or corrupting memory or anything. The 'ol IETF adage of being conservative in what you send but flexible in what you'll receive. -- 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) x2 users connect speed
From: Greg Gibson <gg@pressroom.com>
Date: 1997-10-27 15:52:35

We've reset, even re-seated, every card in the machine and this did not cure the busy/ring no answer problem. This problem is has been intermittent, mind you, and we have yet to determine what sets it off. What we have seen is that a modem card will start to reject calls. If we reset that card it will begin taking calls again, but the card next to it will reject calls when the lines fill up to that point, and we end up resetting every single modem in unit. Then it will run for a period of time (sometimes a couple of days, sometimes a few hours) before it begins rejecting calls again. The reason we originally thought it was a telco problem was because we have also seen this behavior on our PM3s...Livingston told us to upgrade our ComOS to 3.7.1 and that would fix it...since upgrading we haven't seen this problem on the PM3s anymore, but we have seen it on the Total Control unit...just last night as a matter of fact. gg At 02:01 PM 10/27/97 -0600, you wrote: > > >On Mon, 27 Oct 1997, David Bolen wrote: > >> > Please report back. I've seen similar results with 2.5.1. >> >> One question to both of these points - when upgrading to 2.5.1, did >> you instruct all modems to restore from one of the hardware templates, >> and then re-issue any special settings, or did you just upgrade and >> leave all settings alone. I would definitely recommend the former, >> and I know that there was a variety of "interesting" and ambiguous >> behavior during some of the x2 releases without doing that. If that >> happens to match these cases, then restoring to 2.5 may "fix" the >> problem, but only because it's been restored to a build expecting the >> appropriate internal registers and such as they are. > >David's absolutely right here. When I upgraded to 2.5.1, all of my modems >either wouldn't answer or did V.34 only until I do a reset on every modem. > >Brian > > >

Subject: Re: (usr-tc) netMedic
From: Adam Wills (Global 2000) <sysadmin@global2000.net>
Date: 1997-10-27 16:26:39

Yes, I saw this annoucement earlier too. My response to USR is "just because someone is jumping off a bridge, are you going to follow?". Netmedic is the worste piece of $>:t out there- and it only serves to seperate you from ISP's to support it. MS has no reason to support ISP's or provide anything that will make ISP's happy. USR/3com on the other hand, last I checked, still sells products direct for ISP's and end customers- and guess what, about 50% of all new modem purchases my customers make are done on recomendations from our staff on which brand to offer. I assure you we have not recomended one vendor yet that supports let alone includes NetMedic software- to date no-one is shipping anything WITH netmedic, but I seriously hope USR reconsiders its stance on this one. About how much easier my life became from going from terminal servers and analog modems to USR Tc's is about how much worse my life will become from all my customers getting Netmedic and having it bogus report about my ingress router (cisco 7506) being overloaded, and our 2 gig-abit backplane to our WWW servers being unreachible due to congestion or some other b.s. Anyway, Just because The devil (MS) dances with Vital Signs, doesn't mean USR should too. Adam Wills Global 2000 Communications Director of Networking Systems 1840 Western Ave. sysadmin@global2000.net Albany, NY, 12203 http://www.global2000.net (518) 452-1465 On Mon, 27 Oct 1997, Michael Wronski wrote: > Microsoft has also gotten into the game. > > ============= > VitalSigns' Net.Medic Chosen by Microsoft as Best-of-Breed Internet Utility > for Internet Explorer Plus > > Net.Medic SE included in Internet Explorer Plus for Internet Performance > Monitoring > > SANTA CLARA, Calif., Oct. 27 /PRNewswire/ -- VitalSigns Software, Inc., a > leading provider of software solutions that improve the end user's > network experience, today announced that Microsoft has included VitalSigns' > Net.Medic(TM) SE as an added feature to its Internet Explorer Plus. > Net.Medic SE gives end users the ability to monitor, diagnose and correct > the performance of their end-to-end Internet connection. Microsoft Internet > Explorer Plus, including Net.Medic SE, is available at major retail outlets. > > ``Offering Net.Medic SE as an added feature to Internet Explorer Plus > supports our commitment to providing users with comprehensive and powerful > functionality in a browser suite,'' Yusuf Mehdi, director of marketing, > applications and Internet client group at Microsoft Corporation. ``As an added > utility to Internet Explorer, Net.Medic's performance monitoring and reporting > capabilities will provide our users with a unique insight into their Internet > experience.'' > ============== > > `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' > Mike Wronski(mwronski@coredump.ae.usr.com) 3Com/U.S.Robotics > Network Systems Engineer (Level 3) > PGP: http://coredump.ae.usr.com/pgp > > > > >

Subject: (usr-tc) bug in USR Netserver software
From: Erik Bos <erik@xs4all.net>
Date: 1997-10-27 20:00:30

FYI: Some versions of USR's netserver software send RADIUS authentication requests that do not conform to RFC2138. When a user tries to login without a password (he or she simply hits return when prompted for a password) the NAS will send a authentication request with User-Password's length set to 0 instead of 16: A packet sent by a USR TC rack running 3.5.34: 0000 01 ca 00 b4 53 29 6f 37 61 77 29 68 70 70 22 22 0010 70 6f 21 3e 01 0a 61 6c 61 73 64 61 69 72 02 02 ** 0020 04 06 c2 6d 06 b4 05 06 00 00 00 1d 06 06 00 00 0030 00 02 07 06 00 00 00 01 1a 0e 00 00 01 ad 00 00 0040 90 23 00 00 00 15 1a 0e 00 00 01 ad 00 00 00 6c 0050 00 00 00 13 1a 0e 00 00 01 ad 00 00 00 99 00 00 0060 00 03 1a 0e 00 00 01 ad 00 00 00 c7 00 00 00 01 0070 1a 0e 00 00 01 ad 00 00 90 19 00 00 00 00 1a 0e 0080 00 00 01 ad 00 00 90 1a 00 00 00 00 1a 0e 00 00 0090 01 ad 00 00 90 1b 00 00 00 00 20 0a 61 73 64 2d 00a0 75 73 72 31 2c 0a 30 30 30 37 30 30 34 46 3d 06 00b0 00 00 00 00 The length of the User-Password attribute (at offset 0x1f) should be at least 0x12 (that includes two bytes for the identifier and its length) instead of 0x02. Section 5.2 of RFC2138: 5.2. User-Password [...] Type 2 for User-Password. Length At least 18 and no larger than 130. String The String field is between 16 and 128 octets long, inclusive. Most RADIUS servers I'm aware of assume that this attribute is at least 16 bytes long, this might result in (serious) problems caused by memory corruption. Erik

Subject: (usr-tc) Dialback???
From: Stanislav B.Sharonov <stas@raid.ru>
Date: 1997-10-28 12:28:46

Hello! How can I use dialback function using RADIUS and Windows'95 clients (PPP, dialup)? Bye!

Subject: Re: (usr-tc) Is there a way to get the TC Ripv2 to only broadcast
From: Robert M. Gutierrez <rmg@corp.webtv.net>
Date: 1997-10-28 17:26:54

Jaye Mathisen wrote: > > the network route, and not the host routes? > > A vast majority of my customers are dynamic, and I don't need their /32's > filling up the RIP tables, but it would be nice to just assign a > subnet to the netserver card, and have it generate the proper network > route to advertise, then let individual users that need static IP's > broadcast the appropriate /32's. That would be an outbound route advertisement filter, and I have not seen reference to any such beast in the T/C books. On top of that, if there is a route advertisement filter, I'd doubt that there would be support to filter based on length masks. If you have a cisco on the receiving end of the route advertisements, you can filter on both the actual routes rec'd and the lengths of the routes. BTW: RIPv2 is avail only if you have software version 11.1 and up on the cisco, so this exercise is only valid on those platforms. For < 11.0, then don't bother running any routing protocol at all and just static the routes on the cisco to the T/C. Here is an example that both touches on Jaye's problem above and also a previous question for somebody else that wanted to filter on advertisement mask lengths: ! Turn off classful (class-bound) routing rules in the cisco. ip classless ! Lets's say that this network is on the Ethernet 0 interface, and is a /24: interface ethernet 0 ip address 10.0.1.1 255.255.255.0 ! Turn on RIP router rip ! Will listen to v1 and v2 by default, but this will enable sending v2 ! WARNING: Only works for software version 11.1 and up. version 2 ! Network for RIP to use -- in this case, Ethernet 0: network 10.0.1.0 ! Are your routes discontiguious over multiple LAN segments? If so, use this: no auto-summary ! Are you generating a local static default route??? You need to let ! RIP advertise that static route. redistribute static ! Make sure RIP is on only for the ethernet segment, for example, turn off ! RIP on the serial lines(s). passive-interface serial 0 passive-interface serial 1 ! Pointer for where/what route advertisement lists to listen on the segment ! that the USR is on using extended mask/match list(s): distribute-list 101 in ethernet 0 ! Set up an outbound list to send a default route only if this is the only ! router on this LAN -- No need to send tons of other routes to the USR: distribute-list 1 out ethernet 0 ! ! The access lists: ! ! Send only default to the ethernet. Again, keep the USR's routing tables ! to the bare minimum. access-list 1 permit 0.0.0.0 0.0.0.0 ! List ends here as there is an implicit deny afterwards. ! ! The inbound list to believe from the USR. I want to filter only: ! (1) The network(s) that I have assigned to the USR. (172.16.1.0/24 for example) ! Syntax: Network and *Reverse* mask. ! (2) The network mask and mask length filter (ie: accept _only_ /28's here). ! Syntax: Mask length and *reverse* mask filter. access-list 101 permit 101 ip 172.16.1.0 0.0.0.255 255.255.255.240 0.0.0.0 ! List ends here as there is an implicit deny afterwards. *** OR *** ! Set up the filter to accept anything *except* /32 (host) advertisements: ! First, deny any advertisement with a /32 length in the 172.16.1.0/24 subnet. access-list 101 deny 101 ip 172.16.1.0 0.0.0.255 255.255.255.255 0.0.0.0 ! Second, accept any other advertisement in the 172.16.1.0 subnet. access-list 101 permit 101 ip 172.16.1.0 0.0.0.255 255.255.255.0 0.0.0.255 ! List ends here as there is an implicit deny afterwards. *** OR *** ! Set up the filter to accept *only* advertisements for a specific ! subnet assigned to static-ip users, and block the /32 dynamic users out. ! This assumes that I have static routes in place on this cisco for the ! dynamic blocks to go to the right USR's. ! *Dynamic-IP users subnet = 172.16.1.0/24 ! *Static-IP users subnet = 172.16.2.0/24 ! First, deny any advertisement with a /32 length in the 172.16.1.0/24 ! dynamic-ip users subnet. access-list 101 deny 101 ip 172.16.1.0 0.0.0.255 255.255.255.255 0.0.0.0 ! Second, accept any advertisement in the static-ip 172.16.2.0 subnet ! with any length just in case I give out any >/32 blocks access-list 101 permit 101 ip 172.16.2.0 0.0.0.255 255.255.255.0 0.0.0.255 ! List ends here as there is an implicit deny afterwards. Does this all help??? rob. -

Subject: Re: (usr-tc) Is there a way to get the TC Ripv2 to only broadcast
From: Michael Mittelstadt <meek@execpc.com>
Date: 1997-10-29 09:47:43

[Quoth Robert M. Gutierrez] ] Jaye Mathisen wrote: ] > ] > the network route, and not the host routes? ] > ] > A vast majority of my customers are dynamic, and I don't need their /32's ] > filling up the RIP tables, but it would be nice to just assign a ] > subnet to the netserver card, and have it generate the proper network ] > route to advertise, then let individual users that need static IP's ] > broadcast the appropriate /32's. ] ] That would be an outbound route advertisement filter, and I have not ] seen ] reference to any such beast in the T/C books. On top of that, if there ] is ] a route advertisement filter, I'd doubt that there would be support to ] filter based on length masks. ] ] If you have a cisco on the receiving end of the route advertisements, ] you ] can filter on both the actual routes rec'd and the lengths of the ] routes. ] BTW: RIPv2 is avail only if you have software version 11.1 and up on the ] cisco, so this exercise is only valid on those platforms. For < 11.0, ] then ] don't bother running any routing protocol at all and just static the ] routes ] on the cisco to the T/C. The Total Control _can_ be made to send aggregate RIPv2 routes. It's just not documented anywhere I've seen. It's probably easier than trying to caress the RIP routes on one's Cisco. I got it to work just yesterday. After I bellyached to my sales rep, I was put in touch with an engineer who gave me a few good hints. Step 1. Create a small network just for the net0 ports on your Total Controls. I created a /26. Set the netmask on net0 appropriately. Step 2. For each TC, come up with an IP Pool that fits neatly into an aggregatable network. This is a /27 for 24 ports, or a /26 for 48 ports. Step 3. On each TC, add an ippool (it's documented in the Netserver 3.5 release notes). add ippool somename first-ip number-of-hosts. example: add ippool pool1 169.207.80.129 62 Step 4. Turn on enhanced routing. "set enh_routing on". You may have to do a 'reset nic' to get this to start working. I forget. Step 5. That's it. Now as soon as someone dials in, a nice aggregate route is sent back to the Cisco. This all works for me, I'm running 3.6.something. YMMV. I had thousands and thousands of RIP routes, which was a real drag. -- Michael Mittelstadt meek@execpc.com Senior Systems Administrator, ExecPC Internet http://www.execpc.com/~meek 1-800-ExecPC-1 -

Subject: (usr-tc) Aggregate routing
From: Michael Mittelstadt <meek@execpc.com>
Date: 1997-10-29 09:52:33

.. in my last message, I forgot the most important step. Add an entry to the netmask table: add netmask your-pool-network your-pool-netmask. Example of doing Aggregate routing on a TC: tc> add ippool pool1 169.207.80.65 62 tc> add netmask 169.207.80.64 255.255.255.192 tc> set enh_routing on tc> set ripv2 on The TC and it's dialup pool must not be in overlapping networks, or the route sent out looks pretty messed-up. -- Michael Mittelstadt meek@execpc.com Senior Systems Administrator, ExecPC Internet http://www.execpc.com/~meek 1-800-ExecPC-1 -

Subject: Re: (usr-tc) Is there a way to get the TC Ripv2 to only broadcast
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-29 11:13:59

Another alternative is to just set a static route in your router to the TC for the address pool, then do an access list for inbound RIP which stops anything in that pool. -

Subject: Re: (usr-tc) Aggregate routing
From: Brian <signal@shreve.net>
Date: 1997-10-29 12:50:48

On Wed, 29 Oct 1997, Michael Mittelstadt wrote: > .. in my last message, I forgot the most important step. > > Add an entry to the netmask table: > > add netmask your-pool-network your-pool-netmask. > > Example of doing Aggregate routing on a TC: > > tc> add ippool pool1 169.207.80.65 62 > tc> add netmask 169.207.80.64 255.255.255.192 > tc> set enh_routing on > tc> set ripv2 on > > The TC and it's dialup pool must not be in overlapping networks, or > the route sent out looks pretty messed-up. Ok, all my hubs netserver and nmc cards are on 208.206.76.0/24. I made: 208.214.44.0/26 208.214.44.64/26 208.214.44.128/26 208.214.44.192/26 then I this, using the appropriate dialup pool, for each tc hub: tc> add ippool dialup1 208.214.44.1 62 tc> add netmask 208.214.44.0 255.255.255.192 tc> set enh_routing on tc> set ripv2 on tc> save all tc> reboot Now......on 208.206.76.0/24 along with my tc hubs, is all my servers (web, mail, dns, ftp, etc). I run "gated" on them (they are linux boxes), with rip turned on...........here is what I end up with: Why is it sending host routes still? And when I check the routing tables for the hubs, I see no /26's declared.................. Brian netserver code 3.5.93 usr2-93.shreve. usr3ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 usr2-96.shreve. usr3ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 usr2-99.shreve. usr3ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 usr2-101.shreve usr3ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 usr2-105.shreve usr3ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 usr2-107.shreve usr3ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 usr2-111.shreve usr3ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 usr2-112.shreve usr3ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 usr2-122.shreve usr3ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 usr2-127.shreve usr3ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 usr3-128.shreve usr3ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 usr3-129.shreve usr3ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 208.214.45.128 usr3ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 usr3-130.shreve usr3ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 clrpc-1.shreve. usr2ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 usr3-131.shreve usr3ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 usr3-132.shreve usr3ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 usr3-134.shreve usr3ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 usr3-135.shreve usr3ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 usr3-136.shreve usr3ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 localhost * 255.255.255.255 UH 0 0 7 lo usr1-1.shreve.n usr1ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 usr1-8.shreve.n usr1ts1.shreve. 255.255.255.255 UGH 0 0 2 eth0 usr1-9.shreve.n usr1ts1.shreve. 255.255.255.255 UGH 0 0 2 eth0 usr1-16.shreve. usr1ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 208.214.45.16 usr2ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 usr1-17.shreve. usr1ts1.shreve. 255.255.255.255 UGH 0 0 4 eth0 kheflin-gw.shre usr2ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 usr1-23.shreve. usr1ts1.shreve. 255.255.255.255 UGH 0 0 6 eth0 localnet usr1ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 usr1-25.shreve. usr1ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 usr1-29.shreve. usr1ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 usr1-31.shreve. usr1ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 usr1-33.shreve. usr1ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 usr1-34.shreve. usr1ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 usr1-35.shreve. usr1ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 usr1-36.shreve. usr1ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 usr1-37.shreve. usr1ts1.shreve. 255.255.255.255 UGH 0 0 1 eth0 usr1-38.shreve. usr1ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 usr1-39.shreve. usr1ts1.shreve. 255.255.255.255 UGH 0 0 7 eth0 usr1-41.shreve. usr1ts1.shreve. 255.255.255.255 UGH 0 0 0 eth0 208.214.45.0 usr1ts1.shreve. 255.255.255.240 UG 0 0 0 eth0 208.214.45.16 usr2ts1.shreve. 255.255.255.240 UG 0 0 0 eth0 208.214.45.64 usr1ts1.shreve. 255.255.255.240 UG 0 0 0 eth0 208.214.45.128 usr2ts1.shreve. 255.255.255.240 UG 0 0 3 eth0 localnet * 255.255.255.0 U 0 0 180 eth0 208.214.45.0 usr1ts1.shreve. 255.255.255.0 UG 0 0 0 eth0 loopback * 255.0.0.0 0 0 0 lo default router.shreve.n 0.0.0.0 UG 1 0 1852 eth0 > > -- > Michael Mittelstadt meek@execpc.com > Senior Systems Administrator, ExecPC Internet > http://www.execpc.com/~meek 1-800-ExecPC-1 > > - > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/ -

Subject: (usr-tc) Radius (or radii?) Problem..
From: Scott Portmaster List <scottport@mail.rpa.net>
Date: 1997-10-29 14:53:17

I Know this came up last week or so, but has there been any fixes or workaround the problem dealing with if you disconnect a user manually on a TC, the tc sends to the radius accounting a stop of 0? I have scripts that run that do remove user if they are online to long, so you can still get an "estamation" of total time, and putting the kicked script with our homebrew log analyzer is so much fun, i Would like to see if this has been fixed yet. Thanks Scott "Minor Mircles Today, Major Mircles Tommorow" Traynor -

Subject: Re: (usr-tc) network connection problems
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-10-29 16:46:03

matthew said once upon a time: > > > we are having a sporadic problem where we cannot ping or telnet to the >netserver. we can reach/connect to the nmc card just fine. Have you looked at them via the serial console to see what the routing looks like? -

Subject: (usr-tc) Quake Workarounds/Developments
From: Michael Wronski <mwronski@coredump.ae.usr.com>
Date: 1997-10-29 17:04:49

Ok, after a while of waiting here is an unofficial Quake work around for the TC chassis: We have found that the following steps resolve Quake POD issues. If you are experiencing Quake POD, please check the list below and make the changes. 1) If you are using ISDN. Change calls to terminate on the Quad I-Modems instead of using the Munich. (Make sure you are using TCS 2.5.1 or higher) The Munich board was introduced before we could terminate ISDN on the Quads and is no longer necessary. 2) Turn off CCP compression on your Quake friendly dial-up. Or if you cant do that, instruct end users to turn off compression on their PPP client/Win95 for that call. 3) Turn PPP on in the modems. This frees Netserver processing cycles and improves overall performance. 4) Noisy lines. This one can't be helped on the server size, but does cause modem retrains that will degrade Quake performance. Client side modem configurations may help here. R&D continues to work on improving throuput and removing any latency in the netserver. Software fixes will be worked on and addressed in future releases of code. -M -

Subject: (usr-tc) network connection problems
From: matthew <matthew@the-spa.com>
Date: 1997-10-29 18:12:39

we are having a sporadic problem where we cannot ping or telnet to the netserver. we can reach/connect to the nmc card just fine. it happens with several different total control hubs (all dual pri) at different times. the odd thing is that when this happens (for 5-10 minutes at a time) if we have someone somewhere else on the internet try to ping or telnet to it (like a usr engineer hi dave) they can get through fine. the only thing these tc hubs have in common is that they are all on the same class c, same cisco 2501 router and are in the same physical location. users who are logged into the hub when it starts acting up can't go anywhere on the net as the box can't talk to our gateway/router and new users can't login because it can't talk to the radius server. if we shut the sucker off and turn it back on it fixes it. anyone else run into this? only happens maybe once a week per box on the average. matthew -

Subject: Re: (usr-tc) network connection problems
From: Brian <signal@shreve.net>
Date: 1997-10-29 18:51:25

On Wed, 29 Oct 1997, matthew wrote: > > we are having a sporadic problem where we cannot ping or telnet to the > netserver. we can reach/connect to the nmc card just fine. > > it happens with several different total control hubs (all dual pri) at > different times. > > the odd thing is that when this happens (for 5-10 minutes at a time) if we > have someone somewhere else on the internet try to ping or telnet to it > (like a usr engineer hi dave) they can get through fine. > > the only thing these tc hubs have in common is that they are all on the > same class c, same cisco 2501 router and are in the same physical location. > > users who are logged into the hub when it starts acting up can't go > anywhere on the net as the box can't talk to our gateway/router and new > users can't login because it can't talk to the radius server. > > if we shut the sucker off and turn it back on it fixes it. > > anyone else run into this? > > only happens maybe once a week per box on the average. > > matthew I have seen this on older versions of comos, maybe the newer ones too, if you do something like: have all your hubs on one class C. have all hubs net0 routing broadcast AND listen lets say your class C is like 208.206.76.0, well each hub makes a route like: 208.206.76.0 your.hub.ip.address but then they start broadcasting this info, so you end up on hub#1 with 208.206.76.0 hub2.ip.address and wierd things like that. Brian > > - > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/ -

Subject: Re: (usr-tc) network connection problems
From: Scott Portmaster List <scottport@mail.rpa.net>
Date: 1997-10-29 18:54:51

I Had the same thing happen, This was a self lartish problem, we found out it was a client dialing in with an NT Server that also dialed in elsewhere, figure this one out, it would connect fine, once connected, you would loose ALL Control over the netserver card. one you dropped their connection, the card would come back to life. ... Life Sux... This happened on a weekend, and they would dial in ever hour, drove us nuts until we figured it out.. not the problem, the person responsible for the server left for the weekend, on a scheduled dialin (suspending the account worked nicely :)) Scott "Why don't problems come in Xtra-small size?" Traynor On Wed, 29 Oct 1997, matthew wrote: > > we are having a sporadic problem where we cannot ping or telnet to the > netserver. we can reach/connect to the nmc card just fine. > > it happens with several different total control hubs (all dual pri) at > different times. > > the odd thing is that when this happens (for 5-10 minutes at a time) if we > have someone somewhere else on the internet try to ping or telnet to it > (like a usr engineer hi dave) they can get through fine. > > the only thing these tc hubs have in common is that they are all on the > same class c, same cisco 2501 router and are in the same physical location. > > users who are logged into the hub when it starts acting up can't go > anywhere on the net as the box can't talk to our gateway/router and new > users can't login because it can't talk to the radius server. > > if we shut the sucker off and turn it back on it fixes it. > > anyone else run into this? > > only happens maybe once a week per box on the average. > > matthew > > - > -

Subject: Re: (usr-tc) network connection problems
From: matthew <matthew@the-spa.com>
Date: 1997-10-29 20:00:24

any suggestions how to find out who it is if this is the case? did you talk to anyone at usr about this? matthew At 06:54 PM 10/29/97 -0500, you wrote: > > >I Had the same thing happen, This was a self lartish problem, we found out >it was a client dialing in with an NT Server that also dialed in >elsewhere, figure this one out, it would connect fine, once connected, you >would loose ALL Control over the netserver card. one you dropped their >connection, the card would come back to life. ... Life Sux... This >happened on a weekend, and they would dial in ever hour, drove us nuts >until we figured it out.. not the problem, the person responsible for the >server left for the weekend, on a scheduled dialin (suspending the account >worked nicely :)) > >Scott "Why don't problems come in Xtra-small size?" Traynor > >On Wed, 29 Oct 1997, matthew wrote: > >> >> we are having a sporadic problem where we cannot ping or telnet to the >> netserver. we can reach/connect to the nmc card just fine. >> >> it happens with several different total control hubs (all dual pri) at >> different times. >> >> the odd thing is that when this happens (for 5-10 minutes at a time) if we >> have someone somewhere else on the internet try to ping or telnet to it >> (like a usr engineer hi dave) they can get through fine. >> >> the only thing these tc hubs have in common is that they are all on the >> same class c, same cisco 2501 router and are in the same physical location. >> >> users who are logged into the hub when it starts acting up can't go >> anywhere on the net as the box can't talk to our gateway/router and new >> users can't login because it can't talk to the radius server. >> >> if we shut the sucker off and turn it back on it fixes it. >> >> anyone else run into this? >> >> only happens maybe once a week per box on the average. >> >> matthew >> >> - >> > > >- > > -

Subject: Re: (usr-tc) network connection problems
From: matthew <matthew@the-spa.com>
Date: 1997-10-29 20:01:42

hate to say it but we've never had to change any routing in the tc hubs from whatever they come set to. can someone give me a sample of what to check and what it should look like for a straightforward isp setup with radius etc? matthew At 04:46 PM 10/29/97 -0700, you wrote: >matthew said once upon a time: >> >> >> we are having a sporadic problem where we cannot ping or telnet to the >>netserver. we can reach/connect to the nmc card just fine. > >Have you looked at them via the serial console to see what the routing >looks like? > >- > > -

Subject: Re: (usr-tc) network connection problems
From: David Bolen <db3l@ans.net>
Date: 1997-10-29 20:21:14

Scott Portmaster List <scottport@mail.rpa.net> writes: > I Had the same thing happen, This was a self lartish problem, we found out > it was a client dialing in with an NT Server that also dialed in > elsewhere, figure this one out, it would connect fine, once connected, you > would loose ALL Control over the netserver card. one you dropped their > connection, the card would come back to life. ... Life Sux... Just a guess, but this kind of case sounds like the NT machine was announcing a default or some such route to your NETServer, and you had left the NETServer configured to listen. I would definitely suggest that NETServers be configured such that local user definitions explicitly have routing disabled (I believe local users default to not announcing, but still listening). For accounts via RADIUS, ensure that if you have a Framed-Routing attribute in the record it is set to None or just to Broadcast, but don't do Listen or Broadcast-Listen unless you "trust" the customer (which for us would probably mean we personally had control of the equipment at the other end of the dialup link). If you leave a dialup port listening for routing announcements then any dialup user (even if not really running a routing protocol) could generate a RIP packet to your NETServer and put any routing they wanted into your table. For example, if they were really smart about it, they'd do it in small bursts (adding the route and removing it briefly), which could theoretically let them see traffic the NETServer thought it was sending to be routed over a backbone. -- 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) Aggregate routing
From: Brian <signal@shreve.net>
Date: 1997-10-29 22:18:50

On Wed, 29 Oct 1997, Brian wrote: > On Wed, 29 Oct 1997, Michael Mittelstadt wrote: > > > .. in my last message, I forgot the most important step. > > > > Add an entry to the netmask table: > > > > add netmask your-pool-network your-pool-netmask. > > > > Example of doing Aggregate routing on a TC: > > > > tc> add ippool pool1 169.207.80.65 62 > > tc> add netmask 169.207.80.64 255.255.255.192 > > tc> set enh_routing on > > tc> set ripv2 on > > > > The TC and it's dialup pool must not be in overlapping networks, or > > the route sent out looks pretty messed-up. > I have done this, and can't seem to get the USR to add the /26 as a route, let alone broadcast this route as a v2 update. I did those exact steps, and I just get individule host routes on my linux boxes running gated. Are you sure this is all that has to be done for the tc hub to aggregate its route broadcasts? I have net0 routing broadcast, listen, and ripv2 on. Brian > > > > > > > -- > > Michael Mittelstadt meek@execpc.com > > Senior Systems Administrator, ExecPC Internet > > http://www.execpc.com/~meek 1-800-ExecPC-1 > > > > - > > > > /-------------------------- signal@shreve.net -----------------------------\ > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > | Systems Administrator | Perl, Linux | Web hosting, online stores, | > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | > | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | > \-------------------------- 318-222-2638 x109 -----------------------------/ > > > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Systems Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX, Akimoto intake, DC |-=*:Quake:*=-| http://www.shreve.net/ | | headers, Eurosport exhaust |LordSignal/SN| Quake server: 208.206.76.3 | \-------------------------- 318-222-2638 x109 -----------------------------/ -

Messages