August 1997

Subject: (usr-tc) Dialing out..
From: Elio M. Fuentes <emf@agetech.net>
Date: 1997-08-01 12:18:06

Hi all, I'm having a little problem getting the Netserver to dial out to an ascend Pipeline-50. Here's my location: >--- Location: dc64_oscar Type: Automatic Destination: 209.4.97.33 Netmask: 255.255.255.240 Protocol: PPP Options: Routing, Compression Group: 51 Max Ports: 1 Idle Timeout: 0 minutes High Mark: 0 bytes Mtu: 1006 Async Map: 00000000 Dial Script: Send Command Wait for Reply ------------------------------ atdt5917697\r CONNECT >--- when I type in dial dc64_oscar it dials out to the Pipeline-50 with no problem, but the session never establishes it just sits there and then hangs up. I think the problem might be somewhere in the pipeline 50. I have no password set on it and have the connection name as usr1 which is the name of my netserver. I was wondering if anyone has gotten this to work with an Ascend pipeline-50 or 130 and what settings I should use on the router. I know on a Portmaster I can set a user name/password in the actual location entry, but can't seem to do it on the USR. My next question is will this work with 2 channels if I set Max Ports to 2 ??? Thanks Elio Fuentes emf@agetech.net

Subject: (usr-tc) Using USR MIBs with CMU utilities
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1997-08-01 12:26:47

Howdy. I'm fairly new to the world of SNMP, but I've read Rose' _Simple_Book_ and I'm trying to put those principles into action. I've installed the CMU snmp utilities on my management station, and the included snmpwalk utility showed lots of mildly useful things with the included mib.txt. I retrieved USR's mib from their web site, and have tried appending several of those to my current mib definition. That has yet to bring any success, though. How do I retrieve data specific to the TC chassis from the NMC? Thank you for any pointers. --- Mark R. Lindsey, mark@datasys.net Network Engineer, DSS Online 912 241 0607; Fax: 241 0190

Subject: Re: (usr-tc) Using NIC on a TC HUB
From: Elio M. Fuentes <emf@agetech.net>
Date: 1997-08-01 16:05:31

Tatai SV Krishnan wrote: > > On Sun, 3 Aug 1997, Tim Tsai wrote: > > > We want to use a couple of analog/digital modems as "regular" modems > > connecting to a serial port on a computer and dialing out through a POTS > > line. > > > > The problem is that no matter how I fiddle with the settings from the > > TCM, the modem always return back to packetbus mode after a software > > reset. I have saved to NVRAM and the problem persists. We're running > > the latest and greatest versions on everything. This is using PRI, if > > it matters. > > > > Any suggestions? > > > > Thanks, > > > > Tim > > > Set the modem that you want to use with RS232 inactive on the NETServer. > save it. Then reset the modem. Use the NMC or just physically reboot > the modem. > > Say you want to set the slot 2 channel 1 and 2 on to the RS232 then > on the NETServer > > set modem s5 inactive > set modem s6 inactive > reset s5 > reset s6 > > save all > > now reset both the modems via nmc or through the rs232 port send a atz. > > Now the modem will be on the rs232 ports > > krish How do you get it to dial out though? I can access the modem through the serial port with no problem, but it won't dial out ? when I do an ATDT5551212 I get a respone of ERROR.. Thanks. Elio. emf@agetech.net

Subject: Re: (usr-tc) Quake problems
From: Brian <signal@shreve.net>
Date: 1997-08-01 19:23:18

On Fri, 1 Aug 1997, Mike Hamrich wrote: > Since you run Livingston also. Have you noticed that the first ping allways times out on the USR TC but not on the PM3? We are being evaluated by a large accountand the lag on the TC has become an issue. Both systems have light load less > 15 users each when compairsion was done. > USR Tech support has been little help. Is there a setting for the gateway our routing functions that is not obvious? > ---- > From: Russ Panula <rpanula@dacmail.net> > On Thu, 31 Jul 1997 13:22:14 -0500 (CDT), Brian <signal@shreve.net> > wrote: > > >> Has anybody had *any* success with USR's recent releases fixing the > >> Quake problems? If so, which versions? Any information you can pass > >> along would be appreciated. > > > > > it is a known bug that the USR TC corrupts the first packet upon a PPP connect. Brian oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

Subject: Re: (usr-tc) Quake problems
From: Mike Hamrich <mhamrich@drfast.net>
Date: 1997-08-01 19:59:40

This is a multi-part message in MIME format. ------=_NextPart_000_01BC9EB5.72B27B20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Since you run Livingston also. Have you noticed that the first ping = allways times out on the USR TC but not on the PM3? We are being = evaluated by a large accountand the lag on the TC has become an issue. = Both systems have light load less > 15 users each when compairsion was = done. USR Tech support has been little help. Is there a setting for the = gateway our routing functions that is not obvious? ---- On Thu, 31 Jul 1997 13:22:14 -0500 (CDT), Brian <signal@shreve.net> wrote: >> Has anybody had *any* success with USR's recent releases fixing the >> Quake problems? If so, which versions? Any information you can pass >> along would be appreciated. > > ------=_NextPart_000_01BC9EB5.72B27B20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML 3.2//EN"> <HTML> <HEAD> <META content=3Dtext/html;charset=3Diso-8859-1 = http-equiv=3DContent-Type> <META content=3D'"Trident 4.71.0544.0"' name=3DGENERATOR> </HEAD> <BODY> Since you run Livingston also. Have you noticed that the first ping = allways=20 times out on the USR TC but not on the PM3? We are being evaluated by a = large=20 accountand the lag on the TC has become an issue. Both systems have = light load=20 less > 15 users each when compairsion was done. USR Tech support has been little help. Is there a setting for the = gateway our=20 routing functions that is not obvious? ---- From: Russ Panula <rpanula@dacmail.net> On Thu, 31 Jul 1997 13:22:14 -0500 (CDT), Brian  = <<A=20 href=3D"mailto:signal@shreve.net">signal@shreve.net</A>> wrote: >> Has anybody had *any* success with USR's recent releases fixing = the >> Quake problems?  If so, which versions? Any information = you can=20 pass >> along would be appreciated. > > </BODY></HTML> ------=_NextPart_000_01BC9EB5.72B27B20--

Subject: Re: (usr-tc) Quake problems
From: Tim Tsai <tim@futuresouth.com>
Date: 1997-08-01 20:49:58

On Fri, Aug 01, 1997 at 07:23:18PM -0500, Brian wrote: > it is a known bug that the USR TC corrupts the first packet upon a PPP > connect. I think this was a problem with ComOS until recently. At least for ISDN anyway. I don't think that problem was resolved until 3.5. USR being a few dozen revisions behind probably never fixed this bug. On another note, does anybody have any experiences (good or bad) with the new OS for the NetServer? We're afraid to try it. On the other hand, the age of the ComOS really shows next to a PM3. :-) Tim

Subject: (usr-tc) mpip server
From: Brian <signal@shreve.net>
Date: 1997-08-01 21:44:48

After you do: set mpipserver on On the hub that your running an mpipserver, should you also do: set mpipserver 1 208.214.44.2 secret Or do you just leave mpipserver set to 0.0.0.0 I am talking about where your only using ONE mpipserver, and I am talking about what you type on the "server", I know how to setup the clients. Brian oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

Subject: (usr-tc) Quake problems
From: Brian Elfert <brian@citilink.com>
Date: 1997-08-02 12:54:08

On Fri, 1 Aug 1997, Mike Hamrich wrote: >Since you run Livingston also. Have you noticed that the first ping >allways times out on the USR TC but not on the PM3? We are being >evaluated by a large account and the lag on the TC has become an issue. What traceroute program are they using? I'll bet it's the one in Win 95, right? Livingston's OS code would not respond to MS's tracert program until the latest betas. I'll bet you're running ComOS 3.5.1b20 on the PM3, which is the first Livingston OS that properly reponds to MS's tracert program. Now, the USR Netserver runs an old version of Livingston code, so it probably doesn't respond to MS's tracert program. I haven't tried this with my USR Netserver card, but I think I'm correct. Brian

Subject: Re: (usr-tc) Quake problems
From: Mike Hamrich <mhamrich@drfast.net>
Date: 1997-08-02 15:06:31

This is a multi-part message in MIME format. ------=_NextPart_000_01BC9F55.A8AEDD40 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable ----Subject: (usr-tc) Quake problems >What traceroute program are they using? I'll bet it's the one in Win = 95, >right? Yes >Livingston's OS code would not respond to MS's tracert program until = the >latest betas. I'll bet you're running ComOS 3.5.1b20 on the PM3, which = is >the first Livingston OS that properly reponds to MS's tracert program. Yes again! I tell them to try a NT or Unix tracerout. Thanks Brian ------=_NextPart_000_01BC9F55.A8AEDD40 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML 3.2//EN"> <HTML> <HEAD> <META content=3Dtext/html;charset=3Diso-8859-1 = http-equiv=3DContent-Type> <META content=3D'"Trident 4.71.0544.0"' name=3DGENERATOR> </HEAD> <BODY>   ----Subject: (usr-tc) Quake problems >What traceroute program are they using?  I'll = bet it's the=20 one in Win 95, >right? Yes >Livingston's OS code would not respond to MS's tracert program until = the >latest betas.  I'll bet you're running ComOS 3.5.1b20 on the = PM3, which=20 is >the first Livingston OS that properly reponds to MS's tracert = program. Yes again! I tell them to try a NT or Unix tracerout. Thanks Brian </BODY></HTML> ------=_NextPart_000_01BC9F55.A8AEDD40--

Subject: Re: (usr-tc) Quake problems
From: Craig Nelson <craig@jetcity.com>
Date: 1997-08-03 01:49:37

We're getting extreme lag when running QuakeWorld on our netserver version 3.3.3 (w/4mb). It only >seems< to happen under load- lots of users on, maybe lots of x2 users, we're not really sure. I'm hoping that upgrading to the latest releases will help, of course, first I have to upgrade the Netservers to 16mb, and before that I have to send them back for some bench-work. ARRRGHHH - pisses me off that USR didn't warn us that our older equipment might have a few QUIRKS... As far as a Quake server - I would say, as an avid Quake player myself, that I wouldn't PAY extra to play Quake, there are just way too many Quake servers. However, I might choose an ISP based on their support of Quake, and having a Quake server is a strong indication of that. We're using it as a service differentiator, not a value-add. At 01:45 PM 7/31/97 -0500, you wrote: >-> Many of our customers have complained of extreme lag when playing Quake. >-> Judging from the USR bug reports and other posts here, we're not alone. >-> What brings this problem into sharp relief for us is that we're gradually >-> converting our TC+PM25 chassis into TC+NETservers, and the PM25s didn't >-> exhibit this laggy behavior. In fact, this and the NETserver's habit of >-> severely corrupting packets when forced to fragment them for low-MTU links >-> are the only major PM to NETserver issues remaining for us. >-> >-> Has anybody had *any* success with USR's recent releases fixing the Quake >-> problems? If so, which versions? Any information you can pass along would >-> be appreciated. > >On another note can someone point me in the direction on what is involved in >setting up a Quake server ? A FAQ would be great. Also I am curious as to >what folks are charging for use of their Quake servers and how large the market >is for it. > >Thanks in advance, > >Jeff Binkley >ASA Network Computing > > > <.>-----------------------------------------------<.> The thing about Crayons is, They can take take you more places than Starships -Guinan <.>-----------------------------------------------<.>

Subject: (usr-tc) Using NIC on a TC HUB
From: Tim Tsai <tim@futuresouth.com>
Date: 1997-08-03 13:58:19

We want to use a couple of analog/digital modems as "regular" modems connecting to a serial port on a computer and dialing out through a POTS line. The problem is that no matter how I fiddle with the settings from the TCM, the modem always return back to packetbus mode after a software reset. I have saved to NVRAM and the problem persists. We're running the latest and greatest versions on everything. This is using PRI, if it matters. Any suggestions? Thanks, Tim

Subject: Re: (usr-tc) Modems going inactive
From: Nick Kralevich <nickkral@ferrari.autobahn.org>
Date: 1997-08-03 15:11:44

For those of us who are new to the list, where can we get the latest version of the US Robotics operating system for the NetServer/16 v.34? Take care, -- Nick Kralevich nickkral@autobahn.org

Subject: Re: (usr-tc) Quake problems
From: MegaZone <megazone@livingston.com>
Date: 1997-08-03 20:28:22

Once upon a time Mike Hamrich shaped the electrons to say... >I tell them to try a NT or Unix tracerout. AFAIK it the Win95 and WinNT tracert worked the same way, so it won't make a difference. UNIX traceroute works fine. -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) Using NIC on a TC HUB
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-08-04 07:05:00

On Sun, 3 Aug 1997, Tim Tsai wrote: > We want to use a couple of analog/digital modems as "regular" modems > connecting to a serial port on a computer and dialing out through a POTS > line. > > The problem is that no matter how I fiddle with the settings from the > TCM, the modem always return back to packetbus mode after a software > reset. I have saved to NVRAM and the problem persists. We're running > the latest and greatest versions on everything. This is using PRI, if > it matters. > > Any suggestions? > > Thanks, > > Tim > Set the modem that you want to use with RS232 inactive on the NETServer. save it. Then reset the modem. Use the NMC or just physically reboot the modem. Say you want to set the slot 2 channel 1 and 2 on to the RS232 then on the NETServer set modem s5 inactive set modem s6 inactive reset s5 reset s6 save all now reset both the modems via nmc or through the rs232 port send a atz. Now the modem will be on the rs232 ports 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) Using NIC on a TC HUB
From: Charles Hill <chill@ionet.net>
Date: 1997-08-04 09:45:00

Also, be sure that "Auto Config on Card Initialization" is disabled in the NMC. That could also cause the settings to revert back after the card is reset. -CH On Mon, 4 Aug 1997, Tatai SV Krishnan wrote: > On Sun, 3 Aug 1997, Tim Tsai wrote: > > > We want to use a couple of analog/digital modems as "regular" modems > > connecting to a serial port on a computer and dialing out through a POTS > > line. > > > > The problem is that no matter how I fiddle with the settings from the > > TCM, the modem always return back to packetbus mode after a software > > reset. I have saved to NVRAM and the problem persists. We're running > > the latest and greatest versions on everything. This is using PRI, if > > it matters. > > > > Any suggestions? > > > > Thanks, > > > > Tim > > > Set the modem that you want to use with RS232 inactive on the NETServer. > save it. Then reset the modem. Use the NMC or just physically reboot > the modem. > > Say you want to set the slot 2 channel 1 and 2 on to the RS232 then > on the NETServer > > set modem s5 inactive > set modem s6 inactive > reset s5 > reset s6 > > save all > > now reset both the modems via nmc or through the rs232 port send a atz. > > Now the modem will be on the rs232 ports > > 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) MPIP Server
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-08-04 15:43:42

Brian said once upon a time: >The MPIP server is built into the USR TC hub, just do "set mpipserver on" >on one of your hubs...............the release notes for 3.4 cover this I >beleive. > >Brian > >p.s. it works great It does? It was agonizingly slow for us under 3.5.34.

Subject: Re: (usr-tc) Using NIC on a TC HUB
From: David Bolen <db3l@ans.net>
Date: 1997-08-04 16:16:36

"Elio M. Fuentes" <emf@agetech.net> writes: > How do you get it to dial out though? I can access the modem through > the serial port with no problem, but it won't dial out ? when I do an > ATDT5551212 I get a respone of ERROR.. Since this was a modem previously on the packet bus double check that you don't have it set to automatically busy if there is no packet bus link (it's the mdmCcNoPbNoConnEna object, which should be in the "call control" section of TCM). Although it's defined to control whether or not the modem will answer a call if the packet bus link is down, I've found that it also interferes with outbound calling, and results in an ERROR message. If you find this to be enabled, disable it, save the modem settings and then reset the modem (or slot) and you should be fine. -- 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: (usr-tc) Good USR dealer?
From: kbethke@ezy.net
Date: 1997-08-04 16:27:37

Looking for a good USRobotics dealer to buy a netserver and dual = pri card, any recomendations? =20 -Scott --- GSTek Corporation *Kenneth Scott Bethke* Ezy.Net Corporation Sun/Networking/ISP Stuff -- BUY/SELL/TRADE -- FAX: = 410-742-1381 Email:kbethke@ezy.net Voice:410-742-1610 = Web:http://www.ezy.net/gstek

Subject: Re: (usr-tc) MPIP Server
From: Brian <signal@shreve.net>
Date: 1997-08-04 16:28:34

On Tue, 5 Aug 1997, Francis Fong wrote: > Dear Everybody, > > We are in the meantime implementating a PRI access system using USR Total > Control, and need Cross B-Channel bonding accross different TC chassis. I > know we need a MPIP server, but seems like USR doesn't make one. Is there > any software vendor or 3rd party software developer who make this (either > in Win NT 4.0 version or Unix : Solaris /HPUX)? Pls advise. The MPIP server is built into the USR TC hub, just do "set mpipserver on" on one of your hubs...............the release notes for 3.4 cover this I beleive. Brian p.s. it works great > > Tks in advance. > > Bst Rgds, > > Francis Fong / Synergy > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

Subject: Re: (usr-tc) Good USR dealer?
From: Brian <signal@shreve.net>
Date: 1997-08-04 16:29:49

On Mon, 4 Aug 1997 kbethke@ezy.net wrote: > > Looking for a good USRobotics dealer to buy a netserver and dual pri card, any recomendations? We use Microgear 318-797-6999, tell them Brian at ShreveNet sent you. Brian > > -Scott > > --- > GSTek Corporation *Kenneth Scott Bethke* Ezy.Net Corporation > Sun/Networking/ISP Stuff -- BUY/SELL/TRADE -- FAX: 410-742-1381 > Email:kbethke@ezy.net Voice:410-742-1610 Web:http://www.ezy.net/gstek > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

Subject: Re: (usr-tc) Good USR dealer?
From: Terry Kennedy <terry@olypen.com>
Date: 1997-08-04 18:31:24

We use Westcon, Talk to Peter Sherry Terry

Subject: (usr-tc) mdmTeDteRingNoAns trap
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1997-08-04 23:05:01

I'm trying to enable the mdmTeDteRingNoAns trap on all of my modems, but in both of the racks I've tested with, I can't seem to do it. In every case, I'm getting a `general failure' error. I'm attempting to set nas.mdm.mdmTe.mdmTeTable.mdmTeEntry.mdmTeDteRingNoAns.13004 with the integer 1, for example. I've actually run through all of the modems as listed with walk, but none of them will go into that mode. What do I actually need to set to make this happen? Thanks. --- Mark R. Lindsey, mark@datasys.net Network Operator, DSS Online 912 241 0607; Fax: 241 0190

Subject: RE: (usr-tc) mdmTeDteRingNoAns trap
From: Tom Bilan <tom@tdi.net>
Date: 1997-08-04 23:22:28

------ =_NextPart_000_01BCA12D.474C1520 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Were the any of the modems being used when you were trying the set? If so, I think they need to be empty. Tom -----Original Message----- Sent: Monday, August 04, 1997 11:05 PM I'm trying to enable the mdmTeDteRingNoAns trap on all of my modems, but in both of the racks I've tested with, I can't seem to do it. In every case, I'm getting a `general failure' error. I'm attempting to set nas.mdm.mdmTe.mdmTeTable.mdmTeEntry.mdmTeDteRingNoAns.13004 with the integer 1, for example. I've actually run through all of the modems as listed with walk, but none of them will go into that mode. What do I actually need to set to make this happen? Thanks. --- Mark R. Lindsey, mark@datasys.net Network Operator, DSS Online 912 241 0607; Fax: 241 0190 ------ =_NextPart_000_01BCA12D.474C1520 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+Ih4DAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAyAEAAAEAAAAQAAAAAwAAMAIAAAAL AA8OAAAAAAIB/w8BAAAATwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHVzci10Y0BtYWlsLnht aXNzaW9uLmNvbQBTTVRQAHVzci10Y0BtYWlsLnhtaXNzaW9uLmNvbQAAHgACMAEAAAAFAAAAU01U UAAAAAAeAAMwAQAAABkAAAB1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20AAAAAAwAVDAEAAAADAP4P BgAAAB4AATABAAAAGwAAACd1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20nAAACAQswAQAAAB4AAABT TVRQOlVTUi1UQ0BNQUlMLlhNSVNTSU9OLkNPTQAAAAMAADkAAAAACwBAOgEAAAAeAPZfAQAAABkA AAB1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20AAAAAAgH3XwEAAABPAAAAAAAAAIErH6S+oxAZnW4A 3QEPVAIAAAAAdXNyLXRjQG1haWwueG1pc3Npb24uY29tAFNNVFAAdXNyLXRjQG1haWwueG1pc3Np b24uY29tAAADAP1fAQAAAAMA/18AAAAAAgH2DwEAAAAEAAAAAAAAArFkAQSAAQAkAAAAUkU6ICh1 c3ItdGMpIG1kbVRlRHRlUmluZ05vQW5zIHRyYXAAGgwBBYADAA4AAADNBwgABAAXABYAHAABACoB ASCAAwAOAAAAzQcIAAQAFwAVACgAAQA1AQEJgAEAIQAAAEQ1MkE0NzI5RUMwQ0QxMTE5QkZEMDA2 MDk3N0IyODlDAC4HAQOQBgCkBgAAIQAAAAsAAgABAAAACwAjAAAAAAADACYAAAAAAAsAKQAAAAAA AwAuAAAAAAADADYAAAAAAEAAOQCAqYzNTqG8AR4AcAABAAAAJAAAAFJFOiAodXNyLXRjKSBtZG1U ZUR0ZVJpbmdOb0FucyB0cmFwAAIBcQABAAAAFgAAAAG8oU7NhSlHKtcM7BHRm/0AYJd7KJwAAB4A HgwBAAAABQAAAFNNVFAAAAAAHgAfDAEAAAAMAAAAdG9tQHRkaS5uZXQAAwAGEGe8UMUDAAcQtAIA AB4ACBABAAAAZQAAAFdFUkVUSEVBTllPRlRIRU1PREVNU0JFSU5HVVNFRFdIRU5ZT1VXRVJFVFJZ SU5HVEhFU0VUP0lGU08sSVRISU5LVEhFWU5FRURUT0JFRU1QVFlUT00tLS0tLU9SSUdJTkFMTUUA AAAAAgEJEAEAAACGAwAAggMAAEgFAABMWkZ1RXdQqXcACgEDAfcgAqQD4wIAY4JoCsBzZXQwIAcT hwKDAFAO9nBycTIP9iZ9CoAIyCA7CW8yNWY1AoAKgXVjAFALA2MDAEELYG5nMTAzMwkLpiBXBJBl IHRowxaQAHB5IG9mFqMEYhJtBCBiZQuAZyB1sQ+wZCB3FsADoHkIYHMYsBZzcnkYMhayD7E/Fwqi CoQKgEkXQHNvLGwgSRahC4BrFqIXEG7TCeAYoHRvGAEgF9AFMHR5LhqaVANwGpoK9Gx4aTM2AUAV EAFAEUBvCnQFkHQQhDE2IC31IVJPBRBnC4AHQAXQB5Dwc2FnZSFTGpYgZCAxgwsTIGZpLTE0NAFA cR+wMTgwAUAM0CTzYlQgRgNhOgyDYg/gTUMKwBwgUi4gTAuAZAMPsBcQW1NNVFA6EwDAJzBAdgiQ bGxlCC5kYQGQc3lzLvkckHRdGpUmIAZgAjAmiIsCICkweRugQXVnGHAJBUAwNBugMTk5NwEscDE6 MDUgUE0PKfceYCaHGHByLXRjqEB4bQQBaQIgLgWgYx6GKmF1YmogkSaHKAUulCkXkGRtVGVExSCA UhgxTm9BBjEZoHxhcCL/JAoftAu2GwQn/m0ZlxzwCfABoCkAF1Qx/78zAhcgA6AHQAMgFzFtFxDz F6QboGJ1ILAaowuAGADNIHBoFyYzEGNrBCA2QN52FpEHkCCAGKFpFrAbonpjAHAnBUAPsBfQHNJk 1xzwPUAncEkDoGU8kBmw/xqUPbAPsBuhNlEigAJAGDJ4YSBgIoAckDMQAyBmVwtwCkAJcCcdMHID YHL/PuE2USlAIIAdUTa1D7Eamv4gRMUh8CmQN9FFcjgARbT2VDdCRbRFAjAZsEW0OCroLjEzJYA0 Gpo9Mhaj7wuAIIAigAXAMRugAhAFwHhleGEdUCkBPGQA0HTmdTlxFxBydQOgFrADYH8r4DuAOXUW sRqUF6UpYCDvH7A85xiwB0BrOnMcgAIg3xaQFzQ2YAPwOYFnPqECMN8c8BawKUAXkx2bV1ISPpG/ G8BMFxyWD7Ec0gDAaxaSZQQAIA+AcHAJ8BqLVP8PgBwQKZAengqAIscnHRugzyhzKTkalAfAdHcF sBwgLk9WUDMQHOByG6BEUzkF8E9uH7AckBqUOTExEXAyNDEsMB/gNzvxJjBheDpeNCyANdVfvwoK EgEAYXAAAAMAEBAAAAAAAwAREAAAAAADAIAQ/////0AABzAATq2wTqG8AUAACDAATq2wTqG8AQsA AIAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwACgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUA AAAAAAADAAWACCAGAAAAAADAAAAAAAAARgAAAABShQAAtw0AAB4AJYAIIAYAAAAAAMAAAAAAAABG AAAAAFSFAAABAAAABAAAADguMAADACaACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAAsAL4AI IAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAwgAggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAA AAADADKACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAB4AQYAIIAYAAAAAAMAAAAAAAABGAAAA ADaFAAABAAAAAQAAAAAAAAAeAEKACCAGAAAAAADAAAAAAAAARgAAAAA3hQAAAQAAAAEAAAAAAAAA HgBDgAggBgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEAAAABAAAAAAAAAB4APQABAAAABQAAAFJFOiAA AAAAAwANNP03AAC2jA== ------ =_NextPart_000_01BCA12D.474C1520--

Subject: (usr-tc) MPIP Server
From: Francis Fong <francisf@synergy-hk.com.hk>
Date: 1997-08-05 03:56:34

Dear Everybody, We are in the meantime implementating a PRI access system using USR Total Control, and need Cross B-Channel bonding accross different TC chassis. I know we need a MPIP server, but seems like USR doesn't make one. Is there any software vendor or 3rd party software developer who make this (either in Win NT 4.0 version or Unix : Solaris /HPUX)? Pls advise. Tks in advance. Bst Rgds, Francis Fong / Synergy

Subject: Re: (usr-tc) Good USR dealer?
From: Mike Hamrich <mhamrich@drfast.net>
Date: 1997-08-05 11:57:24

This is a multi-part message in MIME format. ------=_NextPart_000_01BCA196.BD1B98C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Westcon was off to a slow start, but did eveything they said they would. = They have GREAT techsupport. Suzane is our rep Tell Her Mike From DrFast.Net say's Hi! ---- We use Westcon, Talk to Peter Sherry Terry

Subject: (usr-tc) List archive
From: Andy Yu-Hun Liao <aliao@aicom.com>
Date: 1997-08-05 17:48:04

Hi, Can anyone point me to an archive for this list? Thanks. Andy Yu-Hun Liao Internet Team, System Admin AICOM Internet Services Corp. (http://www.aicom.com), a division of AIC Asia International Services Corp. Phone #: (604) 298-2881 Fax #: (604) 298-5813

Subject: Re: (usr-tc) List archive
From: Lars Freund <lafreund@cip.e-technik.uni-erlangen.de>
Date: 1997-08-06 11:41:21

On Tue, 5 Aug 1997, Andy Yu-Hun Liao wrote: > Can anyone point me to an archive for this list? http://www.xmission.com -> mailinglisten -> usr-tc -> ... Ciao, Lars +-----------------------------------------------------------------+ | Lars Freund Email: lafreund@cip.e-technik.uni-erlangen.de | | FOnLine Buergernetzverein: http://www.forchheim.baynet.de | | http://cip2.e-technik.uni-erlangen.de:8080/hyplan/lafreund.html | +-----------------------------------------------------------------+

Subject: (usr-tc) ISDN bonded (or MLPPP) on Netserver 16/I?
From: Jaye Mathisen <mrcpu@cdsnet.net>
Date: 1997-08-06 14:08:19

I'm trying to get 2B channels to a Netserver 16/I working, but each B channel gets a different IP on my side, rather than negotiating the MPPP Any tips or ideas?

Subject: Re: (usr-tc) ISDN bonded (or MLPPP) on Netserver 16/I?
From: Jaye Mathisen <mrcpu@cdsnet.net>
Date: 1997-08-06 15:02:39

Doesn't work: U.S. Robotics Total Control (tm) NETServer 8/16 login: !root Password: kf-ns-1> set mpp on Syntax error: usage: set port_name,all option value kf-ns-1> U.S. Robotics Total Control (tm) NETServer 8/16 version 3.2.5.3 Build date: Dec 2 1996 Build time: 12:54:30 On Wed, 6 Aug 1997, Brian wrote: > On Wed, 6 Aug 1997, Jaye Mathisen wrote: > > > > > > > I'm trying to get 2B channels to a Netserver 16/I working, but > > each B channel gets a different IP on my side, rather than > > negotiating the MPPP > > set mpp on > > > > > > Any tips or ideas? > > > > > > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET > UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 > signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > > >

Subject: (usr-tc) STAC compression
From: Brian <signal@shreve.net>
Date: 1997-08-06 16:25:36

Is there a way to tell if a user is using STAC compression when dialing in? do i have to do anything special to there radius/usr config to enable stac? Brian oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

Subject: Re: (usr-tc) ISDN bonded (or MLPPP) on Netserver 16/I?
From: Brian <signal@shreve.net>
Date: 1997-08-06 16:34:39

On Wed, 6 Aug 1997, Jaye Mathisen wrote: > > > I'm trying to get 2B channels to a Netserver 16/I working, but > each B channel gets a different IP on my side, rather than > negotiating the MPPP set mpp on > > Any tips or ideas? > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

Subject: Re: (usr-tc) ISDN bonded (or MLPPP) on Netserver 16/I?
From: Jaye Mathisen <mrcpu@cdsnet.net>
Date: 1997-08-06 16:47:51

Well, when the client calls a portmaster with the 5BRI module, it bonds up just fine. The problem is both channels hook up, but one channel gets a different IP on the server end, ie, client gets a.b.c.d, a.b.c.e, and the traffic goes nowhere, it just sits there. Single channel works just fine. On Wed, 6 Aug 1997, Jordyn A. Buchanan wrote: > Jaye Mathisen <mrcpu@cdsnet.net>: > > >Doesn't work: > > > >U.S. Robotics > >Total Control (tm) NETServer 8/16 > > > >login: !root > >Password: > >kf-ns-1> set mpp on > >Syntax error: usage: set port_name,all option value > > This worked out of the box for us; I don't recall setting anything. It > works both for ISDN and for the new versions of DUN that will bond multiple > analog connections into a single IP. > > Are you sure the client side is set up correctly? > > Jordyn > > |----------------------------------------------------------------| > |Jordyn A. Buchanan mailto:jordyn@bestweb.net | > |Bestweb Corporation http://www.bestweb.net | > |Senior System Administrator +1.914.271.4500 | > |----------------------------------------------------------------| > > >

Subject: Re: (usr-tc) ISDN bonded (or MLPPP) on Netserver 16/I?
From: Jordyn A. Buchanan <jordyn@bestweb.net>
Date: 1997-08-06 19:26:09

Jaye Mathisen <mrcpu@cdsnet.net>: >Doesn't work: > >U.S. Robotics >Total Control (tm) NETServer 8/16 > >login: !root >Password: >kf-ns-1> set mpp on >Syntax error: usage: set port_name,all option value This worked out of the box for us; I don't recall setting anything. It works both for ISDN and for the new versions of DUN that will bond multiple analog connections into a single IP. Are you sure the client side is set up correctly? Jordyn |----------------------------------------------------------------| |Jordyn A. Buchanan mailto:jordyn@bestweb.net | |Bestweb Corporation http://www.bestweb.net | |Senior System Administrator +1.914.271.4500 | |----------------------------------------------------------------|

Subject: Re: (usr-tc) PRI NFAS ID info
From: Brian <signal@shreve.net>
Date: 1997-08-07 10:48:29

On Thu, 7 Aug 1997, Jeff Mcadams wrote: > Trying to set up two PRI's coming into one TC chassis with 1 D channel for > both spans...My understanding is I need the NFAS ID information so that the > chassis knows which span line the call is coming in on. I talked to the > folks that the switch that are working with us on getting these things > working (its *such* a pleasant change from BellSouth), and they had never > heard of the term/acronym NFAS. Anyone have any bright ideas on what they > might know this concept as? its not known as anything else as far as I know. Just explain to them the concept, that the D channel of one PRI is serving as the D channel for other PRI's as well, and that you need to tell those other PRI's where the D channel is located for there signalling information. Non Facilitated Automated Switching is what I think it means.......anyways, it takes a while with bellsouth to find someone who really knows what they are talking about. Brian > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

Subject: (usr-tc) PRI NFAS ID info
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1997-08-07 11:10:42

Trying to set up two PRI's coming into one TC chassis with 1 D channel for both spans...My understanding is I need the NFAS ID information so that the chassis knows which span line the call is coming in on. I talked to the folks that the switch that are working with us on getting these things working (its *such* a pleasant change from BellSouth), and they had never heard of the term/acronym NFAS. Anyone have any bright ideas on what they might know this concept as? -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) ip pools
From: Charles Hill <chill@ionet.net>
Date: 1997-08-07 11:21:19

What is the RADIUS attribute value to specify IP pool name in a user profile. Regards, Charles Hill

Subject: Re: (usr-tc) PRI NFAS ID info
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1997-08-07 11:52:28

Thus spake Brian >On Thu, 7 Aug 1997, Jeff Mcadams wrote: >> Trying to set up two PRI's coming into one TC chassis with 1 D channel for >> both spans...My understanding is I need the NFAS ID information so that the >> chassis knows which span line the call is coming in on. I talked to the >> folks that the switch that are working with us on getting these things >> working (its *such* a pleasant change from BellSouth), and they had never >> heard of the term/acronym NFAS. Anyone have any bright ideas on what they >> might know this concept as? >its not known as anything else as far as I know. Yeah, I'm coming to that conclusion as well. >Just explain to them the >concept, that the D channel of one PRI is serving as the D channel for >other PRI's as well, and that you need to tell those other PRI's where the >D channel is located for there signalling information. He's aware of the concept, but this is the first setup like this that the local area of this phone company has done (its a new competitive access provider in the area), so he's not familiar with the setup. :/ >Non Facilitated Automated Switching is what I think it >means....... Actually, I found what the acronym stands for (Dejanews is awesome :), Non-Facility Associated Signalling >anyways, it takes a while with bellsouth to find someone who >really knows what they are talking about. Amen there....I'm glad I'm not dealing with BellSouth anymore. :) They're getting to someone that will know the information....just the guy at the switch doesn't...thought I might be able to help him along a bit though. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) Totalservices FTP site
From: Andy Yu-Hun Liao <aliao@aicom.com>
Date: 1997-08-07 17:34:16

Hi, I am wondering if anyone else is also having problem when trying to access Totalservice FTP site like I am. I am have a registered account on Totalservices web site. However, when I was trying to connect to Totalservice FTP site, it returned bad password!!?? Email to USR doesn't have any reply back, makes me wonder if they do check their email or not. BTW, can anyone tell me what type of memory I should add to our NetServer card. I remember this was disguss before on the list, so can anyone with the knowledge please email me back? Thank you. Andy Yu-Hun Liao Internet Team, System Admin AICOM Internet Services Corp. (http://www.aicom.com), a division of AIC Asia International Services Corp. Phone #: (604) 298-2881 Fax #: (604) 298-5813

Subject: (usr-tc) ip pools
From: Charles Hill <chill@ionet.net>
Date: 1997-08-07 19:51:47

What is the RADIUS dictionary value for the attribute that specifies the ip pool name in the user profile. Regards, Charles Hill

Subject: Re: (usr-tc) ip pools
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-08-07 20:22:06

On Thu, 7 Aug 1997, Charles Hill wrote: > > What is the RADIUS dictionary value for the attribute that specifies the > ip pool name in the user profile. > > Regards, > > Charles Hill > > There is no special attribute that specifes the ip pool name. Some radius server can be modified to have IP pools within the user table - Those radius servers ( Like merit and modified livingston ESVA ? ) use in the user table entry to have a pool name. To assign a IP address from the assigned pool of address from the NETServer the Framed-IP-Address field should be 255.255.255.254 other than that there is no special framed ip address pool attribute. 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) Totalservices FTP site
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1997-08-07 22:03:39

Thus spake Andy Yu-Hun Liao >BTW, can anyone tell me what type of memory I should add to our NetServer >card. I remember this was disguss before on the list, so can anyone with >the knowledge please email me back? 72-pin, non-parity, uhm...I believe 70 ns or better is what USR quotes. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) NETServer/16 I-modem Experience
From: Butch Kemper <kemper@bihs.net>
Date: 1997-08-07 22:45:10

I am considering purchasing a NETServer/16 I-modem and am interested in hearing comments about your experiences using that device. The application will be to provide X2 access. Thanks. Butch Butch Kemper | Free sound advice available Brazos Internet Consulting Group | "95% sound and 5% advice" 409-361-2324 | Refunds cheerfully provided

Subject: Re: (usr-tc) Totalservices FTP site
From: Andy Yu-Hun Liao <aliao@aicom.com>
Date: 1997-08-07 23:58:32

At 10:03 PM 8/7/97 -0400, you wrote: >Thus spake Andy Yu-Hun Liao >>BTW, can anyone tell me what type of memory I should add to our NetServer >>card. I remember this was disguss before on the list, so can anyone with >>the knowledge please email me back? > >72-pin, non-parity, uhm...I believe 70 ns or better is what USR quotes. Hi, Thanks for the reply. Now, I have a 72pin, non-parity and 70ns and I belive it is EDO. I plug it in and restart the netserver card. It just stay on the RED/RED light, critical failure. Is there any DIP switch I have to set? Or it simply doesn't like EDO memory? Thanks. Andy Yu-Hun Liao Internet Team, System Admin AICOM Internet Services Corp. (http://www.aicom.com), a division of AIC Asia International Services Corp. Phone #: (604) 298-2881 Fax #: (604) 298-5813

Subject: Re: (usr-tc) ip pools
From: David Crabtree <wolfcub@wsnet.com>
Date: 1997-08-08 09:05:23

On Thu, 7 Aug 1997, Charles Hill wrote: > > What is the RADIUS dictionary value for the attribute that specifies the > ip pool name in the user profile. Are you talking about how do you make the Radius Server tell the TC to use the assigned pool of IP addresses for dynamic allocation? If so you set the FRAMED_ADDRESS to 255.255.255.254. /----------------------------David Crabtree----------------------------- | e MailTo: wolfcub@wsnet.com Aliases: WolfCub, [GI] Scream | Web: http://www.wsnet.com/~wolfcub | Role: WebMaster - Graphics - Programmer - Sys Admin - Quake Player \-----------------------------------------------------------------------

Subject: Re: (usr-tc) Totalservices FTP site
From: Joachim Nerz <nerz@ipx2.rz.uni-mannheim.de>
Date: 1997-08-08 09:16:48

On Thu, 7 Aug 1997, Andy Yu-Hun Liao wrote: > At 10:03 PM 8/7/97 -0400, you wrote: > >Thus spake Andy Yu-Hun Liao > >>BTW, can anyone tell me what type of memory I should add to our NetServer > >>card. I remember this was disguss before on the list, so can anyone with > >>the knowledge please email me back? > > > >72-pin, non-parity, uhm...I believe 70 ns or better is what USR quotes. > > Hi, Thanks for the reply. Now, I have a 72pin, non-parity and 70ns and I > belive it is EDO. I plug it in and restart the netserver card. It just > stay on the RED/RED light, critical failure. Is there any DIP switch I > have to set? No! > Or it simply doesn't like EDO memory? Yes! bye Joachim Nerz

Subject: Re: (usr-tc) Totalservices FTP site
From: Lars Freund <lafreund@cip.e-technik.uni-erlangen.de>
Date: 1997-08-08 10:13:30

On Thu, 7 Aug 1997, Jeff Mcadams wrote: > Thus spake Andy Yu-Hun Liao > >BTW, can anyone tell me what type of memory I should add to our NetServer > >card. I remember this was disguss before on the list, so can anyone with > >the knowledge please email me back? > > 72-pin, non-parity, uhm...I believe 70 ns or better is what USR quotes. NON EDO Bye, Lars +-----------------------------------------------------------------+ | Lars Freund Email: lafreund@cip.e-technik.uni-erlangen.de | | FOnLine Buergernetzverein: http://www.forchheim.baynet.de | | http://cip2.e-technik.uni-erlangen.de:8080/hyplan/lafreund.html | +-----------------------------------------------------------------+

Subject: Re: What sort of simm's in total control? [was - Re: (usr-tc) Totalservices FTP site
From: Lars Freund <lafreund@cip.e-technik.uni-erlangen.de>
Date: 1997-08-08 10:17:04

On Fri, 8 Aug 1997, Peter Evans wrote: Hi, > | belive it is EDO. I plug it in and restart the netserver card. It just > | stay on the RED/RED light, critical failure. Is there any DIP switch I > | have to set? Or it simply doesn't like EDO memory? > > The latter. Tried it too ^_^! I was told in this list to use EDO, and I had the same. Our Netserver Card didn't come up again. Even with the old or wihtout SIMM. We had to do a replacement by USR because of using this EDO RAM... Bye, Lars +-----------------------------------------------------------------+ | Lars Freund Email: lafreund@cip.e-technik.uni-erlangen.de | | FOnLine Buergernetzverein: http://www.forchheim.baynet.de | | http://cip2.e-technik.uni-erlangen.de:8080/hyplan/lafreund.html | +-----------------------------------------------------------------+

Subject: (usr-tc) x2 connect times
From: Mark Wilson <mrw@netdirect.net>
Date: 1997-08-08 10:44:52

I've had some customers report that it takes them between 50 and 58 seconds to connect to our TC. This is from the beginning of the handshake until the 'Connected at xxxxk' message in Win95. Connect to our 28.8k lines takes only 28 seconds. Is anyone else seeing this? Is there a reason? Mark Wilson Net Direct

Subject: (usr-tc) dual PRI NFAS setup solution
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1997-08-08 11:51:38

Well...sat down with the guy a the switch (on the phone actually) and worked through the call routing with the dual pri on 1 d-channel setup. Basically, the 5ESS switch that they have routes the calls to a "diffy" (at least its pronounced that way..didn't get the spelling) which has 2 t1's associated with it (called "facilities" in the diffy) which matches up with the the two t1's that we plug into a single USR chassis. The diffy figures out which facility has a free B channel, sends the call setup request down the d-channel indicating the timeslot, and facility its using. So, just as a shot in the dark, I decided to enter the facility numbers that the diffy uses in as the NFAS id's (took me two tries, got them reversed the first time), and viola', it worked. :) So, the answer to my question that I posted yesterday was...if the telco has no clue what NFAS is, ask them for the facility numbers on the diffies. (geez...I feel like I'm talking a foreign language here) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) Old 002059 bundle vs new 001866 bundle
From: Mike Andrews <mandrews@termfrost.org>
Date: 1997-08-08 15:04:52

Quick question: We're getting ready to buy a dual PRI box, and we're debating between the 002059 bundle (old chassis, $14352) and the 001866 bundle (new chassis, but eligible for tradein for an extra free one). Since we have enough stuff to trade in, the new bundle is looking very attractive... Does the newer chassis' Netserver run the same software as the older chassis? 3com's replacing the old Livingston code gradually, and I understand the new code is available for the Netserver 8/8I/16/16I's... I'm asking because I'm unfortunately going to have a nasty time constraint to get this box going (a matter of days -- ouch!!), and I already know Livingston's ComOS pretty well. BTW, is there an FAQ or a web-searchable archive of this list, so I don't ask too many stupid questions? :-) Thanks :) Mike Andrews Digital Crescent mandrews@dcr.net

Subject: What sort of simm's in total control? [was - Re: (usr-tc) Totalservices FTP site
From: Peter Evans <peter@gol.com>
Date: 1997-08-08 16:40:48

Andy Yu-Hun Liao wrote: | At 10:03 PM 8/7/97 -0400, you wrote: | >Thus spake Andy Yu-Hun Liao | >>BTW, can anyone tell me what type of memory I should add to our NetServer | >>card. I remember this was disguss before on the list, so can anyone with | >>the knowledge please email me back? | >72-pin, non-parity, uhm...I believe 70 ns or better is what USR quotes. non EDO ^_^; | Hi, Thanks for the reply. Now, I have a 72pin, non-parity and 70ns and I | belive it is EDO. I plug it in and restart the netserver card. It just | stay on the RED/RED light, critical failure. Is there any DIP switch I | have to set? Or it simply doesn't like EDO memory? The latter. Tried it too ^_^! Peter ----* -- A well fed missile is a happy missile! - TRR 1997 O_u \\ Ciscomancer // P-Chan ya \\ Global OnLine Japan U \Beh! \\ Postmonster // P-Moji-Yo! \\ Steam Engine Dept

Subject: (usr-tc) Re: Multilink Issues (fwd)
From: Charles Hill <chill@ionet.net>
Date: 1997-08-09 00:57:57

Does anybody's knowledge base contain info on how to get a Rockwell. . . I mean, Cray. . . no, I mean Osicom Nethopper BRI connected to a USR. . . no, I mean 3Com Netserver PRI with both B-channels in such a way that it still talks to its ethernet? I have already recommended replacing the router with a Pipeline or a LanLinker or settling for a single B-channel, but he's an "internet consultant" who has sold this thing to our mutual customer, so pride won't allow it and I hate to tell him to go fish. -CH ---------- Forwarded message ---------- Charles, Thanks for the info. I was able at one point to get both channels in and could ping inet hosts from the router, but the local ethernet could not get out. The Osicom guys are supposed to find someone who knows the product. It definately can handle multilink, but they had no specific configs for a USR Total Control, just Ascend and Cisco products. If we do not get anywhere next week I may take you up on the 3COM support. You might email them in case their database has anything for a Rockwell Nethopper BRI dialup router. Thanks Bill > The Multilink setup at APG has been a bit painful. Cray (now Osicom) has taken over the > Rockwell products. The support is friendly but ineffectual. > I have sucessfully configured the multilink but routing from the local ethernet stops. > Have you run across any USR settings that may be different than standard? > It may be falling apart when the remote addresses are negotiated for the multilink group.

Subject: Re: (usr-tc) Re: Multilink Issues (fwd)
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-08-09 10:02:05

> > Does anybody's knowledge base contain info on how to get a Rockwell. . . > I mean, Cray. . . no, I mean Osicom Nethopper BRI connected to a USR. . . > no, I mean 3Com Netserver PRI with both B-channels in such a way that > it still talks to its ethernet? I have already recommended replacing the > router with a Pipeline or a LanLinker or settling for a single B-channel, > but he's an "internet consultant" who has sold this thing to our mutual > customer, so pride won't allow it and I hate to tell him to go fish. -CH What ever you mean charles, dial with it to a 3com/USR NETServer - and if you have access to the NETServer logon as root and set debug to 0x51 capture the same and send it to me. I will debug it for you. krish > > ---------- Forwarded message ---------- > Date: Fri, 8 Aug 1997 19:59:54 -0600 > To: Charles Hill <chill@ionet.net> > Subject: Re: Multilink Issues > > Charles, > > Thanks for the info. I was able at one point to get both channels in and > could ping inet hosts from the router, but the local ethernet could not > get out. The Osicom guys are supposed to find someone who knows the > product. It definately can handle multilink, but they had no specific > configs for a USR Total Control, just Ascend and Cisco products. If we do > not get anywhere next week I may take you up on the 3COM support. You > might email them in case their database has anything for a Rockwell > Nethopper BRI dialup router. > > Thanks > Bill > > > > The Multilink setup at APG has been a bit painful. Cray (now Osicom) has taken over the > > Rockwell products. The support is friendly but ineffectual. > > I have sucessfully configured the multilink but routing from the local ethernet stops. > > Have you run across any USR settings that may be different than standard? > > It may be falling apart when the remote addresses are negotiated for the multilink group. > > >

Subject: Re: (usr-tc) NETServer/16 I-modem Experience
From: Steve Coleman <scoleman@csolutions.net>
Date: 1997-08-09 22:39:45

Butch Kemper wrote: > > I am considering purchasing a NETServer/16 I-modem and am interested in > hearing comments about your experiences using that device. The application > will be to provide X2 access. > I have been very happy with ours. They don't provide the same bang for the buck (dollar per port) as the dual PRI unit's, but they allow you to use BRI which is much cheaper per port than PRI (around here anyway). Steve

Subject: (usr-tc) x2 modems
From: Brian <signal@shreve.net>
Date: 1997-08-10 11:08:26

I am trying to get a USR x2 sportster to do v34/v34+. I can't do it. If I set a floor connect speed of 28800 and ceiling of 33600 the connection drops, because it cant get that. If I set s32=32 (disable x2) it connects at v32 (14400) If I disable v32 ats27=4 it STILL connects at 14400 Why would I want to do this? Because my x2 connect speed is 44000 receive 21600 transmit. I would rather have 28800 bothways. I know 28800 bothways is possible, because when I plug in my old and crusty USR 28800 Sportster I can get 28800 everytime. From a new modem, set to factory default, what do I need to do to get a 56k sportster to do v34? I am dialing into our USR TC hubs. Brian oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

Subject: Re: (usr-tc) x2 modems
From: Robert Sanders <rsanders@mindspring.net>
Date: 1997-08-10 12:18:55

Brian <signal@shreve.net> writes: > If I set s32=32 (disable x2) it connects at v32 (14400) Set s32=34 instead, or just s32.5=1. You don't want to disable V.8 mode, which is what happens if you don't leave the second bit (2) set. -- Robert

Subject: Re: (usr-tc) x2 modems
From: Brian <signal@shreve.net>
Date: 1997-08-10 13:13:48

On 10 Aug 1997, Robert Sanders wrote: > Brian <signal@shreve.net> writes: > > > If I set s32=32 (disable x2) it connects at v32 (14400) > > Set s32=34 instead, or just s32.5=1. You don't want to disable V.8 > mode, which is what happens if you don't leave the second bit (2) set. > thanks, it worked :) Brian > -- Robert > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

Subject: (usr-tc) udp latency
From: Brian <signal@shreve.net>
Date: 1997-08-10 13:52:12

I think there is still some unresolved udp latency issues with the usr netserver card. Of all of our users on our quake server, its users of US using USR TC's that are lagged the most, other isp's users can connect to our quaie servre faster than our own users can. Brian oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

Subject: (usr-tc) Modem Disconnects
From: David Crabtree <wolfcub@wsnet.com>
Date: 1997-08-11 09:03:44

Is there any documents anywhere explaining all of the codes which TCManager recieves and reports on modem disconnects. Granted some of the terms are selve explanatory but others are not. /----------------------------David Crabtree----------------------------- | e MailTo: wolfcub@wsnet.com Aliases: WolfCub, [GI] Scream | Web: http://www.wsnet.com/~wolfcub | Role: WebMaster - Graphics - Programmer - Sys Admin - Quake Player \-----------------------------------------------------------------------

Subject: RE: (usr-tc) Modem Disconnects
From: Wayne Collins <wayncoll@enoreo.on.ca>
Date: 1997-08-11 10:54:23

Hi! We were seeing the same problem when we were using the TC to pass all incoming connections through to a unix box using the telnet service. After a week or so with USR/3com tech support we narrowed it down to (in the USR tech's words): "The telnet code is not as robust as rlogin. I suggest that you switch to using rlogin for connecting to the unix servers" We made the change and the problem was resolved with the switch to rlogin. We were running TCS 2.5 and 2.5.1. Hope this helps... Ttys Wayne -- Wayne Collins Education Network of Ontario mailto:wayncoll@enoreo.on.ca -----Original Message----- Sent: Monday, August 11, 1997 12:58 AM We have been using the USR Total Control Hub for about a year now. Recently, a large number of our users have been complaining of frequent modem disconnects. They are able to establish connection but after sometime (less than 20 seconds), they get disconnected. Using the TCM to examine the cause of disconnection, the following disconnect reason is reported: rcvdGatewayDiscCmd(62). We all know this message appears on the TCM when a port is reset manually. Any idea what this error is all about? How do we solve this problem? Looking forward to your prompt comments and suggestions. Thanks and best regards! Mike BTW, do we have an archive of past discussions? This could save me a lot of time and effort.

Subject: Re: (usr-tc) Modem Disconnects
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-08-11 11:22:26

Michael R. Poyaoan said once upon a time: > > >We have been using the USR Total Control Hub for about a year now. >Recently, a large number of our users have been complaining of frequent >modem disconnects. They are able to establish connection but after >sometime (less than 20 seconds), they get disconnected. Be sure you set the Modem/Line Interface/Carrier Loss time to 200 ms. By default is it set to 7 ms, a ridiculously short time for most dirty lines. We had frequent disconnect problems before we upped it. >BTW, do we have an archive of past discussions? This could save me a lot >of time and effort. ftp://ftp.xmission.com/pub/lists/usr-tc/archive http://www.xmission.com/pub/lists/usr-tc/archive

Subject: (usr-tc) Modem Disconnects
From: Michael R. Poyaoan <mrp@skyinet.net>
Date: 1997-08-11 12:57:38

We have been using the USR Total Control Hub for about a year now. Recently, a large number of our users have been complaining of frequent modem disconnects. They are able to establish connection but after sometime (less than 20 seconds), they get disconnected. Using the TCM to examine the cause of disconnection, the following disconnect reason is reported: rcvdGatewayDiscCmd(62). We all know this message appears on the TCM when a port is reset manually. Any idea what this error is all about? How do we solve this problem? Looking forward to your prompt comments and suggestions. Thanks and best regards! Mike BTW, do we have an archive of past discussions? This could save me a lot of time and effort.

Subject: Re: (usr-tc) Modem Disconnects
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-08-11 13:24:29

refer to http://interproc.ae.usr.co/info/white.html 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, 11 Aug 1997, Lars Freund wrote: > Hi, > > > > Is there any documents anywhere explaining all of the codes which > > TCManager recieves and reports on modem disconnects. Granted some of the > > terms are selve explanatory but others are not. > > I asked for this at support, and the only answer I got was for our > "reason 8" I mentioned. (no acknowledgement for 15 seconds on the bus) > > > Bye, > > Lars > > -- > +-----------------------------------------------------------------+ > | Lars Freund lars@forchheim.com | > | FOnLine Buergernetzverein: http://www.forchheim.baynet.de | > | http://cip2.e-technik.uni-erlangen.de:8080/hyplan/lafreund.html | > +-----------------------------------------------------------------+ > > >

Subject: Re: (usr-tc) Modem Disconnects
From: David Crabtree <wolfcub@wsnet.com>
Date: 1997-08-11 15:22:19

On Mon, 11 Aug 1997, Adam Wills (Global 2000) wrote: > lynx: Can't access start file http://interproc.ae.usr.co/info/white.html She forgot to type the "m" in .com http://interproc.ae.usr.com/info/white.html

Subject: Re: (usr-tc) Modem Disconnects
From: Adam Wills (Global 2000) <sysadmin@global2000.net>
Date: 1997-08-11 15:34:40

lynx: Can't access start file http://interproc.ae.usr.co/info/white.html Could you eleberate Krishnan? 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, 11 Aug 1997, Tatai SV Krishnan wrote: > refer to http://interproc.ae.usr.co/info/white.html > > 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, 11 Aug 1997, Lars Freund wrote: > > > Hi, > > > > > > > Is there any documents anywhere explaining all of the codes which > > > TCManager recieves and reports on modem disconnects. Granted some of the > > > terms are selve explanatory but others are not. > > > > I asked for this at support, and the only answer I got was for our > > "reason 8" I mentioned. (no acknowledgement for 15 seconds on the bus) > > > > > > Bye, > > > > Lars > > > > -- > > +-----------------------------------------------------------------+ > > | Lars Freund lars@forchheim.com | > > | FOnLine Buergernetzverein: http://www.forchheim.baynet.de | > > | http://cip2.e-technik.uni-erlangen.de:8080/hyplan/lafreund.html | > > +-----------------------------------------------------------------+ > > > > > > >

Subject: Re: (usr-tc) Modem Disconnects
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-08-11 15:39:04

sorry my mistake it is krish On Mon, 11 Aug 1997, Adam Wills (Global 2000) wrote: > oops :) for some reason i actually thought they had an out of country site > when i glanced at that part hehehe. > > 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, 11 Aug 1997, David Crabtree wrote: > > > > > On Mon, 11 Aug 1997, Adam Wills (Global 2000) wrote: > > > > > lynx: Can't access start file http://interproc.ae.usr.co/info/white.html > > > > he forgot to type the "m" in .com > > > > http://interproc.ae.usr.com/info/white.html > > > > > > > >

Subject: Re: (usr-tc) Modem Disconnects
From: Charles Hill <chill@ionet.net>
Date: 1997-08-11 15:50:10

I set the Loss-of-Carrier disconnect timeout setting to 30 tenths of a second. . . a medium number that is not too short but just long enough for those who forget to turn off call waiting. -CH > Pete Ashdown wrote: > > Be sure you set the Modem/Line Interface/Carrier Loss time to 200 ms. > > By default is it set to 7 ms, a ridiculously short time for most dirty > > lines. > > My right mouse button :-) tells me that the default is 7 _tenths_ of a > second. > Could it cause problems to set this variable to a huge value like 20s as > you did? I guess that the corresponding modem's not available for that > ammount of time after loss of the remote modem's carrier signal. > > Might not be critical if one has a bunch of idle modems in her/his rack. > > Anybody else being successful increasing this value? > > cu, > Stefan > > ----------------------------------------------------------------------- > Stefan Virsik mailto:virsik@metronet.de > Metronet > Postfach 510 869 phone: (+49) 221 3091 272 > 50944 Cologne, Germany fax: (+49) 221 3091 298 > >

Subject: Re: (usr-tc) Modem Disconnects
From: Adam Wills (Global 2000) <sysadmin@global2000.net>
Date: 1997-08-11 16:22:31

oops :) for some reason i actually thought they had an out of country site when i glanced at that part hehehe. 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, 11 Aug 1997, David Crabtree wrote: > > On Mon, 11 Aug 1997, Adam Wills (Global 2000) wrote: > > > lynx: Can't access start file http://interproc.ae.usr.co/info/white.html > > She forgot to type the "m" in .com > > http://interproc.ae.usr.com/info/white.html > > >

Subject: Re: (usr-tc) Modem Disconnects
From: Brian <signal@shreve.net>
Date: 1997-08-11 16:47:42

On Mon, 11 Aug 1997, Adam Wills (Global 2000) wrote: > lynx: Can't access start file http://interproc.ae.usr.co/info/white.html .com > > Could you eleberate Krishnan? > > 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, 11 Aug 1997, Tatai SV Krishnan wrote: > > > refer to http://interproc.ae.usr.co/info/white.html > > > > 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, 11 Aug 1997, Lars Freund wrote: > > > > > Hi, > > > > > > > > > > Is there any documents anywhere explaining all of the codes which > > > > TCManager recieves and reports on modem disconnects. Granted some of the > > > > terms are selve explanatory but others are not. > > > > > > I asked for this at support, and the only answer I got was for our > > > "reason 8" I mentioned. (no acknowledgement for 15 seconds on the bus) > > > > > > > > > Bye, > > > > > > Lars > > > > > > -- > > > +-----------------------------------------------------------------+ > > > | Lars Freund lars@forchheim.com | > > > | FOnLine Buergernetzverein: http://www.forchheim.baynet.de | > > > | http://cip2.e-technik.uni-erlangen.de:8080/hyplan/lafreund.html | > > > +-----------------------------------------------------------------+ > > > > > > > > > > > > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

Subject: Re: (usr-tc) Modem Disconnects
From: Stefan Virsik <virsik@metronet.de>
Date: 1997-08-11 19:40:47

Hi out there, Pete Ashdown wrote: > Be sure you set the Modem/Line Interface/Carrier Loss time to 200 ms. > By default is it set to 7 ms, a ridiculously short time for most dirty > lines. My right mouse button :-) tells me that the default is 7 _tenths_ of a second. Could it cause problems to set this variable to a huge value like 20s as you did? I guess that the corresponding modem's not available for that ammount of time after loss of the remote modem's carrier signal. Might not be critical if one has a bunch of idle modems in her/his rack. Anybody else being successful increasing this value? cu, Stefan Stefan Virsik mailto:virsik@metronet.de Metronet Postfach 510 869 phone: (+49) 221 3091 272 50944 Cologne, Germany fax: (+49) 221 3091 298

Subject: Re: (usr-tc) Modem Disconnects
From: Lars Freund <lafreund@cip.e-technik.uni-erlangen.de>
Date: 1997-08-11 19:52:16

Hi, > Is there any documents anywhere explaining all of the codes which > TCManager recieves and reports on modem disconnects. Granted some of the > terms are selve explanatory but others are not. I asked for this at support, and the only answer I got was for our "reason 8" I mentioned. (no acknowledgement for 15 seconds on the bus) Bye, Lars -- +-----------------------------------------------------------------+ | Lars Freund lars@forchheim.com | | FOnLine Buergernetzverein: http://www.forchheim.baynet.de | | http://cip2.e-technik.uni-erlangen.de:8080/hyplan/lafreund.html | +-----------------------------------------------------------------+

Subject: (usr-tc) NSD #2245
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-08-12 10:20:41

Is this the same problem that is causing the ethernet to "freeze" on 3.5.34? I really enjoyed the "workaround." "Reboot the Netserver." As if that was a viable workaround for anything. Can any of the USR people say whether we are going to see any resolution on the ethernet freezing problem?

Subject: (usr-tc) Logging modem connect speed in Radius
From: Peter Clausen <peter@cstone.net>
Date: 1997-08-12 10:37:10

I was wondering if the TC has the ability to log modem connect speeds in the detail file generated by RADIUS accounting like the way an Ascend Max does? After giving up on trying to get any kind of accounting output using Ascend RADIUS (it did authenticate users just fine) on a TC, I switched to Livingston RADIUS and now I'm getting start and stop records, but no modem connect speeds are being logged. I know I can use TCM (or another SNMP package) to get this info, but I'd much rather have it in the stop records if at all possible since that is what I currently use to generate my stats.

Subject: Re: (usr-tc) Logging modem connect speed in Radius
From: MegaZone <megazone@livingston.com>
Date: 1997-08-12 11:04:40

Once upon a time Peter Clausen shaped the electrons to say... >I was wondering if the TC has the ability to log modem connect speeds in >the detail file generated by RADIUS accounting like the way an Ascend Max >does? I believe the issue is USR uses VSA's to log that info - and neither Livingston nor Ascend support VSAs in their servers. There is a standard attribute from the RADIUS Extensions draft - Connect-Info - which is what PM-3s log the speeds with. But I don't think USR supports this yet. -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) NSD #2245
From: Tom Bilan <tom@tdi.net>
Date: 1997-08-12 13:22:25

------ =_NextPart_000_01BCA722.C6D05540 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I gave up. I went back to 3.4.x until USR actually tests 3.5.34 and finds out that everyone who is telling them there's a problem isn't on drugs. Tom -----Original Message----- Sent: Tuesday, August 12, 1997 12:21 PM Is this the same problem that is causing the ethernet to "freeze" on 3.5.34? I really enjoyed the "workaround." "Reboot the Netserver." As if that was a viable workaround for anything. Can any of the USR people say whether we are going to see any resolution on the ethernet freezing problem? ------ =_NextPart_000_01BCA722.C6D05540 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IhoRAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAyAEAAAEAAAAQAAAAAwAAMAIAAAAL AA8OAAAAAAIB/w8BAAAATwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHVzci10Y0BtYWlsLnht aXNzaW9uLmNvbQBTTVRQAHVzci10Y0BtYWlsLnhtaXNzaW9uLmNvbQAAHgACMAEAAAAFAAAAU01U UAAAAAAeAAMwAQAAABkAAAB1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20AAAAAAwAVDAEAAAADAP4P BgAAAB4AATABAAAAGwAAACd1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20nAAACAQswAQAAAB4AAABT TVRQOlVTUi1UQ0BNQUlMLlhNSVNTSU9OLkNPTQAAAAMAADkAAAAACwBAOgEAAAAeAPZfAQAAABkA AAB1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20AAAAAAgH3XwEAAABPAAAAAAAAAIErH6S+oxAZnW4A 3QEPVAIAAAAAdXNyLXRjQG1haWwueG1pc3Npb24uY29tAFNNVFAAdXNyLXRjQG1haWwueG1pc3Np b24uY29tAAADAP1fAQAAAAMA/18AAAAAAgH2DwEAAAAEAAAAAAAAArFkAQSAAQAXAAAAUkU6ICh1 c3ItdGMpIE5TRCAjMjI0NQC1BQEFgAMADgAAAM0HCAAMAA0AFgAZAAIAJgEBIIADAA4AAADNBwgA DAANABUAIAACACwBAQmAAQAhAAAAMDYyMTFDRDJCRTEyRDExMTlCRkQwMDYwOTc3QjI4OUMADgcB A5AGAMgFAAAhAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAQAA5AICyIU1Ep7wBHgBwAAEAAAAXAAAAUkU6ICh1c3ItdGMpIE5TRCAjMjI0NQAAAgFxAAEA AAAWAAAAAbynRE0h0hwhBxK+EdGb/QBgl3sonAAAHgAeDAEAAAAFAAAAU01UUAAAAAAeAB8MAQAA AAwAAAB0b21AdGRpLm5ldAADAAYQD0GFJgMABxDtAQAAHgAIEAEAAABlAAAASUdBVkVVUElXRU5U QkFDS1RPMzRYVU5USUxVU1JBQ1RVQUxMWVRFU1RTMzUzNEFOREZJTkRTT1VUVEhBVEVWRVJZT05F V0hPSVNURUxMSU5HVEhFTVRIRVJFU0FQUk9CTEVNSQAAAAACAQkQAQAAALgCAAC0AgAA0gMAAExa RnWvPQHFPwAKAQMB9wKkA+MCAGNowQrAc2V0MCAHEwKDQwBQDuZwcnEyD+Z9iwqACMg7CW8yNTUC gBsKhAswYwBBC2BuZzEYMDMzC9QBMCBJIABnYXZlIHVwLi0V8XcJ8AVAYgDQayAAdG8gMy40LniH FmACMAMRVVNSIADQZHR1B0BseRdgB5B0QwQgF6A1LjM0GJBu6GQgZguAZAQgCGAFQFp0D3B0CqIK gGUWQHLmeQIgFlB3aBeABAAZIcsY8AuAZxrRZW0c8glw0icEIGEgETBvAmAdIRkEAG4nBUACICBk crB1Z3MuGyQbJFQDcOcfagr0HLAzNgFAFLABQE8d8RkwGLADwTE2EHEt9SMCTwUQZwuAB0AF0AeQ cHNhZ2UjAyC6GkAtGDE0NAFAHLAxODBHAUAM0CWTYiBGA2E6NQyDYg/QUA+wFlBBcxBoZG93A6Bb U00YVFA6CrAoFEB4bZUEAWkCIC4FoG1dH2UvJsAGYAIwJydUClBzZFhheSwP4B8gdRlQIIQxMiwQ MTk5NyyR6DoyMSegTSpHICAnJ2EsYHItdGMpaypIdaxiaiJRJyYoLvQpB7AAU0QgIzIyNDVfIL8U 4wvFIeIbQkkcYWj7HFIdECAkEAeAHeca4hxC7GNhLGAcxSAPsB1hG+AbGsEXgCIDUAngemUi5x7B GyQZlD8gFfEJcBjjMQnwam95CYA1gyJ33QWwawrACGAaEC45EDiQ/FJlBuAiMDWDB8AZYASQbxuR PEIoABxAZhskNqN3+yjwHcF2BzAeIRbAO7caMLsFsQBweTVBFRAfW0MDkRtA0RqQZjWDGGJwZW// C1A1shkQHBA34xbBGJAJcP0WEG8cwxeAD6BEkUJxCXD+cwbwGrApwTknN6s4sxzCLR31Px9qEfEA ShADABAQAAAAAAMAERAAAAAAAwCAEP////9AAAcwICuSLUSnvAFAAAgwICuSLUSnvAELAACACCAG AAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMAAoAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAA AwAFgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUAALcNAAAeACWACCAGAAAAAADAAAAAAAAARgAAAABU hQAAAQAAAAQAAAA4LjAAAwAmgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALAC+ACCAGAAAA AADAAAAAAAAARgAAAAAOhQAAAAAAAAMAMIAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAy gAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAeAEGACCAGAAAAAADAAAAAAAAARgAAAAA2hQAA AQAAAAEAAAAAAAAAHgBCgAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4AQ4AI IAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAAAAAeAD0AAQAAAAUAAABSRTogAAAAAAMA DTT9NwAA1To= ------ =_NextPart_000_01BCA722.C6D05540--

Subject: Re: (usr-tc) NSD #2245
From: Brian <signal@shreve.net>
Date: 1997-08-12 17:02:43

On Tue, 12 Aug 1997, Pete Ashdown wrote: > Is this the same problem that is causing the ethernet to "freeze" on > 3.5.34? I really enjoyed the "workaround." "Reboot the Netserver." As if > that was a viable workaround for anything. > > Can any of the USR people say whether we are going to see any resolution on > the ethernet freezing problem? > You know its funny that you and so many others have this same problem. When I worked my problem (same one) thru engineering, the result is they are sending me a new netserver card. Personally I dont think its going to change anything, unless its an enhanced packet bus card, which I am told doesnt have the freeze problem. Does anyone talk to eachother, its more than a "few" people having this problem, there are many isps I talk to that arent even on this list having the nic lockup problem. Brian oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

Subject: Re: (usr-tc) NSD #2245
From: Brian <signal@shreve.net>
Date: 1997-08-12 18:57:41

On Tue, 12 Aug 1997, Jeff Binkley wrote: > -> > Is this the same problem that is causing the ethernet to "freeze" on > > -> 3.5.34? I really enjoyed the "workaround." "Reboot the Netserver." As if > -> > that was a viable workaround for anything. > -> > > -> > Can any of the USR people say whether we are going to see any resolution > -> on > the ethernet freezing problem? > -> > > -> > -> You know its funny that you and so many others have this same problem. When > -> I worked my problem (same one) thru engineering, the result is they are > -> sending me a new netserver card. Personally I dont think its going to > -> change anything, unless its an enhanced packet bus card, which I am told > -> doesnt have the freeze problem. > -> > -> Does anyone talk to eachother, its more than a "few" people having this > -> problem, there are many isps I talk to that arent even on this list having > -> the nic lockup problem. > > Brian, > > I'm not having the problem but maybe I have an enhanced packet bus card. The > system is less than 2 months old. How can you tell if it has the enhanced > packet bus Netserver card ? show vers will tell you the packet bus is enhanced or standard. Brian > > Jeff Binkley > ASA Network Computing > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

Subject: Re: (usr-tc) NSD #2245
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1997-08-12 19:43:00

-> > Is this the same problem that is causing the ethernet to "freeze" on > -> 3.5.34? I really enjoyed the "workaround." "Reboot the Netserver." As if -> > that was a viable workaround for anything. -> > -> > Can any of the USR people say whether we are going to see any resolution -> on > the ethernet freezing problem? -> > -> -> You know its funny that you and so many others have this same problem. When -> I worked my problem (same one) thru engineering, the result is they are -> sending me a new netserver card. Personally I dont think its going to -> change anything, unless its an enhanced packet bus card, which I am told -> doesnt have the freeze problem. -> -> Does anyone talk to eachother, its more than a "few" people having this -> problem, there are many isps I talk to that arent even on this list having -> the nic lockup problem. Brian, I'm not having the problem but maybe I have an enhanced packet bus card. The system is less than 2 months old. How can you tell if it has the enhanced packet bus Netserver card ? Jeff Binkley ASA Network Computing

Subject: Re: (usr-tc) NSD #2245
From: Brian Elfert <brian@citilink.com>
Date: 1997-08-12 20:32:49

On Tue, 12 Aug 1997, Brian wrote: > You know its funny that you and so many others have this same problem. > When I worked my problem (same one) thru engineering, the result is they > are sending me a new netserver card. Personally I dont think its going to > change anything, unless its an enhanced packet bus card, which I am told > doesnt have the freeze problem. > > Does anyone talk to eachother, its more than a "few" people having this > problem, there are many isps I talk to that arent even on this list having > the nic lockup problem. I have a standard packet bus Netserver, and I have yet to see this problem in the 6 or 7 weeks I've been running 3.5.34. (My netserver was purchased in April.) David Bolen from ANS did say that there have been quite a number of revs to the standard packet bus netserver card. Maybe you'll get a card that is the latest revision. Brian

Subject: RE: (usr-tc) NSD #2245
From: Tom Bilan <tom@tdi.net>
Date: 1997-08-12 21:15:39

------ =_NextPart_000_01BCA764.E36449E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Let me know if you get the enhanced packet bus back from them. Also, if you have a case #, that may be helpful :) Tom -----Original Message----- Sent: Tuesday, August 12, 1997 6:03 PM On Tue, 12 Aug 1997, Pete Ashdown wrote: > Is this the same problem that is causing the ethernet to "freeze" on > 3.5.34? I really enjoyed the "workaround." "Reboot the Netserver." As if > that was a viable workaround for anything. > > Can any of the USR people say whether we are going to see any resolution on > the ethernet freezing problem? > You know its funny that you and so many others have this same problem. When I worked my problem (same one) thru engineering, the result is they are sending me a new netserver card. Personally I dont think its going to change anything, unless its an enhanced packet bus card, which I am told doesnt have the freeze problem. Does anyone talk to eachother, its more than a "few" people having this problem, there are many isps I talk to that arent even on this list having the nic lockup problem. Brian oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo ------ =_NextPart_000_01BCA764.E36449E0 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IikBAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAyAEAAAEAAAAQAAAAAwAAMAIAAAAL AA8OAAAAAAIB/w8BAAAATwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHVzci10Y0BtYWlsLnht aXNzaW9uLmNvbQBTTVRQAHVzci10Y0BtYWlsLnhtaXNzaW9uLmNvbQAAHgACMAEAAAAFAAAAU01U UAAAAAAeAAMwAQAAABkAAAB1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20AAAAAAwAVDAEAAAADAP4P BgAAAB4AATABAAAAGwAAACd1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20nAAACAQswAQAAAB4AAABT TVRQOlVTUi1UQ0BNQUlMLlhNSVNTSU9OLkNPTQAAAAMAADkAAAAACwBAOgEAAAAeAPZfAQAAABkA AAB1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20AAAAAAgH3XwEAAABPAAAAAAAAAIErH6S+oxAZnW4A 3QEPVAIAAAAAdXNyLXRjQG1haWwueG1pc3Npb24uY29tAFNNVFAAdXNyLXRjQG1haWwueG1pc3Np b24uY29tAAADAP1fAQAAAAMA/18AAAAAAgH2DwEAAAAEAAAAAAAAArFkAQSAAQAXAAAAUkU6ICh1 c3ItdGMpIE5TRCAjMjI0NQC1BQEFgAMADgAAAM0HCAAMABUADwAnAAIANQEBIIADAA4AAADNBwgA DAAVAA8ADwACAB0BAQmAAQAhAAAAQzhFNjI1ODk1NzEzRDExMTlCRkQwMDYwOTc3QjI4OUMADwcB A5AGAAwIAAAhAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAQAA5AGB/rGmGp7wBHgBwAAEAAAAXAAAAUkU6ICh1c3ItdGMpIE5TRCAjMjI0NQAAAgFxAAEA AAAWAAAAAbynhmmsiSXmyRNXEdGb/QBgl3sonAAAHgAeDAEAAAAFAAAAU01UUAAAAAAeAB8MAQAA AAwAAAB0b21AdGRpLm5ldAADAAYQn7OUbwMABxCwBAAAHgAIEAEAAABlAAAATEVUTUVLTk9XSUZZ T1VHRVRUSEVFTkhBTkNFRFBBQ0tFVEJVU0JBQ0tGUk9NVEhFTUFMU08sSUZZT1VIQVZFQUNBU0Uj LFRIQVRNQVlCRUhFTFBGVUw6KVRPTS0tLS0tT1JJRwAAAAACAQkQAQAAAPkEAAD1BAAA9wcAAExa RnVksizDPwAKAQMB9wKkA+MCAGNowQrAc2V0MCAHEwKDQwBQDuZwcnEyD+Z9iwqACMg7CW8yNTUC gBsKhAswYwBBC2BuZzGYMDMzC9QBMCBMD7DCIAeAIGtubwfgBpAkIHkIYCBnFhF0aKcWUAnwD3Bu YwmAIAqwpGNrFhFidQQgYhhR5iADUhdibS4KogqECoBgQWxzbywWtg9wdiEWUGEgY2EPoCAjyxrg F3BhFiFheRigFlAhF4BscGZ1AyA6KR0Z6lQDcBnqCvRsaTOeNgFAFLABQBEwb3QFkFJ0A8ExNhBx LSFiTz0FEGcLgAdABdAHkHNhBxcwIWMfGmZpLTE0xjQBQB/QMTgwAUAM0FEj82IgRgNhOgyDYg0P 0EIHIQOgW1NNVBRQOgCQZyIBQHNo0wlwG5Aubg+wXRnlJSCXBmACMCWHVApQc2QcwDEa4EF1ZxjA BUAxMgEa4DE5OTcgNjrxFUAgUE0n9x6AJYcYwGByLXRjQADAAxAu1HhtBAFpAiAuBaAepjEoYXVi aiCxJYdSZSg6ICgslCkHsFNE4RwgMjI0NR8fFOMLxfsgQhoCTwOgKVEqcRFhKfBbKoMa4FAPsBZQ QSdAZDsWkAOgdyCCJYAZ+T4g/kkEIBdwBAAXYyJwFkEgcf8CYBmwHFQ3ARvgGMALgDQgjxdzF3EE oBdCbyAiA1BhCeB6ZSIgAiA2NjOALjUuMzQ/IDagNiAJcAdAbBzQCfBqb6Z5GBEXciJ3BbBrCsDx CGBuZC46sDowL6AG4FcgkBdjB8B0D6ByG5By3z4CNPAWsTY2HGN3G/Absf52BzA38TVgPXcZMAWx AHC+eTbhFRAZ1TaQNjZDA5GPQrE6wBbQF3JVU1IYMNxlbwtQN1Ic0HcXgDmS7zVgG6EJcBcgbzkD OiAPoN8boUSRCXAawApAdC2hOslvOUs6UzkCN8U/Q0wZ5Fn/FwEWdD8gGTA90ESRHGMW8v8AcBgg GsAcoUSSOZIEIBtz9zbjN3oZ1VcXgAOgPAA9Ym0YEW0c0DfGKDdzAiBl+zBQF3ByFxAJ8CHhCeAF EH8VEBxCFlBIIR1wOHMXcXn/GeRG0g+gPeA5AhZBG8AnsN8H4CexPzQb0QsgLjvgNKB/D5ACIDxD PAA1IAIwNtJu/xkgTSJHFhnkD2EVEEfDQuP/GuA90DgABBFNIgORF78YwfdYIhrgRiBpD2A78TeA OgH+bAsxGgI1IAeQWYFPhRZQ9zpUUG0Z5ERgIUKiU0EXYP8HQBkgOhE8MA9gTxMa4U0x/wRgRuEc YURhOjEH0DqwRXX/G3E5BAQAGeQ3xVSTRuFG0vtOwwQAcAQgPABjhhxjRtH/WYEncUiyNtQf0Coh ZoQZ5CsXcgMAY2twbxhgdXD/YX8aAiYTHr4KgD6AcE9xX/9yb3N/bmklMAnhVcABkTvgd3XhPoA7 4FMnUz8BGuBJ3xfwGdB1tnYhdaNQZDAnsB0vwTMkYDBQMMAyLTIITkVUGeRVTklY3Q/gZC1gAwAq IHIcgAWxR3YjFVArEFRleEEBUxkFQCM2KpB3yUZBWOt4yCFQNnyAMhnkJt932A12dHAJERrgTEEg N/oxFTAxd/UUox1wAPAEAAtBchggaAJAcDovL+p3g9AuJ0gvICMdcAFB/4LlMuVzj4dPiF+Jb3R2 iq8KChHxAIxgAAAAAwAQEAAAAAADABEQAAAAAAMAgBD/////QAAHMKD0zlqGp7wBQAAIMKD0zlqG p7wBCwAAgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAKACCAGAAAAAADAAAAAAAAARgAA AAAQhQAAAAAAAAMABYAIIAYAAAAAAMAAAAAAAABGAAAAAFKFAAC3DQAAHgAlgAggBgAAAAAAwAAA AAAAAEYAAAAAVIUAAAEAAAAEAAAAOC4wAAMAJoAIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAA CwAvgAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADADCACCAGAAAAAADAAAAAAAAARgAAAAAR hQAAAAAAAAMAMoAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAHgBBgAggBgAAAAAAwAAAAAAA AEYAAAAANoUAAAEAAAABAAAAAAAAAB4AQoAIIAYAAAAAAMAAAAAAAABGAAAAADeFAAABAAAAAQAA AAAAAAAeAEOACCAGAAAAAADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAAAAAAHgA9AAEAAAAFAAAA UkU6IAAAAAADAA00/TcAALAQ ------ =_NextPart_000_01BCA764.E36449E0--

Subject: Re: (usr-tc) NSD #2245
From: Rick <rallan@monmouth.com>
Date: 1997-08-12 23:10:46

Brian, we recently upgraded all our TC Hubs to the new 3.5.34 and I have to say other then having to disable ccp (which would cause our netserver cards to reboot now and then when certain ISDN adapters would connect using compression) we have all of them up for over 20+ straight days. The only problem we have ever run into regarding the netserver cards was having the dreaded fc3 chip which caused one of our netserver cards to reboot 10 times a day. Once we upgraded that card to one with a fc2 chip the problem was gone. 80% of our netservers card are standard bus and the rest enhanced. Brian wrote: > On Tue, 12 Aug 1997, Pete Ashdown wrote: > > > Is this the same problem that is causing the ethernet to "freeze" on > > > 3.5.34? I really enjoyed the "workaround." "Reboot the > Netserver." As if > > that was a viable workaround for anything. > > > > Can any of the USR people say whether we are going to see any > resolution on > > the ethernet freezing problem? > > > > You know its funny that you and so many others have this same problem. > > When I worked my problem (same one) thru engineering, the result is > they > are sending me a new netserver card. Personally I dont think its > going to > change anything, unless its an enhanced packet bus card, which I am > told > doesnt have the freeze problem. > > Does anyone talk to eachother, its more than a "few" people having > this > problem, there are many isps I talk to that arent even on this list > having > the nic lockup problem. > > Brian > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > > Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET > UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 > signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rick---* http://www.monmouth.com | Serving the Central Monmouth Internet Engineer | New Jersey Area Operations and Technical Support | Phone: 732-224-8624 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Subject: Re: (usr-tc) NSD #2245
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-08-13 06:42:18

On Tue, 12 Aug 1997, Pete Ashdown wrote: > Is this the same problem that is causing the ethernet to "freeze" on > 3.5.34? I really enjoyed the "workaround." "Reboot the Netserver." As if > that was a viable workaround for anything. > > Can any of the USR people say whether we are going to see any resolution on > the ethernet freezing problem? > This problem was seen at two places - when the code was upgraded from an Engineering release code to production code and vice versa. And at one site the problem show few nbuffs. The "workaround" for that problem then was to reboot the NETServer - to get it working. This problem cannot be reproduces at will and has been only at these two sites. Do you have this problem? If you do please explain the symptoms and we will work with you to get the resolution to the 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

Subject: (usr-tc) Disconnects and RNA's
From: Brian Trader -- WAN Technician <brian@netins.net>
Date: 1997-08-13 08:02:37

I know there has been talk in here lately about disconnects and slow connect speeds now I was wondering has anyone found a fix for them? We are using 5.5.6 and 5.6.6 on our racks and even got some new software that is still beta but it didn't help. As for RNA's we have been had a bunch of them creeping up lately and I am wondering if anyone else has? Thanxs Brian Trader WAN Technician netINS 515-830-0494

Subject: Re: (usr-tc) Disconnects and RNA's
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-08-13 08:23:40

On Wed, 13 Aug 1997, Brian Trader -- WAN Technician wrote: > > I know there has been talk in here lately about disconnects and slow > connect speeds now I was wondering has anyone found a fix for them? > We are using 5.5.6 and 5.6.6 on our racks and even got some new software > that is still beta but it didn't help. As for RNA's we have been had a > bunch of them creeping up lately and I am wondering if anyone else has? > > > Thanxs > Brian Trader > WAN Technician > netINS > 515-830-0494 > > > Do you have a open ticket with USR on this issue? krish

Subject: Re: (usr-tc) Disconnects and RNA's
From: Brian Trader -- WAN Technician <brian@netins.net>
Date: 1997-08-13 08:45:21

>On Wed, 13 Aug 1997, Brian Trader -- WAN Technician wrote: > >> >> I know there has been talk in here lately about disconnects and slow >> connect speeds now I was wondering has anyone found a fix for them? >> We are using 5.5.6 and 5.6.6 on our racks and even got some new software >> that is still beta but it didn't help. As for RNA's we have been had a >> bunch of them creeping up lately and I am wondering if anyone else has? >> >> >> Thanxs >> Brian Trader >> WAN Technician >> netINS >> 515-830-0494 >> >> >> >Do you have a open ticket with USR on this issue? > >krish > Yes ticket 7060108 been open for over a week Brian Trader Iowa Network Services WAN Technician 515-830-0494

Subject: Re: (usr-tc) NSD #2245
From: James MacKenzie <tomservo@erie.net>
Date: 1997-08-13 09:13:19

On Tue, 12 Aug 1997, Rick wrote: > Brian, we recently upgraded all our TC Hubs to the new 3.5.34 and I have > to say other then having to disable ccp (which would cause our netserver > cards to reboot now and then when certain ISDN adapters would connect > using compression) we have all of them up for over 20+ straight days. > The only problem we have ever run into regarding the netserver cards was > having the dreaded fc3 chip which caused one of our netserver cards to > reboot 10 times a day. Once we upgraded that card to one with a fc2 chip > the problem was gone. 80% of our netservers card are standard bus and > the rest enhanced. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Rick---* http://www.monmouth.com | Serving the Central > Monmouth Internet Engineer | New Jersey Area > Operations and Technical Support | Phone: 732-224-8624 > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= How do you tell if your netserver card has the fc2 or fc3 chip? I have as of yet not upgraded to the 3.5.34, and want to. We are experiencing occasional reboots. (We're currently running 3.4.23). Also, on another completely different note...We're running a 4 Meg netserver card. Is the upgrade to 16 Megs as simple as changing the chip and updating the code? Jim MacKenzie tomservo@erie.net System Administrator ErieNet, Inc. "I love California. I practically grew up in Phoenix." - Former U.S. VP Dan Quayle

Subject: Re: (usr-tc) Disconnects and RNA's
From: pris sears <sears@vt.edu>
Date: 1997-08-13 09:16:04

we have been experiencing a fair number of disconnects as well. is there a USR test number (800) that a user could call in to and download a big file to see if the problem might be on their end? thanks for any info - Pris _____________________________________________________________ Thanks for your kind attention - I'm outta here! Pris Sears | sears@vt.edu | http://sears.cns.vt.edu/ | 231-2305

Subject: (usr-tc) RE: (USR-TC) NSD #2245
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1997-08-13 09:37:00

U>On Tue, 12 Aug 1997, Jeff Binkley wrote: U>> -> > Is this the same problem that is causing the ethernet to U>> -> "freeze" on > 3.5.34? I really enjoyed the "workaround." U>"Reboot the Netserver." As if U>> -> > that was a viable workaround for anything. U>> -> > Can any of the USR people say whether we are going to see any U>resolution U>> -> on > the ethernet freezing problem? U>> -> > U>> -> You know its funny that you and so many others have this same U>problem. When U>> -> I worked my problem (same one) thru engineering, the result is U>> -> they are sending me a new netserver card. Personally I dont U>> -> think its going to change anything, unless its an enhanced packet U>> -> bus card, which I am told doesnt have the freeze problem. U>> -> Does anyone talk to eachother, its more than a "few" people U>> -> having this problem, there are many isps I talk to that arent U>even on this list having U>> -> the nic lockup problem. U>> Brian, U>> I'm not having the problem but maybe I have an enhanced packet bus U>card. The U>> system is less than 2 months old. How can you tell if it has the U>> enhanced packet bus Netserver card ? U>show vers will tell you the packet bus is enhanced or standard. Actually the command is just "version" but here's the output: U.S. Robotics Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.5.34 Build date: Jun 19 1997 Build time: 14:02:28 Network Interface Card: Ethernet & Frame Relay Combination (26) ISDN Interface Card : MUNICH32 (4) Packet Bus Circuit : Standard Licensed for 60 ports. So anyway, I have been running for a couple of months without any freezing with 3.5.34. Jeff Binkley ASA Network Computing CMPQwk 1.42 9999

Subject: (usr-tc) Radius Error Message
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1997-08-13 09:46:00

I am getting the following error message in our RADIUS logs. I've asked before but have never been able to get an answer on it. I believe the attribute is the last modem speed connection option. I'd like to get this fixed and have the modem connect speeds written to the RADIUS database. THis is the stock TCM manager code I am running with Access 7.0 database. SQL: SELECT * FROM CLIENTS WHERE IP = '199.178.136.2' Wed Aug 13 07:01:18 1997 Radius Security Event:Wed Aug 13 07:01:18 1997 Code = 5 PacketID = 17 Length = 20 Authen = 4d 65 59 61 71 41 35 65 41 29 29 49 21 75 2d 79 Attrb: Server_Time Value: 871470078 Accounting Event - Event Log Code = 4 PacketID = 18 Length = 216 Authen = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Attrb: Acct_Session_Id Value: 07020005 Attrb: User_Name Value: User:suedell Attrb: Client_Id Value: 199.178.136.18 Attrb: Client_Port_Id Value: Port#31 Attrb: Acct_Status_Type Value: Acct-Status-Type=1 Attrb: Acct_Authentic Value: RADIUS Attrb: Error: Unknown Attribute (USRNMC) 0x9023 <--- error Value: Attrb: Modulation_Type Value: v32Terbo Attrb: Simplified_MNP_Levels Value: 3 Attrb: Simplified_V42bis_Usage Value: 1 Attrb: Chassis_Call_Slot Value: 0 Attrb: Chassis_Call_Span Value: 0 Attrb: Chassis_Call_Channel Value: 0 Attrb: Unauthenticated_Time Value: 19 Attrb: NAS_Identifier Value: netserver Attrb: NAS_Port_Type Value: 0 Attrb: User_Service_Type Value: Framed_User Attrb: Framed_Protocol Value: PPP Attrb: Framed_Address Value: 199.178.136.39 Attrb: Acct_Delay_Time Value: 0 Attrb: Acct_Delay_Time Value: 871470081 Thanks in advance, Jeff Binkley ASA Network Computing

Subject: Re: (usr-tc) RE: (USR-TC) NSD #2245
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-08-13 10:53:10

Jeff Binkley said once upon a time: >So anyway, I have been running for a couple of months without any >freezing with 3.5.34. I have 9 chassis's running 3.5.34 and 3 that I have had to drop back to 3.3.34 because of the ethernet freezing. They all have the "standard" packet bus. It isn't a bug that happens across the board on the "standards". Right now, it looks like the only salvation I'm going to get is the HiPer system.

Subject: Re: (usr-tc) NSD #2245
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-08-13 10:57:24

Tatai SV Krishnan said once upon a time: >Do you have this problem? If you do please explain the symptoms and we >will work with you to get the resolution to the problem. The ethernet will lock up on 3.5.34 yet I can still use the console. Rebooting it only gives more time on the server before it locks up again (usually a few days later). The command "reset net0" doesn't free up anything. There has also been a symptom where the ethernet starts dropping packets like crazy. Again, a reboot is necessary to clear it up, but the problem will eventually return.

Subject: (usr-tc) Modem Script Reset
From: Michael R. Poyaoan <mrp@skyinet.net>
Date: 1997-08-13 11:32:10

Is it possible to automatically reset the modem, lets say to factory default or to its configured settings, after a certain user disconnects gracefully or ungracefully? How can I do this with the USR Total Contol Hub? Thanks, Mike

Subject: Re: (usr-tc) NSD #2245
From: David Bolen <db3l@ans.net>
Date: 1997-08-13 14:09:25

Rick <rallan@monmouth.com> writes: > Brian, we recently upgraded all our TC Hubs to the new 3.5.34 and I have > to say other then having to disable ccp (which would cause our netserver > cards to reboot now and then when certain ISDN adapters would connect > using compression) we have all of them up for over 20+ straight days. This particular problem appears to be fairly insidious and only affecting particular cards under particular conditions. For many folks running into it it would seem an obvious problem since it occurs so widely and quickly. For others, they don't see it at all. I have also had a good number of standard packet bus cards running fine since the earliest days of 3.5 development, but I also had another equally large set immediately have problems when updated (from a previous production release) to the final 3.5.34. The trick is now for USR to properly identify any specific hardware and/or configuration that they can use to replicate the precise failures in the lab to track down what is tickling it. -- 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) NSD #2245
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-08-13 15:40:59

On Wed, 13 Aug 1997, Pete Ashdown wrote: > Tatai SV Krishnan said once upon a time: > > >Do you have this problem? If you do please explain the symptoms and we > >will work with you to get the resolution to the problem. > > The ethernet will lock up on 3.5.34 yet I can still use the console. > Rebooting it only gives more time on the server before it locks up again > (usually a few days later). The command "reset net0" doesn't free up > anything. > > There has also been a symptom where the ethernet starts dropping packets > like crazy. Again, a reboot is necessary to clear it up, but the problem > will eventually return. > > This is certainly a problem - but this may not be releated to the 2245 bug. When your NETServer lockup and that when you cannot telnet - please do a show mem command from the console This will show the system resources. Based on the system resources we can tell you if you are seeing the same problem. Ethernet lock up could be due to some other issues. I would advice that you please open a ticket with USR support - If you already have please let me know your ticket number. 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) NSD #2245
From: Brian <signal@shreve.net>
Date: 1997-08-13 17:08:19

On Wed, 13 Aug 1997, Tatai SV Krishnan wrote: > On Wed, 13 Aug 1997, Pete Ashdown wrote: > > > Tatai SV Krishnan said once upon a time: > > > > >Do you have this problem? If you do please explain the symptoms and we > > >will work with you to get the resolution to the problem. > > > > The ethernet will lock up on 3.5.34 yet I can still use the console. > > Rebooting it only gives more time on the server before it locks up again > > (usually a few days later). The command "reset net0" doesn't free up > > anything. > > > > There has also been a symptom where the ethernet starts dropping packets > > like crazy. Again, a reboot is necessary to clear it up, but the problem > > will eventually return. > > > > > This is certainly a problem - but this may not be releated to the 2245 > bug. When your NETServer lockup and that when you cannot telnet - please > do a show mem command from the console > > This will show the system resources. Based on the system resources we > can tell you if you are seeing the same problem. > > Ethernet lock up could be due to some other issues. I would advice that > you please open a ticket with USR support - If you already have please > let me know your ticket number. > > Krish I also have a ticket open on this issue, its #7058351. USR has sent me a new Netserver card, and I install it this weekend. Brian > > ----------------------------------------- > \ 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 > -------------------------------------------------------------------------/ > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

Subject: Re: (usr-tc) NSD #2245
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-08-13 17:47:56

On Wed, 13 Aug 1997, Brian wrote: > On Wed, 13 Aug 1997, Tatai SV Krishnan wrote: > > > On Wed, 13 Aug 1997, Pete Ashdown wrote: > > > > > Tatai SV Krishnan said once upon a time: > > > > > > >Do you have this problem? If you do please explain the symptoms and we > > > >will work with you to get the resolution to the problem. > > > > > > The ethernet will lock up on 3.5.34 yet I can still use the console. > > > Rebooting it only gives more time on the server before it locks up again > > > (usually a few days later). The command "reset net0" doesn't free up > > > anything. > > > > > > There has also been a symptom where the ethernet starts dropping packets > > > like crazy. Again, a reboot is necessary to clear it up, but the problem > > > will eventually return. > > > > > > > > This is certainly a problem - but this may not be releated to the 2245 > > bug. When your NETServer lockup and that when you cannot telnet - please > > do a show mem command from the console > > > > This will show the system resources. Based on the system resources we > > can tell you if you are seeing the same problem. > > > > Ethernet lock up could be due to some other issues. I would advice that > > you please open a ticket with USR support - If you already have please > > let me know your ticket number. > > > > Krish > > I also have a ticket open on this issue, its #7058351. USR has sent me a > new Netserver card, and I install it this weekend. > > Brian > > Did you have a problem with NETServer reboot? 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 > > -------------------------------------------------------------------------/ > > > > > > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET > UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 > signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > > >

Subject: Re: (usr-tc) NSD #2245
From: Brian <signal@shreve.net>
Date: 1997-08-13 17:52:45

On Wed, 13 Aug 1997, Tatai SV Krishnan wrote: > On Wed, 13 Aug 1997, Brian wrote: > > > On Wed, 13 Aug 1997, Tatai SV Krishnan wrote: > > > > > On Wed, 13 Aug 1997, Pete Ashdown wrote: > > > > > > > Tatai SV Krishnan said once upon a time: > > > > > > > > >Do you have this problem? If you do please explain the symptoms and we > > > > >will work with you to get the resolution to the problem. > > > > > > > > The ethernet will lock up on 3.5.34 yet I can still use the console. > > > > Rebooting it only gives more time on the server before it locks up again > > > > (usually a few days later). The command "reset net0" doesn't free up > > > > anything. > > > > > > > > There has also been a symptom where the ethernet starts dropping packets > > > > like crazy. Again, a reboot is necessary to clear it up, but the problem > > > > will eventually return. > > > > > > > > > > > This is certainly a problem - but this may not be releated to the 2245 > > > bug. When your NETServer lockup and that when you cannot telnet - please > > > do a show mem command from the console > > > > > > This will show the system resources. Based on the system resources we > > > can tell you if you are seeing the same problem. > > > > > > Ethernet lock up could be due to some other issues. I would advice that > > > you please open a ticket with USR support - If you already have please > > > let me know your ticket number. > > > > > > Krish > > > > I also have a ticket open on this issue, its #7058351. USR has sent me a > > new Netserver card, and I install it this weekend. > > > > Brian > > > > > > Did you have a problem with NETServer reboot? nope, just the lockup problem, had to reboot the netserver to clear it, next time it happens I will do sh mem and sh stream. Brian > > 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 > > > -------------------------------------------------------------------------/ > > > > > > > > > > > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > > Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET > > UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 > > signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > > > > > > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

Subject: Re: (usr-tc) Radius Error Message
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-08-13 17:53:56

This is Connect speed - A vendor specific attribute and here are the values ATTRIB_NMC Connect_Speed 0x9023 integer VALUE Connect_Speed NONE 0 VALUE Connect_Speed 300_BPS 1 VALUE Connect_Speed 1200_BPS 2 VALUE Connect_Speed 2400_BPS 3 VALUE Connect_Speed 4800_BPS 4 VALUE Connect_Speed 7200_BPS 5 VALUE Connect_Speed 9600_BPS 6 VALUE Connect_Speed 12000_BPS 7 VALUE Connect_Speed 14400_BPS 8 VALUE Connect_Speed 16800_BPS 9 VALUE Connect_Speed 19200_BPS 10 VALUE Connect_Speed 21600_BPS 11 VALUE Connect_Speed 28800_BPS 12 VALUE Connect_Speed 38400_BPS 13 VALUE Connect_Speed 57600_BPS 14 VALUE Connect_Speed 44000_BPS 27 VALUE Connect_Speed 45333_BPS 28 VALUE Connect_Speed 46666_BPS 29 VALUE Connect_Speed 48000_BPS 30 VALUE Connect_Speed 49333_BPS 31 VALUE Connect_Speed 50666_BPS 32 VALUE Connect_Speed 52000_BPS 33 VALUE Connect_Speed 53333_BPS 34 VALUE Connect_Speed 54666_BPS 35 VALUE Connect_Speed 56000_BPS 36 VALUE Connect_Speed 57333_BPS 37 VALUE Connect_Speed 64000_BPS 38 VALUE Connect_Speed 25333_BPS 39 VALUE Connect_Speed 26666_BPS 40 VALUE Connect_Speed 28000_BPS 41 VALUE Connect_Speed 115200_BPS 15 VALUE Connect_Speed 288000_BPS 16 VALUE Connect_Speed 75_1200_BPS 17 VALUE Connect_Speed 1200_75_BPS 18 VALUE Connect_Speed 24000_BPS 19 VALUE Connect_Speed 26400_BPS 20 VALUE Connect_Speed 31200_BPS 21 VALUE Connect_Speed 33600_BPS 22 VALUE Connect_Speed 33333_BPS 23 VALUE Connect_Speed 37333_BPS 24 VALUE Connect_Speed 41333_BPS 25 VALUE Connect_Speed 42666_BPS 26 VALUE Connect_Speed 29333_BPS 42 VALUE Connect_Speed 30666_BPS 43 VALUE Connect_Speed 32000_BPS 44 VALUE Connect_Speed 34666_BPS 45 VALUE Connect_Speed 36000_BPS 46 VALUE Connect_Speed 38666_BPS 47 VALUE Connect_Speed 40000_BPS 48 VALUE Connect_Speed 58666_BPS 49 VALUE Connect_Speed 60000_BPS 50 VALUE Connect_Speed 61333_BPS 51 VALUE Connect_Speed 62666_BPS 52 \ 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, 13 Aug 1997, David Bolen wrote: > jeff.binkley@asacomp.com (Jeff Binkley) writes: > > > I am getting the following error message in our RADIUS logs. I've > > asked before but have never been able to get an answer on it. I > > believe the attribute is the last modem speed connection option. > > Yes, USR vendor attribute 0x9023 is "Connect-Speed" and should be an > integer enumerated value as follows: > > # Connect Speed Values > > value Connect-Speed.None = 0 > value Connect-Speed.300 = 1 > value Connect-Speed.1200 = 2 > value Connect-Speed.2400 = 3 > value Connect-Speed.4800 = 4 > value Connect-Speed.7200 = 5 > value Connect-Speed.9600 = 6 > value Connect-Speed.12000 = 7 > value Connect-Speed.14400 = 8 > value Connect-Speed.16800 = 9 > value Connect-Speed.19200 = 10 > value Connect-Speed.21600 = 11 > value Connect-Speed.28800 = 12 > value Connect-Speed.38400 = 13 > value Connect-Speed.57600 = 14 > value Connect-Speed.115200 = 15 > value Connect-Speed.288000 = 16 > value Connect-Speed.75_1200 = 17 > value Connect-Speed.1200_75 = 18 > value Connect-Speed.24000 = 19 > value Connect-Speed.26400 = 20 > value Connect-Speed.31200 = 21 > value Connect-Speed.33600 = 22 > value Connect-Speed.33333 = 23 > value Connect-Speed.37333 = 24 > value Connect-Speed.41333 = 25 > value Connect-Speed.42666 = 26 > value Connect-Speed.44000 = 27 > value Connect-Speed.45333 = 28 > value Connect-Speed.46666 = 29 > value Connect-Speed.48000 = 30 > value Connect-Speed.49333 = 31 > value Connect-Speed.50666 = 32 > value Connect-Speed.52000 = 33 > value Connect-Speed.53333 = 34 > value Connect-Speed.54666 = 35 > value Connect-Speed.56000 = 36 > value Connect-Speed.57333 = 37 > value Connect-Speed.64000 = 38 > value Connect-Speed.25333 = 39 > value Connect-Speed.26666 = 40 > value Connect-Speed.28000 = 41 > value Connect-Speed.29333 = 42 > value Connect-Speed.30666 = 43 > value Connect-Speed.32000 = 44 > value Connect-Speed.34666 = 45 > value Connect-Speed.36000 = 46 > value Connect-Speed.38666 = 47 > value Connect-Speed.40000 = 48 > value Connect-Speed.58666 = 49 > value Connect-Speed.60000 = 50 > value Connect-Speed.61333 = 51 > value Connect-Speed.62666 = 52 > > > (At least that's what I've got in my dictionary - someone from 3Com may > comment more authoritatively) > > > -- 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) Radius Error Message
From: David Bolen <db3l@ans.net>
Date: 1997-08-13 18:28:08

jeff.binkley@asacomp.com (Jeff Binkley) writes: > I am getting the following error message in our RADIUS logs. I've > asked before but have never been able to get an answer on it. I > believe the attribute is the last modem speed connection option. Yes, USR vendor attribute 0x9023 is "Connect-Speed" and should be an integer enumerated value as follows: # Connect Speed Values value Connect-Speed.None = 0 value Connect-Speed.300 = 1 value Connect-Speed.1200 = 2 value Connect-Speed.2400 = 3 value Connect-Speed.4800 = 4 value Connect-Speed.7200 = 5 value Connect-Speed.9600 = 6 value Connect-Speed.12000 = 7 value Connect-Speed.14400 = 8 value Connect-Speed.16800 = 9 value Connect-Speed.19200 = 10 value Connect-Speed.21600 = 11 value Connect-Speed.28800 = 12 value Connect-Speed.38400 = 13 value Connect-Speed.57600 = 14 value Connect-Speed.115200 = 15 value Connect-Speed.288000 = 16 value Connect-Speed.75_1200 = 17 value Connect-Speed.1200_75 = 18 value Connect-Speed.24000 = 19 value Connect-Speed.26400 = 20 value Connect-Speed.31200 = 21 value Connect-Speed.33600 = 22 value Connect-Speed.33333 = 23 value Connect-Speed.37333 = 24 value Connect-Speed.41333 = 25 value Connect-Speed.42666 = 26 value Connect-Speed.44000 = 27 value Connect-Speed.45333 = 28 value Connect-Speed.46666 = 29 value Connect-Speed.48000 = 30 value Connect-Speed.49333 = 31 value Connect-Speed.50666 = 32 value Connect-Speed.52000 = 33 value Connect-Speed.53333 = 34 value Connect-Speed.54666 = 35 value Connect-Speed.56000 = 36 value Connect-Speed.57333 = 37 value Connect-Speed.64000 = 38 value Connect-Speed.25333 = 39 value Connect-Speed.26666 = 40 value Connect-Speed.28000 = 41 value Connect-Speed.29333 = 42 value Connect-Speed.30666 = 43 value Connect-Speed.32000 = 44 value Connect-Speed.34666 = 45 value Connect-Speed.36000 = 46 value Connect-Speed.38666 = 47 value Connect-Speed.40000 = 48 value Connect-Speed.58666 = 49 value Connect-Speed.60000 = 50 value Connect-Speed.61333 = 51 value Connect-Speed.62666 = 52 (At least that's what I've got in my dictionary - someone from 3Com may comment more authoritatively) -- 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) Radius Error Message
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1997-08-13 21:16:00

-> jeff.binkley@asacomp.com (Jeff Binkley) writes: -> -> > I am getting the following error message in our RADIUS logs. I've > asked -> before but have never been able to get an answer on it. I > believe the -> attribute is the last modem speed connection option. -> Yes, USR vendor attribute 0x9023 is "Connect-Speed" and should be an integer -> enumerated value as follows: -> -> # Connect Speed Values -> -> value Connect-Speed.None = 0 -> value Connect-Speed.300 = 1 -> value Connect-Speed.1200 = 2 -> value Connect-Speed.2400 = 3 -> value Connect-Speed.4800 = 4 -> value Connect-Speed.7200 = 5 -> value Connect-Speed.9600 = 6 -> value Connect-Speed.12000 = 7 -> value Connect-Speed.14400 = 8 -> value Connect-Speed.16800 = 9 -> value Connect-Speed.19200 = 10 -> value Connect-Speed.21600 = 11 -> value Connect-Speed.28800 = 12 -> value Connect-Speed.38400 = 13 -> value Connect-Speed.57600 = 14 -> value Connect-Speed.115200 = 15 -> value Connect-Speed.288000 = 16 -> value Connect-Speed.75_1200 = 17 -> value Connect-Speed.1200_75 = 18 -> value Connect-Speed.24000 = 19 -> value Connect-Speed.26400 = 20 -> value Connect-Speed.31200 = 21 -> value Connect-Speed.33600 = 22 -> value Connect-Speed.33333 = 23 -> value Connect-Speed.37333 = 24 -> value Connect-Speed.41333 = 25 -> value Connect-Speed.42666 = 26 -> value Connect-Speed.44000 = 27 -> value Connect-Speed.45333 = 28 -> value Connect-Speed.46666 = 29 -> value Connect-Speed.48000 = 30 -> value Connect-Speed.49333 = 31 -> value Connect-Speed.50666 = 32 -> value Connect-Speed.52000 = 33 -> value Connect-Speed.53333 = 34 -> value Connect-Speed.54666 = 35 -> value Connect-Speed.56000 = 36 -> value Connect-Speed.57333 = 37 -> value Connect-Speed.64000 = 38 -> value Connect-Speed.25333 = 39 -> value Connect-Speed.26666 = 40 -> value Connect-Speed.28000 = 41 -> value Connect-Speed.29333 = 42 -> value Connect-Speed.30666 = 43 -> value Connect-Speed.32000 = 44 -> value Connect-Speed.34666 = 45 -> value Connect-Speed.36000 = 46 -> value Connect-Speed.38666 = 47 -> value Connect-Speed.40000 = 48 -> value Connect-Speed.58666 = 49 -> value Connect-Speed.60000 = 50 -> value Connect-Speed.61333 = 51 -> value Connect-Speed.62666 = 52 -> -> (At least that's what I've got in my dictionary - someone from 3Com may -> comment more authoritatively) Ok. SO how do I get a copy of your dictionay file ? It isn't in mone which I downloaded from Usr's website. Jeff Binkley ASA Network Computing

Subject: (usr-tc) Farallon Netopia
From: Laszlo Vecsey <master@internexus.net>
Date: 1997-08-14 11:02:48

Having a problem with a farallon isdn/router disconnecting right away, here are the merit radius log files and configuration: Aug 14 10:36:46 Total-Control PRI: I1: CALL_REF >0x0000440b< PRI_SLOT >0< TS >40< B_CH >18< Aug 14 10:36:51 Total-Control acct 0000440b dialnet: port I1 PPP succeeded dest Negotiated Aug 14 10:36:53 Total-Control dialnet: port I1 ppp_sync failed dest isdn.mctz.com Aug 14 10:36:53 Total-Control mpip_process_request: Aug 14 10:36:53 Total-Control [BIF IS NULL] Aug 14 10:36:53 Total-Control [MPIP_LINK_REG_REQ] Aug 14 10:36:53 Total-Control Aug 14 10:36:53 Total-Control mpip_process_response: Aug 14 10:36:53 Total-Control Aug 14 10:36:53 Total-Control acct 0000440b dialnet: port I1 mctz succeeded dest 206.152.14.94 Aug 14 10:36:53 Total-Control mpip_process_request: Aug 14 10:36:53 Total-Control MPIP_LINK_DEREG_REQ Aug 14 10:36:53 Total-Control Aug 14 10:36:53 Total-Control mpip_process_response: Aug 14 10:36:53 Total-Control Aug 14 10:37:58 Total-Control PRI: I1: CALL_REF >0x0000440d< PRI_SLOT >0< TS >60< B_CH >15< Aug 14 10:38:03 Total-Control acct 0000440d dialnet: port I1 PPP succeeded dest Negotiated Aug 14 10:38:05 Total-Control dialnet: port I1 ppp_sync failed dest isdn.mctz.com Aug 14 10:38:05 Total-Control mpip_process_request: Aug 14 10:38:05 Total-Control [BIF IS NULL] Aug 14 10:38:05 Total-Control [MPIP_LINK_REG_REQ] Aug 14 10:38:05 Total-Control Aug 14 10:38:05 Total-Control mpip_process_response: Aug 14 10:38:05 Total-Control Aug 14 10:38:05 Total-Control acct 0000440d dialnet: port I1 mctz succeeded dest 206.152.14.94 Aug 14 10:38:05 Total-Control mpip_process_request: Aug 14 10:38:05 Total-Control MPIP_LINK_DEREG_REQ Aug 14 10:38:05 Total-Control Aug 14 10:38:05 Total-Control mpip_process_response: Aug 14 10:38:05 Total-Control mctz Authentication-Type = Unix-PW Port-Limit=2, Service-Type = Framed, Framed-Protocol = PPP, Framed-IP-Address = 206.152.14.94, Framed-IP-Netmask = 255.255.255.224, Framed-Route = "206.152.14.64/27 206.152.14.94 1" Session-Timeout = 0, Idle-Timeout = 0 Any ideas? The farallon is configured with netmasks of .224, ISDN device of .94, and ethernet of .93. - lv

Subject: (usr-tc) Netserver 16/I problem
From: Steve Coleman <scoleman@csolutions.net>
Date: 1997-08-14 15:44:24

We are having an interesting problem with one of our Netserver/I modems. Everyonce in a while, ranging from a few hours, to a few days, the Netserver will become unbearably slow. Pinging the Netserver either results in no reply, or replies in the 800ms range (over 10mb ethernet). Users dialed into the Netserver also experience packet loss to and from our internet router. Packets that do make it to the router, are also in the 800ms range. The router is on the same ethernet segment as the Netserver. A soft reboot of the Netserver clears the problem. But unfortunately, only temporarily because the problem comes back. It doesn't matter if there are 16 people online, or nobody online. The problem has occured under both situations. We are using 4.0.12 of the operating system. If you have any ideas, or suggestions. Please let me know. Thank you, Steve Coleman Computer Solutions

Subject: (usr-tc) ppp_sync
From: Brian <signal@shreve.net>
Date: 1997-08-14 16:26:02

What do these errors mean? Aug 9 23:24:21 usr3ts1 dialnet: port S9 ppp_sync failed dest Aug 10 22:21:57 usr3ts1 dialnet: port I0 ppp_sync failed dest Aug 11 21:38:50 usr3ts1 dialnet: port S20 ppp_sync failed dest Aug 11 21:40:20 usr3ts1 dialnet: port S20 ppp_sync failed dest Brian oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

Subject: Re: (usr-tc) NSD #2245
From: William M Sheeler Sr <tcra@talon.net>
Date: 1997-08-14 17:05:20

At 06:57 PM 8/12/97 -0500, you wrote: >On Tue, 12 Aug 1997, Jeff Binkley wrote: > >> -> > Is this the same problem that is causing the ethernet to "freeze" on > >> -> 3.5.34? I really enjoyed the "workaround." "Reboot the Netserver." As if >> -> > that was a viable workaround for anything. >> -> > >> -> > Can any of the USR people say whether we are going to see any resolution >> -> on > the ethernet freezing problem? >> -> > >> -> >[snip] >> Brian, >> >> I'm not having the problem but maybe I have an enhanced packet bus card. The >> system is less than 2 months old. How can you tell if it has the enhanced >> packet bus Netserver card ? > >show vers will tell you the packet bus is enhanced or standard. > >Brian [snip] Guys: I have my TCs since late June. The following is a vers command on one of the boxes: Command> vers U.S. Robotics Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.5.34 Build date: Jun 19 1997 Build time: 14:02:28 Network Interface Card: Ethernet & Frame Relay Combination (26) ISDN Interface Card : MUNICH32 (4) Packet Bus Circuit : Standard Licensed for 60 ports. Mine says standard bus, and I have had No problems. System up for 30+ days (had to go off to replace a UPS). You'll see I'm running 3.5.34 also. Not sure if this helps or not. 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) Netserver 16/I problem
From: Jordyn A. Buchanan <jordyn@bestweb.net>
Date: 1997-08-14 17:55:05

At 3:44 PM -0600 8/14/97, Steve Coleman wrote: >We are having an interesting problem with one of our Netserver/I >modems. Everyonce in a while, ranging from a few hours, to a few days, >the Netserver will become unbearably slow. Pinging the Netserver either >results in no reply, or replies in the 800ms range (over 10mb >ethernet). Users dialed into the Netserver also experience packet loss >to and from our internet router. Packets that do make it to the router, >are also in the 800ms range. The router is on the same ethernet segment >as the Netserver. > >A soft reboot of the Netserver clears the problem. But unfortunately, >only temporarily because the problem comes back. It doesn't matter if >there are 16 people online, or nobody online. The problem has occured >under both situations. We are using 4.0.12 of the operating system. > >If you have any ideas, or suggestions. Please let me know. Ooh, we've also seen this under the 4.0.x version of the operating system on a Netserver 16, but I thought the people reporting it were going crazy as I've never seen it happen and it seems to clear itself up after a few minutes. We don't see this on any Netserver 16 or Netserver 16/Is running the 3.2.5.3 version of the OS. It might be worthwhile trying to get that version of the OS on your Netserver (if it's possible to go backwards); generally speaking, it looks like USR has got some work to do to get the 4.0 version back to the level of the 3.X OS. Jordyn |----------------------------------------------------------------| |Jordyn A. Buchanan mailto:jordyn@bestweb.net | |Bestweb Corporation http://www.bestweb.net | |Senior System Administrator +1.914.271.4500 | |----------------------------------------------------------------|

Subject: (usr-tc) Bandwidth on Demand
From: Brian <signal@shreve.net>
Date: 1997-08-14 18:03:10

Can the TC hub do bandwidth on demand in the sense that: If there is a packet destined for the customers static IP, the TC hub will dial there house then bring the connection up (on demand) to allow the packets thru?? Does this work when you have multiple USR hubs? How does the packets destined for the static ip know which TC hub to go thru? Brian oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

Subject: Re: (usr-tc) ppp_sync
From: Rick <rallan@monmouth.com>
Date: 1997-08-14 18:11:23

Brian usually the main culprit for error messages like these is that the destination IP being assigned is not available. It could either be in use by a user or you may have some subnet's with static routes using the IP...... Brian wrote: > What do these errors mean? > > Aug 9 23:24:21 usr3ts1 dialnet: port S9 ppp_sync failed dest > Aug 10 22:21:57 usr3ts1 dialnet: port I0 ppp_sync failed dest > Aug 11 21:38:50 usr3ts1 dialnet: port S20 ppp_sync failed dest > Aug 11 21:40:20 usr3ts1 dialnet: port S20 ppp_sync failed dest > > Brian > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > > Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET > UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 > signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rick---* http://www.monmouth.com | Serving the Central Monmouth Internet Engineer | New Jersey Area Operations and Technical Support | Phone: 908-224-8624 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Subject: (usr-tc) Dialout ISDN MPPP
From: Elio Fuentes <emf@agetech.net>
Date: 1997-08-14 18:28:47

Hi all, Is there any way to get the Netserver to dial out to an Ascend pipeline 50 and establish a 128k Multilink Connection. I couldn't get the I ports to dial, but I can place an ISDN call with the modems. Unfortunately when they connect it would drop? What I had to do is connect the modems to a Livingston Portmaster 2 and set the DTE port to the RS-232. It now can dial out and connect to an ascend perfectly at 64k. But now I want to use MPP 128K and can't seem to get it to work with the livingston or the USR. Any ideas??? Can the netserver do this? a Livingston PM3?? Thanks Elio

Subject: Re: (usr-tc) ppp_sync
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-08-15 07:07:36

This is a basically useless message saying that a user failed to successfully negotiate a ppp connection. Why the negotiation fialed is unknown. 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 Thu, 14 Aug 1997, Rick wrote: > Brian usually the main culprit for error messages like these is that the > destination IP being assigned is not available. It could either be in > use by a user or you may have some subnet's with static routes using the > IP...... > > Brian wrote: > > > What do these errors mean? > > > > Aug 9 23:24:21 usr3ts1 dialnet: port S9 ppp_sync failed dest > > Aug 10 22:21:57 usr3ts1 dialnet: port I0 ppp_sync failed dest > > Aug 11 21:38:50 usr3ts1 dialnet: port S20 ppp_sync failed dest > > Aug 11 21:40:20 usr3ts1 dialnet: port S20 ppp_sync failed dest > > > > Brian > > > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > > > > Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET > > UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 > > signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ > > > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > > > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Rick---* http://www.monmouth.com | Serving the Central > Monmouth Internet Engineer | New Jersey Area > Operations and Technical Support | Phone: 908-224-8624 > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > >

Subject: Re: (usr-tc) Bandwidth on Demand
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-08-15 07:20:25

On Thu, 14 Aug 1997, Brian wrote: > > Can the TC hub do bandwidth on demand in the sense that: > > If there is a packet destined for the customers static IP, the TC hub will > dial there house then bring the connection up (on demand) to allow the > packets thru?? Does this work when you have multiple USR hubs? How does > the packets destined for the static ip know which TC hub to go thru? Yes you can do this. If there is a packet that is destined to a customer's network you can route that packet via the NETServer - the NETServer will dial and send the packet out. In case of multiple USR hubs - My main question is are you going to have static routes on all your NETSevers to the same customer? If yes then allNetservers will start to dial. krish > > Brian > > > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET > UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 > signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > > >

Subject: Re: (usr-tc) Bandwidth on Demand
From: Brian <signal@shreve.net>
Date: 1997-08-15 08:10:16

On Fri, 15 Aug 1997, Tatai SV Krishnan wrote: > > On Thu, 14 Aug 1997, Brian wrote: > > > > > Can the TC hub do bandwidth on demand in the sense that: > > > > If there is a packet destined for the customers static IP, the TC hub will > > dial there house then bring the connection up (on demand) to allow the > > packets thru?? Does this work when you have multiple USR hubs? How does > > the packets destined for the static ip know which TC hub to go thru? > > > Yes you can do this. If there is a packet that is destined to a > customer's network you can route that packet via the NETServer - the > NETServer will dial and send the packet out. > > In case of multiple USR hubs - My main question is are you going to have > static routes on all your NETSevers to the same customer? If yes then > allNetservers will start to dial. no I wouldnt want that. Yet, if I only place a static route on ONE netserver, what if all the pri lines to that particular chasis are busy? What if that user dials into ME, and gets a different hub (since they are all on one hunt group), his route won't be there......... Brian > > krish > > > > > > Brian > > > > > > > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > > Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET > > UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 > > signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > > > > > > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

Subject: Re: (usr-tc) Bandwidth on Demand
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-08-15 09:39:11

On Fri, 15 Aug 1997, Brian wrote: > On Fri, 15 Aug 1997, Tatai SV Krishnan wrote: > > > > > On Thu, 14 Aug 1997, Brian wrote: > > > > > > > > Can the TC hub do bandwidth on demand in the sense that: > > > > > > If there is a packet destined for the customers static IP, the TC hub will > > > dial there house then bring the connection up (on demand) to allow the > > > packets thru?? Does this work when you have multiple USR hubs? How does > > > the packets destined for the static ip know which TC hub to go thru? > > > > > > Yes you can do this. If there is a packet that is destined to a > > customer's network you can route that packet via the NETServer - the > > NETServer will dial and send the packet out. > > > > In case of multiple USR hubs - My main question is are you going to have > > static routes on all your NETSevers to the same customer? If yes then > > allNetservers will start to dial. > > > no I wouldnt want that. Yet, if I only place a static route on ONE > netserver, what if all the pri lines to that particular chasis are busy? > What if that user dials into ME, and gets a different hub (since they are > all on one hunt group), his route won't be there......... If all the pri lins to that particular chassis is busy then the NETServer will not be able to dial. If the customer dials into some other chassis then you will have a problem with routes - you will have two server advertising the same route. The static route will be marked unknow. The new route that the customer establishes will have a valid metric. krish > > Brian > > > > > > krish > > > > > > > > > > Brian > > > > > > > > > > > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > > > Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET > > > UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 > > > signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ > > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > > > > > > > > > > > > > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET > UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 > signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > > >

Subject: (usr-tc) Farallon Netopia
From: Laszlo Vecsey <master@internexus.net>
Date: 1997-08-15 10:27:10

Just a followup to my previous post, I noticed on the farallon website there is configuration information for other dialup units but not the usr-tc. Also my client spoke to farallon tech support and found out that as of yet the netopia is incompatible with the usr-tc, and that they are working with usr to get the issue resolved. My client will probably be switching to an Ascend pipeline since they need access right away... for now netopias seem to be out of the picture. - lv

Subject: (usr-tc) Stumper with modems unavailable
From: Jaye Mathisen <mrcpu@cdsnet.net>
Date: 1997-08-15 12:10:52

I have a T1 chassis with 16 quads. TCS 2.5.1. For some reason I cannot fathom, I cannot get slot 10's modems to come ready under DS0<>Modem configuration. They're always white, and the 4 corresponding modems are always blue, and everything else is normal. If I connect to the T1 card, everything looks fine, nothing special about that slot. I checked the ds0-TDM mapping, and it is fine too. I've swapped cards, and cables and T-spans, and everything I can think of, and they just don't come available. Any ideas?

Subject: Re: (usr-tc) Dialout ISDN MPPP
From: Stephen Fisher <lithium@cia-g.com>
Date: 1997-08-15 16:16:31

Not sure about the NETserver but the PM3 can. On Thu, 14 Aug 1997, Elio Fuentes wrote: > Is there any way to get the Netserver to dial out to an Ascend > pipeline 50 and establish a 128k Multilink Connection. > Can the netserver do this? a Livingston PM3??

Subject: Re:(usr-tc) Modem Script Reset
From: Butch Kemper <kemper@bihs.net>
Date: 1997-08-15 18:55:52

At 22:32 -0500 on 8/12/97, Michael R. Poyaoan wrote: > Is it possible to automatically reset the modem, lets say to factory > default or to its configured settings, after a certain user disconnects > gracefully or ungracefully? > > How can I do this with the USR Total Contol Hub? On USR TC dual analog, the courier, the sportster modems, the modem will do a reset when DTR drops if you set the S13 Register, bit 0 = 1. On a Supra modem, the setting at&d3 will cause the modem to reset when DTR drops. Butch Butch Kemper | Free sound advice available Brazos Internet Consulting Group | "95% sound and 5% advice" 409-361-2324 | Refunds cheerfully provided

Subject: Re: (usr-tc) Dialout ISDN MPPP
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-08-16 08:21:13

On Thu, 14 Aug 1997, Elio Fuentes wrote: > > Hi all, > > Is there any way to get the Netserver to dial out to an Ascend pipeline > 50 and establish a 128k Multilink Connection. > > I couldn't get the I ports to dial, but I can place an ISDN call with the > modems. Unfortunately when they connect it would drop? > > What I had to do is connect the modems to a Livingston Portmaster 2 and set > the DTE port to the RS-232. It now can dial out and connect to an ascend > perfectly at 64k. But now I want to use MPP 128K and can't seem to get it > to work with the livingston or the USR. > > Any ideas??? > > Can the netserver do this? a Livingston PM3?? > > Thanks > > Elio > The NETServer uses a daughter card to answer ISDN calls. When you have a pri in the chassis and when you configure the PRI to send Digital calls to say slot 16 - all you are doing is telling the pri card to send the digital calls directly to the NETServer. The Quad Modem 5.x.x upwards are isdn modems you can receive and place calls over them. What you need to do is configure your pri such that the default ISDN slot is not the NETServer, so you should tell the pri that the defaul ISDN is 0 and make sure that you program the modems properlly to receive all isdn + analog calls. Now you can place calls out and receive calls via the modems. If you want to use the Munich daughter card on the NETServer to receive calls and just dialout isdn via the modems then that is also possible. You location table should have a group of modems and you should have at*v2=5dt####\r to dial out and connect - the high water mark should be low and your modems should be allowed to dial out. 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: (usr-tc) TC Modems Reset ???
From: William M Sheeler Sr <tcra@talon.net>
Date: 1997-08-16 14:38:21

Hi All Our 2 TC Racks have been up for 16 + days straight with no glitches, it seems, until now. Last nite, all of the modems on the primary TC (1st 2 PRIs), reset themselves for no apparent reason. One of my people was on line at the time and got dropped. When he came back in he checked the sessions and noticed that ALL sessions were basically the same time (ie most came back on at the same moment or so). What could have happened to cause this ? Is it very bad ?? A sh global shows that the netservers are still Slaves to the PRIs. We have not experienced any of the Ethernet problems some others have (supposedly our TCs are newer and don't do this). Any help would be appreciated. Using TCS 2.5.1 and Netserver ver 3.5.34. 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) TC PRI setup
From: John Arden <jarden@server.delrio.com>
Date: 1997-08-16 14:46:57

I've had my TC box for a week now and have been going round and round with my local telco and the USR tech support line trying to get my PRI line up. The local telco has been out numerous time doing different test (all of which show their lines to be good) and USR has replaced the PRI nic and nac. After a week of this I'm not any further along than I was when I started. I would appreciate if anyone could discuss their first PRI line(s) setup and problems encountered. Thanks, John, jarden@mail.delrio.com

Subject: Re: (usr-tc) TC PRI setup
From: John Arden <jarden@server.delrio.com>
Date: 1997-08-16 14:46:57

Subject: (usr-tc) ISDN MLPPP idle-timeout problem in 3.5.34?
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1997-08-16 23:16:56

Dialing into a chassis (actually 4 at this point...haven't set up MPIP...that's part of my problem, but not all of it...it will be set up Mon.) get an MPPP connection (when both connect to the same chassis, when they don't, the problem is obvious) and after 10 minutes I get horrific lag and slow response. Doing some looking into the problem and the second channel is being dropped by the chassis...my coadmin found (I completely overlooked it) that the reason for the disconnect on the second channel was "Idle-Timeout" Seems to me that this is a bug in the code. All traffic counters are being attributed to the first channel of the connection, not to both or split between them. For example, if I call in, and connect on i1 and i2 on the netserver, then 10 minutes later, i2 gets dropped, its then picked back up (about 20 seconds) later...lets say on i0. Then i0 minutes later i0 gets dropped and picked back up again in about 20 seconds. This continues on, happening every 10 minutes (our idle timeouts are set for 10 minutes), the original first channel never drops, always the second channel that was originally called in is dropped and redial'ed. Known bug? Any workaround (other than not bonding the channels)? Anyone else experiencing this? -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) Linux
From: Tim Tsai <tim@futuresouth.com>
Date: 1997-08-17 23:32:19

Does anybody have a Linux PPP configuration file that works with a USR TC Netserver/16-I? We have a client that can dial up to our Livingston PM3 just fine but it won't work with the USR. Windows 95 and NT users don't seem to have any problems. This is some data he provided. He's running PPPD 2.3.1. I am asking this here because he's only having trouble with the USR. After starting pppd, ifconfig says: lo Link encap:Local Loopback inet addr:127.0.0.1 Bcast:127.255.255.255 Mask:255.0.0.0 UP BROADCAST LOOPBACK RUNNING MTU:3584 Metric:1 RX packets:249 errors:0 dropped:0 overruns:0 TX packets:249 errors:0 dropped:0 overruns:0 ppp0 Link encap:Point-Point Protocol inet addr:209.36.120.69 P-t-P:209.36.120.65 Mask:255.255.255.0 UP POINTOPOINT RUNNING MTU:296 Metric:1 RX packets:15 errors:0 dropped:0 overruns:0 TX packets:25 errors:0 dropped:0 overruns:0 Route -n says: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 209.36.120.65 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 9 lo 0.0.0.0 209.36.120.65 0.0.0.0 UG 0 0 0 ppp0 Pinging the terminal server returns 1 packet every minute or so: PING 209.36.120.65 (209.36.120.65): 56 data bytes 64 bytes from 209.36.120.65: icmp_seq=2 ttl=255 time=171.9 ms 64 bytes from 209.36.120.65: icmp_seq=34 ttl=255 time=170.2 ms 64 bytes from 209.36.120.65: icmp_seq=39 ttl=255 time=170.2 ms --- 209.36.120.65 ping statistics --- 48 packets transmitted, 3 packets received, 93% packet loss round-trip min/avg/max = 170.2/170.7/171.9 ms Traceroute returns nothing. PPP logs show: Aug 17 15:54:36 Rain pppd[9892]: pppd 2.3.1 started by root, uid 0 Aug 17 15:54:36 Rain pppd[9892]: Removed stale lock on modem (pid 9890) Aug 17 15:54:36 Rain pppd[9892]: Using interface ppp0 Aug 17 15:54:36 Rain pppd[9892]: Connect: ppp0 <--> /dev/modem Aug 17 15:54:36 Rain pppd[9892]: sent [LCP ConfReq id=0x1 <mru 296> <asyncmap 0x0> <magic 0x83abf83f> <accomp>] Aug 17 15:54:37 Rain pppd[9892]: rcvd [LCP ConfAck id=0x1 <mru 296> <asyncmap 0x0> <magic 0x83abf83f> <accomp>] Aug 17 15:54:38 Rain pppd[9892]: rcvd [LCP ConfReq id=0x3 < 11 04 05 dc> < 13 07 04 6e f5 a9 68> <asyncmap 0x0> <magic 0x62b54934>] Aug 17 15:54:38 Rain pppd[9892]: sent [LCP ConfRej id=0x3 < 11 04 05 dc> < 13 07 04 6e f5 a9 68>] Aug 17 15:54:38 Rain pppd[9892]: rcvd [LCP ConfReq id=0x4 <asyncmap 0x0> <magic 0x62b54934>] Aug 17 15:54:38 Rain pppd[9892]: sent [LCP ConfNak id=0x4 <asyncmap 0x1>] Aug 17 15:54:38 Rain pppd[9892]: rcvd [LCP ConfReq id=0x5 <asyncmap 0x1> <magic 0x62b54934>] Aug 17 15:54:38 Rain pppd[9892]: sent [LCP ConfAck id=0x5 <asyncmap 0x1> <magic 0x62b54934>] Aug 17 15:54:38 Rain pppd[9892]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>] Aug 17 15:54:38 Rain pppd[9892]: rcvd [IPCP ConfReq id=0x1 <addr 209.36.120.65>] Aug 17 15:54:38 Rain pppd[9892]: sent [IPCP ConfAck id=0x1 <addr 209.36.120.65>] Aug 17 15:54:41 Rain pppd[9892]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>] Aug 17 15:54:41 Rain pppd[9892]: rcvd [IPCP ConfReq id=0x2 <addr 209.36.120.65>] Aug 17 15:54:41 Rain pppd[9892]: sent [IPCP ConfAck id=0x2 <addr 209.36.120.65>] Aug 17 15:54:44 Rain pppd[9892]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>] Aug 17 15:54:44 Rain pppd[9892]: rcvd [IPCP ConfReq id=0x3 <addr 209.36.120.65>] Aug 17 15:54:44 Rain pppd[9892]: sent [IPCP ConfAck id=0x3 <addr 209.36.120.65>] Aug 17 15:54:44 Rain pppd[9892]: rcvd [IPCP ConfNak id=0x1 <addr 209.36.120.69>] Aug 17 15:54:44 Rain pppd[9892]: sent [IPCP ConfReq id=0x2 <addr 209.36.120.69>] Aug 17 15:54:45 Rain pppd[9892]: rcvd [IPCP ConfAck id=0x2 <addr 209.36.120.69>] Aug 17 15:54:45 Rain pppd[9892]: local IP address 209.36.120.69 Aug 17 15:54:45 Rain pppd[9892]: remote IP address 209.36.120.65 Aug 17 15:54:47 Rain pppd[9892]: rcvd [IPCP ConfReq id=0x4 <addr 209.36.120.65>] Aug 17 15:54:48 Rain pppd[9892]: sent [IPCP ConfReq id=0x3 <addr 0.0.0.0>] Aug 17 15:54:48 Rain pppd[9892]: sent [IPCP ConfAck id=0x4 <addr 209.36.120.65>] Aug 17 15:54:51 Rain pppd[9892]: rcvd [IPCP ConfReq id=0x5 <addr 209.36.120.65>] Aug 17 15:54:51 Rain pppd[9892]: sent [IPCP ConfAck id=0x5 <addr 209.36.120.65>] Aug 17 15:54:51 Rain pppd[9892]: sent [IPCP ConfReq id=0x3 <addr 0.0.0.0>] Aug 17 15:54:54 Rain pppd[9892]: sent [IPCP ConfReq id=0x3 <addr 0.0.0.0>] Aug 17 15:54:54 Rain pppd[9892]: rcvd [IPCP ConfReq id=0x6 <addr 209.36.120.65>] Aug 17 15:54:54 Rain pppd[9892]: sent [IPCP ConfAck id=0x6 <addr 209.36.120.65>] Aug 17 15:54:57 Rain pppd[9892]: sent [IPCP ConfReq id=0x3 <addr 0.0.0.0>] Aug 17 15:54:57 Rain pppd[9892]: rcvd [IPCP ConfNak id=0x3 <addr 209.36.120.69>] Aug 17 15:54:57 Rain pppd[9892]: sent [IPCP ConfReq id=0x4 <addr 209.36.120.69>] Aug 17 15:54:57 Rain pppd[9892]: rcvd [IPCP ConfReq id=0x1 <addr 209.36.120.65>] Aug 17 15:54:57 Rain pppd[9892]: sent [IPCP ConfAck id=0x1 <addr 209.36.120.65>] Aug 17 15:55:00 Rain pppd[9892]: sent [IPCP ConfReq id=0x4 <addr 209.36.120.69>] Aug 17 15:55:12 Rain last message repeated 4 times Aug 17 15:55:12 Rain pppd[9892]: rcvd [IPCP ConfAck id=0x4 <addr 209.36.120.69>] Aug 17 15:55:12 Rain pppd[9892]: local IP address 209.36.120.69 Aug 17 15:55:12 Rain pppd[9892]: remote IP address 209.36.120.65

Subject: Re: (usr-tc) Linux
From: Tim Tsai <tim@futuresouth.com>
Date: 1997-08-17 23:45:12

Following up to my own question, this is his pppd configuration file. Thanks, Tim My machine knows its address: ppp0 Link encap:Point-Point Protocol inet addr:209.36.120.62 P-t-P:209.36.120.65 Mask:255.255.255.255 UP POINTOPOINT RUNNING MTU:1500 Metric:1 /dev/modem 115200 crtscts modem lock noipdefault defaultroute asyncmap 0 escape 0 mtu 1503 mru 1503 passive idle 540 nopcomp novj novjccomp ipcp-max-configure 25 ipcp-max-failure 25 lcp-max-configure 25 lcp-max-failure 25 On Sun, Aug 17, 1997 at 11:32:19PM -0500, Tim Tsai wrote: > Does anybody have a Linux PPP configuration file that works with a USR > TC Netserver/16-I? > > We have a client that can dial up to our Livingston PM3 just fine but it > won't work with the USR. Windows 95 and NT users don't seem to have any > problems. This is some data he provided. He's running PPPD 2.3.1. I am > asking this here because he's only having trouble with the USR. > > After starting pppd, ifconfig says: > > lo Link encap:Local Loopback > inet addr:127.0.0.1 Bcast:127.255.255.255 Mask:255.0.0.0 > UP BROADCAST LOOPBACK RUNNING MTU:3584 Metric:1 > RX packets:249 errors:0 dropped:0 overruns:0 > TX packets:249 errors:0 dropped:0 overruns:0 > > ppp0 Link encap:Point-Point Protocol > inet addr:209.36.120.69 P-t-P:209.36.120.65 Mask:255.255.255.0 > UP POINTOPOINT RUNNING MTU:296 Metric:1 > RX packets:15 errors:0 dropped:0 overruns:0 > TX packets:25 errors:0 dropped:0 overruns:0 > > Route -n says: > > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use Iface > 209.36.120.65 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 > 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 9 lo > 0.0.0.0 209.36.120.65 0.0.0.0 UG 0 0 0 ppp0 > > Pinging the terminal server returns 1 packet every minute or so: > > PING 209.36.120.65 (209.36.120.65): 56 data bytes > 64 bytes from 209.36.120.65: icmp_seq=2 ttl=255 time=171.9 ms > 64 bytes from 209.36.120.65: icmp_seq=34 ttl=255 time=170.2 ms > 64 bytes from 209.36.120.65: icmp_seq=39 ttl=255 time=170.2 ms > > --- 209.36.120.65 ping statistics --- > 48 packets transmitted, 3 packets received, 93% packet loss > round-trip min/avg/max = 170.2/170.7/171.9 ms > > Traceroute returns nothing. > > PPP logs show: > > Aug 17 15:54:36 Rain pppd[9892]: pppd 2.3.1 started by root, uid 0 > Aug 17 15:54:36 Rain pppd[9892]: Removed stale lock on modem (pid 9890) > Aug 17 15:54:36 Rain pppd[9892]: Using interface ppp0 > Aug 17 15:54:36 Rain pppd[9892]: Connect: ppp0 <--> /dev/modem > Aug 17 15:54:36 Rain pppd[9892]: sent [LCP ConfReq id=0x1 <mru 296> <asyncmap 0x0> <magic 0x83abf83f> <accomp>] > Aug 17 15:54:37 Rain pppd[9892]: rcvd [LCP ConfAck id=0x1 <mru 296> <asyncmap 0x0> <magic 0x83abf83f> <accomp>] > Aug 17 15:54:38 Rain pppd[9892]: rcvd [LCP ConfReq id=0x3 < 11 04 05 dc> < 13 07 04 6e f5 a9 68> <asyncmap 0x0> <magic 0x62b54934>] > Aug 17 15:54:38 Rain pppd[9892]: sent [LCP ConfRej id=0x3 < 11 04 05 dc> < 13 07 04 6e f5 a9 68>] > Aug 17 15:54:38 Rain pppd[9892]: rcvd [LCP ConfReq id=0x4 <asyncmap 0x0> <magic 0x62b54934>] > Aug 17 15:54:38 Rain pppd[9892]: sent [LCP ConfNak id=0x4 <asyncmap 0x1>] > Aug 17 15:54:38 Rain pppd[9892]: rcvd [LCP ConfReq id=0x5 <asyncmap 0x1> <magic 0x62b54934>] > Aug 17 15:54:38 Rain pppd[9892]: sent [LCP ConfAck id=0x5 <asyncmap 0x1> <magic 0x62b54934>] > Aug 17 15:54:38 Rain pppd[9892]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>] > Aug 17 15:54:38 Rain pppd[9892]: rcvd [IPCP ConfReq id=0x1 <addr 209.36.120.65>] > Aug 17 15:54:38 Rain pppd[9892]: sent [IPCP ConfAck id=0x1 <addr 209.36.120.65>] > Aug 17 15:54:41 Rain pppd[9892]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>] > Aug 17 15:54:41 Rain pppd[9892]: rcvd [IPCP ConfReq id=0x2 <addr 209.36.120.65>] > Aug 17 15:54:41 Rain pppd[9892]: sent [IPCP ConfAck id=0x2 <addr 209.36.120.65>] > Aug 17 15:54:44 Rain pppd[9892]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>] > Aug 17 15:54:44 Rain pppd[9892]: rcvd [IPCP ConfReq id=0x3 <addr 209.36.120.65>] > Aug 17 15:54:44 Rain pppd[9892]: sent [IPCP ConfAck id=0x3 <addr 209.36.120.65>] > Aug 17 15:54:44 Rain pppd[9892]: rcvd [IPCP ConfNak id=0x1 <addr 209.36.120.69>] > Aug 17 15:54:44 Rain pppd[9892]: sent [IPCP ConfReq id=0x2 <addr 209.36.120.69>] > Aug 17 15:54:45 Rain pppd[9892]: rcvd [IPCP ConfAck id=0x2 <addr 209.36.120.69>] > Aug 17 15:54:45 Rain pppd[9892]: local IP address 209.36.120.69 > Aug 17 15:54:45 Rain pppd[9892]: remote IP address 209.36.120.65 > Aug 17 15:54:47 Rain pppd[9892]: rcvd [IPCP ConfReq id=0x4 <addr 209.36.120.65>] > Aug 17 15:54:48 Rain pppd[9892]: sent [IPCP ConfReq id=0x3 <addr 0.0.0.0>] > Aug 17 15:54:48 Rain pppd[9892]: sent [IPCP ConfAck id=0x4 <addr 209.36.120.65>] > Aug 17 15:54:51 Rain pppd[9892]: rcvd [IPCP ConfReq id=0x5 <addr 209.36.120.65>] > Aug 17 15:54:51 Rain pppd[9892]: sent [IPCP ConfAck id=0x5 <addr 209.36.120.65>] > Aug 17 15:54:51 Rain pppd[9892]: sent [IPCP ConfReq id=0x3 <addr 0.0.0.0>] > Aug 17 15:54:54 Rain pppd[9892]: sent [IPCP ConfReq id=0x3 <addr 0.0.0.0>] > Aug 17 15:54:54 Rain pppd[9892]: rcvd [IPCP ConfReq id=0x6 <addr 209.36.120.65>] > Aug 17 15:54:54 Rain pppd[9892]: sent [IPCP ConfAck id=0x6 <addr 209.36.120.65>] > Aug 17 15:54:57 Rain pppd[9892]: sent [IPCP ConfReq id=0x3 <addr 0.0.0.0>] > Aug 17 15:54:57 Rain pppd[9892]: rcvd [IPCP ConfNak id=0x3 <addr 209.36.120.69>] > Aug 17 15:54:57 Rain pppd[9892]: sent [IPCP ConfReq id=0x4 <addr 209.36.120.69>] > Aug 17 15:54:57 Rain pppd[9892]: rcvd [IPCP ConfReq id=0x1 <addr 209.36.120.65>] > Aug 17 15:54:57 Rain pppd[9892]: sent [IPCP ConfAck id=0x1 <addr 209.36.120.65>] > Aug 17 15:55:00 Rain pppd[9892]: sent [IPCP ConfReq id=0x4 <addr 209.36.120.69>] > Aug 17 15:55:12 Rain last message repeated 4 times > Aug 17 15:55:12 Rain pppd[9892]: rcvd [IPCP ConfAck id=0x4 <addr 209.36.120.69>] > Aug 17 15:55:12 Rain pppd[9892]: local IP address 209.36.120.69 > Aug 17 15:55:12 Rain pppd[9892]: remote IP address 209.36.120.65

Subject: (usr-tc) Modems go inactive
From: Tim Brown <tim@sumter.net>
Date: 1997-08-18 13:54:37

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

Subject: Re: (usr-tc) Modems go inactive
From: Tim Brown <tim@sumter.net>
Date: 1997-08-18 14:40:53

> 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: (usr-tc) strange routing.. ?
From: Laszlo Vecsey <master@internexus.net>
Date: 1997-08-18 22:22:59

For some reason 206.*.*.* packets are not being routed correctly by the usr-tc, tcs 2.5.1, unless I specifically add route 206.0.0.0/8 gatewayip 1 Also, I can't seem to delete certain routes. why might this be? The system has been up for quite a while, with no lockups or other side affects: U.S. Robotics Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.5.34 Build date: Jun 19 1997 Build time: 14:02:28 Network Interface Card: Ethernet & Frame Relay Combination (26) ISDN Interface Card : MUNICH32 (4) Packet Bus Circuit : Standard Licensed for 60 ports. System has been up for 3468463 seconds (40 days 3 hrs 27 min 43 sec) - lv

Subject: Re: (usr-tc) Dialout ISDN MPPP
From: MegaZone <megazone@livingston.com>
Date: 1997-08-19 06:27:03

Once upon a time Elio Fuentes shaped the electrons to say... >Can the netserver do this? a Livingston PM3?? All of our ISDN products can do dialout MP. -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) standard vs enhanced NETServer
From: Christopher Brown <ccbrown@feist.com>
Date: 1997-08-19 08:28:15

I was wondering if someone could tell me the difference between the standard and the enhanced NETSever cards. Christopher Brown ccbrown@feistcorp.com Feist Systems, Inc. (316)337-8657 office Wide Area Network Adminisrtator (316)337-8607 fax http://www.feist.com/~ccbrown (316)833-5288 support

Subject: Re: (usr-tc) TC PRI setup
From: Brian <signal@shreve.net>
Date: 1997-08-19 13:12:12

On Sat, 16 Aug 1997, John Arden wrote: > I've had my TC box for a week now and have been going round and round > with my local telco and the USR tech support line trying to get my > PRI line up. The local telco has been out numerous time doing different > test (all of which show their lines to be good) and USR has replaced > the PRI nic and nac. After a week of this I'm not any further along > than I was when I started. > > I would appreciate if anyone could discuss their first PRI line(s) setup > and problems encountered. > > Thanks, > > John, > jarden@mail.delrio.com > If you would like, you can give me a call at 318-222-2638 and I'll check out a few things, I can't spare more than 30minutes, but being we have several USR racks all with PRI lines, I pretty much know what needs to be done. Brian oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

Subject: (usr-tc) Data over Voice
From: Mark Miller <lumm@lehigh.edu>
Date: 1997-08-19 14:29:05

Is it possible for a PRI connected USR Total control hub to answer Data-over-voice (DOV) isdn calls? Does anyone know the secret to configuring this? Or is it just not possible? thanks, mark

Subject: Re: (usr-tc) TC PRI setup
From: Brian <signal@shreve.net>
Date: 1997-08-19 16:47:58

On Tue, 19 Aug 1997, Jeff Binkley wrote: > -> > I've had my TC box for a week now and have been going round and round > > -> with my local telco and the USR tech support line trying to get my > PRI > -> line up. The local telco has been out numerous time doing different > test > -> (all of which show their lines to be good) and USR has replaced > the PRI > -> nic and nac. After a week of this I'm not any further along > than I was > -> when I started. > -> > > -> > I would appreciate if anyone could discuss their first PRI line(s) setup > > -> and problems encountered. > -> > > -> > Thanks, > -> > > -> > John, > -> > jarden@mail.delrio.com > -> > > -> > -> If you would like, you can give me a call at 318-222-2638 and I'll check out > -> a few things, I can't spare more than 30minutes, but being we have several > -> USR racks all with PRI lines, I pretty much know what needs to be done. > > I've got my first one going in next week so any advice would be helpful. > > Jeff Binkley > ASA Network Computing > Make sure in Line Interface options all modems are set to Line Interface Source: priTdm Make sure in DTE interface settings, DTE interface source is set to packetbus. Make Sure in call control options "packet bus answer only" is set to enable. These things are the most common mistakes. Brian oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

Subject: Re: (usr-tc) TC PRI setup
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1997-08-19 17:01:00

-> > I've had my TC box for a week now and have been going round and round > -> with my local telco and the USR tech support line trying to get my > PRI -> line up. The local telco has been out numerous time doing different > test -> (all of which show their lines to be good) and USR has replaced > the PRI -> nic and nac. After a week of this I'm not any further along > than I was -> when I started. -> > -> > I would appreciate if anyone could discuss their first PRI line(s) setup > -> and problems encountered. -> > -> > Thanks, -> > -> > John, -> > jarden@mail.delrio.com -> > -> -> If you would like, you can give me a call at 318-222-2638 and I'll check out -> a few things, I can't spare more than 30minutes, but being we have several -> USR racks all with PRI lines, I pretty much know what needs to be done. I've got my first one going in next week so any advice would be helpful. Jeff Binkley ASA Network Computing

Subject: Re: (usr-tc) Dialout ISDN MPPP
From: Elio Fuentes <emf@agetech.net>
Date: 1997-08-19 17:03:18

At 06:27 AM 8/19/97 -0700, you wrote: >Once upon a time Elio Fuentes shaped the electrons to say... >>Can the netserver do this? a Livingston PM3?? > >All of our ISDN products can do dialout MP. > >-MZ How about a PM2 with 2 Modems.. (the modems dial out ISDN to a Ascend Pipeline 50). Couldn't get it to work.. Elio Fuentes emf@agetech.net

Subject: (usr-tc) Freeze up again...
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-08-19 17:52:54

This is for Krish and the others at USR. I can't stand dealing with the front-line morons on the support line. I just got 3.5.93, and had good results with resolving some Quake lag. I upgraded only four of my 13 servers to 3.5.93 as a test. Today, I put it on one of the servers that had problems with ethernet freezing on 3.5.53. Sure enough, eight hours later, the ethernet port locked up. Swapping out these cards for new cards is not a very good option for me, since one of the three problematic Netservers is in a remote location. When the port locked up, I did a "show mem" from the console. I also did a couple of ping tests: SaltLake7-TC> show mem Total physical RAM: 20480 kb Total physical FLASH: 2048 kb System memory 17428963 bytes - 7098096 used, 10330867 available Free blocks (block_size:count): 32:114 48:38 64:1 80:54 112:5 128:34 144:32 160: 34 176:33 208:0 224:1 240:0 256:0 272:0 288:0 304:0 640:1 1040:1 1168:0 1984:32 4160:21 8208:4 16400:4 20384:21 Real Available Memory: 11040739 System nbufs 1000 - 22 used, 978 available SaltLake7-TC> ping xmission.com Couldn't resolve host name xmission.com SaltLake7-TC> ping 166.70.1.1 No answer from 166.70.1.1 As you can see, I've got plenty of nbufs going on, but nothing wants to get out. Other Netservers on the same subnet are communicating fine. In order to get these three Netservers stable, I have to run 3.3.28 code on them. Hope that helps, there isn't much of a way I can get a debug dump if the ethernet port isn't functional. Doesn't look like this is the same problem as the nbufs, and again, I was running 3.5.93 in the case above. Pete

Subject: Re: (usr-tc) Data over Voice
From: Mike Hamrich <mhamrich@drfast.net>
Date: 1997-08-19 18:18:27

That would be a neat trick, you might be able to get around the ISDN per-minute charges if you could and the Telcom "sees" it as an voice call. I'll look at the manuals tonight. If you find the secret let me know! Mike Hamrich Technical Director DrFast.Net Inc.

Subject: Re: (usr-tc) Freeze up again...
From: Brian <signal@shreve.net>
Date: 1997-08-19 19:43:43

On Tue, 19 Aug 1997, Pete Ashdown wrote: > > This is for Krish and the others at USR. I can't stand dealing with the > front-line morons on the support line. > > I just got 3.5.93, and had good results with resolving some Quake lag. I > upgraded only four of my 13 servers to 3.5.93 as a test. Today, I put it > on one of the servers that had problems with ethernet freezing on 3.5.53. We installed .93 on ALL of our servers, but we also swapped out the netserver on the chassis that was giving us problems, I've sent the old netserver card back to USR. It did have the FC3 chip in it, and the new card has FC2. It was a "Packet Bus Clocking" chassis as well, our "Non Packet Bus Clocking" chassis dont have the nic freeze problem, but they are also different hardware revisions. As far as Quake lag, I think there is STILL UDP latency problems. This problem is more than reproducable, and I really wish it would clear up, because if its lagging Quake, then its lagging other UDP based programs as well, many of which are real-time based. > > Sure enough, eight hours later, the ethernet port locked up. Swapping out > these cards for new cards is not a very good option for me, since one of > the three problematic Netservers is in a remote location. > > When the port locked up, I did a "show mem" from the console. I also did > a couple of ping tests: > > SaltLake7-TC> show mem > Total physical RAM: 20480 kb > Total physical FLASH: 2048 kb > > System memory 17428963 bytes - 7098096 used, 10330867 available > Free blocks (block_size:count): 32:114 48:38 64:1 80:54 112:5 128:34 144:32 160: > 34 176:33 208:0 224:1 240:0 256:0 272:0 288:0 304:0 640:1 1040:1 1168:0 1984:32 > 4160:21 8208:4 16400:4 20384:21 > Real Available Memory: 11040739 > System nbufs 1000 - 22 used, 978 available > SaltLake7-TC> ping xmission.com > Couldn't resolve host name xmission.com > SaltLake7-TC> ping 166.70.1.1 > No answer from 166.70.1.1 > > As you can see, I've got plenty of nbufs going on, but nothing wants to get > out. Other Netservers on the same subnet are communicating fine. > > In order to get these three Netservers stable, I have to run 3.3.28 code on > them. > > > Hope that helps, there isn't much of a way I can get a debug dump if the > ethernet port isn't functional. Doesn't look like this is the same problem > as the nbufs, and again, I was running 3.5.93 in the case above. sh mem -v sh stream is what I was told to send them. > > Pete > Brian oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

Subject: Re: (usr-tc) Freeze up again...
From: Brian <signal@shreve.net>
Date: 1997-08-19 19:43:43

Subject: Re: (usr-tc) Freeze up again...
From: Tom Bilan <tom@tdi.net>
Date: 1997-08-19 21:37:51

Brian, I'm still having the same lockup problems and I DO have the FC3 chip. I finally went back to 3.3.x before the users started burning crosses in my front lawn. Do you know your case#? I would like to reference that in my "conversation" with the cannon fodder they call 1st level support. Thanks, Tom -----Original Message----- Cc: usr-tc@xmission.com <usr-tc@xmission.com> >On Tue, 19 Aug 1997, Pete Ashdown wrote: > >> >> This is for Krish and the others at USR. I can't stand dealing with the >> front-line morons on the support line. >> >> I just got 3.5.93, and had good results with resolving some Quake lag. I >> upgraded only four of my 13 servers to 3.5.93 as a test. Today, I put it >> on one of the servers that had problems with ethernet freezing on 3.5.53. > >We installed .93 on ALL of our servers, but we also swapped out the >netserver on the chassis that was giving us problems, I've sent the old >netserver card back to USR. It did have the FC3 chip in it, and the new >card has FC2. It was a "Packet Bus Clocking" chassis as well, our "Non >Packet Bus Clocking" chassis dont have the nic freeze problem, but they >are also different hardware revisions. > > >As far as Quake lag, I think there is STILL UDP latency problems. This >problem is more than reproducable, and I really wish it would clear up, >because if its lagging Quake, then its lagging other UDP based programs as >well, many of which are real-time based. > >> >> Sure enough, eight hours later, the ethernet port locked up. Swapping out >> these cards for new cards is not a very good option for me, since one of >> the three problematic Netservers is in a remote location. >> >> When the port locked up, I did a "show mem" from the console. I also did >> a couple of ping tests: >> >> SaltLake7-TC> show mem >> Total physical RAM: 20480 kb >> Total physical FLASH: 2048 kb >> >> System memory 17428963 bytes - 7098096 used, 10330867 available >> Free blocks (block_size:count): 32:114 48:38 64:1 80:54 112:5 128:34 144:32 160: >> 34 176:33 208:0 224:1 240:0 256:0 272:0 288:0 304:0 640:1 1040:1 1168:0 1984:32 >> 4160:21 8208:4 16400:4 20384:21 >> Real Available Memory: 11040739 >> System nbufs 1000 - 22 used, 978 available >> SaltLake7-TC> ping xmission.com >> Couldn't resolve host name xmission.com >> SaltLake7-TC> ping 166.70.1.1 >> No answer from 166.70.1.1 >> >> As you can see, I've got plenty of nbufs going on, but nothing wants to get >> out. Other Netservers on the same subnet are communicating fine. >> >> In order to get these three Netservers stable, I have to run 3.3.28 code on >> them. >> >> >> Hope that helps, there isn't much of a way I can get a debug dump if the >> ethernet port isn't functional. Doesn't look like this is the same problem >> as the nbufs, and again, I was running 3.5.93 in the case above. > >sh mem -v >sh stream > >is what I was told to send them. > >> >> Pete >> > > > >Brian > >oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo >Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET >UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 >signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ >oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > > >

Subject: Re: (usr-tc) Dialout ISDN MPPP
From: MegaZone <megazone@livingston.com>
Date: 1997-08-19 22:37:10

Once upon a time Elio Fuentes shaped the electrons to say... >How about a PM2 with 2 Modems.. (the modems dial out ISDN to a Ascend >Pipeline 50). Couldn't get it to work.. "modem" implies phone lines, TA's are used on ISDN. What are you asking? -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) Freeze up again...
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-08-20 07:06:01

On Tue, 19 Aug 1997, Pete Ashdown wrote: > > This is for Krish and the others at USR. I can't stand dealing with the > front-line morons on the support line. I understand - > > I just got 3.5.93, and had good results with resolving some Quake lag. I > upgraded only four of my 13 servers to 3.5.93 as a test. Today, I put it > on one of the servers that had problems with ethernet freezing on 3.5.53. > I need access to one of the card that freezed. > Sure enough, eight hours later, the ethernet port locked up. Swapping out > these cards for new cards is not a very good option for me, since one of > the three problematic Netservers is in a remote location. > > When the port locked up, I did a "show mem" from the console. I also did > a couple of ping tests: > > SaltLake7-TC> show mem > Total physical RAM: 20480 kb > Total physical FLASH: 2048 kb > > System memory 17428963 bytes - 7098096 used, 10330867 available > Free blocks (block_size:count): 32:114 48:38 64:1 80:54 112:5 128:34 144:32 160: > 34 176:33 208:0 224:1 240:0 256:0 272:0 288:0 304:0 640:1 1040:1 1168:0 1984:32 > 4160:21 8208:4 16400:4 20384:21 > Real Available Memory: 11040739 > System nbufs 1000 - 22 used, 978 available > SaltLake7-TC> ping xmission.com > Couldn't resolve host name xmission.com > SaltLake7-TC> ping 166.70.1.1 > No answer from 166.70.1.1 > > As you can see, I've got plenty of nbufs going on, but nothing wants to get > out. Other Netservers on the same subnet are communicating fine. > > In order to get these three Netservers stable, I have to run 3.3.28 code on > them. > > > Hope that helps, there isn't much of a way I can get a debug dump if the > ethernet port isn't functional. Doesn't look like this is the same problem > as the nbufs, and again, I was running 3.5.93 in the case above. > > Pete > This then is not the same issue like 2245 - it is similar - that is what we need to find. I will call you this morning. krish

Subject: Re: (usr-tc) Freeze up again...
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-08-20 07:12:51

On Tue, 19 Aug 1997, Tom Bilan wrote: > Brian, > > I'm still having the same lockup problems and I DO have the FC3 chip. > I finally went back to 3.3.x before the users started burning crosses in > my front lawn. > > Do you know your case#? I would like to reference that in my "conversation" > with the cannon fodder they call 1st level support. > > Thanks, > Tom Tom, Open a call with support and email me the ticket number. krish > > -----Original Message----- > From: Brian <signal@shreve.net> > To: usr-tc@mail.xmission.com <usr-tc@mail.xmission.com> > Cc: usr-tc@xmission.com <usr-tc@xmission.com> > Date: Tuesday, August 19, 1997 9:21 PM > Subject: Re: (usr-tc) Freeze up again... > > > > >On Tue, 19 Aug 1997, Pete Ashdown wrote: > > > >> > >> This is for Krish and the others at USR. I can't stand dealing with the > >> front-line morons on the support line. > >> > >> I just got 3.5.93, and had good results with resolving some Quake lag. I > >> upgraded only four of my 13 servers to 3.5.93 as a test. Today, I put it > >> on one of the servers that had problems with ethernet freezing on 3.5.53. > > > >We installed .93 on ALL of our servers, but we also swapped out the > >netserver on the chassis that was giving us problems, I've sent the old > >netserver card back to USR. It did have the FC3 chip in it, and the new > >card has FC2. It was a "Packet Bus Clocking" chassis as well, our "Non > >Packet Bus Clocking" chassis dont have the nic freeze problem, but they > >are also different hardware revisions. > > > > > >As far as Quake lag, I think there is STILL UDP latency problems. This > >problem is more than reproducable, and I really wish it would clear up, > >because if its lagging Quake, then its lagging other UDP based programs as > >well, many of which are real-time based. > > > >> > >> Sure enough, eight hours later, the ethernet port locked up. Swapping > out > >> these cards for new cards is not a very good option for me, since one of > >> the three problematic Netservers is in a remote location. > >> > >> When the port locked up, I did a "show mem" from the console. I also did > >> a couple of ping tests: > >> > >> SaltLake7-TC> show mem > >> Total physical RAM: 20480 kb > >> Total physical FLASH: 2048 kb > >> > >> System memory 17428963 bytes - 7098096 used, 10330867 available > >> Free blocks (block_size:count): 32:114 48:38 64:1 80:54 112:5 128:34 > 144:32 160: > >> 34 176:33 208:0 224:1 240:0 256:0 272:0 288:0 304:0 640:1 1040:1 1168:0 > 1984:32 > >> 4160:21 8208:4 16400:4 20384:21 > >> Real Available Memory: 11040739 > >> System nbufs 1000 - 22 used, 978 available > >> SaltLake7-TC> ping xmission.com > >> Couldn't resolve host name xmission.com > >> SaltLake7-TC> ping 166.70.1.1 > >> No answer from 166.70.1.1 > >> > >> As you can see, I've got plenty of nbufs going on, but nothing wants to > get > >> out. Other Netservers on the same subnet are communicating fine. > >> > >> In order to get these three Netservers stable, I have to run 3.3.28 code > on > >> them. > >> > >> > >> Hope that helps, there isn't much of a way I can get a debug dump if the > >> ethernet port isn't functional. Doesn't look like this is the same > problem > >> as the nbufs, and again, I was running 3.5.93 in the case above. > > > >sh mem -v > >sh stream > > > >is what I was told to send them. > > > >> > >> Pete > >> > > > > > > > >Brian > > > >oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > >Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET > >UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 > >signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ > >oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > > > > > > > >

Subject: Re: (usr-tc) Dialout ISDN MPPP
From: Elio Fuentes <emf@agetech.net>
Date: 1997-08-20 07:54:46

At 10:37 PM 8/19/97 -0700, you wrote: >Once upon a time Elio Fuentes shaped the electrons to say... >>How about a PM2 with 2 Modems.. (the modems dial out ISDN to a Ascend >>Pipeline 50). Couldn't get it to work.. > >"modem" implies phone lines, TA's are used on ISDN. > >What are you asking? > Ahh. true. Ok 2 TA's on 2 serial ports each TA is on 1 64k Channel on a PM2 can they do dial out MPP? Or will the PM2 only do MPP on the BRI card? Thanks, Elio Fuentes emf@agetech.net

Subject: (usr-tc) SLIP broken in 3.5.93
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-08-20 15:00:48

Just found out today that SLIP performance has been hosed by upgrading to 3.5.93. We still have a considerable amount of people using SLIP (HPUX, Win3.11, etc). I feel really frustrated that I can't call the support line and state things like the above. If I did, I know I'd get a response like, "You should run PPP." Any word from USR regarding interfacing to tier II tech support?

Subject: Re: (usr-tc) standard vs enhanced NETServer
From: David Bolen <db3l@ans.net>
Date: 1997-08-20 20:02:51

Christopher Brown <ccbrown@feist.com> writes: > I was wondering if someone could tell me the difference between the > standard and the enhanced NETSever cards. The card is a different physical design (e.g., simply a different beast at the board layout level). The hardware guys like it a lot better :-) As far as functionality there really aren't that many differences, since when you get down to it both cards are simply a 486-PC design in a total control chassis slot form factor with some interface hardware for custom busses like the packet bus. But as with any design evolution, I expect the EPB design at the hardware level is a bit tighter given knowledge learned over time with the iterations on the previous base design. There is an additional DRAM bank (2) that contains the 16MB soldered onto the board, so I believe the overall memory capacity of the board is a bit higher. The "enhanced" name comes from a different interface chipset for the packet bus (or maybe just a different hardware implementation using the same chipset, I forget), although in terms of raw performance it turns out not to be significantly different than the older "standard" card. The EPB card is also the same base card used for the current EdgeServer product (except with 32MB soldered onto DRAM bank 2, and a 32MB SIMM, along with the daughtercard to hold the IDE/floppy/hard drives and SCSI interface). -- 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) Freeze up again...
From: Brian <signal@shreve.net>
Date: 1997-08-20 20:03:12

On Tue, 19 Aug 1997, Tom Bilan wrote: > Brian, > > I'm still having the same lockup problems and I DO have the FC3 chip. > I finally went back to 3.3.x before the users started burning crosses in > my front lawn. > > Do you know your case#? I would like to reference that in my "conversation" > with the cannon fodder they call 1st level support. 7058351 > > Thanks, > Tom > > -----Original Message----- > From: Brian <signal@shreve.net> > To: usr-tc@mail.xmission.com <usr-tc@mail.xmission.com> > Cc: usr-tc@xmission.com <usr-tc@xmission.com> > Date: Tuesday, August 19, 1997 9:21 PM > Subject: Re: (usr-tc) Freeze up again... > > > > >On Tue, 19 Aug 1997, Pete Ashdown wrote: > > > >> > >> This is for Krish and the others at USR. I can't stand dealing with the > >> front-line morons on the support line. > >> > >> I just got 3.5.93, and had good results with resolving some Quake lag. I > >> upgraded only four of my 13 servers to 3.5.93 as a test. Today, I put it > >> on one of the servers that had problems with ethernet freezing on 3.5.53. > > > >We installed .93 on ALL of our servers, but we also swapped out the > >netserver on the chassis that was giving us problems, I've sent the old > >netserver card back to USR. It did have the FC3 chip in it, and the new > >card has FC2. It was a "Packet Bus Clocking" chassis as well, our "Non > >Packet Bus Clocking" chassis dont have the nic freeze problem, but they > >are also different hardware revisions. > > > > > >As far as Quake lag, I think there is STILL UDP latency problems. This > >problem is more than reproducable, and I really wish it would clear up, > >because if its lagging Quake, then its lagging other UDP based programs as > >well, many of which are real-time based. > > > >> > >> Sure enough, eight hours later, the ethernet port locked up. Swapping > out > >> these cards for new cards is not a very good option for me, since one of > >> the three problematic Netservers is in a remote location. > >> > >> When the port locked up, I did a "show mem" from the console. I also did > >> a couple of ping tests: > >> > >> SaltLake7-TC> show mem > >> Total physical RAM: 20480 kb > >> Total physical FLASH: 2048 kb > >> > >> System memory 17428963 bytes - 7098096 used, 10330867 available > >> Free blocks (block_size:count): 32:114 48:38 64:1 80:54 112:5 128:34 > 144:32 160: > >> 34 176:33 208:0 224:1 240:0 256:0 272:0 288:0 304:0 640:1 1040:1 1168:0 > 1984:32 > >> 4160:21 8208:4 16400:4 20384:21 > >> Real Available Memory: 11040739 > >> System nbufs 1000 - 22 used, 978 available > >> SaltLake7-TC> ping xmission.com > >> Couldn't resolve host name xmission.com > >> SaltLake7-TC> ping 166.70.1.1 > >> No answer from 166.70.1.1 > >> > >> As you can see, I've got plenty of nbufs going on, but nothing wants to > get > >> out. Other Netservers on the same subnet are communicating fine. > >> > >> In order to get these three Netservers stable, I have to run 3.3.28 code > on > >> them. > >> > >> > >> Hope that helps, there isn't much of a way I can get a debug dump if the > >> ethernet port isn't functional. Doesn't look like this is the same > problem > >> as the nbufs, and again, I was running 3.5.93 in the case above. > > > >sh mem -v > >sh stream > > > >is what I was told to send them. > > > >> > >> Pete > >> > > > > > > > >Brian > > > >oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > >Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET > >UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 > >signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ > >oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > > > > > > > > /---------------------------- 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) Data over Voice
From: David Bolen <db3l@ans.net>
Date: 1997-08-20 20:09:16

lumm@Lehigh.EDU (Mark Miller) writes: > Is it possible for a PRI connected USR Total control hub to answer > Data-over-voice (DOV) isdn calls? Does anyone know the secret to > configuring this? Or is it just not possible? My understanding at this point (although someone from 3Com may correct me) is that it is not currently possible. If you could get the call to make it to the NETServer somehow regardless of the fact that it appears to be analog, I believe it would get processed. However, I was unable to get the PRI card to forward such a call through. I also tried using the ISDN functionality in the quad modems but the current code does not yet appear to support the DOV operation similar to the external Courier, so that doesn't work either. I'm not sure which method (via the modem, or direct to the NETServer) is likely to show up first in any future release. -- 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) Dialout ISDN MPPP
From: MegaZone <megazone@livingston.com>
Date: 1997-08-21 00:04:19

Once upon a time Elio Fuentes shaped the electrons to say... >Ahh. true. Ok 2 TA's on 2 serial ports each TA is on 1 64k Channel on a >PM2 can they do dial out MPP? Or will the PM2 only do MPP on the BRI card? No, we do not support MP on async serial ports. To us that isn't an ISDN product. We only support MP on *native* ISDN ports. (And on modems on the PM-3 in the very near future.) -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) Quad 5.6.7
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-08-21 04:21:32

Just noticed that new Quad modem code came out yesterday. Does anyone know what the changes amount to?

Subject: (usr-tc) USR Announcements list
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1997-08-21 08:52:58

Does USR/3Com run any sort of list for announcements of firmware updates? I have seen no such list mentioned anywhere, and it would seem quite reasonable to expect that customers of such sophisticated machinery from a respected company could expect good information. If there is no such list, then I'd be willing to host one on my site. Of course, it wouldn't be as good as having the authoritative information posted from the Mother Site, but it'd give us a place to make guesses about the differences between versions. --- Mark R. Lindsey, mark@datasys.net Network Engineer, DSS Online 912 241 0607; Fax: 241 0190

Subject: (usr-tc) client modem unable to connect
From: William M Sheeler Sr <tcra@talon.net>
Date: 1997-08-21 09:12:05

I have a client having problems connecting to our TCs. It takes anywhere from 1 to 50 tries for my client's modem to handshake with our USR TCs. During these attempts my client can dial to any one of 5 others computer numbers and get a handshake first try. I will outline below what he has tried to do to correct the problem. Any help or suggestions you may have will be appreciated. Changed modem definitions from 33.6 (actual modem) to generic 28.8 Changed port speed form 115000 to 57600 to 19200 Client has a pentium with 32mb ram, Radicom Rockwell 33.6 modem (Acer), Windows 95 build 4.00.950 I don't seem to have this problem with other Rockwell modems. Any ideas? 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) USR Announcements list
From: Michael Wronski <mwronski@coredump.ae.usr.com>
Date: 1997-08-21 09:26:24

At 08:52 AM 8/21/97 -0400, you wrote: >Does USR/3Com run any sort of list for announcements of firmware >updates? I have seen no such list mentioned anywhere, and it would seem >quite reasonable to expect that customers of such sophisticated >machinery from a respected company could expect good information. > >If there is no such list, then I'd be willing to host one on my site. Of >course, it wouldn't be as good as having the authoritative information >posted from the Mother Site, but it'd give us a place to make guesses >about the differences between versions. > Most of the time the latest code is posted to Total Service Website http://totalservice.usr.com All release notes and code is there... `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'Mike Wronski(mwronski@coredump.ae.usr.com) 3Com/U.S.Robotics Network Systems Engineer PGP: http://coredump.ae.usr.com/pgp

Subject: (usr-tc) quad firmware, netserver, etc transfer over smtp?
From: Laszlo Vecsey <master@internexus.net>
Date: 1997-08-21 10:37:19

How involved is it to write custom software to upload firmware via the NMC, is this done over smtp, is there a document I can look at or can someone give me a brief overview? I dont have a sunos or hp system, so the unix binaries from usr aren't of much help. It really would be much nicer to transfer from the commandline instead of using a Win95 system.. Thanks, - lv

Subject: Re: (usr-tc) USR Announcements list
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-08-21 14:26:46

Mark R. Lindsey said once upon a time: > >Does USR/3Com run any sort of list for announcements of firmware >updates? I have seen no such list mentioned anywhere, and it would seem >quite reasonable to expect that customers of such sophisticated >machinery from a respected company could expect good information. > >If there is no such list, then I'd be willing to host one on my site. Of >course, it wouldn't be as good as having the authoritative information >posted from the Mother Site, but it'd give us a place to make guesses >about the differences between versions. Why don't you just send these updates to this list?

Subject: (usr-tc) Hardware replacement
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-08-21 15:25:57

Every time I get off the phone with USR I want to spit nails. Krish was very nice in arranging to get my Netservers replaced. You remember, the ones that will randomly freeze the ethernet. Well, today I got a call from the hardware replacement department wanting to get serial numbers of the Netserver cards. Fine, I pull up TCM and read off the Netserver serial numbers. Then they want the Ethernet NIC numbers. TCM doesn't show this information, so in order to get these serial numbers, I have to pop out the NIC's on the three cards in question and write them down. This shuts down upwards of 138 people so I can read off a number. To make matters worse, one of these NIC's in question is 50 miles away from here. So in order to get this damn thing fixed, I have to drive 50 miles to interrupt service for 46 people, drive back, and tell USR what the serial number is. A little flexibility here would be just smashing.

Subject: Re: (usr-tc) quad firmware, netserver, etc transfer over smtp?
From: David Bolen <db3l@ans.net>
Date: 1997-08-21 15:59:37

Laszlo Vecsey <master@internexus.net> writes: > How involved is it to write custom software to upload firmware via the > NMC, is this done over smtp, is there a document I can look at or can > someone give me a brief overview? That depends on how familiar you are with networking applications, in particular SNMP and TCP based stuff, and how integrated you want to make your tool. The overall process is described in the document on the Total Control SNMP MIB Reference Manual, under the chassis command section of the Chassis MIB documentation. The description there assumes the use of a standalone tftp application, coupled with specific SNMP operations, however, if you want to create an integrated application all you need to do is write some code that does both the SNMP work and then the TFTP file transfer. TFTP is a pretty trivial protocol (thus the name) so it's not too hard to code. (Or "borrow" if you've got an OS that you have source to) What it comes down to is requesting a download command via the chassis command table for the slots you want. You wait until the result code says it is ready, and then tftp the SDL file. After that completes you wait for a flash erasure to take place by again polling the chassis command table for a particular result, and then you tftp the NAC file. When that is done, monitor the chassis command table for the final result. If you don't necessarily care about having a single integrated application, there's nothing really stopping the download from working with the use of an SNMP utility like snmpget/set from the CMU stuff and the tftp command line utility that comes with any Unix OS. Use them together in a script and you could pretty much handle everything without writing any specific code. I prefer a single integrated module myself, but in my case the download was just one aspect of the management tool being written. If you can't find a copy of the MIB reference (it may be online as a PDF somewhere at 3Com, I'm not sure) drop me a line and I can provide some further details. -- 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) USR Announcements list
From: Michael Wronski <mwronski@coredump.ae.usr.com>
Date: 1997-08-21 16:29:11

At 05:11 PM 8/21/97 -0400, you wrote: >Mark Lindsey (mark@vielle.datasys.net) said: >: >Does USR/3Com run any sort of list for announcements of firmware >: >updates? > >Mike Wronski (mwronski@coredump.ae.usr.com) replied: >: Most of the time the latest code is posted to Total Service Website >: http://totalservice.usr.com >: >: All release notes and code is there... > >Thanks, Mike, but would it be too trouble to have the web-page updates >emailed, too? Plenty of companies do it, and I know my firm paid through >the nose for service contracts. I'm not really accustomed to polling >a web site for updates, and the login process doesn't lend itself to >automated polling. > That, I am afraid, is beyond my control. You have some power by paying for those contracts.. I would suggest contacting the customer service group and making the same suggestion.. -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) Data over Voice
From: Greg Coffey <greg@coffey.com>
Date: 1997-08-21 17:05:56

All that to save $19.95 per month? I'd sure like to have my line go dead every 30 secs for 10 secs or so. I have a bunch of AOL disks that I'll sell you cheap. 8^) At 11:00 PM 8/21/97 BST, you wrote: >>That would be a neat trick, you might be able to get around the ISDN >>per-minute charges if you could and the Telcom "sees" it as an voice call. >>I'll look at the manuals tonight. If you find the secret let me know! > >I'm new here, but I have something relevant: > >Soon there will be a telecoms company offering toll free calls. They will >interrupt the call every 30 secs with a 10 sec advert. I want to get a PPP connection :) > >Is there any hardware that you can suggest? Possibly something that changes the wattage of the phoneline, maing the voice completely filtered out. > >WILL A PPP CONNECTION TERMINATE IF YOU START TALKING DOWN THE LINE EVERY 30 SECONDS? > > >Thanks, I appreciate it. > >Private mails to: Steph@emarkt.com > >################################## > Steph@emarkt.com >################################## > S t e p h @ e m a r k t . c o m >################################## > > 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) USR Announcements list
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1997-08-21 17:11:21

Mark Lindsey (mark@vielle.datasys.net) said: : >Does USR/3Com run any sort of list for announcements of firmware : >updates? Mike Wronski (mwronski@coredump.ae.usr.com) replied: : Most of the time the latest code is posted to Total Service Website : http://totalservice.usr.com : : All release notes and code is there... Thanks, Mike, but would it be too trouble to have the web-page updates emailed, too? Plenty of companies do it, and I know my firm paid through the nose for service contracts. I'm not really accustomed to polling a web site for updates, and the login process doesn't lend itself to automated polling. --- Mark R. Lindsey, mark@datasys.net Network Engineer, DSS Online 912 241 0607; Fax: 241 0190

Subject: (usr-tc) RADIUS Dictionary for USRs
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1997-08-21 22:35:25

I'm looking for a RADIUS dictionary to run with my Livingston RADIUS server that knows about all of the NMC's extended information, as listed in the table for the nmcCfgLogCallStatGrpSel. Does anyone have one, or does USR publish one? Thanks much. --- Mark R. Lindsey, mark@datasys.net Network Engineer, DSS Online 912 241 0607; Fax: 241 0190

Subject: Re: (usr-tc) Data over Voice
From: steph@emarkt.com
Date: 1997-08-21 23:00:19

>That would be a neat trick, you might be able to get around the ISDN >per-minute charges if you could and the Telcom "sees" it as an voice call. >I'll look at the manuals tonight. If you find the secret let me know! I'm new here, but I have something relevant: Soon there will be a telecoms company offering toll free calls. They will interrupt the call every 30 secs with a 10 sec advert. I want to get a PPP connection :) Is there any hardware that you can suggest? Possibly something that changes the wattage of the phoneline, maing the voice completely filtered out. WILL A PPP CONNECTION TERMINATE IF YOU START TALKING DOWN THE LINE EVERY 30 SECONDS? Thanks, I appreciate it. Private mails to: Steph@emarkt.com ################################## Steph@emarkt.com ################################## S t e p h @ e m a r k t . c o m ##################################

Subject: (usr-tc) download status, quad modem leds
From: Laszlo Vecsey <master@internexus.net>
Date: 1997-08-21 23:33:26

Just a minor suggestion.. might be useful to show the 'percent complete' when upgrading quad modems by displaying a meter bar, either from top to bottom or bottom to top, using a combination of solid green, yellow, (red) and blinking colors to show the status. Something like that would be more useful than just a single blinking green led at the top of the card, showing the transfer status. ;) Also does anyone know when the new 24modem cards will be available? (No, not just for the leds.. ) and do they allow for a PRI span to be connected through a nic in the back, or how is dial provided? - lv

Subject: Re: (usr-tc) USR Announcements list
From: Laszlo Vecsey <master@internexus.net>
Date: 1997-08-21 23:44:45

I think starting such a list would be a great idea. The main advantage being that many people procmail mailing lists into individual folders, and only check on their contents occasionally.. where as an announce list need not be filtered (low volume) and can arrive directly in your inbox. Perhaps the webmaster or person in charge of the ftp files at totalservice.usr.com could send off such a notification.. including the release notes in text format, instead of pdf. How great would that be. If we really wanted to get nasty, we could poll the web site say every 10 minutes to see if the document has changed.. and work from there to get the results posted to the announce mailing list ;) - lv On Thu, 21 Aug 1997, Mark R. Lindsey wrote: > Does USR/3Com run any sort of list for announcements of firmware > updates? I have seen no such list mentioned anywhere, and it would seem > quite reasonable to expect that customers of such sophisticated > machinery from a respected company could expect good information. > > If there is no such list, then I'd be willing to host one on my site. Of > course, it wouldn't be as good as having the authoritative information > posted from the Mother Site, but it'd give us a place to make guesses > about the differences between versions.

Subject: (usr-tc) New archive site available
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1997-08-21 23:49:34

Howdy, all: I've built an archive mirror of the usr-tc discussion archives, as found at Xmission's FTP site. At http://usr-tc.datasys.net/ you can access the list's full archives by thread, subject, author, or date, and can execute a regular-expression search of the archives. I'll update my mirror on the first of every month with the previous month's postings. http://usr-tc.datasys.net/ Enjoy. --- Mark R. Lindsey, mark@datasys.net Network Engineer, DSS Online 912 241 0607; Fax: 912 241 0190

Subject: Re: (usr-tc) Data over Voice
From: steph@emarkt.com
Date: 1997-08-22 00:23:06

>All that to save $19.95 per month? I'd sure like to have my line go dead >every 30 secs for 10 secs or so. I have a bunch of AOL disks that I'll >sell you cheap. 8^) Firstly, it will offer free WORLDWIDE calls. Secondly, I live in the UK, and my local calls are NOT free, therefore I have to PAY for the internet! So any serious contributions please? And I'm hoping that we can reduce the wattage to filter OUT the voice, so you can get a PERMENANT X2 connect! Private mails to: Steph@emarkt.com ################################## Steph@emarkt.com ################################## S t e p h @ e m a r k t . c o m ################################## I previously said: >>Soon there will be a telecoms company offering toll free calls. They will interrupt the call every 30 secs with a 10 sec advert. I want to get a PPP connection :) >>Is there any hardware that you can suggest? Possibly something that >changes the wattage of the phoneline, maing the voice completely filtered out. >>WILL A PPP CONNECTION TERMINATE IF YOU START TALKING DOWN THE LINE EVERY >30 SECONDS? >>Thanks, I appreciate it. ################################## Steph@emarkt.com ################################## S t e p h @ e m a r k t . c o m ##################################

Subject: Re: (usr-tc) download status, quad modem LED's
From: Michael Wronski <mwronski@coredump.ae.usr.com>
Date: 1997-08-22 09:32:44

At 11:33 PM 8/21/97 -0400, you wrote: >Just a minor suggestion.. might be useful to show the 'percent complete' >when upgrading quad modems by displaying a meter bar, either from top to >bottom or bottom to top, using a combination of solid green, yellow, (red) >and blinking colors to show the status. Something like that would be more >useful than just a single blinking green led at the top of the card, >showing the transfer status. You can expect improved software download speed in the new TCM5.0(in BETA now). But the LED's are a function of the software running on the card and I don't think the download will ever be represented on the card any differently. The new TCM does show the progress a little more graphically and does an entire rack much faster than its predecessor. >Also does anyone know when the new 24modem cards will be available? (No, >not just for the leds.. ) and do they allow for a PRI span to be connected >through a nic in the back, or how is dial provided? > In BETA now. No release date is available. The PRI is in the modem NIC. So if you have 13 HiPer DSP's (24modem card) you will have a PRI cable behind each one of them. There is no need for the DUAL PRI or T1 card with this implementation. -M

Subject: (usr-tc) NIC problem resolved
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-08-22 12:19:27

In regards to my serial number problems with getting NIC replacements yesterday, we managed to get things resolved with USR and got the replacements in this morning. Just so it doesn't sound all bad.

Subject: Re: (usr-tc) download status, quad modem LED's
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-08-22 12:24:56

Brian said once upon a time: >And so is there a 10bT port on each modem NIC? or are they making a 100bT >netserver? The HiPer "Access Server" has a 100bT capable port on it. It may even have two, I don't have the documentation in front of me.

Subject: (usr-tc) HELP! Second PRI Problems
From: Michael H. Hamrich <mhamrich@drfast.net>
Date: 1997-08-22 12:30:44

We are on the second day of installing the second PRI span to a USR TC We have never been able to see a CD light on the seconds span and True on Signal loss Framing and Loss Rcvd the phone company says it's our internal CSU I say they don't have the right cable plugged in. In order to test they keep on bringing down our first span. Any advice! Thanks! Mike

Subject: Re: (usr-tc) download status, quad modem LED's
From: Brian <signal@shreve.net>
Date: 1997-08-22 13:03:02

> > > >Also does anyone know when the new 24modem cards will be available? (No, > >not just for the leds.. ) and do they allow for a PRI span to be connected > >through a nic in the back, or how is dial provided? > > > > In BETA now. No release date is available. The PRI is in the modem NIC. So > if you have 13 HiPer DSP's (24modem card) you will have a PRI cable behind > each one of them. There is no need for the DUAL PRI or T1 card with this > implementation. And so is there a 10bT port on each modem NIC? or are they making a 100bT netserver? Also, any status on the Quake lag (udp latency) problems? .93 still has issues with this. 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: (usr-tc) two netserver console ports
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1997-08-22 14:14:44

Howdy...new question for you guru's. Have two netservers in a remote city. One of which I believe is sufferening from the freezing ethernet problem, but I can't confirm it. What I'd like to be able to do is set up a connection between the console ports of these two netservers, so if the one locks up on its ethernet, I can telnet to the other, then connect out through its console port to the console port on the other so I can see what its status is. What would be the port configurations for a setup such as this...obviously the cabling is easy...null modem and gender changer and its set. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) download status, quad modem LED's
From: James MacKenzie <tomservo@erie.net>
Date: 1997-08-22 14:42:21

On Fri, 22 Aug 1997, Michael Wronski wrote: > In BETA now. No release date is available. The PRI is in the modem NIC. So > if you have 13 HiPer DSP's (24modem card) you will have a PRI cable behind > each one of them. There is no need for the DUAL PRI or T1 card with this > implementation. > > -M And this will still allow for ISDN connections? (Pardon me if this is a stupid question). Jim MacKenzie tomservo@erie.net System Administrator ErieNet, Inc. "I love California. I practically grew up in Phoenix." - Former U.S. VP Dan Quayle

Subject: Re: (usr-tc) New archive site available
From: Stefan Virsik <virsik@metronet.de>
Date: 1997-08-22 15:28:47

Mark R. Lindsey wrote: > I've built an archive mirror of the usr-tc discussion archives, _Very_ cool! Thank you! :-) Stefan Stefan Virsik mailto:virsik@metronet.de Metronet Postfach 510 869 phone: (+49) 221 3091 272 50944 Cologne, Germany fax: (+49) 221 3091 298

Subject: Re: (usr-tc) two netserver console ports
From: David Bolen <db3l@ans.net>
Date: 1997-08-22 16:02:17

Jeff Mcadams <jeffm@iglou.com> writes: > What I'd like to be able to do is set up a connection between the > console ports of these two netservers, so if the one locks up on its > ethernet, I can telnet to the other, then connect out through its > console port to the console port on the other so I can see what its > status is. Hmm, I'm not sure outbound on the console port works - I think I've tried it in the past and while you can define it that way I don't think the reverse connection ever succeeds (or gets a process listening for it). But why not just dial into the hung NETServer through the normal user access number? In my experience when the ethernet hangs, it doesn't stop normal processing of inbound calls, it's just that when the user gets onto the NETServer they can't go anywhere. Of course, if you currently have the !root access from dialup disabled, you'd have to enable it until you got a chance to catch the next hang. -- 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) two netserver console ports
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1997-08-22 16:11:56

Thus spake David Bolen >Jeff Mcadams <jeffm@iglou.com> writes: >> What I'd like to be able to do is set up a connection between the >> console ports of these two netservers, so if the one locks up on its >> ethernet, I can telnet to the other, then connect out through its >> console port to the console port on the other so I can see what its >> status is. >Hmm, I'm not sure outbound on the console port works - I think I've >tried it in the past and while you can define it that way I don't >think the reverse connection ever succeeds (or gets a process >listening for it). Actually...it does. :) I figured it out. Have to pull the card, and flip dip switch 6 to on so the console port uses software configuration rather than being set to login/network(dialin) 9600 8n1 always. Then you can configure the s0 port to be a device port, telnet to the terminal server port on port 6000 (be default) and viola', you get whatever is at the other end of the serial cable (in my case, another terminal server console port). >But why not just dial into the hung NETServer through the normal user >access number? In my experience when the ethernet hangs, it doesn't >stop normal processing of inbound calls, it's just that when the user >gets onto the NETServer they can't go anywhere. Because we have a rather bizarre dial-in setup on our netservers. Either, they start up PPP and authenticate via RADIUS (obviously doesn't work since RADIUS has to authenticate via the network), or after 12 seconds it starts a telnet to our shell servers...ie, there's never a login prompt issued by the portmaster. >Of course, if you currently have the !root access from dialup >disabled, you'd have to enable it until you got a chance to catch the >next hang. Its enabled on ours, but since we never issue a login prompt from the netserver, its a moot point. In any case, my question is moot as I've figured out how to do it anyway. :) -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) Quad Modem Prob
From: Lars Freund <lafreund@cip.e-technik.uni-erlangen.de>
Date: 1997-08-23 10:55:46

Hi, when I dial on my usr-tc, I got on 5 modems (S14, S15, S16, S5, S6) the same effect today: the modem beeps sound strange, I get no connect, my modem hangs up, and in my logfile I can read: Aug 23 09:27:58 S14 didn't get online! status=-1, connect_fail=36, link_fail=31 What does this mean and how can I fix it? I changed last week the modem settings to germany: at&F1 atC10=16&w at&F1 ati7 ats39=13s34=8s50=200&w ats13=128 Perhaps it's related to that? Bye, Lars -- +-----------------------------------------------------------------+ | Lars Freund lars@forchheim.com | | FOnLine Buergernetzverein: http://www.forchheim.baynet.de | | http://cip2.e-technik.uni-erlangen.de:8080/hyplan/lafreund.html | +-----------------------------------------------------------------+

Subject: (usr-tc) OID
From: Michael R. Poyaoan <mrp@skyinet.net>
Date: 1997-08-23 14:44:20

I would like to get some stats on my netserver cards via snmp. Does anyone know the OIDs (object identifier) for the following: modems available modems unavailable modems offline modems dead Can someone please point me to an ftp/web site that includes, but not limited to, the above information. Thanks and best regards, Mike

Subject: Re: (usr-tc) Quad Modem Prob
From: Lars Freund <lafreund@cip.e-technik.uni-erlangen.de>
Date: 1997-08-23 17:44:39

Hi, > Aug 23 09:27:58 S14 didn't get online! status=-1, connect_fail=36, > link_fail=31 > > What does this mean and how can I fix it? sorry, I found it out, as I wondered that I was the only one with this probelm: I changed my modem-settings and had no handshake aktivated... Bye, Lars -- +-----------------------------------------------------------------+ | Lars Freund lars@forchheim.com | | FOnLine Buergernetzverein: http://www.forchheim.baynet.de | | http://cip2.e-technik.uni-erlangen.de:8080/hyplan/lafreund.html | +-----------------------------------------------------------------+

Subject: (usr-tc) Product Release Announcement - Quad Modem .7 Code
From: Michael Wronski <mwronski@coredump.ae.usr.com>
Date: 1997-08-25 09:54:26

At 04:29 PM 8/21/97 -0500, you wrote: >At 05:11 PM 8/21/97 -0400, you wrote: >>Mark Lindsey (mark@vielle.datasys.net) said: >>: >Does USR/3Com run any sort of list for announcements of firmware >>: >updates? >> This just came accross my desk, and it has been a recent topic. So here is a new code announcement: There is a new version of the Quad Modem code for the Enterprise Network Hub on the totalservice web site. It is version 5.5.7 (double-sided) and 5.6.7 (single-sided). This code is compatible with the other pieces of System Release TCS 2.5.1 so it should be considered to be a part of that system release. It basically replaces the existing 5.5.6/5.6.6 code revs, but these older .6 versions can still be obtained from the software library if absolutely needed (these are not recommended and we should encourage customers to use the .7 code). The key differences between the .6 code and the .7 code are: -The .7 code is approved for use in all countries (.6 was approved for US/Canada only) -This code includes x2 version checking, in preparation for the 2nd version of x2 that will be implemented in the client modems. It is extrememly important that our customers have this version of code loaded onto their chassis or a new client modem that does x2 version 2 (not shipping yet, but should be this fall) will only connect at V.34 speeds. This is covered in the release notes and we should encourage ALL customers to upgrade to this version of code as soon as they can. `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' 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) Product Release Announcement - Quad Modem .7 Code
From: Peter Clausen <peter@cstone.net>
Date: 1997-08-25 16:27:19

At 09:54 AM 8/25/97 -0500, you wrote: >The key differences between the .6 code and the .7 code are: >-The .7 code is approved for use in all countries (.6 was approved for >US/Canada only) >-This code includes x2 version checking, in preparation for the 2nd version >of x2 that will be implemented in the client modems. It is extrememly >important that our customers have this version of code loaded onto their >chassis or a new client modem that does x2 version 2 (not shipping yet, but >should be this fall) will only connect at V.34 speeds. This is covered in >the release notes and we should encourage ALL customers to upgrade to this >version of code as soon as they can. How does one obtain this code without paying the $2,700 for an annual service contract? My 90 days of free support ran out a few weeks ago and I'm no longer able to access software releases from your web site. I was quite upset after calling your tech support department and being told that I had to purchase an annual contract in order to re-gain access to the software. All my other equipment (Ascend, Cisco, 3Com, etc) does not require me to purchase a "contract" in order to get the latest code. What gives?

Subject: Re: (usr-tc) download status, quad modem LED's
From: Randy Doran <rtdoran@gate.net>
Date: 1997-08-25 17:02:49

The final release of Hiper ACCESS will allow for ISDN connections. Randy Doran CyberGate Network Operations On Fri, 22 Aug 1997, James MacKenzie wrote: > On Fri, 22 Aug 1997, Michael Wronski wrote: > > > In BETA now. No release date is available. The PRI is in the modem NIC. So > > if you have 13 HiPer DSP's (24modem card) you will have a PRI cable behind > > each one of them. There is no need for the DUAL PRI or T1 card with this > > implementation. > > > > -M > > And this will still allow for ISDN connections? (Pardon me if this is a > stupid question). > > Jim MacKenzie > tomservo@erie.net > System Administrator > ErieNet, Inc. > > "I love California. I practically grew up in Phoenix." - > Former U.S. VP Dan Quayle > > > >

Subject: (usr-tc) Quake lag on 3.5.93
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-08-26 10:12:28

This is a response from one of our subscribers. The non-X2 number is backed by Couriers hooked to Xylogics Annex 4000's. >>All of Salt Lake/Ogden and Provo USR Total Controls have been upgraded to the >>latest version of their code. If you are still seeing regular Quake lag on >>these servers, please let us know. > >Hi, >I am still getting a lot less lag when calling the non-X2 equipment. The TC >upgrade did help some though. When dialed into the X2 number, I was getting >pings in the 180-340 range (it still keeps bouncing) for about 20 minutes. >It was pretty playable during that time. I then went to the dreaded 999 >ping. The high ping didn't occur until more than 6 people were on the >server. I then dialed into the non-X2 number & had rock solid 140-160ms >pings no matter how many people were on the server. I am using a US >Robotics Courier V.Everything with the latest firmware. When calling the X2 >number I do not get an X2 connection because of "multiple codecs" (Thank >You US Worst!). I will be interested to see if anyone else still has some >lag problems with the Total Control equipment. >Thank You,

Subject: Re: (usr-tc) Quake lag on 3.5.93
From: Craig Nelson <craig@jetcity.com>
Date: 1997-08-26 11:20:14

We fought this for weeks as well. We have very old equipment (circa 1994). We finally put 16meg in our netserver and upgraded to the latest TCS (note that we had to forse feed the latest rev into the netserver due to the hardware rev), changed to "ppp in modem" and the problem seemed to go away. Note that we don't play Quake, just Quake-World, and I understand that it it much worse for straight Quake. On another tact - we also put up our own Quake-World server. This had the effect of giving our users a nice place to play (excellent ping times) and made them feel warm-and-fuzzy about our commitment to to the game - after all we play it to and went to all the trouble to put up a server. At 10:12 AM 8/26/97 -0600, you wrote: >This is a response from one of our subscribers. The non-X2 number is >backed by Couriers hooked to Xylogics Annex 4000's. > > >>>All of Salt Lake/Ogden and Provo USR Total Controls have been upgraded to the >>>latest version of their code. If you are still seeing regular Quake lag on >>>these servers, please let us know. >> >>Hi, >>I am still getting a lot less lag when calling the non-X2 equipment. The TC >>upgrade did help some though. When dialed into the X2 number, I was getting >>pings in the 180-340 range (it still keeps bouncing) for about 20 minutes. >>It was pretty playable during that time. I then went to the dreaded 999 >>ping. The high ping didn't occur until more than 6 people were on the >>server. I then dialed into the non-X2 number & had rock solid 140-160ms >>pings no matter how many people were on the server. I am using a US >>Robotics Courier V.Everything with the latest firmware. When calling the X2 >>number I do not get an X2 connection because of "multiple codecs" (Thank >>You US Worst!). I will be interested to see if anyone else still has some >>lag problems with the Total Control equipment. >>Thank You, > > > <.>-----------------------------------------------<.> The thing about Crayons is, They can take take you more places than Starships -Guinan <.>-----------------------------------------------<.>

Subject: Re: (usr-tc) Quake lag on 3.5.93
From: Brian <signal@shreve.net>
Date: 1997-08-26 12:28:48

On Tue, 26 Aug 1997, Pete Ashdown wrote: > This is a response from one of our subscribers. The non-X2 number is > backed by Couriers hooked to Xylogics Annex 4000's. > > > >>All of Salt Lake/Ogden and Provo USR Total Controls have been upgraded to the > >>latest version of their code. If you are still seeing regular Quake lag on > >>these servers, please let us know. > > > >Hi, > >I am still getting a lot less lag when calling the non-X2 equipment. The TC > >upgrade did help some though. When dialed into the X2 number, I was getting > >pings in the 180-340 range (it still keeps bouncing) for about 20 minutes. > >It was pretty playable during that time. I then went to the dreaded 999 > >ping. The high ping didn't occur until more than 6 people were on the > >server. I then dialed into the non-X2 number & had rock solid 140-160ms > >pings no matter how many people were on the server. I am using a US > >Robotics Courier V.Everything with the latest firmware. When calling the X2 > >number I do not get an X2 connection because of "multiple codecs" (Thank > >You US Worst!). I will be interested to see if anyone else still has some > >lag problems with the Total Control equipment. > >Thank You, > I get these type messages daily, many disgruntled Quake players when playing through the Total Control Hubs. 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) Quake lag on 3.5.93
From: Brian <signal@shreve.net>
Date: 1997-08-26 12:28:48

Subject: Re: (usr-tc) Quake lag on 3.5.93
From: Brian <signal@shreve.net>
Date: 1997-08-26 15:25:08

On Tue, 26 Aug 1997, Craig Nelson wrote: > We fought this for weeks as well. We have very old equipment (circa 1994). > We finally put 16meg in our netserver and upgraded to the latest TCS (note > that we had to forse feed the latest rev into the netserver due to the > hardware rev), changed to "ppp in modem" and the problem seemed to go away. > Note that we don't play Quake, just Quake-World, and I understand that it > it much worse for straight Quake. > > On another tact - we also put up our own Quake-World server. This had the > effect of giving our users a nice place to play (excellent ping times) and > made them feel warm-and-fuzzy about our commitment to to the game - after > all we play it to and went to all the trouble to put up a server. > I had to force feed that latest version of the code using pcsdl, tcs wouldnt take it........which sucks. The problem should be given priority, right below the nic lockup problem. The problem has been present in several generations of code, and effects ALL UDP based streams, most of which are real time based applications. 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) Quake lag on 3.5.93
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-08-26 15:58:35

Craig Nelson said once upon a time: > >We fought this for weeks as well. We have very old equipment (circa 1994). >We finally put 16meg in our netserver and upgraded to the latest TCS (note >that we had to forse feed the latest rev into the netserver due to the >hardware rev), changed to "ppp in modem" and the problem seemed to go away. >Note that we don't play Quake, just Quake-World, and I understand that it >it much worse for straight Quake. We've got the latest hardware rev, with 20 megs, "pppmodem on", and 3.5.93. Although 3.5.93 has helped, it is still happening, with QuakeWorld as well. >On another tact - we also put up our own Quake-World server. This had the >effect of giving our users a nice place to play (excellent ping times) and >made them feel warm-and-fuzzy about our commitment to to the game - after >all we play it to and went to all the trouble to put up a server. People are complaining because they can't play our own QuakeWorld server over the TC's. This is a 200mhz Pentium II mainlined into our FDDI backbone (http://quake.xmission.com for more info if anyone cares). >>This is a response from one of our subscribers. The non-X2 number is >>backed by Couriers hooked to Xylogics Annex 4000's. This is the key thing about it. The subscribers never experience lag over the Xylogics equipment, even though it is only capable of 33.6 and is not even in the same building as the Quake server. It is remotely connected over frame-relay T1.

Subject: Re: (usr-tc) Quake lag on 3.5.93
From: David Bolen <db3l@ans.net>
Date: 1997-08-26 16:54:16

Brian <signal@shreve.net> writes: > I had to force feed that latest version of the code using pcsdl, tcs > wouldnt take it........which sucks. Just use an older SDL file - in my case my previous version was 3.2.20 (I never deployed a 3.3 version) and it should work fine. -- 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) Quake lag on 3.5.93
From: Brian <signal@shreve.net>
Date: 1997-08-26 17:08:16

On Tue, 26 Aug 1997, Pete Ashdown wrote: > Craig Nelson said once upon a time: > > > >We fought this for weeks as well. We have very old equipment (circa 1994). > >We finally put 16meg in our netserver and upgraded to the latest TCS (note > >that we had to forse feed the latest rev into the netserver due to the > >hardware rev), changed to "ppp in modem" and the problem seemed to go away. > >Note that we don't play Quake, just Quake-World, and I understand that it > >it much worse for straight Quake. > > We've got the latest hardware rev, with 20 megs, "pppmodem on", and 3.5.93. > Although 3.5.93 has helped, it is still happening, with QuakeWorld as well. > > >On another tact - we also put up our own Quake-World server. This had the > >effect of giving our users a nice place to play (excellent ping times) and > >made them feel warm-and-fuzzy about our commitment to to the game - after > >all we play it to and went to all the trouble to put up a server. > > People are complaining because they can't play our own QuakeWorld server > over the TC's. This is a 200mhz Pentium II mainlined into our FDDI > backbone (http://quake.xmission.com for more info if anyone cares). > > >>This is a response from one of our subscribers. The non-X2 number is > >>backed by Couriers hooked to Xylogics Annex 4000's. > > This is the key thing about it. The subscribers never experience lag over > the Xylogics equipment, even though it is only capable of 33.6 and is not > even in the same building as the Quake server. It is remotely connected > over frame-relay T1. > David, The bitch of it is, that its actually FASTER for people not using your service, and using another isp, to use your quake server. That is to say as long as that provider is not using Total Control. 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) Quake lag on 3.5.93
From: Brian <signal@shreve.net>
Date: 1997-08-26 17:24:22

On Tue, 26 Aug 1997, Tom Bilan wrote: > You hit that one on the nose. USR is e-mailing me 3.5.93 but it hasn't arrived > as of yet (I talked to them today). > > If it locks up then I'm going to press to get the FC2 chip. Did the FC2 stop > the lockups on yours Brian? Yes it did , but then again I have only been running it for about 9 days or so, which IMHO, is not long enough to say its fixed. i was seeing lockups every 7 days or so. Brian > > Thanks, > Tom > > On Tuesday, August 26, 1997 6:08 PM, Brian [SMTP:signal@shreve.net] wrote: > > On Tue, 26 Aug 1997, Pete Ashdown wrote: > > > > > Craig Nelson said once upon a time: > > > > > > > >We fought this for weeks as well. We have very old equipment (circa 1994). > > > >We finally put 16meg in our netserver and upgraded to the latest TCS (note > > > >that we had to forse feed the latest rev into the netserver due to the > > > >hardware rev), changed to "ppp in modem" and the problem seemed to go away. > > > > > > > >Note that we don't play Quake, just Quake-World, and I understand that it > > > >it much worse for straight Quake. > > > > > > We've got the latest hardware rev, with 20 megs, "pppmodem on", and 3.5.93. > > > Although 3.5.93 has helped, it is still happening, with QuakeWorld as well. > > > > > > >On another tact - we also put up our own Quake-World server. This had the > > > >effect of giving our users a nice place to play (excellent ping times) and > > > >made them feel warm-and-fuzzy about our commitment to to the game - after > > > >all we play it to and went to all the trouble to put up a server. > > > > > > People are complaining because they can't play our own QuakeWorld server > > > over the TC's. This is a 200mhz Pentium II mainlined into our FDDI > > > backbone (http://quake.xmission.com for more info if anyone cares). > > > > > > >>This is a response from one of our subscribers. The non-X2 number is > > > >>backed by Couriers hooked to Xylogics Annex 4000's. > > > > > > This is the key thing about it. The subscribers never experience lag over > > > the Xylogics equipment, even though it is only capable of 33.6 and is not > > > even in the same building as the Quake server. It is remotely connected > > > over frame-relay T1. > > > > > > > David, > > > > The bitch of it is, that its actually FASTER for people not using your > > service, and using another isp, to use your quake server. That is to say > > as long as that provider is not using Total Control. > > > > 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 -----------------------------/ > > > > > > /-------------------------- 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) Quake lag on 3.5.93
From: Tom Bilan <tom@tdi.net>
Date: 1997-08-26 18:15:38

You hit that one on the nose. USR is e-mailing me 3.5.93 but it hasn't arrived as of yet (I talked to them today). If it locks up then I'm going to press to get the FC2 chip. Did the FC2 stop the lockups on yours Brian? Thanks, Tom On Tuesday, August 26, 1997 6:08 PM, Brian [SMTP:signal@shreve.net] wrote: > On Tue, 26 Aug 1997, Pete Ashdown wrote: > > > Craig Nelson said once upon a time: > > > > > >We fought this for weeks as well. We have very old equipment (circa 1994). > > >We finally put 16meg in our netserver and upgraded to the latest TCS (note > > >that we had to forse feed the latest rev into the netserver due to the > > >hardware rev), changed to "ppp in modem" and the problem seemed to go away. > > > > > >Note that we don't play Quake, just Quake-World, and I understand that it > > >it much worse for straight Quake. > > > > We've got the latest hardware rev, with 20 megs, "pppmodem on", and 3.5.93. > > Although 3.5.93 has helped, it is still happening, with QuakeWorld as well. > > > > >On another tact - we also put up our own Quake-World server. This had the > > >effect of giving our users a nice place to play (excellent ping times) and > > >made them feel warm-and-fuzzy about our commitment to to the game - after > > >all we play it to and went to all the trouble to put up a server. > > > > People are complaining because they can't play our own QuakeWorld server > > over the TC's. This is a 200mhz Pentium II mainlined into our FDDI > > backbone (http://quake.xmission.com for more info if anyone cares). > > > > >>This is a response from one of our subscribers. The non-X2 number is > > >>backed by Couriers hooked to Xylogics Annex 4000's. > > > > This is the key thing about it. The subscribers never experience lag over > > the Xylogics equipment, even though it is only capable of 33.6 and is not > > even in the same building as the Quake server. It is remotely connected > > over frame-relay T1. > > > > David, > > The bitch of it is, that its actually FASTER for people not using your > service, and using another isp, to use your quake server. That is to say > as long as that provider is not using Total Control. > > 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) MPIP discrepancy
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-08-27 02:26:16

What is the difference between: add mpipclient <ip address> <secret> and set mpipclient <ip address> <secret> They are both valid commands.

Subject: (usr-tc) Disconnect causes
From: Brian Elfert <brian@citilink.com>
Date: 1997-08-27 10:07:57

Does 3.5.34 now correctly pass disconnect causes to RADIUS accounting? With 3.4.23, every single stop record had lost-carrier as the disconnect reason. Now, I just looked, and the causes are different for each stop record. If this works now, I'll be extremely happy. This makes troubleshooting 10 times easier. Brian

Subject: Re: (usr-tc) Disconnect causes
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-08-27 11:33:44

On Wed, 27 Aug 1997, Brian Elfert wrote: > Does 3.5.34 now correctly pass disconnect causes to RADIUS accounting? > > With 3.4.23, every single stop record had lost-carrier as the disconnect > reason. > > Now, I just looked, and the causes are different for each stop record. > > If this works now, I'll be extremely happy. This makes troubleshooting 10 > times easier. > > Brian > > 3.5.34 does send the proper cause for stop records Here is a sample that I get from my NETServer Acct-Status-Type = Stop Acct-Session-Time = 2937 Acct-Terminate-Cause = ACCT_TERM_USER_REQUEST Acct-Authentic = RADIUS Called-Station-Id = "1601" Acct-Status-Type = Stop Acct-Session-Time = 2931 Acct-Terminate-Cause = ACCT_TERM_ADMIN_RESET Acct-Authentic = RADIUS Called-Station-Id = "1601" Acct-Session-Time = 336 Acct-Terminate-Cause = ACCT_TERM_LOST_CARRIER Acct-Authentic = Local Called-Station-Id = "1601" Acct-Status-Type = Stop Acct-Session-Time = 4749 Acct-Terminate-Cause = ACCT_TERM_USER_REQUEST Acct-Authentic = Local Called-Station-Id = "1601" \ 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) Disconnect causes
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-08-27 11:35:39

Tom Bilan said once upon a time: > >Wouldn't it be just wonderful if USR would use the Radius standard instead >of hex codes in the VSA field? Yup. Has anyone hacked their Merit code to handle these yet?

Subject: RE: (usr-tc) Disconnect causes
From: Tom Bilan <tom@tdi.net>
Date: 1997-08-27 12:29:53

Wouldn't it be just wonderful if USR would use the Radius standard instead of hex codes in the VSA field? You'd think it would be much easier or something. It would probably be what the customer would want too.... Tom On Wednesday, August 27, 1997 11:08 AM, Brian Elfert [SMTP:brian@citilink.com] wrote: > Does 3.5.34 now correctly pass disconnect causes to RADIUS accounting? > > With 3.4.23, every single stop record had lost-carrier as the disconnect > reason. > > Now, I just looked, and the causes are different for each stop record. > > If this works now, I'll be extremely happy. This makes troubleshooting 10 > times easier. > > Brian > >

Subject: Re: (usr-tc) maximum number of simultaneous ports...
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-08-27 13:51:13

On Wed, 27 Aug 1997, System Administrator wrote: > Does the usr tc support a radius attribute which controls the maximum > number of simultaneous ports a user may use? Does this work across boxes? > How about w/ ISDN? > > Thanks! > > Jesse Sipprell > Senior Systems Engineer > Evolution Communications, Inc. > > * Finger sysadmin@evcom.net for my PGP Public Key * > > Port Limit krish

Subject: Re: (usr-tc) Disconnect causes
From: MegaZone <megazone@livingston.com>
Date: 1997-08-27 14:11:51

Once upon a time David Bolen shaped the electrons to say... >I'm not sure I follow - VSAs _are_ part of the RADIUS standard.. What was meant is that there is a standard attribute for disconnect reasons. There is no reason to use a VSA an obfuscate things when they could use the same attribute as everyone else. Ascend is famous for this too - they have a few 'Ascend attributes' that are straight out duplicates of standard attributes. -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) maximum number of simultaneous ports...
From: System Administrator <sysadmin@evcom.net>
Date: 1997-08-27 14:30:48

Does the usr tc support a radius attribute which controls the maximum number of simultaneous ports a user may use? Does this work across boxes? How about w/ ISDN? Thanks! Jesse Sipprell Senior Systems Engineer Evolution Communications, Inc. * Finger sysadmin@evcom.net for my PGP Public Key *

Subject: (usr-tc) Total Control paremeter option
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1997-08-27 14:36:00

I am turning up my first ISDN PRI on our Total Control system. I have a question on an option and was wondering how otehrs are configuring this option. The option is under the quad modem cards under ISDN Modem Call Control Options. The option is: ForceNetwork Rate Speed . The options are 56kbs or 64kbs . The default appears to be 56kbs. I would expect that for a PRI T-1, this should be set for 64kbs. Thoughts ? Jeff Binkley ASA Network Computing

Subject: Re: (usr-tc) USR Announcements list
From: System Administrator <root@wingnet.net>
Date: 1997-08-27 14:49:07

> Most of the time the latest code is posted to Total Service Website > http://totalservice.usr.com > > All release notes and code is there... Right, but given the fact that most of us have loads of machinery, OSes and such that all have upgrades, I agree that it is a very reasonable request that USR simply start a mailing list devoted to notification of new code releases. Nothing more. No questions, no support, etc... JUST for announcements. How many out there agree? WingNET System Administrator 423-559-LINK (v) 423-559-5444 (f)

Subject: RE: (usr-tc) Disconnect causes
From: David Bolen <db3l@ans.net>
Date: 1997-08-27 16:01:38

Tom Bilan <tom@tdi.net> writes: > Wouldn't it be just wonderful if USR would use the Radius standard instead > of hex codes in the VSA field? > > You'd think it would be much easier or something. It would probably be what > the customer would want too.... I'm not sure I follow - VSAs _are_ part of the RADIUS standard.. -- 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) Disconnect causes
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-08-27 16:14:44

Robert Sanders said once upon a time: >I've added VSA support to our server, originally derived from >Livingston radiusd 1.16 but long since mutated into something almost >wholly other. USR's brand of VSAs are very straightforward. If >anybody's interested I could (eventually) generate a patch file >against the stock release. Against Livingston or Merit? I'm personally only interested in the Merit. >Also, the rumor is that USR has a modified Merit radiusd 2.4.2x >floating around somewhere internally that supports VSAs; what I don't >know is whether they give that away or require that you purchase their >Security & Accounting product. Ask your sales rep. With source? I've hacked my Merit aplenty.

Subject: Re: (usr-tc) Disconnect causes
From: MegaZone <megazone@livingston.com>
Date: 1997-08-27 16:19:52

Once upon a time David Bolen shaped the electrons to say... >attribute may not cover what the equipment can support. So at that >point a vendor has the option of just using other values (and hoping No, the option is to ask the WG chair to *assign* new values. Simple. And it is done. In fact, just this past week some new values were added to the RFC attributes by the WG. Just picking a number is rude, and it has been done (Ascend) and caused problems when it later turns out it clashes with the RFC. >Worse, they tend (from what I've noticed) to pick attributes from the >main attribute set as opposed to using VSAs... I'm not sure if they Yep. And eventually Ascend users will pay for it when official values stomp on that address space. >Personally, I think a large part of the reason that this is an issue >is simply because many (most?) of the publically available RADIUS >servers don't handle VSAs well, which is unfortunate. From my Well, most of them were based on Livingston 1.16 - and 1.16 didn't do VSA's because they came LATER than the server. It was an addition added because some vendors insisted they couldn't work with the standard alone. >should always be the most desirable goal. I see VSAs as a necessary >evil however as vendors try to leapfrog each other in functionality >and/or as a reflection that the standardization process will probably >always lag slightly behind the actual NAS development. To date Livingston has never used a VSA, and our engineering is committed to not using them at all costs. If it is really that important, it belongs in the standard and we'll bring it to the WG. -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) Disconnect causes
From: MegaZone <megazone@livingston.com>
Date: 1997-08-27 17:02:25

Once upon a time David Bolen shaped the electrons to say... >> No, the option is to ask the WG chair to *assign* new values. >And then wait until that process is complete? I think product cycle >times won't always allow that. It takes like a day or two unless he's out. "Hey, can we have 7 for FUBAR? Here's the justification... *spew*" Looks, it isn't used. Goes to the list "Any objections ot 7 being FUBAR?" If no one screams, that's it. I've watched it happen several times. >Exactly - you bring up my very point. The new values picked this week >were in fact corrected because of the very fact that Ascend went this >route of trying to use a standard attribute with a non-standard Right. They never talked to the chair, they just did it unilaterally. *THAT* was wrong. >in use before being added to the value list. Luckily, no-one else was >already using the proposed values in their original orientation or we >would have had a clash between two operating NASs. And Ascend users would have been shafted. So they could yell at Ascend for being dinks and not following proceedure. >functionality, as other server bases do support them (including I >believe the current server available to Livingston customers, right?) Actually 2.0.1 does not do VSA - we've never needed it. I don't know if 2.1 will bother with them either. Out next gen server does everything AFAIK. >I can tell you however, that I have in the past and will continue in >the future to use functionality on my TC equipment that is not yet >(nor may not be) supported by the standard in the time frame I need But the thing is - does USR ask for it to be in the standard? I read the IETF-RADIUS list constantly, and I rarely see USR (or other vendors) trying to propose their VSAs as standard. I think many vendors would rather just use VSA and not bother even *trying* to make it standard. -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) Disconnect causes
From: Robert Sanders <rsanders@mindspring.net>
Date: 1997-08-27 17:39:49

MegaZone <megazone@livingston.com> writes: > Once upon a time David Bolen shaped the electrons to say... > >I'm not sure I follow - VSAs _are_ part of the RADIUS standard.. > > What was meant is that there is a standard attribute for disconnect > reasons. There is no reason to use a VSA an obfuscate things when they > could use the same attribute as everyone else. They use it. The NETserver reports accurate (though not necessarily very precise) termination causes via Acct-Terminate-Cause, attribute 49. Nevertheless, there is plenty of reason to resort to VSAs when the standard attributes are non-existent at the time of need or, in the case of Connect-Info, very poorly designed. Furthermore, Acct-Terminate-Cause isn't sufficiently expressive for my purposes. "Lost-Carrier" isn't nearly specific enough when you consider the dozens of possible reasons for a modem-initiated disconnection. That's why I wish more of USR's rich NMC-based accounting information were gatewayed through the NETserver as VSAs. The RFEs have been submitted. I long for the day when I can examine a single accounting log and see that the L2 terminate cause was the ominous Lost-Carrier, but the L1 terminate cause was v42DisconnectCmd (which is okay!). If USR did the exact same thing as "everyone else", they'd hardly be differentiating themselves from the crowd. And unlike Ascend, USR has the good manners to tuck their proprietary attributes into a legal place without unnecessarily polluting the tiny standard attribute space. regards, -- Robert

Subject: Re: (usr-tc) Disconnect causes
From: David Bolen <db3l@ans.net>
Date: 1997-08-27 17:46:11

MegaZone <megazone@livingston.com> writes: > What was meant is that there is a standard attribute for disconnect > reasons. There is no reason to use a VSA an obfuscate things when they > could use the same attribute as everyone else. I may have confused myself about a specific reference along the thread, since I do get standard "Acct-Terminate-Cause" attributes in the stop accounting records from the NETServer. So which specific attribute was in question? Of course in general, the use of VSAs can be tricky, even when there is a standard attribute available. The enumerations for that standard attribute may not cover what the equipment can support. So at that point a vendor has the option of just using other values (and hoping to get them added into the official set with the values picked) or using a VSA. Using the VSA is guaranteed to be safe and unique, but is perhaps not as attractive a solution from the perspective of standardization. But getting stuck with use of an enumeration that later gets used for something else is hardly a good state to end up in either. > Ascend is famous for this too - they have a few 'Ascend attributes' that > are straight out duplicates of standard attributes. Worse, they tend (from what I've noticed) to pick attributes from the main attribute set as opposed to using VSAs... I'm not sure if they kept them all in the experimental range or not (was the experimental range even fully defined back when they chose them?) Personally, I think a large part of the reason that this is an issue is simply because many (most?) of the publically available RADIUS servers don't handle VSAs well, which is unfortunate. From my perspective, it really doesn't matter if the attributes show up in the logs based on a VSA or on a standard attribute - in either case it's simply an attribute and a value. I'll grant that comparing multiple vendors in a shared network is easiest when they share as many attributes as possible though, so that should always be the most desirable goal. I see VSAs as a necessary evil however as vendors try to leapfrog each other in functionality and/or as a reflection that the standardization process will probably always lag slightly behind the actual NAS development. -- 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) Disconnect causes
From: David Bolen <db3l@ans.net>
Date: 1997-08-27 17:51:01

Robert Sanders <rsanders@mindspring.net> writes: > I long for the day when I can examine a single accounting > log and see that the L2 terminate cause was the ominous Lost-Carrier, > but the L1 terminate cause was v42DisconnectCmd (which is okay!). Desiring this kind of information is one of the reasons that we took the approach of constructing a custom call record containing information from several sources (NETServer syslogs, NMC traps, accounting information, SNMP polls) integrated together, since over time no single source has really had everything we wanted. Either that or it was because stuff like RADIUS accounting wasn't even available in the beginning :-) -- 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) Disconnect causes
From: Robert Sanders <rsanders@mindspring.net>
Date: 1997-08-27 17:53:05

Pete Ashdown <pashdown@xmission.com> writes: > >Wouldn't it be just wonderful if USR would use the Radius standard instead > >of hex codes in the VSA field? > > Yup. What VSA are you talking about? Acct-Terminate-Cause is present in my NETservers' Stop records. I'm not sure what "hex codes" you're talking about. > Has anyone hacked their Merit code to handle these yet? I've added VSA support to our server, originally derived from Livingston radiusd 1.16 but long since mutated into something almost wholly other. USR's brand of VSAs are very straightforward. If anybody's interested I could (eventually) generate a patch file against the stock release. Also, the rumor is that USR has a modified Merit radiusd 2.4.2x floating around somewhere internally that supports VSAs; what I don't know is whether they give that away or require that you purchase their Security & Accounting product. Ask your sales rep. regards, -- Robert

Subject: (usr-tc) Interpreting traps
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1997-08-27 18:16:46

I've set up the CMU snmp utilities, including snmptrapd, on a machine at my site, and directed traps from my racks toward it. However, I'm not getting much good from such messages as Enterprise Specific Trap (58) Uptime: 3 days, 1:41:26 Enterprise Specific Trap (58) Uptime: 20 days, 9:46:55 Enterprise Specific Trap (13) Uptime: 8 days, 4:42:27 Enterprise Specific Trap (7) Uptime: 8 days, 6:50:34 Enterprise Specific Trap (29) Uptime: 3 days, 16:24:33 Occasionally, I'll see a Authentication Failure Trap (0) Uptime: 7 days, 20:28:41 which, I suppose, is better information than nought. How do I configure snmptrapd to give a little more verbose help for USR's traps? Thanks. --- Mark R. Lindsey, mark@datasys.net Network Engineer, DSS Online 912 241 0607; Fax: 241 0190

Subject: RE: (usr-tc) Disconnect causes
From: Tom Bilan <tom@tdi.net>
Date: 1997-08-27 18:55:36

Would you rather program VLAs or just have the correct terminate code where the terminate code is supposed to be? Tom On Wednesday, August 27, 1997 4:02 PM, David Bolen [SMTP:db3l@ans.net] wrote: > Tom Bilan <tom@tdi.net> writes: > > > Wouldn't it be just wonderful if USR would use the Radius standard instead > > of hex codes in the VSA field? > > > > You'd think it would be much easier or something. It would probably be what > > the customer would want too.... > > I'm not sure I follow - VSAs _are_ part of the RADIUS standard.. > > -- 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) Disconnect causes
From: David Bolen <db3l@ans.net>
Date: 1997-08-27 19:33:54

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) Disconnect causes
From: David Bolen <db3l@ans.net>
Date: 1997-08-27 19:42:30

MegaZone <megazone@livingston.com>writes: > No, the option is to ask the WG chair to *assign* new values. And then wait until that process is complete? I think product cycle times won't always allow that. > Simple. And it is done. In fact, just this past week some new values were > added to the RFC attributes by the WG. Just picking a number is rude, and > it has been done (Ascend) and caused problems when it later turns out it > clashes with the RFC. Exactly - you bring up my very point. The new values picked this week were in fact corrected because of the very fact that Ascend went this route of trying to use a standard attribute with a non-standard enumeration. And it raised the very problem I noted, which is it got in use before being added to the value list. Luckily, no-one else was already using the proposed values in their original orientation or we would have had a clash between two operating NASs. > Well, most of them were based on Livingston 1.16 - and 1.16 didn't do > VSA's because they came LATER than the server. It was an addition added > because some vendors insisted they couldn't work with the standard alone. Oh, just to be clear - I'm certainly not picking on the Livingston code per se - it's very understandable why it didn't do VSAs. I'm just noting that the fact that a fairly old code base hasn't been updated in a publically-available version to support later parts of the RADIUS standard shouldn't be a reason for not using the functionality, as other server bases do support them (including I believe the current server available to Livingston customers, right?) And if permitting VSAs allowed RADIUS to be incorporated into more platforms than not having them would (in which case those platforms might have forgone RADIUS entirely), then I consider them a good thing. > To date Livingston has never used a VSA, and our engineering is committed > to not using them at all costs. If it is really that important, it belongs > in the standard and we'll bring it to the WG. I certainly wish you the best in maintaining this approach, and I hope you can achieve the functionality you want in a timely enough fashion. I can tell you however, that I have in the past and will continue in the future to use functionality on my TC equipment that is not yet (nor may not be) supported by the standard in the time frame I need it, and the VSAs allowed me to achieve the functionality I needed. Some of that has since made it to standard attributes (and USR has in fact adapted in many cases - such as the extensions attribute "Prompt"), but I needed that functionality faster. As I said, I consider it a necessary evil. But it's just as easy (for me) to support as standard attributes and it allows me the functionality I need without waiting for the lengthy delays of changes to the standard. -- 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: (usr-tc) AcctTerminate causes
From: Tom Bilan <tom@tdi.net>
Date: 1997-08-27 19:59:39

I take it all back (almost) :) I installed 3.5.93 on one of my ENHs and whilst anxiously awaiting all day for it to lock up the ethernet port I found that 3.5.93 is now using real Radius Terminate non-VSA codes! *clutches heart and calls for Elizabeth* Anyway, if 3.5.93 is stable enough to run on all the other boxes then it looks like USR has that problem licked. Also, when is the hiper card coming out? I need more lines and I would be upset if I bought the conventional chassis with the cards and 1 month later USR came out with a cool better new toy that did it all on 1 card. Does anyone know what the price is slated to be? Thanks, Tom

Subject: Re: (usr-tc) Disconnect causes
From: MegaZone <megazone@livingston.com>
Date: 1997-08-27 20:07:31

Once upon a time David Bolen shaped the electrons to say... >But I still think that 3Com (and other vendors) should be able to make >use of all aspects of the RADIUS protocol, including VSAs, in their >products where it makes sense. Wouldn't it be nice if they provided a matching SERVER though? -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) Disconnect causes
From: Tom Bilan <tom@tdi.net>
Date: 1997-08-27 20:11:23

Some of us don't have the code for the version of Radius that we depend on and therefore can add the extra parsing to determine VSAs. So you're saying that you would rather custom code to determine the terminate code rather than have it inside the acctterminatecause field? I have a M.S. is CSE and it's not that I'm unable to write my own version of radius but hey, I already work 80 hours a week. Thanks, Tom On Wednesday, August 27, 1997 7:34 PM, David Bolen [SMTP:db3l@ans.net] wrote: > 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) Disconnect causes
From: Tom Bilan <tom@tdi.net>
Date: 1997-08-27 20:14:33

yep. I like the unilatterally part... I'm not anti-USR at all. I did pick their product after months of debating and having Cisco reps and Ascend reps in my office constantly. I may have gone with PM3s if Kflex was out (which wasn't their fault) but I had a huge edge by being the first to go 56k in my area. Anyway, just take my comments at face value. Tom On Wednesday, August 27, 1997 8:02 PM, MegaZone [SMTP:megazone@livingston.com] wrote: > Once upon a time David Bolen shaped the electrons to say... > >> No, the option is to ask the WG chair to *assign* new values. > >And then wait until that process is complete? I think product cycle > >times won't always allow that. > > It takes like a day or two unless he's out. > > "Hey, can we have 7 for FUBAR? Here's the justification... *spew*" > Looks, it isn't used. Goes to the list "Any objections ot 7 being FUBAR?" > > If no one screams, that's it. > > I've watched it happen several times. > > >Exactly - you bring up my very point. The new values picked this week > >were in fact corrected because of the very fact that Ascend went this > >route of trying to use a standard attribute with a non-standard > > Right. They never talked to the chair, they just did it unilaterally. > *THAT* was wrong. > > >in use before being added to the value list. Luckily, no-one else was > >already using the proposed values in their original orientation or we > >would have had a clash between two operating NASs. > > And Ascend users would have been shafted. So they could yell at Ascend > for being dinks and not following proceedure. > > >functionality, as other server bases do support them (including I > >believe the current server available to Livingston customers, right?) > > Actually 2.0.1 does not do VSA - we've never needed it. I don't know if > 2.1 will bother with them either. Out next gen server does everything AFAIK. > > >I can tell you however, that I have in the past and will continue in > >the future to use functionality on my TC equipment that is not yet > >(nor may not be) supported by the standard in the time frame I need > > But the thing is - does USR ask for it to be in the standard? I read the > IETF-RADIUS list constantly, and I rarely see USR (or other vendors) trying > to propose their VSAs as standard. I think many vendors would rather just > use VSA and not bother even *trying* to make it standard. > > -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) Disconnect causes
From: David Bolen <db3l@ans.net>
Date: 1997-08-27 20:25:48

(Getting slightly off-topic of the TC itself, so skip if you want) MegaZone <megazone@livingston.com> writes: > It takes like a day or two unless he's out. > > "Hey, can we have 7 for FUBAR? Here's the justification... *spew*" > Looks, it isn't used. Goes to the list "Any objections ot 7 being FUBAR?" > > If no one screams, that's it. > > I've watched it happen several times. And I've seen very long discussions and negotations and issues raised with all sort of proposed changes go on as well. Often for months. This isn't an issue with the chair, but just a note that generating "rough concensus" on a mailing list for stuff like this takes time. Waiting for someone to scream and/or then discussing things isn't normally done in a day or two. > But the thing is - does USR ask for it to be in the standard? I read the > IETF-RADIUS list constantly, and I rarely see USR (or other vendors) trying > to propose their VSAs as standard. I think many vendors would rather just > use VSA and not bother even *trying* to make it standard. Well, that's specifically how "Prompt" showed up for example. Whether they ask for all others or not is unclear. Of course USR had to choose a non-VSA number for their earlier version of prompt and then the chair wouldn't use it for the official extension attribute (ok, so USR chose a bad value :-)), but... As for requesting other features, probably not as much as they should, but perhaps more than others. Certainly Pat Calhoun is a frequent, if sometimes less than diplomatic (Hi Pat!) contributor :-) I have also been a member of the ietf-radius list for years now, and I have to tell you while there is plenty of good discussion ongoing, there are also plenty of less than fruitful denials of reasonable requests for additions to either the standard or to the attributes or whatever. And if a suggestion is perceived to have slightly less than absolutely global appeal (e.g., if you ask for something that might only be reasonable in a smaller subset of configurations) you're in for a long battle. It was with mild amusement that I saw the comments from John in the recent IETF about a way to indicate that a server was working on a request to avoid too many duplicate NAS transmissions. I was involved in a suggestion for that back in '95 I believe (I think I was the first requester, but don't hold me to that) and was broadly shot down since perhaps only the largest networks with multi-second back-end processing might need something like that. Guess I should have waited for the next round of discussion two years later, eh? :-) I'm a big fan of the IETF process, but to be honest I'm also a big fan of having an "out" in a protocol like RADIUS that permits proprietary customizability while permitting the main standard to track more broad based features. I think it mixes well the forces present in the real commercial product world, and the desire to have a single consistent standard. And I certainly agree with you and would strongly suggest that all vendors try to get useful features into the official set of attributes, but would not restrict them from using VSAs until that can be done or for truly specialized functionality that might never gain broad enough appeal to be accepted into the standards. So, what was that accounting attribute again? :-) -- David

Subject: RE: (usr-tc) Disconnect causes
From: David Bolen <db3l@ans.net>
Date: 1997-08-27 20:34:07

Tom Bilan <tom@tdi.net> writes: > Some of us don't have the code for the version of Radius that we > depend on and therefore can add the extra parsing to determine > VSAs. I certainly sympathize, but would point out that any server you are using for which you don't have code (and thus presumably you purchased some sort of commercial copy) is not truly a fully functional RADIUS server unless it supports VSAs, since they are part of the RFC for RADIUS. So rather than pressuring USR to avoid VSAs (well, I guess we could do that too when unnecessary), I would pressure your vendor of your server to support the RFC in its entirety. > So you're saying that you would rather custom code to determine > the terminate code rather than have it inside the acctterminatecause > field? Well, given that I already went the custom code route rather than commerical (not that there were many available when I started), I guess the answer is yes, but the custom aspect was for more features than just VSAs - they kind of fell out in the wash since I was writing support for the RADIUS RFC. > I have a M.S. is CSE and it's not that I'm unable to write > my own version of radius but hey, I already work 80 hours a week. Ah, the good 'ol days of only 80 hours a week :-) Obviously this is an unfortunate issue - and even if you had source to your server you might just as well be time constrained and not able to adapt it. I guess there's no simple answer other than that hopefully in the not too distant future there will be more alternatives in the area of at least commercial (if not generally available) servers that support VSAs as well as standard attributes. But I still think that 3Com (and other vendors) should be able to make use of all aspects of the RADIUS protocol, including VSAs, in their products where it makes sense. -- 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) USR Announcements list
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1997-08-27 20:57:00

-> > Most of the time the latest code is posted to Total Service Website > -> http://totalservice.usr.com -> > -> > All release notes and code is there... -> -> Right, but given the fact that most of us have loads of machinery, OSes and -> such that all have upgrades, I agree that it is a very reasonable request -> that USR simply start a mailing list devoted to notification of new code -> releases. Nothing more. No questions, no support, etc... JUST for -> announcements. -> -> How many out there agree? -> -> WingNET System Administrator -> 423-559-LINK (v) -> 423-559-5444 (f) I agree. It might also help sell additional support agreements since we would have a better idea of what we were buying. Jeff

Subject: Re: (usr-tc) Disconnect causes
From: David Bolen <db3l@ans.net>
Date: 1997-08-28 00:25:19

MegaZone <megazone@livingston.com> writes: > Once upon a time David Bolen shaped the electrons to say... > >But I still think that 3Com (and other vendors) should be able to make > >use of all aspects of the RADIUS protocol, including VSAs, in their > >products where it makes sense. > > Wouldn't it be nice if they provided a matching SERVER though? Entirely agreed. But I thought they did - doesn't the 3Com provided server support their VSAs? (I have to admit lack of knowledge here since I've always had my own) Granted, the one I'm thinking of was for a Windows platform and thus might not be a good fit to many of us discussing this, but... -- 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) Disconnect causes
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1997-08-28 06:44:09

We do provide Radius server that supports our Vendor specific attributes. We also have given users modified livingston code that supports these attributes 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 Thu, 28 Aug 1997, David Bolen wrote: > MegaZone <megazone@livingston.com> writes: > > > Once upon a time David Bolen shaped the electrons to say... > > >But I still think that 3Com (and other vendors) should be able to make > > >use of all aspects of the RADIUS protocol, including VSAs, in their > > >products where it makes sense. > > > > Wouldn't it be nice if they provided a matching SERVER though? > > Entirely agreed. But I thought they did - doesn't the 3Com provided > server support their VSAs? (I have to admit lack of knowledge here > since I've always had my own) > > Granted, the one I'm thinking of was for a Windows platform and thus > might not be a good fit to many of us discussing this, but... > > -- 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) Interpreting traps
From: Michael Wronski <mwronski@coredump.ae.usr.com>
Date: 1997-08-28 09:08:42

At 06:16 PM 8/27/97 -0400, you wrote: >I've set up the CMU snmp utilities, including snmptrapd, on a machine >at my site, and directed traps from my racks toward it. However, >I'm not getting much good from such messages as > > Enterprise Specific Trap (58) Uptime: 3 days, 1:41:26 > Enterprise Specific Trap (58) Uptime: 20 days, 9:46:55 > Enterprise Specific Trap (13) Uptime: 8 days, 4:42:27 > Enterprise Specific Trap (7) Uptime: 8 days, 6:50:34 > Enterprise Specific Trap (29) Uptime: 3 days, 16:24:33 > I would suggest using UCD snmp.. (Modified CMU) that can dynamically load MIBS.. I run UCD and can get the fill trap def with all OID values.. The only setup trick is to provide the code with env vars that point to the USR mibs.. This is a sample of my verbose output.. 1997-08-20 15:08:13 host.foo.bar [1.1.1.1] enterprises.usr: Enterprise Specific Trap (78) Uptime: 2 days, 4:20:28 enterprises.usr.nas.nmc.nmcTrap.nmcTrapSequenceNumber.0 = 11651 enterprises.usr.nas.nmc.nmcStat.nmcStatEventId.0 = 11651 enterprises.usr.nas.nmc.nmcCfg.nmcGmtime.0 = 872107575 enterprises.usr.nas.chs.uchasSlot.uchasSlotTable.uchasSlotEntry.uchasSlotInd ex.1 = 1 enterprises.usr.nas.chs.uchasEntity.uchasEntityTable.uchasEntityEntry.uchasE ntityIndex.1 = 1 enterprises.usr.nas.dt1.dt1Stat.dt1StatTable.dt1StatEntry.dt1StatCallEventCo de.1 = usrDisconnect(5) enterprises.usr.nas.ids0.ids0StatTable.ids0StatEntry.ids0StatDs0Index.1 = 8 enterprises.usr.nas.mdm.mdmCs.mdmCsTable.mdmCsEntry.mdmCsCallRefNum.1 = 24269 enterprises.usr.nas.ids0.ids0StatTable.ids0StatEntry.ids0StatDevConnTo.1 = quadIModem(4) enterprises.usr.nas.ids0.ids0StatTable.ids0StatEntry.ids0StatSlotConnTo.1 = 6 enterprises.usr.nas.ids0.ids0StatTable.ids0StatEntry.ids0StatChanConnTo.1 = 4 enterprises.usr.nas.ids0.ids0StatTable.ids0StatEntry.ids0StatCallArrivalTime .1 = 872107083 enterprises.usr.nas.ids0.ids0StatTable.ids0StatEntry.ids0StatCallConnectTime .1 = 872107083 enterprises.usr.nas.ids0.ids0StatTable.ids0StatEntry.ids0StatCallTerminateTi me.1 = 872107610 enterprises.usr.nas.ids0.ids0StatTable.ids0StatEntry.ids0StatCallType.1 = analog(1) `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' 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) download status, quad modem LED's
From: Brian Elfert <brian@citilink.com>
Date: 1997-08-28 09:33:08

On Fri, 22 Aug 1997, James MacKenzie wrote: > On Fri, 22 Aug 1997, Michael Wronski wrote: > > > In BETA now. No release date is available. The PRI is in the modem NIC. So > > if you have 13 HiPer DSP's (24modem card) you will have a PRI cable behind > > each one of them. There is no need for the DUAL PRI or T1 card with this > > implementation. > > > > -M > > And this will still allow for ISDN connections? (Pardon me if this is a > stupid question). The info I got says that the HiPer DSP cards will handle both ISDN and analog calls internally. The info I have indicates that there are not 24 DSPs, but several larger ones that handle multiple calls. Brian

Subject: Re: (usr-tc) download status, quad modem LED's
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-08-28 16:07:39

Brian Elfert said once upon a time: >The info I got says that the HiPer DSP cards will handle both ISDN and >analog calls internally. The info I have indicates that there are not 24 >DSPs, but several larger ones that handle multiple calls. I wonder when we'll start to see that new TI DSP in use that can do something like a gazillion instructions a second?

Subject: Re: (usr-tc) Quake Questions..
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-08-28 16:24:56

Michael Wronski said once upon a time: > >Those of you that are still experiencing "quake lag." Please answer > >these questions in some e-mail to me and not this list: Sent. >Also, has anyone tried the console command "sys_ticrate 0.1"? In >the tech docs this is said to reduce the number of UDP packets >sent out by the server. The docs state that it will improve performance >for dial up users. This was in relation to Quake and has no bearing on QuakeWorld. In any case, it has no effect on the USR problem.

Subject: Re: (usr-tc) Disconnect causes
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-08-28 16:27:11

Tom Bilan said once upon a time: >I'm not anti-USR at all. I did pick their product after months of debating and >having Cisco reps and Ascend reps in my office constantly. I may have gone >with PM3s if Kflex was out (which wasn't their fault) but I had a huge edge >by being the first to go 56k in my area. Anyway, just take my comments at >face value. You mighht be interested to find out that a recent lab test judged X2 37% faster than Kflex. I had a URL around here somewhere...

Subject: (usr-tc) Quake Questions..
From: Michael Wronski <mwronski@coredump.ae.usr.com>
Date: 1997-08-28 16:52:44

Those of you that are still experiencing "quake lag." Please answer these questions in some e-mail to me and not this list: 1) What Netserver are you using (EPB non EPB)? 2) How much ram? 3) Software version? 4) Quake server and version? (Winquake,Quakeword) 5) Platform running quake server on?(Linux,Solaris,NT,etc) Also, has anyone tried the console command "sys_ticrate 0.1"? In the tech docs this is said to reduce the number of UDP packets sent out by the server. The docs state that it will improve performance for dial up users. A quote from the tech notes: >>>> <excerpt>sys_ticrate Only used by dedicated servers. This determines the rate at which the server will send out updates to the clients. The default value is 0.05 (20 updatesper second). For servers where bandwidth is limited, using modems or the internet for example, it is advisable to lower this value to 0.1 (10 updates per second). This will have a very minor effect on responsiveness, but will half to outbound bandwitdh required making the modem players a lot happier. </excerpt><<<<<<<< Thanks in advance. -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) Disconnect causes
From: MegaZone <megazone@livingston.com>
Date: 1997-08-28 17:10:53

Once upon a time Pete Ashdown shaped the electrons to say... >You mighht be interested to find out that a recent lab test judged X2 37% >faster than Kflex. I had a URL around here somewhere... Was it K56flex - or was it the stuff Ascend was shipping? (Big difference.) -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) Quake Questions..
From: Brian <signal@shreve.net>
Date: 1997-08-28 18:35:44

On Thu, 28 Aug 1997, Michael Wronski wrote: > Those of you that are still experiencing "quake lag." Please answer > > these questions in some e-mail to me and not this list: > > > 1) What Netserver are you using (EPB non EPB)? > non EPB 3.5.93 > 2) How much ram? > 16MB > 3) Software version? 3.5.93 > > 4) Quake server and version? (Winquake,Quakeword) > latest from idsoftware.com 1.01, Dedicated server > 5) Platform running quake server on?(Linux,Solaris,NT,etc) > linux > > Also, has anyone tried the console command "sys_ticrate 0.1"? In of course. This is NOT software related. I am telling you, some very intelligent admins who know alot about Quake and alot about USR TC hubs have been having problems. My definitive test? I can dial in on a portmaster and not have the problem, dial into a sportster and not have a problem, its only when going through a TC hub.......the problem is EXTREMELY replicatable on just about anyones TC hub, this should be a easy one. 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: Re: (usr-tc) Disconnect causes
From: David Bolen <db3l@ans.net>
Date: 1997-08-28 20:23:36

MegaZone <megazone@livingston.com> writes: > Was it K56flex - or was it the stuff Ascend was shipping? > > (Big difference.) If I'm recalling the same tests as Pete, they were done before any implementation of K56flex actually existed (regardless of what marketing hype was out there, the first go round was the original K56plus or V.flex2 depending on where you got your chipset), and I do think they used mismatched client/server modems, which is perhaps partially why the x2 modems did so much better. From what I can tell later tests are showing the two to be quite a bit closer than that (although x2 normally still gets the edge). Of course, neither camp is standing still presumably in their own developments while the ITU work proceeds, so it will be interesting to see how both x2 and K56 improve in the coming months prior to an official standard. -- 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: (usr-tc) PLEASE HELP ME!
From: steph@emarkt.com
Date: 1997-08-28 23:49:16

I have to take this opportunity to thank Mike for his opinion on my "voice over data problem." I needed to "filter out" automated voice messages from a regular phoneline, in order to get a continuous PPP connection to the Internet. Does anyone have their own views on the subject? Mike told me to: > S10 register to a higher number.. This works for things like call > waiting.. Set it to 255.. Someone told me that a phoneline can take a very high level of watts, and so in theory you could change the wattage on the line using a special hardware device, rendering ALL speech inactive, and allowing continuous data transfer. Does this make sense to you? Mike said: > No. It would not be feasible to separate the voice and data sine they > occupy the same audible freq range.. I thought they didn't. Would it vary from country to country? I live in the UK, and am no way as technically gifted as you guys :) Thanks for your help, Stephann Makri ################################## Steph@emarkt.com ################################## S t e p h @ e m a r k t . c o m ##################################

Subject: RE: (usr-tc) Quake Questions..
From: Tom Bilan <tom@tdi.net>
Date: 1997-08-29 10:24:19

I have the exact same config as Brian and have had a quake server up and running over 6 months BEFORE I had the USR chassis and it used to run great! I run QuakeWorld 2.01 which is about 10days old. 3.5.93 was supposed to help but I just got this message from a sassy mouth 14 year old today. I get 2-3 of these every day... "Well as usual TDI disconnected me while I am playing Quake. Probably because TDI is terrible and you use X2, the worst possible thing for analog modems. Maybe if you used Kflex like all the GOOD modems do instead of using that horrible garbage that USR uses then maybe I could get a good ping, but I suppose that is totally out of the question. The more lag we have the more we want ISDN I guess. Well if this keeps up then I am just going to have to find a different ISP/" What am I supposed to say back to him? Yeah I know I spent $100,000 on this equipment and sorry it works like shit for Quake. ? Tom On Thursday, August 28, 1997 7:36 PM, Brian [SMTP:signal@shreve.net] wrote: > On Thu, 28 Aug 1997, Michael Wronski wrote: > > > Those of you that are still experiencing "quake lag." Please answer > > > > these questions in some e-mail to me and not this list: > > > > > > 1) What Netserver are you using (EPB non EPB)? > > > > non EPB 3.5.93 > > > 2) How much ram? > > > > 16MB > > > 3) Software version? > > 3.5.93 > > > > > 4) Quake server and version? (Winquake,Quakeword) > > > > latest from idsoftware.com 1.01, Dedicated server > > > 5) Platform running quake server on?(Linux,Solaris,NT,etc) > > > > > linux > > > > > Also, has anyone tried the console command "sys_ticrate 0.1"? In > > of course. > > > This is NOT software related. I am telling you, some very intelligent > admins who know alot about Quake and alot about USR TC hubs have been > having problems. > > My definitive test? I can dial in on a portmaster and not have the > problem, dial into a sportster and not have a problem, its only when g oing > through a TC hub.......the problem is EXTREMELY replicatable on just about > anyones TC hub, this should be a easy one. > > 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: Re: (usr-tc) Quake Questions..
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-08-29 11:41:19

Tom Bilan said once upon a time: >"Well as usual TDI disconnected me while I am playing Quake. Probably >because TDI is terrible and you use X2, the worst possible thing for analog >modems. Maybe if you used Kflex like all the GOOD modems do instead of >using that horrible garbage that USR uses then maybe I could get a good >ping, Found that review comparing Kflex and X2! http://techweb.cmp.com/hpc/aug97/38MDM01.HTM > but I suppose that is totally out of the question. The more lag we >have the more we want ISDN I guess. Well if this keeps up then I am just >going to have to find a different ISP/" He should want ISDN anyway if he knew anything about anything. >What am I supposed to say back to him? Yeah I know I spent $100,000 on >this equipment and sorry it works like shit for Quake. ? A client once told me about arguing with customers is like teaching a pig to sing. It is pointless and it only pisses off the pig. I have a similar situation with a customer who doesn't know his UDP from his TCP. I've had him run several tests with Netperf: http://www.cup.hp.com/netperf/NetperfPage.html This keeps him busy and educates him more about the difficulties in isolating this problem. Also, everything I've heard from Quake players here is that things are much worse when it comes to ISPs using Livingston. The only thing we've found that is immune to the problem is Xylogics.

Subject: RE: (usr-tc) Quake Questions..
From: Brian <signal@shreve.net>
Date: 1997-08-29 12:53:44

On Fri, 29 Aug 1997, Tom Bilan wrote: > I have the exact same config as Brian and have had a quake server > up and running over 6 months BEFORE I had the USR chassis and > it used to run great! > > I run QuakeWorld 2.01 which is about 10days old. > > 3.5.93 was supposed to help but I just got this message from a sassy > mouth 14 year old today. I get 2-3 of these every day... > > "Well as usual TDI disconnected me while I am playing Quake. Probably > because TDI is terrible and you use X2, the worst possible thing for analog > modems. Maybe if you used Kflex like all the GOOD modems do instead of > using that horrible garbage that USR uses then maybe I could get a good > ping, but I suppose that is totally out of the question. The more lag we > have the more we want ISDN I guess. Well if this keeps up then I am just > going to have to find a different ISP/" > > What am I supposed to say back to him? Yeah I know I spent $100,000 on > this equipment and sorry it works like shit for Quake. ? Its amazing, I actually get customers sending me these types of emails alot lately too. Mainly Quake players etc. I don't get them ragging on x2, although I think it may be part of the problem. Alot of times with x2, we see 21k transmit, and like 43-48k receive. For Quake, a real time application, this sucks. Its better to disable x2 if you get a connect like that, and connect at v34 28k transmit and receive. Local users, playing thru the hub over ethernet to the server, should get ping times between 130-200, this is not the cause, it fluctuates, and has this rising effect of 200-1000+. It's unplayable. I bet it messes with all udp apps as well. Brian > > Tom > > On Thursday, August 28, 1997 7:36 PM, Brian [SMTP:signal@shreve.net] wrote: > > On Thu, 28 Aug 1997, Michael Wronski wrote: > > > > > Those of you that are still experiencing "quake lag." Please answer > > > > > > these questions in some e-mail to me and not this list: > > > > > > > > > 1) What Netserver are you using (EPB non EPB)? > > > > > > > non EPB 3.5.93 > > > > > 2) How much ram? > > > > > > > 16MB > > > > > 3) Software version? > > > > 3.5.93 > > > > > > > > 4) Quake server and version? (Winquake,Quakeword) > > > > > > > latest from idsoftware.com 1.01, Dedicated server > > > > > 5) Platform running quake server on?(Linux,Solaris,NT,etc) > > > > > > > > > linux > > > > > > > > Also, has anyone tried the console command "sys_ticrate 0.1"? In > > > > of course. > > > > > > This is NOT software related. I am telling you, some very intelligent > > admins who know alot about Quake and alot about USR TC hubs have been > > having problems. > > > > My definitive test? I can dial in on a portmaster and not have the > > problem, dial into a sportster and not have a problem, its only when g > oing > > through a TC hub.......the problem is EXTREMELY replicatable on just > about > > anyones TC hub, this should be a easy one. > > > > 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 ------------------------ > -----/ > > > > > /-------------------------- 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) Possible Quake solution
From: Pete Ashdown <pashdown@xmission.com>
Date: 1997-08-29 13:02:15

This doesn't fix the people having problems who aren't using X2, but this is from one of our subscribers: >Just figured this out. With all the hype going on about the new TC rack >software, I was still getting 999 pings from 990-0900. (I have an >x2-enabled Courier 20mhz). I forced my Courier to something like 39k or >41k by using &N20 as part of my dialing string. (I normally get 48k or >50.3k connect rates). This set the maximum link rate, and my modem >never re-trained, neither did the ARQ light flash. I finally saw better >performance on x2 than on the 539-0900! 130ms pings, and I haven't even >tried 43 or 45k connect rates yet. Sweeeeet!

Subject: (usr-tc) What's the advantage to setting "Reported Address".
From: Jaye Mathisen <mrcpu@cdsnet.net>
Date: 1997-08-29 13:38:32

I've never had to use it that I can see.

Subject: (usr-tc) MTU settings
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1997-08-29 14:50:45

Has anyone played with the MTU settings on netservers? I changed the setting in DUN to 576 (via regedit) and our web page (pretty simple test overall) seemed to load *much* faster (1/4 the time?) as it did with the default 1500. My co-admin found a place (I think) where it said that an MTU value from RADIUS is considered a suggestion to the netserver, but that it doesn't aggressively negotiate for its MTU setting and will allow the remote system to override it (back up to the default 1500). We're looking for a good way to get the MTU set for our customers to 576. Anyone know of a good way to do that? -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) Splitting the configuration of the trunk settings
From: Cindy Smith <cindyo@ktc.com>
Date: 1997-08-29 15:03:29

In need to split the configuration of a trunk group. For example, I need to be able to set up 13 channels for the group to have a Dial-In/Dial-out trunk signal start use Dial Tone and 11 channels use wink. I also need to split between loopStart and eAndMTypeII under the Dial-in/Dial-out Trunk Type. Is this possible? The reason for this is an emergency situation. I have a TC down and the parts are lost in UPS hell someplace. This will get part of my lines up again until I get the parts. Thanks in advance, -Cindy Smith -KTC I-Net

Subject: Re: (usr-tc) What's the advantage to setting "Reported
From: Michael Wronski <mwronski@coredump.ae.usr.com>
Date: 1997-08-29 17:35:58

At 01:38 PM 8/29/97 -0700, you wrote: > > >I've never had to use it that I can see. > It has to do with hosts that expect your users to all come from the same place or an auth server that expects the same.. You can have many racks and many IP's for the netservers, but the host you connect to will be given the same IP address.. This, of course, only applies to non-PPP sessions and is a one way spoof.. If you ping that reported address, only the node that acctually has that address will respond. -M

Subject: Re: (usr-tc) Quake Questions..
From: MegaZone <megazone@livingston.com>
Date: 1997-08-29 18:27:49

Once upon a time Pete Ashdown shaped the electrons to say... >Found that review comparing Kflex and X2! > http://techweb.cmp.com/hpc/aug97/38MDM01.HTM Last modified July 31st - BEFORE K56flex started shipping. (What Rockwell shipped before then should never have been called K56Flex as it did not meet the *requirements* to carry that name. It was basically K56Plus.) A number of people have reported Quake *rocks* over a PM-3 with the new Lucent modems. Latency is very low. And even better performance comes if they have a Stac HW compression card. Turn of V.42bis in the client modem, let Win95 do Stac, and latency is down to 100. And throughput is up. >He should want ISDN anyway if he knew anything about anything. A lot of people *want* ISDN - is it financially feasible in that area? >Also, everything I've heard from Quake players here is that things are much >worse when it comes to ISPs using Livingston. The only thing we've found Running with the old modems latency was too high for some tastes. But I've not seen any other setup with latency as low as the PM-3 with new cards. Definitely not when using the Stac option. The gamers I know using that setup are drooling over it. -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) MTU settings
From: MegaZone <megazone@livingston.com>
Date: 1997-08-29 18:29:53

Once upon a time Jeff Mcadams shaped the electrons to say... >default 1500. My co-admin found a place (I think) where it said that an >MTU value from RADIUS is considered a suggestion to the netserver, but >that it doesn't aggressively negotiate for its MTU setting and will >allow the remote system to override it (back up to the default 1500). If the user is using PAP/CHAP then the RADIUS setting is basically worthless. MTU is negotiated BEFORE PAP/CHAP is done. So by the time the NAS learns the setting from RADIUS, it is far too late - negotiation is over and done. This is the way PPP works, for ANY NAS. Now, if the user is using a chat script, auth is done first, and the NAS has the info before PPP starts. But really, who does that these days? -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) MTU settings
From: MegaZone <megazone@livingston.com>
Date: 1997-08-29 19:15:00

Once upon a time David Bolen shaped the electrons to say... >Either of these options would certainly make the RADIUS setting >something other than worthless. Ok - not compeletely worthless. But most of the issues that get solved by changing MTU are solved by changing the *clients* MTU (or MRU on the NAS). -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) MTU settings
From: David Bolen <db3l@ans.net>
Date: 1997-08-29 21:51:24

MegaZone <megazone@livingston.com> writes: > If the user is using PAP/CHAP then the RADIUS setting is basically worthless. I'm not sure I agree. > MTU is negotiated BEFORE PAP/CHAP is done. So by the time the NAS learns > the setting from RADIUS, it is far too late - negotiation is over and done. > This is the way PPP works, for ANY NAS. Well, yes, the MRU LCP negotation takes place in order to get LCP up and before the authentication phase, but while it's been a while since I read the RFCs, I was under the impression that receipt of an LCP configuration request while in the authentication phase restarted the automaton for LCP and allowed re-negotiation of options. (I'm not sure if the same holds true after NCPs are up or not) But since at that point you haven't yet opened any NCPs while authenticating, I would think it would be very easy for any NAS to simply re-option the MRU via standard LCP re-negotiation if the value received from RADIUS was other than what it negotiated in the first place. Even if that wasn't possible, since technically the result from RADIUS represents an MTU for the NAS, as long as the returned value from RADIUS was less than the MRU negotiated with the client, the NAS doesn't really even have to renegotiate in order to obey the RADIUS setting. By definition the MRU is maximum, but not required, so the NAS is free to limit itself to the smaller RADIUS value even though the client had indicated a larger MRU. Either of these options would certainly make the RADIUS setting something other than worthless. > Now, if the user is using a chat script, auth is done first, and the NAS > has the info before PPP starts. But really, who does that these days? You might be surprised - still quite a few things (particularly custom applications) that are scripted out there... -- 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: (usr-tc) OVERWHELMING REPLIES
From: steph@emarkt.com
Date: 1997-08-29 22:21:51

As you may have guessed, I have had overwhelming numbers of replies to my question yesterday about filtering voice from a phoneline. Thanks to everyone who didn't reply, which seems to be . . . . . . well . . . all of you! <BG> Please try to spare a single minute to help someone less experienced than yourself. Mike did, and I thank him again! ################################## Steph@emarkt.com ################################## S t e p h @ e m a r k t . c o m ##################################

Subject: Re: (usr-tc) Disconnect causes
From: MegaZone <megazone@livingston.com>
Date: 1997-08-30 02:16:18

Once upon a time Robert Sanders shaped the electrons to say... >results. For example, moving Choicenet's filter selection out of the >RADIUS authentication phase and into some apparently new and ChoiceNet does things RADIUS *cannot*. The dynamic filter lists would not be possible with the RADIUS protocol. ChoiceNet does more than just spit out static filters, it can do some of the computing for the NAS interpreting dynamically expanded lists. It required a new system. Though personally I do wish we'd release the source code, and/or propose ChoiceNet as a standard like we did with RADIUS. It was a marketing decision to use it as a competitive advantage and not make it open. >server designs. So, should I a) use VSAs for it, b) wait until the >committee process can design a Call-Arrival-Coordinates parameter >general enough to express a call's position within the general N-space Make it s string like Connect-Info. Heck, maybe they could put it at the end of Connect-Info. -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) Disconnect causes
From: Robert Sanders <rsanders@mindspring.net>
Date: 1997-08-30 02:35:43

MegaZone <megazone@livingston.com> writes: > Wouldn't it be nice if they provided a matching SERVER though? http://www.usr.com/business/30419.html regards, -- Robert

Subject: Re: (usr-tc) Disconnect causes
From: Robert Sanders <rsanders@mindspring.net>
Date: 1997-08-30 02:53:22

MegaZone <megazone@livingston.com> writes: > To date Livingston has never used a VSA, and our engineering is committed > to not using them at all costs. If it is really that important, it belongs > in the standard and we'll bring it to the WG. That sounds like a reasonable goal, but I have to question the results. For example, moving Choicenet's filter selection out of the RADIUS authentication phase and into some apparently new and undocumented protocol is an annoyance to those of us (well, maybe just me) who'd like to support dynamic filters in their remaining Livingston gear. I have to agree with the others who said that standardization can slow down and obfuscate what should be a simple process. My USR chassis wants to tell me which slot, span, and channel a call arrived on. That information may be meaningless for the majority of other terminal server designs. So, should I a) use VSAs for it, b) wait until the committee process can design a Call-Arrival-Coordinates parameter general enough to express a call's position within the general N-space of all past, present, and future NAS architectures or c) give up all hope of learning that information? "At all costs" is a strong phrase. VSAs are an imperfect tool in an imperfect world. Sometimes I'd rather just get the job done than worry too much about aesthetic correctness. regards, -- Robert

Subject: Re: (usr-tc) MTU settings
From: Brian <signal@shreve.net>
Date: 1997-08-30 08:11:53

On Fri, 29 Aug 1997, Jeff Mcadams wrote: > Has anyone played with the MTU settings on netservers? I changed the > setting in DUN to 576 (via regedit) and our web page (pretty simple test > overall) seemed to load *much* faster (1/4 the time?) as it did with the > default 1500. My co-admin found a place (I think) where it said that an > MTU value from RADIUS is considered a suggestion to the netserver, but > that it doesn't aggressively negotiate for its MTU setting and will > allow the remote system to override it (back up to the default 1500). I use RADIUS, but as you said, RADIUS won't force it. I use 576, I find shell sessions to be much more responsive. Also real time applications such as Quake benefit, since the packets are forwarded quicker, and the quicker, the closer to real time we get. Brian > > We're looking for a good way to get the MTU set for our customers to > 576. Anyone know of a good way to do that? > -- > 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) MTU settings
From: Brian <signal@shreve.net>
Date: 1997-08-30 08:11:53

Subject: Re: (usr-tc) MTU settings
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1997-08-30 09:47:24

Thus spake MegaZone >Once upon a time Jeff Mcadams shaped the electrons to say... >>default 1500. My co-admin found a place (I think) where it said that an >>MTU value from RADIUS is considered a suggestion to the netserver, but >>that it doesn't aggressively negotiate for its MTU setting and will >>allow the remote system to override it (back up to the default 1500). >If the user is using PAP/CHAP then the RADIUS setting is basically worthless. >MTU is negotiated BEFORE PAP/CHAP is done. So by the time the NAS learns >the setting from RADIUS, it is far too late - negotiation is over and done. >This is the way PPP works, for ANY NAS. Oh blah...now I remember you saying that on portmaster-users when I was on there. :/ >Now, if the user is using a chat script, auth is done first, and the NAS >has the info before PPP starts. But really, who does that these days? Yeah, no chat script here...we could do that for some of our older customers, but seeing as we're trying to switch everyone to PAP login... :/ Any other bright ideas forgetting an MTU setting since RADIUS won't work for it? -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) AcctTerminate causes
From: Brian Elfert <brian@citilink.com>
Date: 1997-08-30 10:16:33

On Wed, 27 Aug 1997, Tom Bilan wrote: > I take it all back (almost) :) > > I installed 3.5.93 on one of my ENHs and whilst anxiously awaiting all > day for it to lock up the ethernet port I found that 3.5.93 is now using > real Radius Terminate non-VSA codes! 3.5.34 also has real RADIUS terminate codes. It makes debugging so much easier. Brian

Subject: RE: (usr-tc) Quake Questions..
From: Tom Bilan <tom@tdi.net>
Date: 1997-08-30 11:51:57

> > He should want ISDN anyway if he knew anything about anything. He's only 14 so I don't think he'll be able to afford it :) [snip] > > Also, everything I've heard from Quake players here is that things are much > worse when it comes to ISPs using Livingston. The only thing we've found > that is immune to the problem is Xylogics. I had an 2-Annex-3 64 port units (still do if anyone wants them real cheap) and quake just flew on them. I'm actually considering adding 5 lines just for quake junkies to get them off my butt. -Tom

Subject: RE: (usr-tc) Quake Questions..
From: Tom Bilan <tom@tdi.net>
Date: 1997-08-30 11:53:19

bingo. I have actually seen x2 people on a clean 95 install run at 130-140ms ping on quake and that is like glass. Tom On Friday, August 29, 1997 1:54 PM, Brian [SMTP:signal@shreve.net] wrote: > On Fri, 29 Aug 1997, Tom Bilan wrote: > > > I have the exact same config as Brian and have had a quake server > > up and running over 6 months BEFORE I had the USR chassis and > > it used to run great! > > > > I run QuakeWorld 2.01 which is about 10days old. > > > > 3.5.93 was supposed to help but I just got this message from a sassy > > mouth 14 year old today. I get 2-3 of these every day... > > > > "Well as usual TDI disconnected me while I am playing Quake. Probably > > because TDI is terrible and you use X2, the worst possible thing for analog > > modems. Maybe if you used Kflex like all the GOOD modems do instead of > > using that horrible garbage that USR uses then maybe I could get a good > > ping, but I suppose that is totally out of the question. The more lag we > > have the more we want ISDN I guess. Well if this keeps up then I am just > > going to have to find a different ISP/" > > > > What am I supposed to say back to him? Yeah I know I spent $100,000 on > > this equipment and sorry it works like shit for Quake. ? > > > Its amazing, I actually get customers sending me these types of emails > alot lately too. Mainly Quake players etc. I don't get them ragging on > x2, although I think it may be part of the problem. > > Alot of times with x2, we see 21k transmit, and like 43-48k receive. For > Quake, a real time application, this sucks. Its better to disable x2 if > you get a connect like that, and connect at v34 28k transmit and receive. > > Local users, playing thru the hub over ethernet to the server, should get > ping times between 130-200, this is not the cause, it fluctuates, and has > this rising effect of 200-1000+. It's unplayable. I bet it messes with > all udp apps as well. > > Brian > > > > > > > > > >

Subject: (usr-tc) initialization strings on x2 modems
From: John Arden <jarden@server.delrio.com>
Date: 1997-08-30 12:43:34

Does anyone have a url for the courier & sportster x2 modem initialization strings? I have had quite a few customers go the upgrade route on their modems and I have seemed to miss this information on usr's page. Thanks, jarden@mail.delrio.com

Subject: Re: (usr-tc) Disconnect causes
From: Robert Sanders <rsanders@mindspring.net>
Date: 1997-08-30 13:00:35

MegaZone <megazone@livingston.com> writes: > ChoiceNet does things RADIUS *cannot*. The dynamic filter lists would > not be possible with the RADIUS protocol. ChoiceNet does more than just > spit out static filters, it can do some of the computing for the NAS > interpreting dynamically expanded lists. Our RADIUS server dynamically creates filters from locally held policy, static user parameters, and information contained in the RADIUS auth-req. I don't see why that necessitates a new protocol. What computation happens to produce the information exchanged via RADIUS is not specified by the protocol. Transliterating static a/v pairs from a users file is *not* the only way to generate RADIUS auth-acks. [I think Livingston needs to realize that it's trying to sell PM-3s, not ChoiceNet software, but I won't take us that far off topic.] > >server designs. So, should I a) use VSAs for it, b) wait until the > >committee process can design a Call-Arrival-Coordinates parameter > >general enough to express a call's position within the general N-space > > Make it s string like Connect-Info. Pardon my stubbornness, but you prefer vendor-specific string value interpretations to more rigorously defined and type expressive vendor-specific attribute definitions? Ick. But I think Connect-Info is unforgivably gross and a cop-out to boot, so I'm biased. Why not fold all the Acct-{Input,Output}-{Octets,Packets} attributes into an amorphous string called Acct-Traffic-Info? And Called-Station-Id & Calling-Station-Id into Phone-Number-Stuff? And Framed-Protocol, Framed-IP-Address, Framed-IP-Netmask, and Framed-MTU into Big-Bunch-O-Packet-Parameters? We could really preserve that precious attribute space if we just specified one omnibus attribute for auth-reqs, which is Question, and one attribute for auth-acks, which is Answer. The specification and parsing is left as an exercise for the user. :-) regards, -- Robert

Subject: Re: (usr-tc) Disconnect causes
From: Robert Sanders <rsanders@mindspring.net>
Date: 1997-08-30 13:18:52

Robert Sanders <rsanders@mindspring.net> writes: > MegaZone <megazone@livingston.com> writes: > > > ChoiceNet does things RADIUS *cannot*. The dynamic filter lists would > > not be possible with the RADIUS protocol. ChoiceNet does more than just > > spit out static filters, it can do some of the computing for the NAS > > interpreting dynamically expanded lists. It occurs to me that I may be missing the point. Are you saying that ChoiceNet does this computation at the beginning of the user session to produce a complete, expanded filter from various local data, or that it faults in new filter rules on demand *throughout* the user session? The white paper is rather vague. There are over 2700 allowed sites in the distributed "yahooligans" list, which would make a rather unwieldy filter if completely expanded at connect time. One final note on ChoiceNet, and then I promise I'll really stick to the list charter. Isn't Livingston worried that the prevalence of shared server hosting and the imminent stampede to Host-header-based virtualizing will render filtering on IP addresses an insufficient mechanism for restricting access to websites? regards, -- Robert

Subject: RE: (usr-tc) Quake Questions..
From: Bob Purdon <bobp@southcom.com.au>
Date: 1997-08-30 14:48:29

> I run QuakeWorld 2.01 which is about 10days old. Ditto. > "Well as usual TDI disconnected me while I am playing Quake. We've never had anyone disconnected while playing Quake (well, not *because* they were playing Quake). > What am I supposed to say back to him? Yeah I know I spent $100,000 on > this equipment and sorry it works like shit for Quake. ? We've not seen anything as severe as what people here seem to be reporting, although we have seen intermittent problems. We're running 3.5.33. Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Subject: (usr-tc) USR X2
From: steph@emarkt.com
Date: 1997-08-30 22:02:44

Have you seen the supposed USR software upgrade for Sportster users on the Internet? This file, USRUPG.EXE or somthing searches for the modem but "fails handshake". Is this just an illegal warez release, or is it a legit X2 upgrade? Don't you need some new hardware for a X2 upgrade anyway? ################################## Steph@emarkt.com ################################## S t e p h @ e m a r k t . c o m ##################################

Subject: (usr-tc) Shall I go?
From: steph@emarkt.com
Date: 1997-08-30 22:02:46

No one seems to answer my mails, so shall I go to another mailing list? Does anyone know of any that discuss telecoms in general? ################################## Steph@emarkt.com ################################## S t e p h @ e m a r k t . c o m ##################################

Subject: (usr-tc) USR X2
From: steph@emarkt.com
Date: 1997-08-30 22:02:47

Subject: (usr-tc) Shall I go?
From: steph@emarkt.com
Date: 1997-08-30 22:02:49

Subject: Re: (usr-tc) Disconnect causes
From: MegaZone <megazone@livingston.com>
Date: 1997-08-31 02:22:25

Once upon a time Robert Sanders shaped the electrons to say... >Our RADIUS server dynamically creates filters from locally held >policy, static user parameters, and information contained in the >RADIUS auth-req. I don't see why that necessitates a new protocol. Which still doesn't do all of what ChoiceNet does. It is NOT a one time "here's a filter" thing. Doing complex filter list computation, et al, does NOT belong in a RADIUS server. RADIUS has been kept simple quite deliberately. And bouncing UDP back and forth is not the best way to handle an interactive session (ChoiceNet is TCP). If it were a simple dumb filter server, sure, you could go it with something like RADIUS. Generating responses dynamically on the server is far from earth shattering, it is not hard to do. But that's not all it does. >[I think Livingston needs to realize that it's trying to sell PM-3s, > not ChoiceNet software, but I won't take us that far off topic.] We don't sell ChoiceNet, it is free to any HW user. In order to get ChoiceNet you have to use Livingston HW. That's deliberate, and we've sold a number of units to users because we have ChoiceNet and other vendors don't. That's what competition is about. >vendor-specific attribute definitions? Ick. But I think Connect-Info >is unforgivably gross and a cop-out to boot, so I'm biased. Why not >fold all the Acct-{Input,Output}-{Octets,Packets} attributes into an >amorphous string called Acct-Traffic-Info? And Called-Station-Id & Connect-Info is not 'amorphous': String The String field is encoded as a ASCII characters with the connection speed at the beginning of the string. For example, "28800 V42BIS/LAPM" -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) Disconnect causes
From: MegaZone <megazone@livingston.com>
Date: 1997-08-31 02:29:18

Once upon a time Robert Sanders shaped the electrons to say... >to produce a complete, expanded filter from various local data, or >that it faults in new filter rules on demand *throughout* the user >session? The white paper is rather vague. There are over 2700 Throughout the session. It can send a simple static filter, and that is a one time thing. But it lists are used, it is a dynamic arrangement where the server and the NAS work together during the users session. >allowed sites in the distributed "yahooligans" list, which would make >a rather unwieldy filter if completely expanded at connect time. Exactly. >the list charter. Isn't Livingston worried that the prevalence of >shared server hosting and the imminent stampede to Host-header-based >virtualizing will render filtering on IP addresses an insufficient >mechanism for restricting access to websites? Personally I think filtering Websites based on IP is rock stupid, and I always have. But the marketing folks at Yahoo and here think it is fine since it is more a 'permit the good, block the rest' situation. If someone tried to just block 'bad' sites it'd never work - proving a negative is impossible. You'd never be sure to block all 'bad' sites. With the current system, if a 'good' site and a 'bad' site coexist at an IP, BOTH would have to be blocked. The only way to change that would be a system whereby the filters actually examined HTTP packets for a Host: header. And THAT is more properly handled by a proxy server. I wouldn't want to see that done in a NAS. On another note - I've been running websites and involved with the field since 1991. I don't think there will be a 'stampese' to Host: header use. Too many broken implementations out there now. It'll take a while for it all to filter out and to finally have it all working well. I still run into virtual sites that I'fall through' to the base site on. There is a learning curve for server admins and developers both. But in the long run it is smarter than assigning multiple IPs to a server to host multiple sites. -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

Messages